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.
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:
- Reduce trust assumptions as much as possible (using the most decentralized, trusted committees available)
- Ensure the Celestia community ultimately governs the LSP, especially validator selection
- Use battle-tested, observable, audited protocols
Anything less than the above should be considered against the interests of the Celestia community.
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.
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.
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)
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:
- 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.
- 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.
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.
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.
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.