StakeWise V3
  • Main Hub
  • Guides
    • Staking
    • Running a Vault
    • osToken
    • DeFi
      • SWISE-ETH Liquidity Pool
    • StakeWise V2
      • Migrate to StakeWise V3 on Ethereum
      • Migrate to StakeWise V3 on Gnosis Chain
      • Change solo withdrawal credentials to 0x01 address
        • Using Ledger Nano X
        • Using Windows
        • Using macOS
      • Exit solo validator
  • Protocol overview (in-depth)
    • Introduction
    • Vaults
    • osToken
    • Fees
    • Oracles
  • For operators
    • Operator Service
      • Running with Remote Signer
      • Running with Hashi Vault
      • Running as API service
      • Monitoring
    • Kubernetes staking setup
    • Smoothing Pool relays
    • Migrate from V2
      • Ethereum
      • Gnosis
    • DVT
      • Running operator with DVT
  • For developers
    • Create a Vault
    • Stake
    • Unstake
    • Oracles
    • Contributions
    • Networks
      • Gnosis
      • Mainnet
      • Holesky
      • Chiado
    • Vault's performance
  • Governance
    • StakeWise DAO
    • DAO Treasury
Powered by GitBook
On this page
  1. Protocol overview (in-depth)

Oracles

Learn about the StakeWise V3 oracles

StakeWise V3 relies on an off-chain component called Oracles to fetch information about staking rewards from the Beacon Chain and trigger validator registration and exit processes.

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

StakeWise DAO has elected 12 Oracles to form an Oracle Network and ensure seamless functioning of the protocol.

Oracle Network explained

To minimize concerns about the manipulation of outcomes and reduce the susceptibility of the Oracle Network to regulatory capture, as well as to maximize the longevity of the protocol, StakeWise DAO follows an approach where a network of Oracles is working via a consensus mechanism to determine the outcomes.

Instead of an Oracle being a single entity with centralized power over the protocol’s outcomes, using a network of Oracles is the gold standard for ensuring that the protocol does not have overpowered centralized components.

A large number of participants is a must for the Oracle Network to remain decentralized. Meanwhile a high threshold for consensus is necessary to prevent centralization concerns and reduce the risk of malicious capture of the Oracle Network.

Hence, the StakeWise DAO has elected 11 participants with a 7/11 threshold for updating rewards and processing validator registrations/exits.

Oracle duties

An Oracle is an entity responsible for fetching validator rewards data for all the Vaults from the Beacon Chain (and Gnosis Beacon Chain) and pushing it on-chain. An Oracle is also responsible for approving validator registration for all the Vaults, and exiting validators in response to withdrawal and redemption requests.

Correct and timely fulfillment of Oracle duties is necessary for a seamless staking and unstaking experience for both users and operators in StakeWise. These duties are performed automatically using Oracle software developed by the StakeWise team, with no manual actions involved.

Because an Oracle has the power to influence the amount of rewards paid out to stakers and the effectiveness of validator registration and exit, it has a very important role in the whole system.

Oracle Network participants

  • Chorus One

  • Stake.fish

  • Telekom (formally T-Systems MMS)

  • Finoa Consensus Services

  • Bitfly (operators of the Beaconchain explorer)

  • SenseiNode

  • Gateway.fm

  • Gnosis Chain team

  • P2P

  • DSRV

  • StakeWise development team

  • Chorus One

  • Stake.fish

  • Telekom (formally T-Systems MMS)

  • Finoa Consensus Services

  • Bitfly (operators of the Beaconchain explorer)

  • SenseiNode

  • Gateway.fm

  • Gnosis Chain team

  • Axol.io

  • DSRV

  • StakeWise development team

PreviousFeesNextOperator Service

Last updated 3 months ago

Page cover image