Oracle Duties

Oracles run the v3-oracle ↗ nodes and are responsible for validator registration, reward distribution, and validator exits.

Validator Registration Approval

Oracles approve validator registration requests before they are submitted to the Beacon Chain Deposit Contract ↗.

The Operator Service → periodically checks whether its Vaults have accumulated enough ETH for registering new validator(s). When the Vault has enough ETH, the operator sends a registration approval request to Oracles that includes encrypted exit signature(s) for the validator(s) it is attempting to create. This is done to maintain the protocol's ability to exit validators on demand, and to perform checks against the front-running withdrawal credentials attack described here ↗. The operator must receive 8 out of 11 approvals from Oracles to register a validator for the Vault.

Approval Process

1. Operator sends the validator registration requests and encrypted exit signatures to the Oracles.
2. Oracles sign approval messages that include the current tree root hash from the Beacon Chain Deposit Contract.
3. Operator submits registration to the Vault contract with Oracle signatures.
4. Vault contract calls the Keeper contract ↗ to validate Oracle signatures and confirm the tree root hash hasn't changed.
5. Vault transfers ETH to the Beacon Chain deposit contract to complete validator registration.

This process ensures Oracles approve validators based on current Beacon Chain state, bridging the consensus and execution layers while preventing stale approvals and replay attacks.

Deep Dive

For details on how the Operator Service initiates and prepares validator registration, see the Validator Registration → section in Vaults.

Reward Distribution

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 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 ↗ polls each Oracle's API, collects a threshold of matching signatures (rewardsMinOracles, currently 6 of 11), and submits them to the Keeper contract ↗. The Keeper contract verifies the signers, checks the threshold and nonce, and stores the new Merkle root. Individual Vaults can then harvest their rewards.

For MetaVaults, the per-Vault calculation also propagates the underlying sub-Vaults' rewards into the parent.

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

The validator exit process is automated and trustless. Validator exits require exit signatures that are generated during the validator registration process.

As part of registration, the Operator Service encrypts exit signatures using Shamir's secret sharing and distributes them to all Oracles.

Key Benefit

This approach ensures validators can be exited on demand while maintaining protocol security through decentralized signature management.