In the blog The Road to Trustless Ethereum Staking 140iq elite nerds talk about creating a permissionless frame-work for validators to onboard themselves to limit the governance needed, making Lido more permissionless.
I see future problems with how Lido decides which staking tokens to make. Lido is going to be creating many staking tokens in the future. stETH, bLUNA, BETH, stKSM, stDOT, stAAVE, stMATIC, etc.
Each proposal has had different terms, agreements, and vesting schedules. This could become problematic because how is Lido supposed to determine which staking token is more important than others? How will teams building these staking tokens feel when they are getting different deals than other teams?
We should at least get consensus over what terms Lido finds acceptable.
With most of the supply locked up right now we won’t have governance issues but that will change in a year.
For example, Uni is still struggling with energetic minority special interest groups attempting to capture value. Lido’s treasury and voting power will increasingly become more valuable as the amount of power it can weld over a blockchain’s validator set increases. It might be mission critical to automate as much of Lido as possible before more LDO tokens become liquid.
Strongly agreed with this. I think there’s a lot of value in having a set of rough guidelines (e.g. does Lido pay “for the work”, or only for a sucessful outcome? assuming a successful outcome, what is the long term fee split?, etc.). Would happily pay a small LDO grant for someone to review past proposals and make a propose a unified approach
I don’t think we should have a fixed process (blockchains and teams who work for them are unique like snowflakes and require different treatment). But having a “reasonable template” that works for most of them would be good.
DeFiance seconds this approach to fund a formal framework.
Having a formal framework to onboard future staking tokens should clarify and streamline the process. Current dilemmas regarding fee split, performance incentives, payback period can be solved to a large degree.
Some thoughts:
The total incentives can be partially weighted by the potential value brought into Lido (teams successfully targeting a larger market cap PoS blockchain should be incentivised proportionately)
The edited vesting rewards schedule by Mixbytes seem to be fair.
Teams building the staking tokens should be considered a franchise rather than a contractor as the success of the staking tokens depends very much on the team’s continual efforts as well. Lido may offer a small grant amount to cover operating costs.
I think the main value here is to have a way to easily compare various proposals, and also for people wanting to propose integrations to have some default values they can use (e.g. 20% fee share, X LDO paid out at Y$ generated in staking fees, etc.). If specific integrations want to change from these defaults, it makes sense to allow them to, but it forces to highlight why and makes it clear that a specific parameter isn’t standard (which helps when reviewing).
Clearly it seems the sentiment is “no” here
It’s not been decided yet, but it does seem to go in line with Lido’s goal of decentralizing more. Hopefully when it is proposed, after some iterating, there is broad support for adopting it. Maybe a snapshot would be a good thing to do to officialize it?
I think that’s the biggest question for Lido to agree on. I suspect we’re more on the “franchise” side, because it is easier to align incentives that way.
Teams building the staking tokens should be considered a franchise rather than a contractor as the success of the staking tokens depends very much on the team’s continual efforts as well. Lido may offer a small grant amount to cover operating costs.
The proposals so far have this already baked in, with a portion of the fees going to the operator teams.
I wrote up a rough draft for a vesting plan that uses daily revenue that accrues to Lido’s treasury instead of fixed amount of LDO tokens as each KPI is triggered. I have literally zero experience doing this so I welcome everyone to take a scalpel to my idea. I used MATIC as an example and not as something I want to implement for Shard Lab’s plan. Im happy with that plan.
The “marketshare” column shows the market share that a staking tokens must reach to trigger a vesting event.
The “daily revenue*vesting multiplier” column shows the hypothetical daily revenue(in dollars) that Lido’s treasury would be accruing MULTIPLIED by the “vesting multiplier”. The vesting multiplier is an arbitrary number that would indicate the number of days it would take for Lido to break even at each vesting period. For example, at 2.5% market share earning $12,114.67 per day, it would take Lido 30 days to recoop the value of the LDO tokens paid to the vendor.
The “Total LDO tokens paid” column indicates the total amount of LDO tokens vested to the vendor. Using the first example again, at 2.5% market share earning $12,114.67, at 30 days revenue that is $363,440.10, or 83,935 LDO tokens paid to Shard Labs in this example.
The 30 day average price of LDO and MATIC is the 30 days BEFORE the KPI is triggered. I used 30 day average to calculate the price because I was worried that incentivized agents could manipulate the price of each token right before a KPI is reached to increase/decrease the value of LDO tokens paid to the vendor.
In this model, I see the following being debated:
-KPI’s
-Vesting multiplier
-How to calculate the price of of tokens when KPI’s are triggers(ie 30, 60, 90, etc day average price.)
Other thoughts:
I have seen some plans that ask for Lido to pay for development costs if it is determined by both parties that the project is a failure. I think it would be best for Lido to always pay for development costs up front and be done with it. Because of the ambiguity of what is considered a failure, it could cause lots of friction and drama to determine payment after the fact.
Thanks for sharing this! I think this approach generally makes sense, but IMO we should probably bias it towards implementers capturing more upside if this goes well.
Specifically, I think this means that the LDO quantities should be set before a project starts, like now (vs. convert when implementers reach a milestone) and there shouldn’t be subsidies for development costs. If the implementations succeed, the implementers should feel like the ROI for them was very positive, and if it fails, then their cost is capped. If the implementation cost is guaranteed, then it becomes much harder to assess what to pay out when things go wrong vs. just look at the staking metrics when things go right.
Another thing I mentioned to you privately @frontalpha that I want to share here: I think there should be a term in the grant agreements that if Lido suspects the team working on the integration is trying to influence the LDO or staked token’s price to their benefit w.r.t payouts, Lido should have the right to terminate the relationship/agreement immediately.
Finally, another thing worth considering is how to deal with rewards if the staking % drops below a milestone after having hit it (e.g. goes from 15% back to 10%). Either the payment is considered “done” when the milestone is hit, or you could stop the vesting when the % drops below it. The latter approach is more complex to monitor, but may be more robust against gaming number. A middle ground could be that the milestone payment triggers after N days/weeks above the milestone.
The terms should be fair, simple, and friendly. DAO’s taking a verbal commitment there, same as the team. It’s all based on trust, we’re choosing a lifelong partner, not a contractor. Revenue share should take care of incentive alignment, not restrictive payment schedules.
So my feeling is we shouldn’t safeguard too much; our realistic worst case is not “the team is malicious”, but “we lost the market”.
Teams we want for Lido are good
That means that they can make it on their own if need be. They take less risk vs. less upside by going with Lido, but they are essentially good enough to make their own liquid staking product. So the terms must be compared to basically doing a venture, and in the current market, the alternative to going with Lido is quite generous.
What does that mean for the terms template:
needs to feel friendly and partnery, not restrictive
needs to have good potential upside
The “vesting multiplier” framework works good for this; taking TWAP on the day of hitting the KPI is not great for a default IMO, as it reduces potential reward. I don’t like the idea of de-vesting if market share goes down, but I’d support having a “maintain a market share of X for minimum Y days” as a KPI, like we have with Mixbytes and Shard Labs.
So I have read through everyone’s responses and want to summarize what we have discussed.
Realities of the staking landscape
-Lido cannot automate/formalize vesting terms because competition is fierce.
-Lido Partners are very talented and could build staking products without Lido so our vesting terms should be guided by good-faith, trust, and friendship(Obviously). Being restrictive and concerned about the downside risk(like I was leaning toward) will have a chilling effect on Lido integrations.
Vesting terms that have consensus with Lido community members
-Partner should share revenue earned through staking product(ie 10-20% of fees that go to Lido treasury would go to partner that built the staking product)
-KPI vesting amounts should be based on revenue earned by Lido(ie 10-30 days revenue)
-Amounts vested should be set at the time of proposal, not when the KPI is hit.
-KPI’s must be maintained for N # of days or weeks before vesting
What else would you guys like to see in the next partnership vesting terms?
