Hey @Porter_Smith, thanks for the great questions and for the continued feedback on this proposal! And sorry for the delayed reply, I’ve been pretty sick the last week with some kind of flu and just recovered.
What if you extended some form of veto right or governance recourse to plain ETH?
We actually thought a lot about including ETH holders. The upside is that it should bring a more diverse set of potential veto participants and thus make the governance more resilient. The downside, however, is that ETH holders naturally have less skin in the game in relation to the Lido protocol so just assigning the veto power to this group may significantly increase the attack surface created by the dual governance mechanism.
For example, imagine a situation where Lido governance has to push some emergency upgrade to fix a smart contract vulnerability. Allowing ETH holders to block this upgrade without risking anything or paying any cost would enable an almost free attack on the protocol.
The last time we discussed this with Eugene (@ujenjt) we came up with an option that we believe might allow ETH holders to participate in the veto and at the same time seemingly doesn’t introduce significant attack vectors. The idea is roughly the following:
- ETH holders can join veto signalling escrow, maybe with a discounted veto power compared to stETH holders.
- ETH holders cannot exit the signalling escrow while Veto Signalling, Rage Quit, or Rage Quit Accumulation state is active, but can switch between supporting and not supporting veto in the Veto Signalling state.
- Veto Signalling state duration depends on the total amount of veto power (in the signalling escrow) supporting the veto.
- The rage quit condition remains the same: more than the second threshold stETH should be locked in the veto signalling escrow. ETH holders alone cannot trigger the rage quit.
- ETH holders can withdraw their ETH from the veto signalling escrow either when the Veto Cooldown state is entered (if rage quit didn’t happen) or when the Rage Quit state is exited (if rage quit happened). This puts them in the same conditions as stETH holders participating in the veto.
So basically, if DAO proposes smth bad for Lido or Ethereum, active ETH holders can extend the DAO execution timelock up to the max veto signalling duration and use this extra time to reach to stETH holders via social channels and ask them to rage quit the protocol.
We might be able to include this mechanism in the initial DG version if time allows.
Could you provide more context on how we plan to arrive at specific threshold numbers for the stETH veto? Is there more background data on how much stETH this is given the overall size of the market? Specifically, have we done an analysis on exactly where this stETH can come from given how much may be locked up in DeFi, cold storage, etc.?
We’re in the process of modeling and analysis so these numbers are just our best guesses for now.
Preliminary analysis shows that around 33% of (w)stETH total supply is held by private addresses, i.e. EOAs and smart contract wallets not belonging to CEXes or custodians.
Could you provide more context on the decision to freely move stETH in and out of the veto state without having to lock it up? Are DDOS attacks prevented by the longer timeline required to execute the entire process (~three months)?
The idea is that we want the DAO and stakers to be able to negotiate and de-escalate while in the Veto Signalling state. The “happy path” scenario is the following:
- DAO votes for a misaligned decision.
- Some stakers trigger Veto Signalling.
- DAO withdraws the decision.
- Stakers cancel Veto Signalling by moving stETH out of the escrow.
The DoS attacks are prevented by the Veto Cooldown state that inevitably comes between the Veto Signalling and the Normal state and that allows the DAO to execute pending decisions.
The most damage one can do without withdrawing stETH is locking the DAO for a duration between
VetoSignallingMinDuration + VetoSignallingDeactivationDuration and
VetoSignallingMaxDuration + VetoSignallingDeactivationDuration, depending on the stETH amount they control.
All stETH that is part of the current Rage Quit (i.e. that was automatically moved from the veto signalling escrow to the rage quit escrow upon the Rage Quit Accumulation state activation or that was moved into the rage quit escrow in the Rage Quit Accumulation state) cannot be moved out of the rage quit; stakers will only be able to withdraw the underlying ETH after all stETH that’s undergoing a rage quit is fully withdrawn and the subsequent
Stakers that move stETH into veto signalling escrow while rage quit is ongoing are not joining/prolonging the current rage quit; instead, having enough stETH in the signalling escrow will lead to Veto Signalling being activated after Rage Quit state ends.
Local vs. global settlement debate: is this basically local settlement (from the previous thread)?
Yes, for this version, we propose going with just local settlement.
While global settlement allows for better protection of passive stakers, it also enables an attacker to destroy the protocol in the worst case, and we don’t feel safe enough to implement this until we have the critical parts of the code (specifically stETH minting and transfers) ossified and/or verified on the bytecode level.
Any considerations for the UX for implementation of veto? This could be very important to average users who may seek to use the veto.
UX is indeed very important. We’re planning to develop a dedicated UI for veto participation that will be open-source and deployed on IPFS. It will explain the current state of governance and veto participation and allow to join/leave veto, join rage quit, and track the participant’s current status and allowed actions.
The goal is that any staker can participate in the veto as frictionlessly as possible without dependence on any trusted party.
What is the penalty for freezing the system? What specific mitigation measures prevent this?
For temporarily freezing the DAO (up to
VetoSignallingMaxDuration + VetoSignallingDeactivationDuration), the only cost is the opportunity cost of locking stETH for the duration of the DAO lock.
Any longer lock will require possessing at least
VetoSecondSealThreshold share of the total stETH supply and exiting this stETH to ETH, thus the total cost consists of the two components:
- The opportunity cost of locking stETH for
VetoSignallingMaxDuration + RageQuitAccumulationDuration + EthWithdrawalDuration + RageQuitEthWithdrawalTimelock (where
EthWithdrawalDuration is the time required for validators to exit).
- The cost of non-received protocol rewards, i.e.
stETH_APY * stETH_amount * (EthWithdrawalDuration + RageQuitEthWithdrawalTimelock).
To lock the DAO for a longer period, the attacker has to:
- Sell the ETH locked for
RageQuitEthWithdrawalTimelock to liquid ETH. This will inevitably come with some discount.
- Sell the liquid ETH for a stETH wallet/EOA that possesses at least
VetoSecondSealThreshold share of total stETH supply for the duration of at least
VetoBalSnapshotShift, OR bribe at least
VetoSecondSealThreshold share of total stETH supply into triggering the Rage Quit Accumulation state.
We’re still working on scenario modeling and attack cost analysis and would appreciate any input!
What are the background dynamics and context for the Tiebreak Committee? Is there any other way to structure this role?
The Tiebreaker Committee was introduced to address the specific scenario:
- An attacker notices a vulnerability in the protocol allowing them to withdraw other users’ ETH.
- An attacker blocks the DAO for a prolonged period by either bribing stETH holders, borrowing stETH on the open market, purchasing, or minting stETH, and using it to trigger the Rage Quit state.
- The Gate Seal committee notices this and pauses withdrawals to prevent ETH theft. Since governance is blocked, this pause will last until the governance is unblocked. But the governance cannot be unblocked until the Rage Quit state ends, and it ends when the ETH is withdrawn. Since withdrawals are paused, we arrive at a deadlock.
In this specific case, and only in this case, the Tiebreaker Committee gains the power of executing any decision the DAO has approved by voting. So this committee does have the ability to bypass stETH veto but it can only do it in a very specific case, and its power is limited since it can only execute decisions that the DAO has proposed and voted in favor of.
Looking at this from an attack modeling perspective, in order to execute a change bypassing the stETH veto, an attacker has to:
- Control the DAO.
- Force stETH holders to trigger a Rage Quit state OR control at least the
VetoSecondSealThreshold share of the stETH total supply.
- Control the Gate Seal committee.
- Control the Tiebreaker Committee.
It’s still a lot of power, thus the committee should be as resilient as possible. For this committee, speed of reaction should be absolutely sacrificed for security since the committee only activates in the doomsday scenario when there’s no need to take any urgent measures as validator exits and ETH withdrawals are already paused and any code upgrades are blocked.
There are various ways of structuring the committee, the one presented in the design overview document is not the only/final one. For example, @ujenjt proposed the following alternative structure:
- Social layer sub-committee: representatives from EF and client teams.
- Validators sub-committee: all active Ethereum validators with voting power weighted by the time since activation.
- DAOs sub-committee: governance contracts of largest DAOs by TVL.
Each sub-committee requires a majority support, and for the super-committee to execute a DAO decision, approval from all sub-committees is required.
In the future, the Gate Seal committee should be replaced by an autonomous and trustless mechanism, e.g. an invariant-based circuit breaker contract, making it impossible to transition the protocol into a paused state (and thus empower the Tiebreaker Committee) without some critical code invariant being broken.
Whether DG can be altered in a way that makes the committee unnecessary remains an open question. We’ve yet to come up with any practical way of doing so and would appreciate any ideas or hints on potential research directions.
In the absence of a token bonding mechanism, are you concerned about malicious LDO proposer not getting punished and being able to repeat their malicious proposals later?
Since the DAO has the power of transferring or burning LDO on any address, it can still punish a malicious proposer in the case the attacker controls less LDO than the active and honest DAO participants:
- An attacker obtains/bribes more than a quorum LDO and tricks the DAO into accepting malicious proposals (or benefits from voter apathy).
- Stakers notice this and trigger Veto Signalling.
- While in Veto Signalling, honest DAO members outvote the attacker and kill all pending proposals, including the attackers’ proposals (by voting for the KillAllPendingProposals special proposal). This guarantees that the DAO won’t be able to execute any proposal before stakers can re-trigger Veto Signalling.
- Honest DAO members communicate to stakers that, after the veto is lifted, they will burn or jail the attacker’s LDO.
- Stakers cancel the veto state. After a timelock, the DAO gains the ability to execute new proposals.
Then, two scenarios are possible. The happy one:
- The honest DAO members submit the proposal for burning/jailing the attacker’s LDO and outvote the attacker.
- The DAO continues normal operation.
The unhappy one:
- The honest DAO members don’t submit the proposal for burning/jailing the attacker’s LDO or are unable to outvote the attacker.
- Stakers re-trigger Veto Signalling and potentially exit the protocol via Rage Quit.
Bonding changes the default outcome of an attack in the case the DAO for some reason is malfunctioning or the attacker controls more LDO than honest and active DAO members. Since opposition from stakers automatically results in either the proposal being killed or LDO being jailed/burned, voter bribing attacks become much less efficient.
Predictability in governance is likely to be very important if we expect non-active stETH holders to pay attention to Lido governance. Has there been any consideration to forcing major votes to follow a set schedule, so that stETH holders know they must pay attention at one particular time during the year, or biannually?
Honestly, I won’t expect the majority of stETH holders to pay any attention to the Lido governance no matter its cadence, and neither do I think Lido governance should rely on this in any form since it’s incompatible with the LST holders’ incentives. DG was proposed in part to address this problem/assumption by allowing a minority of stETH holders who are actively monitoring the DAO to trigger an extended timelock on pending decisions, giving the time for the majority of stakers to react.
I imagine the veto-triggering scenario to be closer to this (and I mean this scenario when I say “stakers trigger Veto Signalling”):
- Lido DAO approves some controversial or malicious change.
- The interested parties notice the change. These parties could be individual stakers but a more realistic expectation is that they would be the protocols/companies integrated with or holding stETH, Lido DAO contributors, and the wider tech community. They don’t necessarily hold stETH.
- These parties socially amplify the information about the controversial decision.
- This information reaches the active minority of stETH holders who pay attention to CT or crypto news.
- Active minority of stETH holders trigger an extended timelock by joining veto and further amplify the information.
- Gradually, less active stETH holders join, potentially triggering a rage quit.
To accommodate this scenario, the dynamically expanding timelock mechanism (as more stakers join) was included in the proposal.
That said, limiting the governance cadence for the most major changes is a good idea since it improves the overall predictability of the protocol changes. To my knowledge, no contributors are currently working on limiting it onchain so it remains a future research direction.
One thing to note here is that some Ethereum consensus changes, especially around staking mechanics, might require some level of support from Lido contracts, and this support almost certainly will require upgrades of core contracts. Since Ethereum forks are not bound to any pre-defined schedule, just pinning major Lido upgrades to a pre-defined schedule most probably won’t work and a more complex mechanism would be required. It should also be synchronized with the GOOSE/LIP processes adopted by the DAO to avoid governance locks resulting from different offchain and onchain schedules.