HackMDStETH rebase design questions
Q: Would stETH be considered a "supply elastic" token (like AMPL where supply might increase/decrease to maintain a target value)? Or do holder balances increment simply as a means of distributing staking rewards?
A: StETH isn't "supply elastic" in a sense AMPL is, as it's total supply isn't tied to any specific target value. Total supply & holder balances represent the ETH staked with Lido (funds buffered on the Lido smart contract + funds in deposit queue + the amounts staked with Lido Beacon chain validators). The staking rewards are distributed via rebase of the holder balances. The supply and individual balances do change regularly, though.
Total supply and individual balances change when:
- staking rewards are reported by oracles, changes upwards a bit (limited by 10% APR, so about 0,03% per day). Current settings can be checked on the Oracle interface here: https://mainnet.lido.fi/#/lido-dao/0x442af784a788a5bd6f42a01ebe9f287a871243fb/, and the design for the sanity checks is detailed in the proposal: https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-2.md#sanity-checks-the-oracles-reports-by-configurable-values
- slashing is reported by oracles, changes downwards, no more than 5% in one day. Never happened.
- (not implemented) After the merge, when priority fees and MEV earnings are accounted for
Total supply also changes, without effect on all individual balances, when: * not totally true - rounding can change 1 wei rounding or so
- Ether is staked through Lido, total supply increases
- stETH is burned, balance decreases
- (not implemented) when withdrawals are implemented in Ethereum protocol, total supply of stETH changes stETH is unstaked
Q: If it is a reward distribution vehicle, is there a reason why this is done through rebasing as opposed to an on-chain operation?
A: We've got over 20k holders atm, and there will be more - there's no sensible way to change these balances one by one. As the staking rewards are distributed between all the stETH holders, doing so with direct transfer calls would require an unbounded loop. The StETH smart contract is designed to increase all holders' balances in one tx, so can't use direct transfers and is performing a rebasing instead.
Q: Do you have any other docs / data you can share related to the rebase mechanism?
A: General StETH design overview can be found here: https://blog.lido.fi/steth-the-mechanics-of-steth/
Rebasing is explained in Lido.sol docs: https://docs.lido.fi/contracts/lido#rebasing
Q: I see that some DeFi protocols support this rebasing behavior (Curve, Maker, Aave) while others do not (UniSwap) – do you have any background on how some of these DeFi platforms have solved for rebase support?
A: There are two tricks to working with rebasable tokens, depending on the protocol design: one is never cache the token balances, and always re-query them; and the other is to do bookepeeng in constant "shares".
Note that for DeFi protocols not supporting rebasable tokens Lido has WstETH token (essentially second approach wrapped in token form) — the non-rebasable StETH representation. It's integrated into Maker, and the Balancer, Sushi & 1inch pools are using this tokens instead of StETH. WstETH is better suited to be bridged across different blockchains and to L2s as well. StETH offers significantly nicer UX though, as users don't need to wrap/unwrap tokens.
On AAVE Lido is preparing tho integrate StETH, but the custom aToken contract is required to pull this off.
Q: Is there any noteworthy element related to the oracle report dependency that we should be aware of?
- The balances can decrease if the total penalties from the last report are bigger than the staking rewards accrued for the same timeframe.
- While the reports happen mostly in ~24h intervals, that's not the protocol restriction. For instance, there could be edge cases where the Beacon chain doesn't reach the finality for significant amount of time preventing the Oracles from getting "verified" total balance.
- Oracle reports are bound by sanity checks
