RFC-0011: Liquid Staking on Mina

[45930]

Rendered RFC

🚀 Introduction to the Innovation

RFC-0011 outlines the need and the obstacles facing liquid staking on Mina

🔑 Why This Change Is Crucial

It is commonly asserted that Mina "already has" liquid staking, but that's only true for the current iteration of the blockchain with no smart contracts. Once users are asked to lock funds in a smart contract or L2, we will quickly discover that there's a tremendous disincentive to do so. Staking rewards are only available to users who keep Mina tokens safely tucked away in their wallet for the long term. Only by strategically moving tokens back to a wallet in time for the ledger snapshot, then back to a smart contract after, will a user get to earn rewards while generally participating in the ZkApp ecosystem.

💭 Seeking Your Input

Everyone involved in Mina should be represented in this discussion from token holders to staking pools to ZkApp developers. Please add your commentary!

[0xstardust]

So true. Staking on Mina is already more liquid than on Ethereum, Cosmos, or Substrate. You're not immobilizing your assets on Mina.

But the issue is still that the yield needs to be claimed. You need a composable yield token that empowers a decentralized array of validators. And further, you need incredibly strong governance wrapping this. LSTs are super powerful and have great product market fit. It is paramount that we build a system where LSTs solve for the "flight to quality" problem and create a composable yield. At the same time, we also need to ensure that the LST doesn't consolidate power into the hands of a small set of node operators and threaten the very network the LST serves.

[teddyjfpender]

Thanks for the PR @45930!

I think there are a few things to consider here to decouple requirements from a potential solution. Here's how I see it:

Requirement: While Mina does have liquid staking, depositing Mina into zkApp smart contracts does not maintain the user's desired contribution to the overall stake distribution (i.e. delegating their Mina to a specific block-producer). More formally:

As a Mina wallet user who interacts with zkApps 
I want to continue delegating to a block-producer of my choice while interacting with zkApps by depositing Mina into their smart contracts
So that I can maintain my desired contribution to the network's stake distribution

Without such a feature, should a zkApp, app-chain, L2, or otherwise acquire enough Mina it can choose the block producer of its choice and significantly impact the stake distribution. Naively I think there are three potential solution spaces:

1. A liquid-staked-token (LST)
   • The most viable LST, in my opinion, would be if as many block-producers collaborated on and operated a single zkApp that minted the same sMINA token for users who deposit MINA into one/some of the contracts (one contract per block producer). Should block producers not collaborate on a single LST this would result in more than multiple possible LSTs; this may or may not be a good thing, for example if one staked Mina token (s1MINA) offered different features/guarantees than another staked Mina token (s2MINA) token. Point being is that any LST's primary feature should be to not compromise the end-user's delegation decision otherwise there would be the same issue as with a regular zkApp.
2. A protocol level-change
   • At the protocol-level there could be a change to the delegation mechanism but this is mostly beyond my understanding. Cardano also has a Ouroboros-family consensus and decouples spending from delegation, any address can be made up of two things: a spending validator and a delegation validator (simply this can be a spending public key and a staking public key). A validator is just something that checks if a redeemer satisfies the validator's constraints; for some validator, v, and a redeemer p it checks v(p) = true -- I think that sounds at least a little bit like Mina! This is a really nice feature and allows for Cardano dApps users to deposit funds to address who's spending validator is a smart contract script and staking validator is simply the user's stake key; dApp users can continue staking their ADA while using the dApp. However Mina is not a UTxO ledger so while protocol changes for this can be inspired by Cardano's end-user experience it would likely look different at the protocol level.
3. zkApps design decisions
   • zkApp developers could allow for users to deposit into multiple contracts specifically for allowing delegation to multiple block producers and have governance features where users can choose which block producers each contract are delegating to and how much; a multi-delegating zkApp if you will. This is a design decision that zkApps would have to implement themselves and may not be desired by some zkApp operators given staking could be part of their own business model.

I think there are more potential solution spaces but these are the three that come to my mind quickly. On a personal note to signify my biased opinions, I am not a huge fan of LSTs, I do not see them as a feature of an ecosystem but as an artefact of a consensus protocol that has chosen trade-offs which lead to allowing for increasing centralisation. There is an opportunity to create something that is innovative and works for well for the Mina ecosystem and I would encourage conversation in that direction first. The additional features that go beyond the above requirement such as paying forward rewards or maximising yield are secondary features to the primary feature which is to maintain the integrity of the end-user's delegation decision and could be constrained depending on the specific underlying solution.

[45930]

@teddyjfpender thanks for joining the converstaion!

I'm not 100% agreed with

As a Mina wallet user who interacts with zkApps I want to continue delegating to a block-producer of my choice while interacting with zkApps by depositing Mina into their smart contracts so that I can maintain my desired contribution to the network's stake distribution

I don't think users, in general, care about their network stake outside of rewards. I think users, in general, care about not getting diluted by inflation. People who are interested in the Mina network, protocol governance, and longevity of the protocol care about stake decentralization and delegated voting power, etc... but not every user cares about those things.

I would suggest:

As a Mina wallet user who interacts with zkApps I want my Mina to appreciate at the same rate as inflation.

I think this further isolates the token holder from a good faith participant in Mina. Our job as the latter is to design something that meets this need for users while retaining the properties we want to be good for the network.

The most viable LST, in my opinion, would be if as many block-producers collaborated on and operated a single zkApp that minted the same sMINA

Yes, personally this is where I'm leaning, but in my ideal, it's not a consortium of staking pools, but a protocol that can be implemented by anyone. For instance, maybe under the hood there is some complex token network, or state that is BP-specific, but they all roll into a single ZkApp with a single user-facing token. Consider something like DAI which can be backed by any asset, but produces a single interface token. A Mina LST would be less risky than DAI because funds are always secure, and the only bad action a BP can take is to not send rewards for an epoch.

Another problem I see with base protocol staking is it's discrete and latent. It's "liquid" in the sense that you can always withdraw your funds, but you will miss out on rewards if you withdraw right before the staking snapshot. This is confusing. An LST could wrap this discrete process in a continuous one via market forces (demand for sMINA increases closer to payment date, or exchange rate between sMINA and MINA improves over time, either mechanism is better for token holders).

3. zkApps design decisions

This is the de facto option, and what drove me to bring this topic up. Staking pools hate paying out rewards. It's constantly something that comes up in zk ignite proposals. Making zkapp devs track staking delegation and user payouts is a worst-case-scenario for me.

[teddyjfpender]

@45930 -- I'm only highlighting one requirement for a specific user persona, of course there are multiple.

I should clarify, I'm advocating for eliciting requirements for each user persona interacting with the network, that includes and surely not limited to just wallet-users, block producers, and zkApp developers. Indeed they'll all have different preferences, as you mention:

• some wallet users may care significantly about just the reward distribution
• some more inclined to protocol longevity and governance
• block producers could prefer automated reward distribution

To discover solutions, the ecosystem must elicit each user personas requirements, there is not just one correct user story but many, like the two we have here already. Solutions of course have trade-offs and for the ecosystem to convene on a solution would require understanding the trade-offs.

Another problem I see with base protocol staking is it's discrete and latent.

A less discrete and less latent protocol would have trade-offs, for example if epochs were shorter nodes would have to perform epoch boundary calculations more often. A solution like an LST that is less discrete and less latent would have different trade-offs, for example if an LST guaranteed a 3% return during one epoch but only produce enough blocks for a 1% return does that not leave delegators at risk of MEV? Or rather if an LST guaranteed a 1% return during on epoch but consistently produced enough blocks for a 3% return does that not exploit/disenfranchise delegators or is any different to a higher block producer fee? Again I'm advocating for good requirements elicitation to better serve the ecosystem with as much information as possible about could make the most sense.

It's "liquid" in the sense that you can always withdraw your funds, but you will miss out on rewards if you withdraw right before the staking snapshot. This is confusing.

This is likely confusing for end-users because the "liquid" nature of Mina staking is not the same as "liquid" staked tokens elsewhere (e.g. lDOT or Lido's product). The vernacular we use in the Mina ecosystem does not map 1:1 to the vernacular used in other ecosystems, be it Ethereum or Cardano or elsewhere. There are almost two features commingled together in its "liquid" nature -- the ability not to "withdraw" but to change delegation preferences at any time is the "liquid" feature, in that sense the delegation to a BP is "liquid", it just so happens you can send MINA anywhere while you're still staking so it is also "liquid" in that sense too.

[kantp]

Hi @45930, thanks for the PR!

I agree with @teddyjfpender that it's best to take one step back, and solicit clearly the requirements that different user personae have around the delegation and rewards system as a whole (where "delegation and rewards system" includes protocol level features and zkApps that might be developed specifically). Off the top of my head, I see six user personae:

1. Owner of Mina tokens mainly interested in getting rewards
2. Owner of Mina tokens with a broad interest in Mina itself
3. Block Producer
4. Developer/Maintainer of a large zkApp, expecting to control a large number of Mina tokens (such as a bridge, L2, Appchain, ...)
5. Developer of a smaller zkApp
6. The Mina system (wants to be secure, performant, and not overloaded)

There might be more, but I think those are the most important ones. We already stated a couple of requirements from some of them in this RFC and thread. Having a more complete list will make it easier to come up with and evaluate potential solutions. My intuition is that it will be best to consider this together with what's discussed in #9: the way that rewards are distributed by the system (again, either protocol or specific zkApps) will have an effect on what we are able to offer in terms of handling rewards for tokens that are locked in a contract.

My suggestion is to produce one rfc that lists all the requirements we can think of (could be an extension of this one). With that, we can invite people to come up with designs that require a sufficient subset of them. I'm happy to contribute, I did do this before for another system. What do you think?

[45930]

@teddyjfpender and @kantp thanks to your comments I realize I was mistaken to include staking pools in my motivation section. The existing RFC-0005 #9 is the appropriate place for that persona to be captured. I agree with what you two are saying in general about staking in the protocol and making decisions about the protocol that consider every viewpoint. But this RFC is about addressing a specific, pressing need specifically for token holders: any usage of Mina tokens other than parking in a wallet results in loss of value.

To be clear, the explicit goal of this RFC is to solicit feedback from the community. It seems we're agreed on that, but I'm not sure what is meant by "taking a step back".

Intent: Solicit feedback from relevant stakeholders and understand how to move forward on liquid staking

---

@teddyjfpender responding to you here:

A less discrete and less latent protocol would have trade-offs

Agree, I am leaning heavily toward not conflating the L1 staking protocol and this separate liquid inflation-protection mechanism. IMO there is the L1 staking mechanism which is used for PoS consensus, and sometimes overloaded for voting as well, then there is an inflation-protection mechanism which is decoupled from consensus and voting entirely and only exists to encourage users to add liquidity to the Mina ecosystem.

for example if an LST guaranteed a 3% ...

This is getting into detail about what an LST even is. Does it have guarantees? Does the token price inflate or is the token holder eligible to claim rewards, etc... The existing baseline is the L1 delegated staking mechanism, by which no guarantees are made. It's entirely valid for a staking pool to stake with a large delegated balance and never pay out any delegate. So I would reject a requirement that an LST does any better than that, such as a specific guarantee of reward. I would suggest the only requirements for this mechanism are that

1. rewards are synchronous (not delayed by 1 month) and
2. that the obligation is transferable (can be supplied to a zkapp, app chain, or sent to another user)

Though I am open to other requirements of course, which is why I opened the RFC. Coming from the PoV specifically of a token holder, and letting go of every other persona for now, does that spark any new requirements in your head?

---

@kantp responding to you here:

Off the top of my head, I see six user personae

If we tighten the scope of this RFC to an inflation-protection mechanism, and forget about previous conceptions of what an LST is, then we filter down to one relevant persona: 1. Owner of Mina tokens mainly interested in getting rewards - do you agree?

My intuition is that it will be best to consider this together with what's discussed in #9: the way that rewards are distributed by the system (again, either protocol or specific zkApps) will have an effect on what we are able to offer in terms of handling rewards for tokens that are locked in a contract.

Thank you for bringing #9 to my attention. I realize that I was overloading my proposal to include staking pools as a potential persona. In fact, that pre-supposes some implementation detail of an inflation-protection mechanism.

I disagree that these threads should be "considered together" in any way. Any potential protocol change for staking pools should be done carefully, and the current implementation of staking is fine as-is (there are hundreds of high quality nodes running the Mina network). The inflation-protection mechanism, on the other hand, is an urgent need to attract users to Mina, and an implementation with rough edges that meets some basic criteria would be acceptable in the short term. That is why my goal is for Mina to actually sponsor an RFP to implement some inflation protection system after enough feedback and requirements have been gathered on this RFC.

[45930]

My latest commit: cc3ed14 includes some changes, including replacing liquid staking with inflation protection in some places and removing the section about staking pools.

[0xstardust]

This is really thorough. As I try to keep up with this, the big decision/blocker is how delegation rewards get paid out trustlessly via RFC005.

Liquid staking on Mina will be a huge success. At Kintsu we are very interested in building it so rewards are infused into other DeFi activities across a wide variety of L1 zkApps (ex: Lumina) and beyond with Zeko, ProtoKit, etc..

If you agree that it will be a huge success, the next question is how to build this responsibly. You get the composable yield effect, but then how do you make sure the liquid staking protocol delegates to a wide array of validators? This is the real advantage of Kintsu, where our solution promotes further decentralization through on-chain governance

[EmrePiconbello]

So how about this? Since we are discussing the utilization of the yield and rewards, we don't require a liquid staking protocol because we already have liquid staking. The 2 epoch reward delay is not something we can adjust because it's a protocol level issue. Without a protocol-level staking or any kind of staking improvement, as mentioned here #9, we shouldn't have any protocol collecting all stake and splitting it to block producers. We don't know which validators are online, we don't have any conclusive way to measure performance outside VRF, and we have a lot of variance due to luck. If the way of doing it just going top 5-10 validator than that's worse since it will increase stake concentration more. Considering the limitations we already have, I don't see how it can be handled in a trustless manner. Maybe I am missing something.