Skip to main content

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 the Vault contract forwards the deposit to the Beacon Chain Deposit Contract ↗.

Once the Operator Service has prepared a new validator, it sends an approval request to every Oracle, including the validator public key, the deposit signature, the current deposit_root, an expiration deadline, and each Oracle's encrypted exit share.

Each Oracle then independently:

  1. re-derives the Vault's withdrawal credentials from the Vault address and verifies the deposit signature against those credentials;
  2. decrypts its own exit-signature share and verifies it is a valid BLS signature against the corresponding public-key shard;
  3. verifies the deposit_root matches current Beacon Chain state and commits to it by signing its approval message;
  4. includes the IPFS hash of the encrypted exit shares in the approval message it signs. The shares are uploaded to IPFS. This is done to maintain the protocol's ability to exit validators on demand.

Once enough Oracles have signed, the Operator Service submits the bundled signatures to the Vault contract. The Keeper contract ↗ verifies the signature threshold is met (validatorsMinOracles, currently 6 of 11) and confirms the current deposit_root still matches the one the Oracles signed.

The recheck guards two things. The pre-signed exit signature is bound to a specific validator index the Operator Service predicted at registration — a new deposit would shift that index and invalidate the signature. The recheck also protects from the front-running withdrawal credentials attack ↗, where a malicious operator races their own deposit ahead of the Vault's.

Once everything passes, the Vault forwards the deposit to the Beacon Chain Deposit Contract ↗. The deposit enters the Beacon Chain's deposit queue ↗ before the validator is queued for activation. Processing time depends on network congestion.

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:

IconReward 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. 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.

IconKey Benefit

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

Last updated on