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

The Operator Service monitors the Vault and, once enough ETH has accumulated (32 ETH per validator), prepares a registration and sends an approval request to all 11 Oracles. The request carries all the information each Oracle needs to verify the registration trustlessly, including the encrypted exit signature shares that let the protocol exit the validators on demand.

Each Oracle independently:

  1. rebuilds the deposit message and verifies the deposit signature against it;
  2. decrypts its own exit signature share and verifies it is a valid BLS signature against the corresponding public-key shard;
  3. confirms that none of the public keys are already registered and that each validator is assigned the next expected index;
  4. uploads the encrypted exit shares to IPFS and signs an approval message that commits to their IPFS hash, the current deposit_root, the Vault address, the validators payload (public keys and deposit signatures), and an expiration deadline.

Once at least 6 Oracles have signed, the Operator Service bundles those signatures and submits them to the Keeper ↗ — the smart contract that enforces the rules on-chain.

The Keeper confirms the 6-of-11 threshold is met and that the deposit_root still matches what the Oracles signed, ensuring the Deposit Contract's state did not change since the Oracles approved — which also protects against the front-running withdrawal credentials attack ↗.

Once everything passes, the Vault forwards the deposit to the Beacon Chain Deposit Contract ↗. The deposit enters the Beacon Chain's deposit queue, and the validator is created once the pending deposit is processed.

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