Moving toward safer and more aligned TIA liquid staking

[aidangs]

Moving toward safer and more aligned TIA liquid staking

Ensuring Celestia liquid staking protocols (LSPs) are safe and aligned is necessary for base layer stability and decentralization.

TIA’s staking APR and utility as a monetary asset on rollups will drive long-term demand for liquid staking tokens (LSTs). MilkyWay recently launched the first TIA LST, which currently secures ~440k TIA with a 5/7 multisig. In the future, it’s likely that CEXs will also launch TIA LSTs (similar to cbETH) given their high PMF and profitability for exchanges.

Unfortunately, both options introduce unnecessary trust assumptions and misalignment with Celestia’s own governance. This is problematic. However, prohibiting such external solutions is neither technically nor socially viable, as doing so would oppose several of Celestia’s own core values.

This post will explore the design space for LSPs that best serve those values. They must be designed with Celestia’s own interests in mind as their sole objective. This means ensuring that such protocols are maximally aligned with Celestia’s own governance and carry minimal trust assumptions.

We at Stride are building a decentralized LSP for Celestia with exactly these goals in mind, so receiving the community’s input here is essential. The Stride protocol has reliably provided the leading LSTs across IBC-enabled blockchains for over a year now, but we appreciate that Celestia has very unique needs relative to other Cosmos chains.

We propose activating interchain accounts (ICA) on Celestia on an accelerated timeline as the most prudent step to enabling decentralized and aligned LSPs. A forthcoming CIP will propose the activation of ICA.

This post will discuss how ICA enables Stride to make Celestia’s liquid staking ecosystem healthier today, as well as how we can work together beyond that to create the optimal long-term solution for Celestia.

What differentiates liquid staking protocols

Celestia LSPs can differ radically on several dimensions, including:

• Trusted committee vs. trust-minimized
• In vs. out-of-protocol
• Validator selection strategy

In gathering feedback from many Celestia contributors and stakeholders, we’ve concluded that Celestia’s interests are best served by an out-of-protocol LSP which is trust-minimized in its design and cedes ultimate governance power to Celestia’s own community in some form. Although the ideal, trust-minimized solutions like SNARK accounts and zk-IBC will take time to design and build, any Celestia LSP should meet the following criteria:

1. Reduce trust assumptions as much as possible (using the most decentralized, trusted committees available)
2. Ensure the Celestia community ultimately governs the LSP, especially validator selection
3. Use battle-tested, observable, audited protocols

Anything less than the above should be considered against the interests of the Celestia community.

The solution space

As a blockchain optimized to provide high-throughput data availability to rollups, Celestia seeks to minimize base layer functionality and therefore lacks a general-purpose execution environment. Additionally, Celestia does not currently support IBC for tokens other than TIA. As a result, implementing a TIA LSP requires adding it natively to the Celestia base layer itself (enshrinement) or implementing it offchain (on a rollup or other blockchain).

An enshrined LSP may be the most aligned option, but it risks adding base layer overhead and increases the scope of onchain governance. At minimum, it would require extensive time and research to implement safely while incorporating a diverse range of stakeholder preferences.

This necessitates offchain LSPs, where the path of least resistance is to launch with unaligned multisig governance and quickly gain market share instead of prioritizing alignment with the values and interests of the Celestia community.

Current Options - Multisigs & CEXs

Of the trusted committee solutions, CEX-issued LSTs and multisig LSTs (e.g., MilkyWay) are the least healthy for the network. They come with several tradeoffs:

• Custodians or multisig participants can have arbitrary upgrade powers, including theft of funds. They lack decentralized governance.
• Multisig key management is inherently complex. Over $1B has been stolen from multisigs due to compromised private keys (Ronin, Harmony, Mixin, Multichain, etc.). While some steps can be taken in an attempt to minimize risk, multisigs remain fundamentally suboptimal in the trust they require from users. No PoS chain has suffered such an attack to our knowledge, because validators are distributed (socially and physically) and typically use MPC software like Horcrux to ensure keys are both highly available and secure.
• Neither centralized custodians nor multisig signers are slashable. Breaking protocol rules has no onchain consequences. Even more decentralized options such as ICAs don’t solve this entirely on their own though. Some form of dual governance must also grant control to Celestia stakeholders to provide accountability.

Although both options are suboptimal for network health and trust-minimization, a major risk for the Celestia community is that the market simply doesn’t care. Time-to-market is crucial for LSPs, and apps such as Blast demonstrate that market participants are willing to deposit large sums into multisigs (~$1.1 billion at time of writing) with glaring security concerns.

Short-term best improvement - Interchain Accounts (ICAs)

Interchain accounts (ICAs) offer the best path to more trust-minimized, battle-tested LSPs in the short-to-medium term.

The gold standard for interoperability is IBC. IBC allows for flexible client types, such as solo clients, Tendermint light clients, and VM light clients (see recent work on the WASM light client, which could enable a zk light client). The trust properties of an IBC connection depend on the underlying light client.

Stride has an existing Tendermint light client and IBC connection on Celestia with excellent trust properties.

• Stride uses interchain security (ICS), which means the Cosmos Hub validator set runs the Stride protocol (one of the oldest, most decentralized sets) and the Stride light client on Celestia uses the Hub validator set for header updates
• The validator set has significant overlap with the Celestia validator set
• The Stride protocol remains fully sovereign, governed by Stride stakeholders and governance (not Cosmos Hub governance)

Long-term endgame - SNARK accounts & zk-IBC

Celestia’s liquid staking endgame isn’t yet clear. However, referencing Celestia’s core values, we do know that it should be trust-minimized, give power to the Celestia community, and minimize base layer technical complexity.

Long-term, there exist (at least) two trust-minimized approaches with promise:

1. LSP built as a Celestia zk-rollup that leverages SNARK accounts. While SNARK accounts are still in spec form, we expect them to ship in the next 12-24 months. This would allow zk-rollups to control accounts.
2. LSP built as a Celestia sovereign rollup using a zk-IBC client on Celestia and ICA. Light clients can be upgraded through hard forks, and Stride’s current Tendermint light client could be migrated from a Tendermint light client to a zk-IBC light client. Stride contributors are working with Sovereign Labs to spec out this migration path, which we’ll describe in a separate forum post coming soon.

Celestia should govern the liquid staking protocol

TIA liquid staking must be as accountable as possible to the Celestia community and aligned with its values. Concretely, we think the Celestia community should have the final say in important matters such as how LSPs select validators.

Full accountability to the base layer should be the ultimate goal of any LSP, and the zk approaches described above may help with this goal. In the meantime, committee-based approaches should use best practices for protocol upgrade mechanisms and validator selection.

There are different approaches to validator selection, with tradeoffs of each outlined below. Keep in mind, this is just a starting point for the discussion! Optimizing the design will be an iterative, community-driven process.

Ultimately, we defer to the Celestia community as to how its own validators should be selected.

(1) Copy-staking. Stride inherits the Celestia validator set distribution and rebalances frequently.

• Pros: Neutral, since TIA stakers choose the stake distribution, and Stride merely inherits it. No tokenholder governance. Fully onchain algorithm (Stride queries the underlying validator set and delegates accordingly).
• Cons: More centralizing than other approaches, as user-driven delegation tends to produce a top-heavy validator set.

(2) stTIA holders (or a broader proxy for Celestia community, such as a TIA governance vote) elect/approve a council, and the council evaluates and selects a subset of validators for delegation.

• Pros: Can produce a more decentralized validator set, intentionally increasing the Nakamoto coefficient, supporting geographical diversity, etc.
• Cons: Involves tokenholder governance. Additionally, stTIA holders only represent a subset of Celestia governance.

(3) Stride governance elects Celestia validators through its normal process, but veto powers are given to stTIA holders . This resembles the proposed LDO + stETH dual governance being developed on Ethereum.

• Pros: Also enables selection of a decentralized validator set. Additionally places even less burden on stTIA (or TIA) holders for routine governance duties. Most stTIA holders are unlikely to follow the day-to-day decisions of active validator set management.
• Cons: stTIA holders again only represent only a subset of Celestia governance. This is potentially more problematic for stTIA than it is for stETH dual governance, as stTIA will naturally be much smaller to start. There are also complexities around giving stTIA holders veto powers while not setting the bar too low, thus introducing griefing vectors.

We remain open to exploring other approaches as well, such as giving TIA holders a method to elect validators more directly. Overall, we’re seeking the Celestia community’s feedback here to work towards whatever solution best aligns with their values and interests.

What apps with Celestia underneath will use stTIA?

stTIA should be optimized for usability as a monetary asset throughout the modular ecosystem and for rollups building on Celestia. We’ve spoken with teams building in the ecosystem and have some early clear paths for stTIA usability:

• Eclipse: bootstrap stTIA liquidity on Eclipse to support TIA usage in the Ethereum ecosystem (bridged via Hyperlane)
• Astria: bootstrap stTIA liquidity on the AstriaEVM (bridged via Hyperlane) and Astria’s rollups
• Dymension: bootstrap stTIA liquidity on the Dymension hub (bridged via IBC)
• Hyperlane: for bridging stTIA throughout the modular ecosystem and beyond. Later, restaked stTIA could be used integrate a Restaking Interchain Security Module (potentially via Eigenlayer or another restaking protocol)

Stride contributors are also working with Sovereign Labs to spec out how trust-minimized liquid staking could be built as a zk-rollup using the Sovereign SDK.

Closing thoughts

Safe, aligned LSPs are critical to the future success of Celestia, and for enabling TIA to become a widespread monetary asset across the broader modular ecosystem.

Current TIA LSPs carry unnecessary trust assumptions. A core tenet of the Celestia mission is re-thinking the trust-assumptions of blockchains in favor of light clients, and we believe the community shouldn’t settle for a status-quo secured by unaligned multisigs.

We believe it is urgently important for Celestia to activate ICA, enabling Stride protocol to launch safer and more aligned TIA liquid staking. This offers a massive improvement over the current situation. Then as new technology (such as SNARK accounts and zk-IBC) becomes available, Stride will continue to improve stTIA’s trust-minimization. Together, we will accelerate the adoption of Celestia and TIA throughout the modular ecosystem. \

Have a comment or question? Please post it! (: We would love to engage with any and all perspectives on TIA liquid staking.

We intend to submit a CIP to activate ICA on Celestia on an accelerated timeline.

Thank you to Jon Charbonneau, Cem Özer, Josh Bowen, Susannah Evans, Jon Kol, Neel Somani, and Myles O’Neil for feedback and guidance on this post.

[LanreIge]

Great post, and I agree that Celestia governance should be looking to avoid a situation where we rely on a centralized LST option. One question (and apologies if I’m missing something obvious): Why is Celestia integrating the Liquid Staking Module not a proposed option?

[Disclosure: I’m the Grants Lead for the Neutron Grants Program. Neutron was incubated by P2P.org who also created Lido]

[themandalore]

Why do you guys need LST’s at all? Is the goal to have TIA used a money or collateral? And if the goal is just to enable restaking, why let EigenLayer run it? You could easily just enshrine other jobs if that’s the goal.

[neelsomani]

Hey folks, Neel from Eclipse here. stTIA from Stride will be big for bootstrapping TIA liquidity on Eclipse. I think this is a great proposal.

[cem]

Cem from Sovereign Labs here. We’re looking forward to speccing out the end-game of Celestia liquid staking with the Stride team!

[aidangs]

Good question.

The liquid staking module is core infrastructure that serves two purposes
(1) Improve the liquid staking UX
(2) Add liquid staking regulation to the base layer

My opinion is that adding LSM to Celestia is orthogonal to the rest of this post. It comes with its own set of benefits and tradeoffs, but isn’t necessary for networks to support liquid staking (Stride provided stATOM for almost a year before the Hub added LSM).

Given the complexity of the module, it’s not obvious that Celestia should add LSM to the base layer (a core value of Celestia is to keep the base layer minimal). It also hasn’t been upstreamed to the Cosmos SDK (to my knowledge), so Celestia would need to run a Cosmos SDK fork, which would require an involved CIP and engineering work. These costs would need to be weighed against the benefits, which feels beyond the scope of adding ICA on an accelerated timeline to enable safer and more aligned liquid staking in the short-term.

[aidangs]

Is the goal to have TIA used a money or collateral?

Those closer to TIA are better suited to respond to this.

In my view, TIA is very well-positioned to be used as money and collateral throughout the rollup ecosystem built on Celestia. In particular, sovereign rollups using TIA as a gas token makes a lot of sense (and some teams I listed above have indicated they hold this view as well). I’d also expect defi apps to give TIA integration priority - the earliest users of sovereign rollups will likely be from the Celestia ecosystem, so there will be demand to use TIA in those apps.

[GreatUA]

Hello, I used Stride for a year, it cooperates with many Cosmos chains and has expert understanding about liquid staking. I think TIA needs liquid staking - it helps community and users to decide - stake TIA or not or may be use pools. Communuty likes to have ability to use token in different ways.

[jbowen93]

Hey all, Josh from Astria, signaling mine and Astria’s support for the addition of the ICA module into celestia-app pending a CIP, @aidangs please lmk if you need or want any help with that process.

Regarding ways to select validators, I have a few thoughts.

RE: Copy-staking

Assuming a naive model I worry this may lead to a lower than desired staking reward due to certain validator’s commission, most notably bitcoinsuisse who has 6.89% voting power with 100% commission.

RE: Governance

Mustafa’s first proposed core value for Celestia’s social layer from this tweet says:

1. Off-chain governance trumps token-holder governance.

“We reject kings, presidents and voting. We believe in rough consensus and running code.” – David D. Clark, IETF

A vital aspect of the trust-minimisation that the Celestia network strives for is that no majority of dishonest parties can arbitrarily change or violate protocol rules. Therefore the canonical fork—and the state transition function—of the Celestia blockchain is ultimately defined by its social layer and ecosystem, not by token voting, validators or whales.

Network upgrades through hard forks are considered to be the canonical chain if they have broad uptake by the social layer and ecosystem. Before being adopted, a network upgrade can be evaluated against the values of the social layer, which may involve the values described in this post.

That being said, I don’t see a decision on the delegation mechanism as blocking the initial governance and technical work to add ICA.

[cmwaters]

I appreciate the very comprehesive write up.

I have for some time been of the opinion that liquid staking poses a substantial risk to the incentive mechanics of proof of stake and so have generally erred on the side of caution. However, users will naturally prefer greater liquidity over locked up tokens and thus it seems that some form of liquid staking is inevitable.

Given this, I would hope that the community is drawn to using the protocol that mitigates the risk of centralization as best as possible. I think Stride is an example of a protocol going in the right direction and am in favour of enabling ICA for a short term, relatively secure LST and that we can continue to ideate solutions that give users liquidity while also not compromising on the security of the proof of stake system.

As to validator selection, I do think the simpler copy-staking model makes the most sense. If it’s a protocol level rule, it’s easy to detect if there has been divergence (so there’s some accountability). It gives slightly more power to conventional stakers and less power to stTIA holders. I mean this not in terms of the return from staking which should be relatively similar but from how the voting power of validators would be chosen. Investors care more about return, attackers care more about voting power and controlling the network. At a minimum, it doesn’t give power to some external party which could be acquired at a cheaper price

I do want to echo Josh Bowens concern that the algorithm may want to exclude the validators with a commission above some limit.

[evan]

enabling ICA in the next upgrade seems very reasonable, so I’m certianly not blocking on that.

I do have some concerns over the proposed mechanisms to pick the validator set, however.

Copy Staking

The copy staking mechanism is really interesting. Long term, I am a bit worried about it however.

If stTIA becomes very successful, and say 50% of the voting power is copy staked, does that mean that if I don’t liquid stake, my voting power can be doubled? If so, then does that mean it only costs half as much to attack the network?

Does this mechanism need to account for other liquid staking protocols as well?

stTIA

If stTIA holders control a council, would this open us up to governance attacks? Meaning, would it be possible to buy or borrow a bunch of stTIA, set a malicous council, and then return or sell the stTIA?

stTIA Veto

similar to the above concerns, could an attacker borrow a bunch of stTIA and veto all changes? Have vetos occurred in other scenarios? If users are using their stTIA in defi, would this mean they would have to exit their positions to potentially save the protocol?

[velvetmilkman1]

Great proposal and thanks for going deep into the specifics.

The most common questions will be directed towards validator selection process. You’ve laid out three potential solutions. imho the best outcome is something that looks like Option #1 but with some parameters that ensure validators that under-performing validators are excluded from the set.

Option 1: Copy-Staking - As @jbowen93 points out, it makes sense to exclude extractive validators that charge 100% commission. Applying a max commission rate in order to qualify as a stTIA validator seems like a reasonable standard. This would ensure the greatest amount of validator inclusion possible and benefit all Celestia stakeholders. On the flip side, it also entrenches existing validators in the active set and doesn’t account for other issues such as performance, governance participation, and liveness.

Option 2: stTIA Holders Choos - As mentioned in the “Cons” section, this could be a great solution if stTIA becomes a large source of staked TIA down the road but seems premature. If one stTIA holder owns a majority of the tokens, they will be able to direct and influence the entire delegation. This seems like a logical Step 2, if/when stTIA makes up a larger percentage of future stake and there are 100s or 1,000s of stTIA wallet holders down the road.

Option 3: Stride Governance Elects the Validators and Delegation - I assume the current governance process Stride has enacted is as detailed in the Stride forum post “The Curation Process Steps.”

While giving up the delegation process to STRD holders has been raised as a concern, one part of the process I think makes a lot of sense is that governance ordinarily sets “a minimum threshold for up-time, minimum threshold for governance participation, and maximum threshold for commission. It excludes validators that do not meet the thresholds.”

In Step 5, Stride governance is used to “determine how many validators are required for the host-chain set.” Is there anywhere to better understand how the appropriate number of validators are determined and recommended to the community?If so, is it fair to assume you’ll simply remove the 6 month threshold from the analysis? Is there anything else you would also alter from the Stride governance voting on Celestia?

IMO the best-case scenario is to apply something like Option 1 while also setting pre-conditions to receive delegations, that is re-evaluated on a regular and periodic basis. The Stride team’s experience in performing this analysis should help ensure any standards set are the most comprehensive and best-in-class. Lastly, it may also be worth considering putting together a working group to tackle liquid staking, as discussed in CIP-7.

[funnyflatfoot]

Hey Neel, what are the top reasons for rollups to bootstrap TIA liquidity unless they use TIA as a gas token?

[KagemniKarimu]

I appreciate the detailed exploration of Celestia’s liquid staking protocols and the emphasis on safety and alignment with Celestia’s values. The proposal to activate Interchain Accounts (ICAs) is a forward-thinking step. ICAs, known for enhancing cross-chain interoperability in the Cosmos ecosystem, could significantly reduce trust assumptions in Celestia’s LSPs, aligning with the ethos of web3/DeFi.

I have read the Strangelove IBC report thoroughly and think any incoproration of IBC (in its present incarnation) and IBC (in its coming-form) are going to greatly improve the interoperability of the space. SNARKs and zk are a bit beyond my current acumen, but I very much see a zk future so I look forward to learning more about Celestia’s path.

[rootulp]

Copying this comment from the CIP to preserve for posterity:

[question] does this proposal recommend enabling one or both parts?

1. The controlling portion of interchain accounts
2. The hosting portion of interchain accounts
3. The controlling and hosting portion of interchain accounts

I think it’s either 2 or 3 but think it could be clarified.

[rootulp]

Thanks for the comprehensive CIP!

I have a clarifying question about the allow messages parameter. What does CIP-14 propose as the value for this parameter? There are two options: wildcard or explicit list of messages that are allowed.

In the spirit of conservatism, I expect it will be easier to pass CIP-14 if the list of messages were explicitly defined and scoped to the minimum necessary that would enable the liquid staking use case. An explicit list of allowed messages would also make the ICA integration easier to test.

If the wildcard option is proposed, I think CIP-14 should be updated to include a section that analyzes the interaction of ICA with the Celestia-specific MsgPayForBlobs. This section may also want to include a note about the implications ICA has on future messages that may be added to Celestia.

[aidangs]

@rootulp

question] does this proposal recommend enabling one

Definitely - this proposal is to add the host portion of interchain accounts.

[aidangs]

Agreed, it makes sense to use an explicit list of allow messages.

These are the allow messages proposed

allow_messages:
- /ibc.applications.transfer.v1.MsgTransfer
- /cosmos.bank.v1beta1.MsgSend
- /cosmos.staking.v1beta1.MsgDelegate
- /cosmos.staking.v1beta1.MsgBeginRedelegate
- /cosmos.staking.v1beta1.MsgUndelegate
- /cosmos.staking.v1beta1.MsgCancelUnbondingDelegation
- /cosmos.distribution.v1beta1.MsgSetWithdrawAddress
- /cosmos.distribution.v1beta1.MsgWithdrawDelegatorReward
- /cosmos.distribution.v1beta1.MsgFundCommunityPool
- /cosmos.gov.v1.MsgVote

Here’s a breakdown of how the allow messages are used

• /ibc.applications.transfer.v1.MsgTransfer – Used to send TIA (rewards, redemptions) back to Stride chain for distribution

• /cosmos.bank.v1beta1.MsgSend – Used to transfer TIA between accounts owned by Stride (there are designated ICAs for processing staking, rewards, redemptions, etc.)

• /cosmos.staking.v1beta1.MsgDelegate – Used to stake

• /cosmos.staking.v1beta1.MsgBeginRedelegate – Used to rebalance across validators

• /cosmos.staking.v1beta1.MsgUndelegate – Used to unstake

• /cosmos.staking.v1beta1.MsgCancelUnbondingDelegation – A failsafe that can be used in the scenario of an erroneous unbonding (e.g. a protocol bug)

• /cosmos.distribution.v1beta1.MsgSetWithdrawAddress – Used to set the withdrawal ICA (having separate ICA accounts for staking and rewards simplifies accounting)

• /cosmos.distribution.v1beta1.MsgWithdrawDelegatorReward – Used to process reward withdrawal

• /cosmos.distribution.v1beta1.MsgFundCommunityPool – There is a feature on Stride that allows community pools to liquid stake, this allows ICAs to return tokens to the community pool

• /cosmos.gov.v1.MsgVote – Not used today so optional, but nice to have for LSPs so they can add stToken holder voting in the future

[agouin]

Strangelove and Rollchains are in support of this proposal.

In addition to the allow messaged proposed by @aidangs , we are in need of the feegrant messages via ICA for the Rollchains blob posting mechanism. This is for the purpose of in-protocol granting/revoking of validator account feegrants.

- /cosmos.feegrant.v1beta1.MsgGrantAllowance
- /cosmos.feegrant.v1beta1.MsgRevokeAllowance

[rootulp]

I don’t have any objections with including the feegrant messages. Do the CIP authors have any feedback about including those messages?

cc: @aidangs @womensrights