Skip to main content

Oracles

Introduction​

Oracles are specialized entities that connect blockchains to external data sources, enabling smart contracts to access real-world information.

In the StakeWise protocol, Oracles monitor validator performance data on the Beacon Chain and reach consensus on validator registration approvals, reward distribution, and exit processes within Vaults.

Oracles are a crucial part of the protocol, and must remain sufficiently decentralized and maintain high uptime in order for StakeWise to work seamlessly.

The protocol operates with 11 Oracles selected and approved ↗ by the StakeWise DAO through governance processes. These Oracles form a decentralized network of independent nodes that ensures protocol resilience and prevents single points of failure. This distributed approach eliminates centralized control, reduces regulatory capture risks, and ensures protocol longevity through consensus-based decision making.

Oracle decisions require threshold-based consensus depending on the operation. Validator registration requires 8 out of 11 Oracle signatures, while reward updates need 6 out of 11 signatures.

Through Oracle consensus, all Vaults stay synced with the Beacon Chain, display accurate information, trigger secure and timely new validator registrations, and fulfill exit requests. These duties are performed automatically using Oracle software developed by the StakeWise team, with no manual actions involved.

Oracles are one of the protocol’s building blocks to deliver seamless staking and unstaking experiences.

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). Upon having 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.

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

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

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

Oracle Network Participants​

  1. Chorus One ↗
  2. Stake.fish ↗
  3. Telekom ↗ (formerly T-Systems MMS)
  4. Finoa Consensus Services ↗
  5. Bitfly ↗ (operators of the Beaconchain ↗ explorer)
  6. SenseiNode ↗
  7. Gateway.fm ↗
  8. Gnosis Chain ↗ team
  9. P2P ↗
  10. DSRV ↗
  11. StakeWise Labs ↗ (the development team)
Last updated on