"Simple can be harder than complex. You have to work hard to get your thinking clean to make it simple."
— Steve Jobs
Bond is one of the most popular tools to ensure Liquid Staking Protocol security and alignment between Node Operators and stakers. At its core, Ethereum itself, as well as any other PoS-based networks, utilizes a bonding approach by locking staked tokens to be used as a guarantee of alignment between participants and the security of the network.
There are multiple possible implementations of the bonding mechanism within Ethereum LST. This document outlines the fundamental principles of the bonding mechanics, main decision drivers, and considered implementation options for Lido on Ethereum.
Lido
is a core Lido contract that stores the protocol state, accepts user submissions, and includes the stETH token;Lido
and representing the user's share in pooled ether under the protocol control;To create a solid and reliable design of the bonding mechanism, the following fundaments principles are formulated:
The proposed design is based on the following formulated principles in addition to the common ones:
Based on the formulated principles, the bond must be staked, but the rewards on it should not be socialized with other users. To solve this problem, two options are proposed: to have parallel accounting for bonded ETH within the protocol or to recalculate the shares of bonded ETH depending on the rewards on the bond.
In this implementation, it's proposed to explicitly separate the staked bond from the staked user ETH at the contract level and, when the protocol is rebased, mint shares as rewards for node operators for their percentage of user stake (X% of unbonded part, that correspond to the module fee) and for the bond (100% for bond part). If bond or its part should be burned, the protocol simply subtracts this ETH from the total bonded ETH, thereby compensating for the protocol's losses.
Similar approach to the previous one, with the exception of not complicating the onchain part, but moving it to the performance oracle's responsibility. Node operator comes up with a bond that is staked. The performance oracle then counts how many rewards the node operator’s validators got per report frame. If those particular validators did better than the others, the protocol mints the bond shares to make up the difference. Or it burns shares if the validator performed worse than the others.
To implement in protocol bonds functionality, a performance oracle at the level of the entire protocol is required to distribute rewards between modules and within modules with a bond according to the performance of validators.
It is proposed that a performance oracle collects the exact rewards and penalties per frame for each Lido validator and aggregates this data to the operator layer. Rewards and penalties are suggested to be divided into three conceptual layers:
Some modules, such as Curated Module can remain bondless at the operator level. Since in-protocol bonds imply burning a part of the bond for validator's duty violations, the question arises where the coverage of these losses in such modules will come from. A good solution could be a cover fund, which could be connected to the modules regardless of the existing bond system and cover losses exceeding the operator's bond (or in case of its absence).
In this way it is possible to build a multi-layer loss coverage system for the whole protocol where each layer can cover losses or escalate higher. The following levels of loss coverage can be defined, taking into account further scaling of the protocol:
Given the modular architecture introduced by the staking router, it is worth considering the implementation of the bonding mechanism on the staking module level. This approach will allow module developers to introduce module-specific bonding features and make it faster to release staking modules with the bond on the mainnet.
The "Simple bond" idea is to stake tokens with Lido using the submit
method on the stETH contract or accept the bond in the form of stETH tokens. This approach will result in the bonded tokens being stored in the form of stETH.
To ensure a perfect fit between the module and bond contract, it is proposed to use individual instances of the bond contract for each module.
A bond contract is responsible for:
A staking module is responsible for:
Bond tokens deposited by the Node Operator or the staking module on behalf of the Node Operator are stored on the bond contract balance until released and claimed.
The bond contract stores the Node Operator to bond curve mapping, allowing for different bond requirements for different Node Operators (e.g., different DVT cluster configurations, individual bond reductions, etc.)
The staking module should provide information about the current number of validators for the given Node Operator to the bond contract. Using the bond curve assigned to the Node Operator bond contract calculates the amount of bond tokens required to cover all Node Operators's validators. This information is used to calculate the amount of bond tokens that can be claimed (excess bond).
As described above, an excess bond is calculated based on the current number of validators for the given Node Operator and its bond curve. There are several cases when excess bond tokens might appear:
In all cases, an excess bond should be available for claim. Excess bond tokens can be claimed as stETH, Withdrawal NFT or wstETH.
A penalty might have the form of stETH tokens burning (penalty in favor of all stETH holders) and transferring penalized tokens to Lido Treasury (penalty in favor of the protocol). The staking module provides the amount of tokens to be penalized and the penalty type in the corresponding method call.
The Simple bond approach fully conforms to the first three fundamental bonding principles. At the same time, the fourth principle still needs to be fulfilled due to the stETH token rebase being fully socialized between stETH holders and depending on the overall Lido validator's performance.
The best way to illustrate this violation is in case of a negative stETH rebase (after the Oracle report, the stETH share rate decreases). This effectively means that Node Operators might get negative bond rewards (which can be read as penalties) due to the low performance of the other Lido validators.
There are several facts worth mentioning here regarding negative stETH rebase:
At the current state of Lido on Ethereum (as of Dec 2023), it will take around 1000 validators to get slashed simultaneously or at least 66% of Lido validators should go offline for a day to make one stETH rebase slightly negative (0.1% APR) and more than 7k of simultaneous slashings to make losses larger than insurance fund can cover.
Given that, negative stETH rebase can be treated as an acceptable limitation due to low chances of ever happening and clear pathways for mitigation.
Given multiple possible implementations of the bond mechanics, each with its own pros and cons, a decision should be made on what approach to follow during the implementation of other staking modules, including CSM.
Two considered options are described in detail in the first part of the document.
Authors are leaning toward Simple bond option. While this option comes with several limitations (fully socialized bond rewards and risk of negative rebase impact), it is significantly more feasible regarding delivery time. Given approved Lido 1-year Goals, it seems reasonable to select option that will allow to deliver Community Staking Module and partner DVT modules in 2024, leaving Protocol-wise for the further upgrades.
In the case of Simple bond implementation, a question of the possible negative stETH rebase influence on the bonded tokens should be considered.
Do not implement additional coverage mechanics and accept the risk of the negative stETH rebase of the bonded tokens in the same way as it is accepted by the other stETH holders.
Set a dedicated insurance fund for the compensation of bonded tokens.
Store shareRate
on each bond deposit to allow for a proportional bond reduction in case of negative stETH rebase.
Authors are leaning toward Option A due to the low probability of negative rebase, the presence of general mitigation measures, and operational simplicity.
Two options have been considered regarding possible bond mechanics in Lido have been considered with the decision outcome to start with the Simple bond approach and switch to the Protocol-wise implementation in the future. It is also proposed that existing negative rebase mitigation tools be utilized to cover the possible negative rebase of the bonded tokens.