diff --git a/docs/intro/how-lava-work.md b/docs/intro/how-lava-work.md
index ee1e9ab..ae796d2 100644
--- a/docs/intro/how-lava-work.md
+++ b/docs/intro/how-lava-work.md
@@ -24,7 +24,7 @@ RPC execution in Lava Network follows a request → relay → proof → settleme
 
 1. **Request initiation** – Consumers (wallets, dApps, indexers, AI agents) request blockchain data or transaction submission via supported APIs. They access Lava RPC API through different interfaces (Gateway, Public Endpoints, or Smart Router), but under the hood, all connect to the same Lava Protocol.
 
-2. **RPC Node Provider selection** – Consumers are matched to RPC Node Providers using PairingLists (see below). These lists ensure a pool of eligible Providers that meet latency, stake, and compliance requirements.
+2. **RPC Node Provider selection** – Consumers are matched to RPC Node Providers using pairing lists (see below). These lists ensure a pool of eligible Providers that meet latency, stake, and compliance requirements.
 
 3. **Off-chain relay** – The consumer establishes a direct peer-to-peer connection with a chosen RPC Node Provider. The Provider executes the RPC call against its full node infrastructure and returns the result.
 
@@ -51,30 +51,66 @@ Specifications can be added, updated, or extended via on-chain governance, allow
 
 ## Pairing
 
-Lava Network connects consumers to RPC Node Providers using **PairingLists**: algorithmically generated sets of RPC Node Providers optimized for performance and reliability.
+Lava Network connects consumers to RPC Node Providers using **pairing lists**: algorithmically generated sets of RPC Node Providers optimized for performance and reliability.
 
 ### How Pairing Works
 
-1. **Pairing request** – A consumer sends a GetPairing query to the Lava blockchain (via any Lava RPC Node Provider).
+1. **Pairing request** 
+    
+    A consumer sends a GetPairing query to the Lava blockchain (via any Lava RPC Node Provider).
 
-2. **Eligibility check** – RPC Node Providers must have staked LAVA, be in good standing (not jailed), and support the required specification and add-ons.
+2. **Eligibility check** 
 
-3. **Filtering** – RPC Node Providers are filtered based on consumer-defined policies (e.g., preferred geolocation or project allowlists).
+    RPC Node Providers must have staked LAVA, be in good standing (not jailed), and support the required specification and add-ons.
 
-4. **Randomization** – Eligible RPC Node Providers are pseudorandomly shuffled using a consumer-specific seed derived from the blockchain state.
+3. **Filtering** 
+    
+    RPC Node Providers are filtered based on consumer-defined policies like:
+    - Spec compatibility (chain + API support)
+    - Request type (e.g., archival support)
+    - Active status & pairing eligibility
+    - Other protocol-level filters
 
-5. **Scoring** – RPC Node Providers are weighted by stake and continuously measured Quality of Service (QoS) metrics (latency, availability, freshness).
+4. **Randomization** 
+    
+    Eligible RPC Node Providers are pseudorandomly shuffled using a consumer-specific seed derived from the blockchain state.
 
-6. **PairingList delivery** – The resulting list is valid for one epoch and used by the consumer to establish connections.
+5. **Scoring (Weighted Random Selection)** 
+    
+    Each eligible Provider receives a composite score between 0 and 1. The score combines four weighted components:
 
-### Consumer - Provider Interaction
+    | Metric| Description| 
+    |-------|-------|
+    | Availability      | % of successful responses over time (higher is better)  |
+    | Latency           | Request - response time (lower is better) |
+    | Sync / Freshness  | How up-to-date the node is (lower lag is better) |
+    | Stake | Relative stake weight   |
 
-- Consumers establish peer-to-peer connections with the most optimal RPC Node Provider from their PairingList.
-- Requests are sent, and responses are received through this RPC Node Provider.
-- At the end of each epoch, RPC Node Providers accumulate compute units (CUs) based on serviced demand.
-- Monthly, RPC Node Providers claim rewards proportional to their CU usage and subscription allocations.
+    :::note
+    The actual weights are governance-adjustable and may evolve over time to optimize network outcomes.
+    :::
 
-## Quality of Service and Reputation
+    The final individual provider score is computed as a weighted sum of all scores.
+
+
+6. **Pairing list delivery** 
+    
+    The resulting list is valid for one epoch and used by the consumer to establish connections.
+
+    A provider from the list is chosen using continuous probability draw. Once all Providers are scored:
+    - All composite scores are summed.
+    - A random value is generated between 0 and total score.
+    - Providers are iterated cumulatively until the sum exceeds the random value.
+    - The Provider at that point is selected.
+
+7. **Consumer - Provider Interaction**
+
+    - Consumers establish peer-to-peer connections with the most optimal RPC Node Provider from the pairing list.
+    - Requests are sent, and responses are received through this RPC Node Provider.
+    - At the end of each epoch, RPC Node Providers accumulate compute units (CUs) based on serviced demand.
+    - Monthly, RPC Node Providers claim rewards proportional to their CU usage and subscription allocations.
+
+## Quality of Service
 
 RPC Node Provider performance is tracked and scored using transparent, on-chain reputation metrics. Key signals include:
 
diff --git a/docs/provider/improving-provider-service.md b/docs/provider/improving-provider-service.md
index 4e8ecc0..19bd153 100644
--- a/docs/provider/improving-provider-service.md
+++ b/docs/provider/improving-provider-service.md
@@ -3,14 +3,14 @@ slug: /improving-provider-service
 title: Imroving Provider Service
 ---
 
-# Improving RPC Node Provider Service
+# Improving RPC Node Provider Performance
 
-## Reputation
-The Lava Network places a strong emphasis on delivering exceptional Quality of Service (QoS) to its consumers. To ensure this, consumers actively participate in monitoring and customizing their QoS excellence metrics. They gauge RPC Node provider's performance by measuring latency in Provider responses relative to a benchmark, assessing data freshness in comparison to the fastest Provider, and evaluating the percentage of error or timeout responses in the availability metric. These scores are diligently recorded and sent on-chain alongside the relay proofs of service, creating a transparent and accountable system. The Provider's performance metric is called "Reputation". Higher reputation indicates higher QoS scores.
+## Provider Performance
+The Lava Network places a strong emphasis on delivering exceptional Quality of Service (QoS) to its consumers. To ensure this, consumers actively participate in monitoring and customizing their QoS excellence metrics. They gauge RPC Node provider's performance by measuring latency in Provider responses relative to a benchmark, assessing data freshness in comparison to the fastest Provider, and evaluating the percentage of error or timeout responses in the availability metric. These scores are diligently recorded and sent on-chain alongside the relay proofs of service, creating a transparent and accountable system. 
 
 To further enhance the integrity of the QoS scores, updates are aggregated across all consumers in a manner that safeguards against false reports. Negative reports are weighted by usage, meaning that a consumer must actively use and pay a Provider to diminish their QoS score. This mechanism discourages users from artificially lowering a Provider's score.
 
-The Reputation metric only affect pairings and is aggregated over time with a decay function that favors the latest data, meaning Providers can improve, and those Providers that their service fails will be impacted to affect fewer users. This approach ensures that the reputation system remains dynamic and responsive, benefiting Providers striving to enhance their services while minimizing the impact of service failures on a broader scale.
+QoS metrics only affect pairings and is aggregated over time with a decay function that favors the latest data, meaning Providers can improve, and those Providers that their service fails will be impacted to affect fewer users. This approach ensures that the provider evaluation system remains dynamic and responsive, benefiting Providers striving to enhance their services while minimizing the impact of service failures on a broader scale.
 
 ## 📊 Passable QoS {#passable-qos}
 Passable Quality of Service is scored separately in each relay session. Lower scores mean lower rewards. Up to half the accumulated CU can be reduced for bad service. Passable QoS metrics can be viewed both in the [Lava Info explorer](https://info.lavanet.xyz/?utm_source=provider-rewards&utm_medium=docs&utm_campaign=docs-to-info) and [Prometheus metrics](/provider-features#config-prometheus).
@@ -120,13 +120,9 @@ lavap test events 2000 --event lava_provider_latest_block_report --node {PUBLIC_
 
 <br />
 
-## 📊 Reputation Score {#reputation-score}
-
-Reputation Socre is calculated very similarly to Passable QoS. QoS Excellence provides a range of scores that are time-weighted to take the latest information
-all the actions mentioned here to improve passable QoS affect Reputation 
 
 ### Metrics 📈
-Reputation score divides into 3 metrics:
+Quality of Service score divides into 3 metrics:
 * Availability - score in the range `0-1`
 * Sync/ Freshness of data - how much time behind other Providers are we, lower is better, `0` means your sync is the best in the pairing
 * Latency - how many benchmark ticks passed during a relay in average (time taken / benchmark time). lower is better
diff --git a/docs/provider/provider-faq.md b/docs/provider/provider-faq.md
index daa3576..233516e 100644
--- a/docs/provider/provider-faq.md
+++ b/docs/provider/provider-faq.md
@@ -101,7 +101,7 @@ Troubleshooting:
 ### 🟡 What is QoS (Passable Quality-of-Service)? {#qos}
 This score for RPC Node Providers per relay is based on the metrics of latency, sync, and availability. There are two different types of QoS: 
 - [Passable QoS](/improving-provider-service#passable-qos)
-- [Reputation Score](/improving-provider-service#reputation-score)
+
 
 
 ### 🟡 How can you improve your RPC Node Provider's QoS? {#improve-qos}
diff --git a/docs/provider/provider-rewards-service.md b/docs/provider/provider-rewards-service.md
index ef3bc3b..6c826db 100644
--- a/docs/provider/provider-rewards-service.md
+++ b/docs/provider/provider-rewards-service.md
@@ -20,7 +20,6 @@ RPC Node Providers earn rewards from subscriptions, commission on restaked LAVA,
 
  After staking on chain, RPC Node Providers serve consumers and get cryptographic proofs of relay service. These proofs are submitted on chain to accumulate CUs that lead to token rewards. The calculation for Provider rewards is complex and contingent on the validity of submitted proofs. However, given valid proofs, rewards are mostly affected by 3 factors:
  - ☑️ **Passable Quality of Service** - The individual score of a relay session. Passable QoS directly alters rewards in a given session.
- - ⭐ **Reputation Score** - The reputational score of a Provider. Reputation Score affects Provider selection both within a pairing and in the pairing probabilities.
  - 🚨 **Jail** - The disabling mechanism for inferior/defunct Providers. Jailing prevents a Provider from giving service for a period of time.
 
 <br/>