Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 21 additions & 15 deletions docs/docs/oracles/oracle-duties.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down