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/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:

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, bafkreibqhdr6p5uh67ickt4dpppb525bwuofjocnpsx4dbl57llogfph2e.
5. Save the cryptographically signed vote to the local database and expose via API.
6. The Keeper service ↗ fetches votes from Oracle APIs, concatenates them, and sends the resulting transaction to the Keeper contract ↗.
7. Upon verification, the protocol updates global state.
8. Individual Vaults can claim their rewards.

The reward update process has protocol-wide impact.

Validator Exits

The validator exit process is automated and trustless. During validator registration, the Operator Service generates each validator's pre-signed exit message, splits it into BLS signature shares using a threshold scheme, and encrypts a share for every Oracle — so the validators can always be exited, even if the operator disappears.

When a Vault has unstake requests, the Oracles independently identify which validators must exit and publish those exits over their APIs. The Operator Service picks up the Oracle-signalled exits and triggers them on-chain through the Vault contract.

Validator Consolidations

After the Pectra upgrade ↗, validators with 0x01 withdrawal credentials can be upgraded to 0x02 (raising the effective balance cap to 2048 ETH), and multiple validators can be merged into a single compounding validator.

Both operations require the Vault's validators manager signature. The upgrade from 0x01 to 0x02 additionally requires Oracle approval, because it introduces a new compounding validator: the Operator Service sends a consolidation request, each Oracle confirms the keys are active validators of the Vault and returns a signed approval, and the Vault contract submits the consolidation once the ConsolidationsChecker contract ↗ verifies that at least 6 of 11 Oracles have signed.

Merges into an existing compounding validator need only the validators manager signature — no Oracle approval — and the Vault contract requires the target to already be a registered 0x02 validator.

How Oracle Votes Reach the Chain

Oracles never submit transactions themselves — they only sign messages and expose them over HTTP. Two off-chain services bridge Oracle signatures to on-chain state:

• The Operator Service collects Oracle signatures for validator registrations and consolidations, since the Vault operator is the party initiating those flows.
• The Keeper service ↗ polls each Oracle's API for reward distribution votes, aggregates a threshold of them, and submits the transaction to the Keeper contract ↗.