diff --git a/docs/docs/oracles/oracle-duties.mdx b/docs/docs/oracles/oracle-duties.mdx
index bc41af6b..4eedddef 100644
--- a/docs/docs/oracles/oracle-duties.mdx
+++ b/docs/docs/oracles/oracle-duties.mdx
@@ -38,22 +38,28 @@ For details on how the Operator Service initiates and prepares validator registr
 
 <Image img={require('./img/reward_distribution.png')} alt="Oracle reward distribution process for Vaults" />
 
-Oracles periodically vote on the consensus rewards/penalties accumulated by the Vaults in the Beacon Chain and execution rewards (MEV & priority fees) for the Vaults connected to the Smoothing Pool.
-
-The reward distribution process consists of the following steps:
-
-:::custom-info[Reward Distribution Process]
-1. Verify sufficient time has passed since the last reward distribution.
-2. Calculate rewards/penalties for all Vaults based on validator balances in the Beacon Chain.
-3. Calculate MEV and priority fee rewards for Vaults connected to the Smoothing Pool.
-4. Create Merkle trees from the reward calculations and upload them to IPFS. For example, <code>bafkreibqhdr6p5uh67ickt4dpppb525bwuofjocnpsx4dbl57llogfph2e</code>.
-5. Save the cryptographically signed vote to the local database and expose via API.
-6. The [Keeper service ↗](https://github.com/stakewise/v3-keeper/) fetches votes from Oracle APIs, concatenates them, and sends the resulting transaction to the [Keeper contract ↗](https://etherscan.io/address/0x6B5815467da09DaA7DC83Db21c9239d98Bb487b5#code).
-7. Upon verification, the protocol updates global state.
-8. Individual Vaults can claim their rewards.
-:::
+Oracles periodically vote on the consensus rewards and penalties accumulated by each Vault's validators on the Beacon Chain.
+
+Each Oracle independently:
+
+1. computes each Vault's consensus rewards and penalties from its validators' Beacon Chain balances;
+2. computes each Vault's MEV rewards — for Smoothing Pool Vaults, a proportional slice of the shared escrow; for Vaults with their own MEV escrow, the on-chain unlocked amount;
+3. builds a Merkle tree of all per-Vault rewards and computes each Vault's proof;
+4. uploads the full snapshot (every Vault's rewards + every Vault's proof) to IPFS;
+5. signs an EIP-712 message that includes the Merkle root and the IPFS hash.
+
+Once enough Oracles have voted, the [Keeper service ↗](https://github.com/stakewise/v3-keeper/) polls each Oracle's API, collects a threshold of matching signatures (`rewardsMinOracles`, currently **6 of 11**), and submits them to the [Keeper contract ↗](https://etherscan.io/address/0x6B5815467da09DaA7DC83Db21c9239d98Bb487b5#code). The Keeper contract verifies the signers, checks the threshold and nonce, and stores the new Merkle root. Individual Vaults can then harvest their rewards.
 
-The reward update process has protocol-wide impact.
+For MetaVaults, the per-Vault calculation also propagates the underlying sub-Vaults' rewards into the parent.
+
+:::custom-notes[How the Smoothing Pool share is calculated]
+Every 12 hours, Oracles:
+
+1. Calculate the new MEV that arrived in the shared escrow since the last vote;
+2. Reject misbehaving Vaults (e.g. redirecting the fee recipient, using an untrusted relay, or skimming rewards);
+3. Split the new MEV among Vaults, weighted by their validators' attestation rewards on the Beacon Chain;
+4. Lock each Vault's newly distributed share, releasing it once the Vault produces its next correct MEV block (or once all its validators have fully withdrawn).
+:::
 
 ## Validator Exits