Summary
A technical in-depth guide of our OPUS Pool to demystify pooled staking with Stakewise and restaking osETH on Eigenlayer with Chorus One.In a nutshell, the steps are as follows:
These simple steps will get you ready to participate in the restaking ecosystem. If you’re interested in reading more about what happens in each step, below we will unravel what happens under the hood.
Go to Opus Pool, connect your wallet and deposit some ETH into our Stakewise vault. Traditional staking usually requires a staker to deposit 32ETH to spin up a validator on Ethereum in order to start earning rewards. Our 1-click staking experience enables users to stake any amount, powered by Stakewise. Stakewise v3 offers a permissionless, non-custodial pooled staking solution enabling any node operator to create a “vault”. A vault is essentially an isolated staking pool managed by the node operator and providing an automated process for ETH deposits, reward distribution, and withdrawals. You can learn more about Stakewise in our extensive guide here.
Under the hood: On a more technical level, when you stake into our Stakewise Pool, the flow works as follows:
A user deposits ETH into our MAX-MeV Stakewise vault. Once enough ETH has accrued (32 ETH), we can deposit a new validator in our vault. This is done by running an additional piece of software, stakewise v3-operator, alongside our usual Ethereum validator infrastructure, which listens to Deposit events and initiates the validator registration process. This architecture offers some very unique features. For one, the permissionless onboarding. Stakewise makes it possible to create your own vault with customized experiences, such as a private vault- only allowing stake from whitelisted addresses, a public vault- allowing stake from everyone, MEV smoothing and many more. Secondly, the ability to initiate a forced-exit by the Stakewise DAO. The Ethereum protocol requires validator exit messages to be signed with the validator signing key (the key held by the node operator required to operate the validator for signing blocks and attestations).
This means that, until EIP-7002 is implemented to support signing exit messages with withdrawal credentials (the key the staker holds to withdraw their funds), users depend on the node operators to exit validators on their behalf. To remediate this potential attack vector in a fully permissionless environment, there are certain steps a node operator must go through when registering a new validator. They submit shards of their signing keys to all Oracles through a process known as Shamir-secret sharing, a secret sharing algorithm which enables trustless and secure sharing of distributed, private information. Moreover, the pre-signed exit transaction messages are sent to the oracles in an encrypted manner. This allows the DAO to exit a validator on their behalf, should a node operator go rogue. Once oracles have approved registration, the operator sends the validator registration transaction to the so-called Keeper contract- essentially the brain in the architecture- which executes the deposit on-chain. EIP-7002 is still in its design phase, but it will open up new solutions to remove the need for Oracles by enabling the execution layer to trigger validator exits under certain conditions.
After a successful validator registration process, we’re ready to run a validator and collect rewards in our vault. Similarly to other liquid staking protocols, Stakewise relies on several oracles to fetch rewards from the Beacon Chain. Since The Merge, Ethereum’s architecture consists of the Consensus Layer (“Beacon Chain” which contains the consensus state and validator management) and the Execution Layer (“the EVM” which handles execution payloads, maintains a mempool of transactions). While combining both layers facilitated an easy transition to a Proof-of-Stake chain, it left the communication between both layers via Engine API somewhat limited- the Consensus Layer can query the Execution layer, but not the other way round. Essentially this means there’s no trustless way for the EVM to connect to the Beacon Chain to e.g. fetch validator rewards data. As a workaround, Stakewise employs trusted Oracles which regularly fetch rewards data from the Beacon Chain and vote for the rewards/penalties from all vaults. The vault rewards are saved as a Merkle tree and uploaded to IPFS, e.g see this example. The Merkle root is saved in the Keepers contract, again, the brain of our architecture. If you’re not familiar with Merkle trees, proofs and roots, they are one of the founding blocks of how Ethereum works, here’s a recommended read.
Essentially, it’s a data structure that helps us verify data consistency and make efficient proofs of inclusion (Merkle-proofs) to verify a piece of data is in the tree. More concretely, since the Merkle root is stored in the Keepers contract, it’s easy to verify that the stored Merkle tree hasn’t been tampered with.
To keep a vault’s state up to date, the Keeper contract needs to be “harvested”, meaning that the vault can fetch the Merkle root from the Keeper and derive validators rewards/penalties to update its state. If the state isn’t updated in a specified timeframe, any user interaction will be blocked.
With EIP-4788, which is implemented in the upcoming Dencun Upgrade (currently being rolled out to all testnets), the parent (previous) beacon block root will be included directly into the execution block enabling the EVM to access the block root from a trusted source, and thus removing the need for an Oracle and instead, enshrining it in the protocol. The way it will work is similar to the implemented workaround- the parent beacon block root represents the hash of the entire header of the previous block. A smart contract deployed on Ethereum will hold a limited number of parent beacon block roots, such that the execution layer can derive the consensus state in a trustless manner.
With this foundational knowledge in mind, let’s look at a specific example transaction of someone depositing 0.01 ETH into our Stakewise vault:
You can see the address which deposited 0xe46825... calls the deposit function on the Chorus One vault address 0xe6d8d8… . As we mentioned in the previous section, the v3-operator listens to DepositEvents emitted. Looking at the event logs, we get a good glimpse into what happens when you deposit into a vault:
The address is recorded along with the amount of your stake (assets), resulting in a number of “shares”which are calculated as follows: assets * total shares in vault / total assets in vault, see contract code for reference. The calculated shares will be the indicator how much of the rewards accrued by the Ethereum validator will be paid out to the staking address.
Once you’ve deposited successfully in our Stakewise vault, you can go ahead and mint your osETH in 1-click. The minted osETH should be visible in your wallet after the transaction was successful. If it’s not visible, you may need to add the token manually, e.g. for MetaMask see this resource.
Under the hood: As mentioned above, Stakewise offers a liquid staking token called osETH to provide liquidity to its stakers. This is a fantastic improvement on the staking experience, because you get a representation of your staked ETH which you can use to earn additional yield in the DeFi world. During vault setup, a node operator may choose to configure a vault that allows to mint an ERC20 token or whether the vault is tokenless. The issued liquid staking token- osETH- is overcollateralized, meaning the underlying assets in the vault are worth more than the osETH issued in order to cover potential losses from slashing. The biggest risk for staking is the risk of getting slashed, e.g due to double signing, which could result in losing part of the stake. Slashing is usually the consequence of bad key management practices that optimise for speed rather than consistency. It’s therefore important for node operators to apply sound security and key management practices, in order to minimize the risk.
One interesting feature of osETH is that it has a built-in slashing protection mechanism for its stakers. During the minting process you might have noticed that you can only mint up to 90% of the staked ETH. The excess backing insures stakers against poor staking performance or slashing events. Such penalties are absorbed by the excess backing.
To keep track of this, Stakewise defines a certain parameter known as “position health” which monitors the value of osETH minted relative to the value of their ETH currently staked in the Vault (see in screenshot above). The value can be Healthy/Moderate/Risky/Unhealthy. A “Healthy” position means that minted osETH doesn’t exceed 90% of the staked ETH. If the value of minted osETH grows faster and suddenly exceeds 92% of the staked ETH in the vault, the position status will move to “Unhealthy”. Let’s look at a concrete example: Imagine a user minted osETH against a staked position worth 100 ETH in Vault X. Suddenly, Vault X decided to increase its fees much higher than other vaults. During an incident, the node operator was forced to migrate their keys and started producing inconsistent attestations and downtime causing inactivity leaks all resulting in penalties and lower profit accrued in the vault. On top of that the bull market hits and demand for Ethereum validator exceeds current supply making the validator activation queue extremely long, but still growing overall TVL. A month later the minted osETH is now worth 92.01 ETH, making the user's position status "Unhealthy" and opening up for liquidation because the value of minted osETH relative to their ETH stake exceeds the liquidation threshold, i.e. is >92% enabling the DAO to liquidate a vault (if you remember, they have the ability to exit validators on a node operator's behalf), in order to ensure the excess backing of osETH.
The final step in our OPUS Pool journey let’s you restake your freshly minted osETH and other liquid staking tokens with EigenLayer.
Now what’s Eigenlayer and why will it bring more yield? To sum it up: “Restaking offers stakers the flexibility to contribute to the security of multiple networks, potentially earning rewards, verifying trust, or engaging in blockchain events. Users that stake $ETH can opt-in to EigenLayer smart contracts to restake their $ETH and extend cryptoeconomic security to additional applications on the network”. To read more about how it works, head to our blog article on Eigenlayer.
Under the hood: As of the time of writing, no AVS are live on mainnet yet. Until the EigenLayer protocol goes live with EigenDA (AVS developed by the EigenLayer team), restakers will receive restaked points as a measure of the user’s contribution to the pooled security, while securing the opportunity to be rewarded as an early restaker. Once AVSs go live, you will be able to delegate to Chorus One and receive rewards from your restaked ETH or Liquid Staking Tokens. This graph below shows what will happen once we enter this Stage:
The (re-)staker deposits their osETH (or other Liquid Staking Tokens) into the EigenLayer StrategyManager contract, which is responsible for accounting and allowing restakers to deposit LSTs into the given strategy contract. When users deposit into the StrategyManager, the funds are transferred to the respective LST’s StrategyBaseTVLLimits contract e.g. osETH or stETH, which returns shares proportionally to the users stake. The number of shares is calculated using an internal exchange rate which depends on the total number of deposits.
Here’s an example transaction of a user depositing osETH into the StrategyManager via our OPUS Pool. The event logs show the address where the funds were deposited from (depositor), the address of the token contract (in this case osETH token contract), and the address of the strategy contract (the address of the osETH strategyBaseTvlLimits contract).
Once the AVSs go live on mainnet, restakers will be able to delegate their LSTs to Chorus One. This is done by calling a function on the DelegationManager which manages delegation and undelegation of the stakers to operators. As of now, this functionality is paused, so stay tuned for the next EigenLayer mainnet upgrade and don’t miss your chance to delegate your restaked tokens to your favourite node operator.
A step-by-step guide to staking ETH on OPUS Pool
Restake with EigenLayer Seamlessly via Chorus One's OPUS Pool: A Detailed Guide
Learn more about Adagio, Chorus One’s pioneering Ethereum MEV-Boost client
MEV Max - Introducing Chorus One’s Liquid Staking Pool on Stakewise V3
Considerations on the Future of Ethereum Staking
Chorus One is one of the biggest institutional staking providers globally operating infrastructure for 50+ Proof-of-Stake networks, including Ethereum, Cosmos, Solana, Avalanche, and Near, amongst others. Since 2018, we have been at the forefront of the PoS industry and now offer easy enterprise-grade staking solutions, industry-leading research, and also invest in some of the most cutting-edge protocols through Chorus Ventures.
