Optimizing Liquid Staking for Celestia

Research
1

The Liquid Staking Conundrum

Liquid staking has proven to be a pivotal, even a necessary component of Proof-of-Stake (PoS) economies. The model of liquid staking adopted by a chain significantly influences various facets like stake distribution, decentralization, governance control and security.

Given that the model of liquid staking has a profound impact on the dynamics on the chain, it is useful to define what the optimal liquid staking solution for Celestia looks like. A solution that takes a measured approach to achieving capital efficiency with staked TIA.

Tracing the Roots of Liquid Staking

Ironically, Centralized Exchanges (CEXs) were the initial enablers of liquid staking. Opting to stake assets with a CEX afforded users the luxury of earning staking rewards without the customary token lockup, courtesy of the non-custodial nature of CEXs. This posed a serious risk as users might move capital to non-custodial solutions over self custody; which hurt the fundamental ethos of blockchains.

Liquid staking was largely a countermeasure to this problem. By letting users mint a derivative token off their staked assets; they could achieve similar amounts of capital efficiency without losing custody over their assets.

Delving into Interchain Accounts

The advent of Cosmos SDK chains and Inter-Blockchain Communication (IBC) surfaced new design considerations. How does a single liquid staking protocol serve numerous sovereign chains? Interchain Accounts (ICA) was the pioneering solution. For the first time, it enabled one chain to tether to another, presenting a liquid staking product through this linkage.

However, this model of liquid staking is not without issues. The chain actually executing the liquid staking logic is not beholden to the validator set of the chain it onboards. This creates notable external risk, especially if a large percentage of stake was liquid staked. (This is the direction PoS chains seem to be heading in). This makes the liquid staking centralization problem a lot more pronounced as the centralizing protocol now lays completely beyond the control of the chain’s validators.

A further challenge emerges in the realm of control over stake allocation and the economic dynamics of validators. The external liquid staking protocol assumes a commanding role, possessing the authority to determine which validators remain active within the set and the extent of their voting power. This situation economically binds the loyalties of validators to liquid staking protocols, as opposed to TIA delegators, who serve as representatives of the wider community. Consequently, this could pave the way for a divergence of incentives, wherein the objectives of validators and community representatives potentially misalign.

Navigating Through Potential Solutions

Within the Cosmos Hub community, several solutions, notably the Liquid Staking Module (LSM) and Interchain Security (ICS), have emerged to navigate these issues.

LSM

The LSM is a module that lets users mint non-fungible tokenized delegation shares. These delegation shares are then consumed by a liquid staking protocol to issue a Liquid Staking Token (LST). Although LSM’s primary allure is enabling users to seamlessly transition their stake between staking and liquid staking positions, from a security perspective, its potential to deploy logic that regulates liquid staking is equally noteworthy. Presently, the LSM does this by instituting a global liquid staking cap and validator bond requirements for validators to be eligible for ICA delegations. These measures are meant to slow the pace of liquid staking.

While this method curbs liquid staking in the short term, it doesn’t offer a viable long-term solution to align liquid staking markets to the chain community that it serves. It restricts the capital efficiency benefits provided by liquid staking and places centralized financial requirements on validators participating in liquid staking.

ICS

Interchain Security, a feature intrinsic to the Cosmos Hub, allows it to lend its validator set to a consumer chain. Thus, the consumer chain inherits security from the Cosmos Hub ensuring that liquid staking remains fundamentally governed by Hub validators. This validator overlap provides greater control and creates value alignment between the liquid staking protocol and the Cosmos Hub.

Though the Cosmos Hub lets governance be done by consumer chain governance tokens; in theory a consumer chain with no governance token would be the better solution as it prevents the problem of stake distribution mentioned above.

Contextualizing Celestia

With the Celestia chain launching soon, it is important to think about some of these security and alignment trade offs that come with unbridled liquid staking. The imperative for a Celestia-aligned liquid staking protocol becomes more pronounced and complex because Celestia does not have an execution layer. Most liquid staking implementations remain beyond the control of Celestia validators. It is our opinion that liquid staking on Celestia should be within a shared security framework wherein the Celestia validators and TIA stakers completely control the liquid staking protocol.

In addition, this protocol should also economically align itself with Celestia to create maximum utility for liquid staked TIA in the roll up ecosystem and beyond.

There are a few options on how this can be done:

  1. Developing a Custom Native Staking Module: Implementing a custom native staking module on Celestia, which mints a liquid staking derivative: This option would provide the highest security guarantees as the protocol is completely within the security apparatus of Celestia. However, the Celestia chain was meant to be minimal; so introducing app logic on the chain might deviate from the vision of the chain.
  2. Implementing a Liquid Staking Roll-Up: A liquid staking roll-up, especially one that shares security with Celestia and aligns at the sequencer level with the main Celestia chain, emerges as a plausible solution. It would be ideal if the governance token for this liquid staking protocol was liquid staked TIA. This ensures that liquid stakers themselves have say over the operations of the protocol.

Conclusion: Whitelisted ICA

In conclusion, the outlined discussions and design alternatives should be pivotal in deciding the activation of ICA on the Celestia chain. It might be prudent to have permissioned ICA, wherein only governance (or any other social consensus) can agree upon individual ICA connections based on their purpose and the product that ICA brings to the Celestia chain. A more robust mechanism for selective ICA deployment can be figured out in the future that does not rely on social consensus for every ICA connection.

This permissioned approach to enabling ICA can lead to a dialogue within the Celestia community about TIA’s liquid staking future and help keep track of risks as we launch and move forward.

5 Likes
2

This is a timely post with respect to the conversations in the Ethereum community regarding Lido.

Because a liquid staking protocol can have such large economic and social influence over the base protocol, I tend to think that it’s better to enshrine liquid staking natively in the base protocol so that it’s aligned with, enforced by and governed by the same underlying community as the base protocol. From that perspective developing an native liquid staking module would be preferable to outsourcing it to another chain or rollup.

You bring up a good point though that a native liquid staking module could introduce too much application logic or state which would go against one of Celestia’s core values. That said, my hunch is that liquid staking doesn’t need to create much additional state (just an additional token balance per participating address) and the app logic could be made relatively simple as well. Someone more informed should weigh in on this point.

Whatever path the Celestia community chooses to pursue to support liquid staking will have large impacts on the future of the protocol, so different options and their repercussions should be carefully considered.

Aside from LSTs, are there other use cases for ICA that you think are relevant to Celestia?

3 Likes
3

Hey Nick, thanks for the reply! Definitely some interesting points raised. So in general, I agree with the direction of maximizing alignment between the liquid staking protocol and Celestia; and from a technical perspective running the protocol natively is probably a good way to do this. Though, there are some downsides to ‘enshrining’ a liquid staking protocol on the base layer. Liquid staking, is a consumer facing financial product that drives substantial DeFi utility to the base token. Historically, liquid staking protocols run by fully equipped specialist teams have done a far better job at taking LSTs to market and achieving base token growth than chain run protocols. Though I’m not sure if ‘enshrine’ here means chain run. Kava and Crescent are a few example I can think of where their LSTs are relatively insular within their ecosystems and have not managed to find substantial use cases elsewhere.

An important element here is probably the presence of a liquid staking token (governance or a fee capture token). Protocols with liquid staking tokens have performed far better than ones without tokens. A successful LS protocol requires a lot of liquidity and integrations; all of which require incentives, marketing and partnerships with DeFi teams and communities. One example I can think of is Lido on non ETH chains, due to the governance process of getting LDO bridged over, non ETH LSTs received less incentives which stymied their growth when compared with native providers who were able to create substantial utility for their LSTs. I don’t think TIA should play the role of an incentive token as TIA governance is bound to be (rightfully) conservative and risk averse with incentive plans. The capital benefit of having a token also leads to a better equipped liquid staking team, which is also a plus for security. I also don’t think liquid staking on Celestia should be governed by any token other than TIA, so in this case a fee capture token with other utilities might be the better choice.

Another reason, why I would suggest a semi-external entity doing liquid staking is because of the work it takes. Constant security monitoring, active maintanence, user support, DeFi integrations development (bridges, oracles, feature changes, etc). There is also a need for managing economic risks with liquid staking. Again, I am not sure if the Celestia chain or a core contributor of Celestia should be taking this on. I know there is a ‘regulatory’ angle to this risk, but that’s not really my area of expertise.

For these reasons, I think a native liquid staking module on a technical and political level makes complete sense. But I think we need to address the business and product deficiencies. Here is how I would address them if we were to deploy a native protocol. The way I see it, there are two problems with a native implementation.

  1. Who / what token community does BD, integrations, maintenance, incentives, upgrades, liquidity bootstrapping, etc.?
  2. How is stake distributed amongst validators?

For the first problem, I would propose non governance DAOs (ironic, I know) as shared security roll ups. These could be a whole new class of roll ups that are fully governed by TIA but can have their own token, business model and team. So the TIA community can bestow a mandate to these quasi independent teams. The idea here is to get the best of both worlds, full alignment and governance control + an independent profit motivated team offering critical services to the TIA community. This model can be used beyond liquid staking for any security critical product / feature.

The second problem is trickier to solve, governance is an obvious solution. But TIA stakers voting on TIA stake distribution might lead to centralizing patterns. The ideal system is here is to let delegators choose their own validators, but this would require adding a lot more custom logic and would only be possible as a roll up without expanding state on Celestia. As you rightly pointed out, a custom, native deployment has to be kept very simple. I could see ways to outsource some complexity to rollups while still maintaining a native implementation; but seems complicated and needs to be fleshed out.

With regards to the ICA question, ICA can technically be used for other things like cross chain DEXs, yield aggregators, etc. So far, I think liquid staking has been the predominant use (other products haven’t been shipped yet afaik). A good approach to ICA could be to enable it whenever possible but not enabling any message types. Teams which want to utilize ICA can turn on the message type through governance and the community can judge case by case on the utility and evaluate risks.

4 Likes
4

I think a large problem with enshrining a fungible LST, is that it requires delegation management.

Different users may have different preferences. Some may prioritize factors such as uptime and preexisting reputation, others may prioritize factors such as community alignment or contribution. As such it’s difficult to create a perfect, automated solution for delegation. If the Celestia protocol is to try to implement one for the inclusion and weight of validators, it risks introducing subjective biases into the token. Users who don’t agree with these biases, will desire a market for LSTs with different delegation policies as a result.

In the extreme you could embrace the Celestia protocol’s role in taking a more hands on approach to inclusion and weight distribution by taking a “Proof of Governance” approach (h/t @JonCharbonneau). But this approach would probably be controversial given the magnitude of change this would impose on participants and stakeholders in the Celestia protocol such as token holders and validators. Not to mention the technical and social implications of needing a robust governance process to allocate stake and weight.

I lean pretty heavily towards believing that the best solution is to have an LSM-like mechanism that promotes maximum competition between staking derivatives and strong social culture for choosing liquid staking protocols which dedicate the most resources to factors like security and Celestia’s ecosystem development.

3 Likes
5

Incredibly high quality comments all round. This has been a topic I’ve been pondering in general for a while, and have been excited about proposals that have sought to bring LSM style mechanisms to Ethereum for that vey reason. However the truth is, even with a great easy acronym, LSM is far from ready to just purely be deployed and be done with it. Lots of those issues have been mentioned earlier above.

However, the good side of these problems is that as a CosmosSDK chain, we are not alone with these needs. It seems pretty clear that there is need to develop the LSM further to allow for things like LST gov token support, delegation markets, slashing insurance, just to name a few.

This makes me thing that maybe Celestia could partner up with a CosmosSDK related public good funder to issue an RFP for a project like this? Possibly Atomaccelerator for example?

6

You could potentially solve the delegations question by adopting an intents based model. In such a model, users would be able to pick which validators they would like the protocol to delegate to and the protocol would reflect their intent. With Interchain Queries, this can be done at scale with assets held across multiple chains.