This improvement proposal provides a way for Lido governance to burn stETH as a means to distributed cover for losses to staking. It doesn’t oblige Lido to cover for losses or introduce any auto-cover mechanism; just provides a clean option to use cover if DAO ever deems it necessary.
Currently, Lido has no adopted and well-defined mechanism of applying coverage for stakeholders’ losses due to validators penalties, slashing, and other conditions.
There are discussions and research on coverage options that took place earlier:
To precisely specify coverage application without breaking existing principles, agreements, and integrations with stETH token (as a clear example we have in mind Anchor/bETH) we propose an in-protocol solution. The proposal is aimed to improve the overall technical transparency and completeness of the Lido protocol regarding a coverage application.
Proposed solution
We propose an on-chain in-protocol mechanism of applying coverage by burning stETH token (which may sound frightening at the first glance). The burn is limited by design with governance permissions hardened with fine-grained control: it could be invoked only by the proposed dedicated contract and only on its address.
To mitigate possible issues with external integrations we define exact time slots for the coverage application and provide externally available counters of ever burnt stEth.
Use cases
The proposed solution can be used to implement the cover cases (I mean after mass slashing/penalties events) and the non-cover cases (possible underperforming cases or rare penalties when there is no balance decrease between the consecutive Lido oracle reports).
After all, to be precise, it’s an application mechanism definition, not a cover solution itself. The proposed solution is suitable for enacting both self-cover options, so for external 3rd party insurance providers.
Specification
Formal specification and further details provided on the LIP GitHub repo.
To make sure I am understanding this correctly. @TheDZhon you are proposing to market buy stETH and then burn it pro-rata to the loss event in order to increase balances of the remaining account holders?
I think it is a clever approach and of the 3 proposed in the LIP repo I like this one the best as it appears the simplest to understand from a user perspective with only a modest amount of technical overhead.
You got the common scheme, yeah. But I’d say that proposal is more about the technical side for increasing stETH balances because the way we could grab stETH should be defined depending on the cover/non-cover event.
For example, instead of market buy we also could get stETH directly from Lido treasury (if DAO has quorum on the particular case, of course) or, someone who got penalties and decides to reimburse it could provide us already collected stETH.
Chorus One recently provided reimbursement for downtime that cost stETH holders to forego some staking rewards they otherwise would have received. It seems like your proposal is the same idea, just slightly different and maybe a more formal process. Would you agree or do you view your proposal as something new entirely?
I actually don’t understand why burning stETH is seen as the best method to give value to other stETH holders. If stETH is intended to represent a 1:1 claim on the ETH locked up in the staking contracts (I think it is anyway), why is it better to break that relationship by burning stETH as opposed to sending funds directly to the staking contracts themselves? Would stETH be rebased following the burn so that existing holders eventually see an increase in stETH balances proportional to what was burned?
I could be missing something very obvious in both the example I shared and your proposal…
I would propose to rename this proposal as it’s a bit confusing. This LIP is about implementing a technical mechanism for burning stETH in an in-protocol way (or rather changing/“improving” the current mechanism) to track how much has been burnt and for which overall reason (cover / non-cover).
The source of actual funding in the case of a “buy and burn” isn’t in the scope of the proposal (it may be through treasury, it may be via a 3rd party as in the case with Chorus), and although I think that’s clear after reading the post and the spec, it would be good to somehow distill this in the subject/topic to avoid confusion.
Yes, exactly. The main change in this proposal is that it introduces a way to distinguish a “profit” rebase from “loss compensation” rebase for protocols that do need to distiguish these two things, e.g. Anchor Protocol.
The proposal has no presumption of when and how exactly loss compensation happens - just introduces a change to make this possible in a way that’s understood by 3rd party protocols.
I should mention, to be precise, Chorus One reimbursement will be burnt today if and after the Lido DAO voting process is finished with a quorum. This would lead to a positive stETH rebase for all token holders and this particular case is a non-deal-breaker for the 3rd party integrations.
In terms of the topic proposal, it would be a non-cover request type.
I like this proposal. However, I would suggest two things:
Make requestStETHBurn permissioned. Burning tokens is not part of any custom use cases and is not easy to roll back action. Therefore, to avoid accidental triggering and misinterpretations, I would like to allow only voting to burn tokens. Additionally, it seems like a good idea to split requestStETHBurn into two methods instead of a boolean flag isCover.
The mechanism is based on the assumption that the burning of the stETH takes place in one transaction with the oracle report. For this, the contract implements the IBeaconReportReceiver interface. Thus, after the deployment and installation of the delegate, this slot will be occupied. I propose to develop in advance a mechanism that supports the ability to install multiple IBeaconReportReceivers.
My thoughts on the first point: sure, we can make requestStETHBurn permissioned to prevent various unforeseen circumstances and misinterpretations, and looks like we should do it. Perhaps we could split requestStETHBurn into two methods also, but maybe it is more a matter of taste.
On the second point: yep, I agree. I propose to implement and audit a possible adapter to support multiple beacon report receivers, but don’t deploy it with this LIP yet to stick with the KISS principle.
Yeah, I think that we really need another specification of a simple contract that would be installed as the beacon report receiver and that would allow passing the invocation to a list of callbacks managed by the DAO.