# \[ADR\] Bond Mechanics in Lido

> "Simple can be harder than complex. You have to work hard to get your thinking clean to make it simple."
>
> — Steve Jobs

# Intro
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.
# Glossary
- The **Lido DAO** is an organization headquartered on Ethereum that operates liquid-staking services across various Proof-of-Stake blockchains, including Ethereum and Polygon;
- `Lido` is a core Lido contract that stores the protocol state, accepts user submissions, and includes the stETH token;
- **stETH** is an ERC-20 token minted by `Lido` and representing the user's share in pooled ether under the protocol control;
- **Node Operator** (NO) is a person or entity that runs validators;
- **Staker** is a person or entity holding stETH tokens;
- A **bond** is ETH put out by a validator (Node Operator) as collateral for bad behavior or poor performance;
- A **bond curve** is a function returning the total amount of tokens required to cover N validators;
- The **staking router** (SR) is a smart contract within the Lido on Ethereum protocol that facilitates stake allocation, withdrawals, and rewards distribution across different modules;
- A **staking module** (SM) is a smart contract or a set of smart contracts connected to the staking router, which:
- maintains the underlying operator and validator sets,
- is responsible for on/off-boarding operators,
- maintains validator deposits, withdrawals, and exits,
- maintains fee structure and distribution for the module and participants, etc;

# Fundamental principles
To create a solid and reliable design of the bonding mechanism, the following fundaments principles are formulated:
1. Bond should allow economic alignment between stakers and Node Operators;
2. Bond should allow coverage for the consequences of the inappropriate or malicious actions by Node Operators to a reasonable extent;
3. Bonded tokens should acquire staking rewards;
4. Node Operators' bond should be penalized or confiscated only after inappropriate or malicious actions by the corresponding Node Operator.
# Possible implementations
## Protocol-wise bond

### First Principles
The proposed design is based on the following formulated principles in addition to the common ones:
- The deposit on a validator consists of two parts: stakers and node operator.
- Rewards are socialized among stakers, but distributed among node operators according to their performance.
- Rewards on the node operator’s part of the deposit belong to the operator.
- Penalties for poor validators performance are primarily imposed on the node operator, not stakers.

### Design Options
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.

#### 1. Parallel Accounting
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.

#### 2. Recalculation of Bond Shares
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.

### Performance Oracle
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:
- **Consensus Layer.** Rewards and penalties from this layer are accurately counted for each validator based on the balance difference at the end and start of the report frame (taking skimming into account) and distributed among operators
- **Execution Layer.** Rewards and penalties from this layer are allocated to validators based on their performance on the CL. It is proposed that deltas of balances on CL are used as a measure of validators' performance.
- **Lido Layer.** Rewards and penalties from this layer are distributed according to protocol policy.

### Bondless Modules

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:
- **Validator.** Bond per validator (may be useful for some types of modules)
- **Operator.** Bond at operator level
- **Module.** Insurance fund at module level
- **Protocol.** External insurance protocols at protocol level

### Pros
- Accurately accounting for the rewards and penalties of each individual validator, operator and module is the first step in building a competitive market between modules and operators within modules.
- A common approach for rewards distribution simplifies module development. Each module can reuse the performance oracle report to distribute rewards to operators within the module.

### Cons
- Development complexity

## Module level bond, aka "Simple bond"
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.

### Description
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:
- Storing Node Operator's bond tokens;
- Storing Node Operator to bond curve mapping;
- Calculating the amount of the bond tokens required to cover all Node Operator's validators;
- Releasing (making available for claim) excess bond tokens;
- Penalizing bond tokens on the staking module request;

A staking module is responsible for:
- Providing information about the Node Operator for the bond contract (validators count, manager address, etc.);
- Managing Node Operator's properties;
- Request setting and changing of the bond curve for the Node Operator;
- Requesting Node Operator's bond penalization;
- Distributing staking rewards allocated by the Staking Router;
- Any other stuff not related to the essential bond management;

#### Bond contract responsibilities description
##### Storing Node Operator's bond tokens
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.

##### Storing Node Operator to bond curve mapping
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.)

##### Calculating the amount of the bond tokens required
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).

##### Releasing excess bond tokens
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:

- The number of active Node Operator's validators has decreased;
- Bond tokens (stETH) amount increased due to rebase;
- Node Operator uploaded excess bond;

In all cases, an excess bond should be available for claim. Excess bond tokens can be claimed as stETH, Withdrawal NFT or wstETH.

##### Penalizing bond tokens
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.

### Fundamental principles compliance
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:
- Negative stETH rebase never happened yet;
- In the case of the negative stETH rebase, the Lido Insurance fund can be used to compensate for it for all stETH holders based on the DAO decision;

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](https://etherscan.io/address/0x8B3f33234ABD88493c0Cd28De33D583B70beDe35/) 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.

### Pros
- No need for the core protocol changes;
- Can be customized for the module's needs;
- Due to stETH mechanics, staking rewards for the bond are socialized;

### Cons
- Partially violates the fourth fundamental bonding principle;

# Problem 1. Bond Implementation
## Context and Problem Statement
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](https://research.lido.fi/t/community-staking-module/5917).

## Decision drivers
- Provide a robust solution for staking modules to implement bond mechanics;
- Do not compromise on protocol security;
- Allow for the release of the [CSM](https://research.lido.fi/t/community-staking-module/5917) and other staking modules in 2024;

## Considered options
Two considered options are described in detail in the first part of the document.

## Decision outcome
Authors are leaning toward [**Simple bond**](#Module-level-bond-aka-“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](https://research.lido.fi/t/hasus-goose-submission-proposed-goals-for-lido-dao-to-consider/5590#proposed-1-year-goals-14), it seems reasonable to select option that will allow to deliver [Community Staking Module](https://research.lido.fi/t/community-staking-module/5917) and partner DVT modules in 2024, leaving [Protocol-wise](#Protocol-wise-bond) for the further upgrades.

# Problem 2. Coverage for the possible negative stETH rebase for the Simple bond approach
## Context and Problem Statement
In the case of Simple bond implementation, a question of the possible negative stETH rebase influence on the bonded tokens should be considered.

## Decision drivers
- Make an informed decision on the negative stETH rebase coverage;
- Do not compromise on protocol security;

## Considered options
### Option A
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.

#### Pros
- No additional complexity is required;
- Minor negative rebase cases can be covered using the Lido Insurance fund for all stETH holders;

#### Cons
- In case of negative stETH rebase, the amount of the bonded tokens provided by the Node Operators will decrease even if their validators were performing well;
- Significant negative stETH rebase might result in the appearance of "unbonded" validators for the Node Operators;
- In case of negative stETH rebase, Node Operators will not be able to claim bond rebase rewards until the total amount of the bonded tokens is enough to cover all Node Operator's validators;

### Option B
Set a dedicated insurance fund for the compensation of bonded tokens.

#### Pros
- To some extent (depending on the insurance fund size), negative rebase might be directly covered for the Node Operators;

#### Cons
- Bad optics in terms of different methods to compensate for the negative stETH rebase for the Node Operators and regular stETH holders;

### Option C
Store `shareRate` on each bond deposit to allow for a proportional bond reduction in case of negative stETH rebase.

#### Pros
- In case of negative stETH rebase, Node Operators will have the option to request bond reduction and will be able to continue claiming bond rewards;

#### Cons
- Bond tokens lost due to negative stETH rebase will not be compensated;

## Decision outcome
Authors are leaning toward **Option A** due to the low probability of negative rebase, the presence of general mitigation measures, and operational simplicity.

# Conclusion
Two options have been considered regarding possible bond mechanics in Lido have been considered with the decision outcome to start with the [**Simple bond**](#Module-level-bond-aka-“Simple-bond”) approach and switch to the [**Protocol-wise**](#Protocol-wise-bond) 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.

# Appendix 1. Related docs
- [Ejecting bad performers](https://hackmd.io/@lido/Sy0nRd36a)