Summary
Like the existing version of StakeWise, the upcoming V3 upgrade 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. In this proposal, StakeWise core team suggests a list of 11 Oracles who it believes can achieve the required degree of decentralisation and uptime. We ask for DAO approval to include these organizations as members of the Oracle Network for StakeWise V3.
Background about the Oracle role in V3
With the launch of StakeWise V3 hinging on this last milestone, the core team is looking to finalise the participants in the Oracle Network - a crucial component for the proper functioning of the StakeWise protocol. But what is an Oracle and why is a network of Oracles required for V3?
An Oracle is an entity responsible for fetching validator rewards data for all the Vaults from the 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. These duties are performed automatically using Oracle software developed by the StakeWise team, with no manual actions involved.
Correct and timely fulfillment of Oracle duties is necessary for a seamless staking and unstaking experience for both users and operators in StakeWise. 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.
Why an Oracle Network
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, the core team suggests 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.
Over time the DAO should be looking to replace the Oracle Network with trustless solutions based on zk tech, but quite a few technological advances must happen before it can become feasible.
Proposed Network Size & Threshold
We propose 11 participants total with 7/11 threshold for updating rewards and processing validator registrations/exits.
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.
Operational requirements
Due to the high threshold requirement and near-constant involvement of Oracles in the user interactions with the protocol, all entities running Oracles must achieve near-perfect uptime. The core team believes that Oracles must be expected to have above 99% uptime and will follow the same standard itself as one of the Oracles. This excludes situations where V3-Operator has failed as defined by unexpected errors in the software developed by the StakeWise core team.
This is not trivial to achieve due to the occasional conflicts between the new versions of consensus and execution clients and the Oracle software, as well as potential node downtime experienced in environments with poor internet connection and insufficient technical resources.
In light of the high demands on uptime & technical expertise in running the Oracle, the best prospects for the role of Oracles are staking companies with stellar reputations, and infrastructure-focused teams with significant web3 experience.
As a core team, we are fortunate to work with amazing partners who have expressed interest in becoming an Oracle for the StakeWise V3 protocol. Here is the list of 11 entities that we propose for the Oracles role:
- 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 Labs
We are confident that the proposed set of Oracles will handle the responsibility and meet the required uptime without issues.
Oracle compensation
The team has not made the compensation structure public since it expects to cover the cost of the Oracle Network using its own resources.
Voting & discussion
A Snapshot vote has been initiated to receive DAO approval for the proposed Oracle Network and we request all SWISE holders to put the token to vote and make their voices heard!
If there are questions or things you would like to discuss before marking your vote, please use this thread to do so.
