Skip to content

Modular Money: Liquid Staking for People in a Hurry

Jon Charbonneau 02.2.24 51 min read

Thank you to Evan Forbes, Jacob Arluck, Jon Kol, Mike Neuder, Myles O’Neil, NashQ, and NoSleepJon for valuable feedback, review, and related discussions.

Thank you to Aidan Salzmann, Elijah, Hasu, Mike Ippolito, Riley Edmunds, RoboMcGobo, Sacha Yves Saint-Leger, and Vishal Talasani for really bad feedback, review, and related discussions.

Introduction

DBA is proud to lead the Stride Association’s recent fundraise. This report dives into Stride’s technical architecture and the market opportunity that got us so excited.

Stride is a specialized Cosmos chain that issues liquid-staking tokens (LSTs) for other IBC-enabled chains. Stride has consistently dominated traditional markets such as stATOM and stOSMO, but we’re even more excited by their huge growth potential. The hottest new IBC-enabled chains such as Celestia, dYdX, Dymension, Berachain, Namada, Penumbra, Initia, and more are now becoming a reality.

Above any of the technical points we’ll cover here, DBA backs people. Aidan, Riley, Vishal, and many other Stride contributors have proven to be outstanding operators. They’ve consistently demonstrated leadership in the Cosmos community, a tireless work ethic, operational excellence, prudent risk-management, and impressive execution. This is an area we’ve spent a lot of time thinking about, so we’re thrilled to now work alongside the best-in-class team here.

This post covers the following:

  • Stride’s Architecture – How Stride works under the hood, leveraging Interchain Accounts (ICAs), Interchain Security (ICS), and the Liquid Staking Module (LSM).
  • Current LST Market – Analysis of the LST market structure among IBC-enabled chains, how this differs from Ethereum’s, and why.
  • Growth Opportunities – Analysis of Stride’s largest growth opportunities, both from further penetrating existing markets and expanding into new ones.
  • Celestia & stTIA – Celestia is incredibly unique in its architecture, core values, governance processes, and asset utility. Designing stTIA as modular money requires special consideration.

Stride’s stTokens

Up until this week, Stride’s full LST product suite was stATOM, stOSMO, stINJ, stEVMOS, stJUNO, stSTARS, stSOMM, stUMEE, stCMDX, and stLUNA. Stride has a cumulative TVL >$100mm, of which ~$80mm is split between stATOM and stOSMO.

Source: DefiLlama, as of 2/2/24

Stride is now poised to aggressively expand its market position in 2024. It’s been a huge week, as Stride made headlines by launching stDYDX and stTIA in just the past few days. stTIA’s been off to a particularly fast start, picking up >$12mm TVL in just the day since launch, at time of writing.

Looking ahead, Stride can easily issue LSTs for any IBC-compatible chain (with ICAs), and it intends to support as many as possible. Other candidates for Stride to add support in the near-to-medium-term include Dymension, Berachain, Namada, Penumbra, and Initia among others.

These offer several new multi-billion dollar markets for Stride to launch into. As such, Stride is incredibly well positioned to act as the best index on all IBC-enabled chains. It’s already built up a dominant base among classic Cosmos projects, and now it’s set to rapidly grow alongside the wave of new modular chains.

Now let’s dig into how Stride really works under the hood.

Security, Governance, & Economics

Interchain Security (ICS)

As an ICS consumer chain of the Cosmos Hub, Stride’s technical architecture is deeply intertwined with its security, economics, and governance. We’ll cover all of them here.

When Stride first launched in September 2022, its chain was secured by its own validator set using STRD as the staking token. Then in July 2023, Stride adopted Replicated Security (RS) and swapped out its own validators for the Cosmos Hub’s. ICS refers to a family of shared security protocols, of which RS is one of them:

  • Replicated Security (a.k.a. ICS v1) – All (or nearly all) validators on the “provider chain” (e.g., Cosmos Hub) run and secure the “consumer chain” (e.g., Stride). They subject themselves to additional slashing conditions for the consumer chain. This requires a governance vote from the provider chain to be approved.
  • Partial Set Security – Subsets of provider chain validators are able to more flexibly opt into running consumer chain nodes. Validators who are not running nodes are able to delegate to validators that are running nodes.
  • Mesh Security – Subsets of each chain are able to provide security to validate each other.

RS is the only form of ICS currently live, with Stride and Neutron being the Hub’s two consumer chains. This gives Stride one of the most decentralized and economically secure validator sets in crypto.

Governance

When Stride adopted ICS, its validators transitioned to being “governors.” Governors can vote on governance on behalf of their delegators (though delegators can still vote themselves, if they wish).

STRD remains the governance token controlling the Stride DAO. This includes responsibilities such as ultimately overseeing the host chain validator sets for their respective stTokens. STRD stakers may vote the following on governance proposals, with each token having equivalent voting power:

To pass a governance proposal, the following conditions must be met:

  • Deposit – Proposals require a deposit of ≥1,000 STRD to go onchain (otherwise the transaction will fail). A total deposit of ≥2,000 STRD is required to initiate the voting period. Anyone (including multiple parties collectively) can put up the deposit, so long as the 2,000 STRD is met within 48 hours of the proposal being put onchain.
  • Voting Period – 3 days.
  • Turnout – ≥33.4% of all staked STRD must vote to reach quorum.
  • Pass Threshold – (Yes) > (No + NoWithVeto) among participating voting power.
  • Veto Threshold – If ≥33.4% of participating voting power choose to veto the proposal, then the proposal is automatically rejected, and the deposit is burned.

Locked and vesting tokens are eligible to stake, and thus are eligible to participate in governance votes. However, to remain neutral, the core team contributors have always let governors vote for them rather than voting themselves.

While the Cosmos Hub validators are the ones that physically run the chain, the Stride DAO is always ultimately in control. For example, in the same way that STRD holders voted to swap their validators for the Hub’s via ICS, they could vote to remove them and secure themselves in another manner.

ICS Economics

Users may still stake their STRD with governors and receive some inflationary rewards. However, these rewards were cut in half as part of the transition to ICS, as incentivizing additional security from STRD stakers is no longer needed. This one-time 50% reduction was in addition to STRD’s existing inflation schedule which drops by 50% per annum on September 4th. This inflation rate is incredibly low, with inflationary staking rewards currently set to <1% of total supply per annum.

In return for the security it receives, Stride agreed to pay to the Cosmos Hub 15% of all ongoing revenues (STRD inflationary staking rewards, Stride’s transaction fees, MEV revenue, and stToken fee revenue). We’ll take a deeper look at the economics at the end of this report.

There have been some concerns raised around the potentially centralizing economics of RS given the disparity between:

  • Cost to run another chain – Validators incur additional (roughly fixed) costs to run additional consumer chains. There’s some minimum additional server costs, employee salary costs, etc.
  • Income from running another chain – The revenue from running another consumer chain is variable and proportional to the validator’s stake.

If a validator has a small amount of stake, their additional variable income is unlikely to cover the incremental costs to run the consumer chain. To address this, there’s a soft opt-out for the bottom 5% of voting power in RS today. This allows the bottom 5% to choose not to run consumer chains without being punished. Of the Cosmos Hub’s 180 validators, the top ~100 hold ~95% of stake weight. This means that the bottom ~80 validators don’t actually have to sign blocks for consumer chains (i.e., Stride and Neutron). They can simply earn the rewards for consumer chains without paying the costs.

Finally, as part of the agreement for Stride to become a consumer chain, the Cosmos Hub also deployed 450k ATOM as protocol-owned liquidity (POL) into the stATOM/ATOM liquidity pool on Astroport’s Neutron deployment. This remains the property of the Cosmos Hub, and was intended to bootstrap trading liquidity. The Hub later decided to add another 900k of stATOM/ATOM POL to Osmosis in December, on which it’s earning ~$100k annualized.

Interchain Account (ICAs)

Most liquid-staking protocols (LSPs) are deployed as smart contracts on their home chain. For example, users directly interact with the Lido contract on Ethereum to mint stETH.

However, Stride is designed for a multichain world. The Stride blockchain is purpose-built to issue LSTs for other external chains. It does not host any other native activity such as DeFi. We’ll walk through example transaction flows to see how Stride’s interchain staking operates.

Users Deposit Tokens → Mint stTokens

A Cosmos Hub user wants to deposit ATOM and mint stATOM. Stride abstracts away interchain complexities to mimic a single-chain UX, but this is what actually happens under the hood:

Source: Based on Stride documents

This interchain staking is enabled by interchain accounts (ICAs) and interchain queries (ICQs):

  • ICAs = Cross-chain writes. Allow you to control accounts on host chains (the Cosmos Hub here) from a controller chain (Stride here) account using IBC.
  • ICQs = Cross-chain reads. Allow you to read accounts on host chains (the Cosmos Hub here) from a controller chain (Stride here) account using IBC.

Stride Stakes & Auto-compounds Rewards

The user here received their stATOM immediately upon Stride receiving the ATOM collateral. Then, every Stride epoch (6 hours), Stride programmatically sweeps all new deposits and stakes them on their respective host chains (e.g., ATOM on the Cosmos Hub). Most of Stride’s core protocol logic runs at this 6 hour cadence.

Stride automatically collects host chain staking rewards then stakes them again as they accrue. This auto-compounds rewards for stToken holders, boosting the yield beyond the baseline staking APR.

As a result of this architecture, stToken prices should increase over time relative to the underlying asset. For example, at genesis 1 stATOM = 1 ATOM. Over time though, the stATOM pool has accrued ATOM rewards which are staked again. As a result, 1 stATOM = ~1.3 ATOM today, and this continues to increase.

This contrasts to rebasing tokens which increase in quantity rather than in price (e.g., stETH holders receive more stETH). Rebasing tokens are intended to trade ~1:1 with the underlying as a result (noting that market deviations are always possible in extreme circumstances).

stDYDX also offers a particularly interesting opportunity here because DYDX V4 stakers now receive staking rewards denominated in USDC. To account for this, Stride will also routinely conduct the following actions programmatically via ICAs:

  1. Bridge $USDC rewards from dYdX → Osmosis via IBC
  2. Swap $USDC into $DYDX
  3. Bridge $DYDX from Osmosis → dYdX via IBC
  4. Stake the $DYDX tokens on dYdX

As with Stride’s other stTokens, this mechanism auto-compounds the staking rewards for stDYDX under the hood. It provides a source of consistent buy pressure for DYDX and helps to increase the chain’s security as well.

Users Redeem stTokens → Tokens

Finally, users can always redeem their stTokens with Stride. Stride will automatically initiate and manage unbonding on the host zone, then users receive the native tokens in their wallet:

Note that these unbondings are only triggered every few days. Due to an SDK constraint, Stride can issue no more than 7 undelegation messages in a given unbonding period per chain. The exact length varies slightly depending on the respective host chain’s unbonding period. For example, the Cosmos Hub’s unbonding period is 21 days. 21 ÷ 7 = 3, then 1 is added as a buffer, so Stride issues an undelegation every 4th day for a delegator and validator pair.

Alternatively, users can just directly swap their stTokens for the base tokens on DEXs (e.g., swap stATOM for ATOM on Osmosis) to immediately receive the underlying asset. In practice, most users do this to convert LSTs.

Liquid Staking Module (LSM)

The LSM is a form of protocol-level regulation aimed at providing safer and more efficient LSTs. It was developed by Iqlusion with involvement from Stride among others. The Cosmos Hub became the first and only chain to implement the LSM with the Gaia v12 upgrade in September 2023. Note that other Cosmos chains can (and likely will) adopt variations of it in the future, but we’ll just use the Hub for the example below.

The LSM features three main components:

1) Instantly Convert Native → Liquid Stake

Converting unstaked ATOM → stATOM is fundamentally quick and easy. However, converting already staked ATOM → stATOM has historically been challenging.

All PoS chains have an unbonding window, so migrating native stake → liquid stake would first require unbonding your stake. This forfeits all staking rewards in the unbonding period (typically 14-21 days in Cosmos chains).

The LSM addresses this, allowing users to instantly convert natively staked ATOM → liquid staked ATOM with the same UX as converting unstaked ATOM → liquid staked ATOM.

Step 1: Users Tokenize Natively Delegated Stake → Semi-fungible LSM Shares

The LSM does not itself directly issue maximally fungible LSTs like stATOM to end users. Rather, the LSM exposes the necessary infrastructure to do so, which LSPs such as Stride can build on top of.

Specifically, the LSM enables users to tokenize their natively delegated stake, issuing semi-fungible “LSM shares” that represent the user’s position. A user may tokenize some or all of their natively delegated stake. These LSM shares are transferable tokens, and the holder of them can redeem them for the underlying stake at any time.

While these LSM shares are technically fungible tokens, they carry extremely limited fungibility. They are specific to the delegation record that was created when they were tokenized. These tokens carry two important unique markers:

  1. Validator operator – LSM shares note the validator to whom the underlying tokens are delegated. Different validators carry different payouts and slashing risks. For example, if only Coinbase is slashed, then all LSM shares for stake delegated to Coinbase would take a hit. Meanwhile, LSM shares for other validators would be unaffected.
  2. Reward recipient – LSM shares carry the record ID for the validator operator, tracking which exact delegation to this validator is being represented. They track who then receives the rewards for the given delegation. The owner may transfer the rights to receive these rewards to another address.

Consider the following example for Alice:

  • Alice has 100 ATOM natively staked to the Coinbase validator.
  • Alice signs a message (MsgTokenizeShares) to create LSM shares representing 50 of her staked ATOMs.
  • Alice’s 50 LSM shares are all fungible with each other. She may also split them up as she wishes (e.g., deposit 25 of them into an LSP, transfer 20 to another wallet of her’s, and keep 5 in the initial wallet).

And similarly for Bob:

  • Bob has 100 ATOM natively staked to the Coinbase validator.
  • Bob signs a message (MsgTokenizeShares) to create LSM shares representing 50 of his staked ATOMs.
  • Bob’s 50 LSM shares are also fungible with each other, and he also may split them up and use them accordingly.

However, Alice LSM shares are not fungible with Bob’s LSM shares, even though they are using the same validator (and thus have the same slashing risk in the event that Coinbase gets slashed). They’re specific to their own delegation record, and track claims on different rewards.

Transferring the LSM shares to another address also does not on its own transfer ownership of the rewards generated from the underlying stake. For example, if Alice just transfers her LSM shares to Bob, they would continue to accrue rewards claimable by Alice. Bob can start to receive the rewards if:

  • He redeems the LSM shares for the underlying stake, or
  • Alice signs a message (MsgTransferTokenizeShareRecord) which transfers ownership of the rewards to Bob.

This is designed to provide LSPs with maximal design flexibility, allowing them to redeem the LSM shares or simply keep them tokenized and hold them. Additionally, it allows LSPs to receive the claim on the rewards immediately, and then they can just redeem them later on.

Step 2: Users Deposit Semi-fungible LSM Shares Into LSP → Get Fungible LSTs

LSPs (e.g., Stride) can then transform these LSM shares into the fully fungible LSTs (e.g., stATOM) that end users want. Let’s walk through an example of Alice converting her natively staked ATOM → stATOM via the LSM. To Alice, it’s as simple as deciding whether to:

  • Convert her unstaked ATOM → stATOM (screenshot on the left), or
  • Flipping a switch to convert her natively staked balance → stATOM (on the right):

Under the hood, this is what happens when Alice converts her native stake → stATOM:

  • Alice has 2 ATOM natively staked with Coinbase on the Cosmos Hub.
  • Alice uses the LSM to tokenize 1 of her ATOM staked to Coinbase. This 1 LSM share notes Coinbase as the delegate, and Alice receives the rewards for this stake.
  • Alice’s LSM share is transferred via IBC to Stride and deposited. She also transfers reward ownership to the Stride contract address (via MsgTransferTokenizeShareRecord). Stride now controls the token which can be redeemed for the underlying stake, and it owns the associated staking rewards in the meantime.
  • Alice receives ~0.78 stATOM from Stride (the current ATOM/stATOM exchange rate).

Whether Alice pulls from her staked or unstaked ATOM balance, she converts 1 ATOM → ~0.78 stATOM just as easily. The complexity of the LSM is fully abstracted away.

Once the LSP has received the LSM shares, the next step of what to do with them is an open design space. Different LSPs could handle this differently. The simplest implementation of an LSP would just collect these LSM shares, issue LSTs against them, then never redelegate the basket of collected shares. However, Stride’s design is more active and opinionated. It takes these LSM shares then redelegates them based on its own target validator distribution for that chain. This stake delegation process is arguably the most important differentiating factor between LSTs, and will always require some level of external management.

Note that the LSM has another great benefit for users here, even aside from liquid staking. It allows users to safely transfer their natively staked ATOM between wallets without having to unstake (e.g., to more frequently rotate keys as a best security practice).

2) 25% Global LST Cap

The LSM limits liquid staked ATOM to 25% of the total supply of staked ATOM. For example, if there’s a total of 100 ATOM staked, then liquid staking would be limited to 25 ATOM of that. This prevents LSPs from hitting the ⅓ threshold needed to halt the chain.

The LSM enforces the cap by limiting the following to 25%:

  • Stake held by LSPs (measured by voting power staked via ICAs), plus
  • Stake tokenized using the LSM.

Once the 25% cap is hit, the LSM:

  • Prevents ICAs from staking more ATOM, and
  • Prevents delegators from tokenizing any more delegations using the LSM.

While it’s not possible to add liquid stake above 25%, note that it is possible for LSPs to control 25% then increase their share due to a mass unbonding of native stake. For example:

  • Say there’s a total of 100 ATOM staked
  • 25% is liquid-staked (25 ATOM)
  • 75% is natively staked (75 ATOM)
  • Then, 1/3 of the native stake (25 ATOM) unbonds
  • There’s now 75 ATOM staked total, of which ⅓ is liquid staked (25 ATOM)

Setting the initial cap at 25% provides a conservative buffer. The host chain’s governance (the Cosmos Hub’s here) can always opt to change this parameter if desired later on, for example to increase the allowable share as LSPs prove to be robust and valuable. LSPs such as Stride do not control this parameter.

3) Validator Self-bond Requirements

All forms of delegated staking suffer from a classic principal-agent problem (PAP):

  • Principal – The delegator (i.e., user) is punished in the event of slashing.
  • Agent – The delegate (i.e., validator) is the one that actually may commit slashable offenses (e.g., double-signing).

The LSM mitigates the PAP by requiring validators to self-bond some tokens proportional to the tokens delegated to them. There’s a tradeoff here though:

We want validators to have skin in the game, but we don’t want the capital costs to be insurmountable for the little guy. Additionally, an excessive self-bond requirement further incentivizes evading the mechanism entirely. It’s impossible to prevent out-of-band agreements for external parties to put up stake for the validator.

One extreme end of the spectrum is to simply not support in-protocol delegation. This is implicitly a 100% self-bond requirement. We see this in Ethereum, and the result is most people delegating stake via out-of-protocol mechanisms (e.g., via LSPs and/or centralized custodians).

The other extreme is to allow delegation with 0 skin in the game. This is actually how most PoS chains work today, and how the Cosmos Hub still works for natively delegated stake. No self-bond is required to receive natively delegated stake. The LSM self-bond is only required to receive delegated liquid stake. Anyone is free to spin up a validator, attract natively delegated stake, then act maliciously (e.g., double-signing). Their delegators will be slashed, but the validator suffers no punishment of their own.

There’s some argument that LSPs exacerbate the PAP here as validator selection is typically one step further removed from the user:

  • Native delegation – The user picks their delegate directly.
  • Liquid staking – The user selects an LSP. The LSP then picks the underlying validators, distributing the associated risk across all LST holders equally. The user may choose a different LSP, but this is often irrational and impractical depending on the alternative LSTs available. Fostering competitive LSPs with lower switching costs may be helpful.

LSTs may also introduce further attack vectors (e.g., intentionally causing mass slashings to manipulate the stATOM/ATOM price and trigger DeFi liquidations). This may increase the profitability of such an attack by validators.

To mitigate the PAP here, the LSM requires validators to self-bond ATOM in order to be eligible for LSP delegations or to mint LSM tokens. The validator bond factor is 250:1. For every 1 ATOM a validator self-bonds, they’re eligible to receive up to 250 ATOM delegated from LSPs. As with the 25% LST cap, this 250:1 bond factor is also a starting point which is tunable by governance.

Additionally, the LSM doesn’t actually mandate that the “self-bond” comes from the validator’s own address. Another address may delegate this “self-bond” to the validator (in which case “self-bond” would be a bit of a misnomer). This means that LSPs could for example front the bond for all of their delegates, or possibly only subsidize the bond for smaller validators who lack the capital (e.g., an LSP could subjectively front the bond for a hobbyist, but make Coinbase put up the full bond themselves).

Note that validator self-bonds and delegated stake are treated equally regarding slashing and rewards. Within the same validator, both receive the same rewards and bear equivalent slashing risk. There is some discussion of tranching risk in future iterations (e.g., making the validator self-bond take the first hit on slashing, or even remove slashing for delegated stake entirely).

Validators ultimately weigh the incremental self-bond capital costs vs. the additional commissions they can earn. As noted in the LSM proposal:

“For a validator, the economics boil down to: is the commission revenue earned on an additional 250 units of stake from an LST provider enough to outweigh the cost of locking up 1 additional unit of validator bond? For example, on the Cosmos Hub, assuming a 5% validator commission, validator bonding 1 additional unit of ATOM can attract 250 additional units of ATOM stake from LST providers. The annual commission revenue on those additional 250 units of ATOM is 250 unit 21% APR 5% commission = 2.625 additional units of annual commission revenue.

In other words, the average validator can earn 2.6 units of commission revenue each year on each unit of validator bond they lock up, so it seems economical for validators to validator bond. The Cosmos Hub community, through governance, can vote to adjust the validator bond factor, to modulate the competitive dynamics between validators, liquid staking users and liquid staking providers.”

How Much to Enshrine?

In typical Cosmos to Ethereum fashion, you’ll notice that recent conversations in Ethereum about enshrined liquid staking and two-tier staking actually look a lot like the LSM. You can refer to these pieces by Dankrad, Arixon, Mike Neuder, and Vitalik for more detail.

The fundamental questions here are how much should we enshrine, and to what end?

  • Enshrine the entire liquid staking system, with the protocol issuing LSTs to end users that attempt to replace out-of-protocol LSPs.
  • Enshrine minimal infrastructure that regulates out-of-protocol LSPs, making them safer and more competitive.

Some of the Ethereum ideas have touched on both directions, while the LSM clearly does the latter. I generally view this as the more attractive and inevitable path:

  • LSTs are one of the largest markets in crypto. Killing off the open-market innovation around them would be detrimental even if it could be done safely.
  • Even with slashing risk removed, it’s still beneficial from a user perspective to improve asset fungibility and maximally smooth rewards across all validators. Different validator-specific LSTs would bear different rewards. Without active LSP governance, it’s challenging to prevent MEV-stealing and enforce reward-pooling.
  • Penumbra’s staking tokens and two-tier staking contemplate LSTs which are fungible within a validator (i.e., if Alice and Bob both delegate to Coinbase, then their tokens are fungible), but not across them (i.e., their stake isn’t fungible with someone delegated to Figment). However, if the protocol doesn’t issue 100% fungible LSTs across all validators, then out-of-protocol LSPs will likely pool and wrap them anyway.

The LSM is a nice balance towards this goal of making open-market LSTs safer and more competitive. It does not attempt to supplant them. Further work can and will be done to make them even safer and reduce competitive moats between different LSPs built atop the LSM.

Validator Selection Processes

Host chain validator selection is one of the most important dimensions on which LSTs differentiate themselves. If designed responsibly, they can very positively influence validator decentralization and performance.

Stride’s default selection process is intended to best serve the interests of their respective host chains in a scalable manner. Stride governance also has the flexibility to deviate from this default process as needed. For example, it can be used to quickly adjust and avoid delegating to inactive validators. Stride governance has done this for both Osmosis and Cosmos Hub validators on multiple occasions as validators wound down operations.

Additionally, Stride can further account for the unique needs of different host chains that warrant it. Stride has custom processes for the Cosmos Hub, Osmosis, dYdX, and Celestia.

Default Validator Selection Process

By default, Stride distributes stake to new stToken host chains as follows:

  • CEX validators are ineligible to receive delegations.
  • Validators with >10% commissions are also ineligible.
  • Delegate stake to the remaining eligible top 30 validators on the host chain (as determined by stake weight).
  • Stake is delegated to these 30 validators proportional to their existing stake-weight (i.e., Stride copies the weighting that the chain’s native stakers have delegated).

This default process is just that – a default. It’s a simple design which minimizes onboarding friction, quickly providing reliable LSTs needed by the long-tail of many chains. This default tries to be minimally opinionated, mostly copying the host chain’s expressed user preferences. Removing CEXs and validators taking excessive commissions is a simple and generally noncontroversial alteration, improving the chain’s decentralization and economics.

Entirely bespoke alternatives such as a hand-picked whitelisting process (e.g., as in Lido’s NOR) would not be scalable or repeatable for every chain at launch.

Community-Led Selection – Cosmos Hub & Osmosis

While the default process above is a great way to get started with a new stToken, larger chains will often warrant more customization, particularly as they mature. For example, stATOM and stOSMO both initially launched with the default framework described above, but the underlying validator selection process has since changed for both chains.

To further involve the respective communities in the validator selection process, Stride established advisory councils for both the Cosmos Hub and Osmosis. These councils are composed of highly involved members of their respective communities capable of evaluating validators. Anyone was free to apply to join the councils, and the most qualified candidates were ultimately ratified via onchain signaling proposals from the Cosmos Hub’s governance and Osmosis’ governance, respectively.

These council members are tasked with evaluating validator applicants who want to receive stake delegations from Stride. To be eligible, validators must meet the following requirements:

  • Uptime of ≥ 99% in the last 90 days
  • Commission ≤ 10%
  • Voted for ≥ 7 of the last 10 governance proposals
  • Has been in the active validator set for ≥ 3 months

Eligible validators may then submit an application to their respective council, explaining how they’ve contributed both technically and socially to their given chain in the past 6 months. Each member assesses the applications independently and scores validators 1-10. If a council member has a conflict of interest for a given validator, they abstain. The scores across all council members are averaged to give one score for each validator.

Stride then sorts validators into quartiles based on their existing delegated stake weight. For example, if a host chain has 100 validators:

  • Quartile 1 – The 25 validators with the most delegated stake
  • Quartile 2 – Validators #26-50 in terms of delegated stake
  • Quartile 3 – Validators #51-75 in terms of delegated stake
  • Quartile 4 – Validators #76-100 in terms of delegated stake

Within each quartile, the advisory council selects the 8 validators with the highest score, for a total of 32 validators. These 32 validators are allocated delegations based on their cohort rankings (1-8), weighted as follows:

image

Source: Redelegate the Stride Cosmos Hub Validator Set

Finally, the advisory council puts forward this list of 32 validators for Stride governance to confirm. It’s recommended that this process is refreshed every 6 months for larger chains. The final allocations for the last round can be found here (Cosmos Hub) and here (Osmosis).

The Cosmos Hub’s LSM proposal noted Stride’s approach here as the perfect example of how to mitigate vote power concentration risk:

“Stride, a leading Cosmos liquid staking provider, delegates its ATOM in such a way that a maximum of 25% is delegated to validators in each quartile of the active set, as measured by existing delegations. Stride’s innovative and responsible approach to host-chain validator selection means that liquid staking with Stride does not entail the risk of vote power concentration. Ideally, other liquid staking providers will follow Stride’s example and delegate their ATOM in a way that distributes it across the active set.”

Note that the specific eligibility criteria, validator set size, and delegation weights used for the Cosmos Hub and Osmosis here can of course be modified for future chains as applicable.

Custom Process – dYdX

dYdX Chain officially launched this past October, and Stride just launched stDYDX earlier this week. dYdX requires a more tailored approach to validator selection than the previous examples for a few reasons:

  • dYdX has an incredibly top-heavy validator set, with the top two validators comprising nearly 40% of total stake.
  • The chain only launched a few months ago, and thus has insufficient validator performance data to evaluate.
  • Validator set composition keeps changing frequently, with validators falling out of the active set due to insufficient stake.

To address these challenges, Stride contributors have proposed a curated initial validator set as outlined in this forum post announcing the launch of stDYDX. These operators were selected with feedback from the dYdX Foundation, taking into account their guidelines on best practices for validators.

Stride is initially proposing 10 validators at launch, with stake distributed evenly amongst them. All of them are in the bottom 66% of stake (i.e., not the top two validators). Every 1-2 weeks thereafter, 3-4 validators will be added (until there are 32 validators) to minimize the likelihood of any validators falling out of the active set. The Stride DAO temporarily authorized the Stride Association to manage the dYdX validator selection.

In time, it will likely make sense for Stride to adopt a more community-led approach such as described earlier to involve the dYdX community more directly in their validator selection.

LSTs in Cosmos vs. Ethereum

LST Demand Drivers

Although Ethereum boasts the largest LST market today, the idea initially came out of Cosmos. Felix Lutsch first wrote about Delegation Vouchers back in June 2019. Since then, LSTs have spiraled into the multi-billion dollar behemoth we see today. You can hear more about this past, present, and future of LSTs on this great Bell Curve podcast with Aidan and Felix.

So, why did LSTs disproportionately take off on Ethereum first? Let’s take a look at the high-level incentives to use LSTs rather than native staking:

1) The Merge

Ethereum had a strong idiosyncratic demand driver leading up to the Merge. There was a very long period where it was unclear when ETH staked on the Beacon Chain would be withdrawable. The only way to ensure some form of liquidity in the meantime was via LSTs.

This is not applicable for Cosmos.

2) Native Delegation

Ethereum doesn’t support in-protocol stake delegation. Most stakers want to delegate stake rather than run their own validators, so they delegate out-of-protocol. LSTs are one such method.

Cosmos chains support easy native stake delegation, so out-of-protocol mechanisms aren’t needed.

3) DeFi Adoption

A key demand driver for LSTs is the ability to earn staking yield while using your tokens in DeFi (e.g., collateralizing a loan position, lending to earn yield, having LP position, etc.). There are a lot of DeFi apps on and around Ethereum with high activity, so there’s more attractive stuff to do with ETH LSTs.

Cosmos has had less DeFi adoption, so there’s simply been less stuff to do with LSTs.

4) Asset Moneyness

ETH is money. A lot of people want to use ETH in various forms, whether that be as DeFi collateral, paying for gas, buying NFTs, etc. Even if your chain has lots of activity, “money-like” assets such as ETH are disproportionately used as collateral.

Additionally, ETH is bridged around as money. It’s the native token of many other chains (major L2s) in a way that no other token is today. Once it’s being bridged and wrapped anyway, why not make it an LST? As ETH usage moves primarily to L2s, LST adoption is likely to accelerate. We’re seeing this play out with the recent chase for “native yield,” as L2s increasingly prefer ETH LSTs over base ETH.

Cosmos assets have been less useful and money-like. Holders are more inclined to just buy, stake, and hold these assets on their home chain hoping for the price to go up. This trend may start to turn around as cross-chain infrastructure improves and the bull market kicks back into gear. Cosmos DeFi is growing, and so are accepted gas tokens. For example, Neutron just voted to add stATOM, wstETH, dYdX, and TIA as gas tokens.

Outside of ETH, TIA appears best-positioned to become a money-like asset across many chains and achieve high LST adoption. It has more money-like attributes, is needed for payments across its rollups, and it will be bridged anyway when it’s being used. If you’re using TIA on an L2, why not hold stTIA?

5) Auto-compounding Rewards

LSTs can auto-compound rewards. As described earlier, this is valuable in boosting a staker’s ultimate yield beyond the baseline staking APR.

Validator balances in Ethereum are currently fixed at 32 ETH per validator. This means that the only way to compound rewards is by earning a full additional 32 ETH, then staking that with another validator. This would take years to accrue.

However, you’ll earn 32 ETH very quickly if you’ve got millions of ETH staked, so you can consistently spin up new validators, boosting rewards. This limitation favors large validators and/or pooling stake (such as via an LSP) such that rewards can be auto-compounded faster. Note that EIP-7251 (increase max effective balance) addresses exactly this issue among others.

6) Tax Efficiency

I’ve got a disclaimer at the end of this thing, but double disclaimer – this isn’t tax advice, I have no idea what I’m talking about, this will vary depending on jurisdiction, tax laws are unclear, etc.

Now, some people depending on their jurisdiction may use LSTs due to perceived tax efficiency benefits. In particular, receipt of staking rewards as a validator may be considered income taxable upon receipt. Alternatively, non-rebasing LSTs (such as Stride’s stTokens) increase in price rather than quantity. There’s an argument that these rewards are then captured as capital gains, which are typically only taxable upon sale and at a lower rate than income. Some LSTs such as stETH include the rebasing model, but these can be wrapped (i.e., wstETH) to achieve the same effect.

There’s also some argument that even if staking rewards are taxable as income, they would only be considered taxable upon claiming. Staking mechanics differ by chain. Some will automatically deposit the new rewards into your account, and others may accrue rewards which require a transaction to claim them at the validator’s discretion.

7) Avoid Unbonding Window

The ability to sell is valuable, and all PoS chains have an unbonding window. If you want to earn staking rewards while retaining the ability to sell instantly, you need an LST. Cosmos’ particularly long unbonding windows (14-21 days) can actually make LSTs even more appealing in this regard. The length in Ethereum can vary based on the exit queue at the time, though it will generally take days to complete.

Alternatively, some might not trust themselves with that liquidity:

In summary, here are the incentives to use LSTs for the respective ecosystems:

Ethereum had the prime setup for LSTs – its native staking has been uniquely challenging to use, people really like ETH-based DeFi, and people really like using ETH as money in DeFi and elsewhere. As a result, LSTs have a ~40% staking market share in Ethereum. It will take time for other chains to catch up with similar adoption.

The LST market penetration in Cosmos is still incredibly low, providing high potential for future growth. For example, only ~1% of ATOM and ~5% of OSMO circulating supply are liquid staked.

Cosmos has been trapped in a difficult cycle. DeFi activity in Cosmos is rather paltry, largely as a result of the incredibly high staking yields across most of the ecosystem. This creates an incredibly high hurdle rate for Cosmos DeFi to take off, as it must compete with staking yields. This tradeoff can be broken with LSTs (removing the opportunity cost of staking), but there’s reduced demand for LSTs in Cosmos because of the minimal DeFi activity.

For any PoS asset to meaningfully be used in DeFi, it’s necessary for that chain to adopt LSTs. Ecosystems that want to increase DeFi activity need to aggressively lean into LSTs more. As noted in the LSM proposal:

“The growth of Cosmos DeFi over the past six months has represented a virtuous cycle. As DeFi activity increases, the demand for ATOM increases and liquidity conditions improve. And as the demand for ATOM increases and liquidity conditions improve, ATOM appreciates in price, leading to more DeFi activity.

But this virtuous cycle wouldn’t be possible without liquid staking. Without liquid staking, the use of ATOM as collateral is not economically viable, due to forfeited staking rewards. Only with liquid staking does it make economic sense to deploy ATOM as collateral, since the user doesn’t have to forfeit his staking rewards.

Liquid staked ATOM, especially Stride’s stATOM, has played an essential role in the development and expansion of Cosmos DeFi over the past six months. Most upcoming Cosmos DeFi apps will also be dependent on liquid staked ATOM.”

Here are a few of the most common use cases today for stTokens:

Institutional Adoption

Slow institutional acceptance has been one of the largest factors slowing LST growth to date.

It’s a common trend that my personal ETH and SOL positions are mostly in wstETH and jitoSOL, but DBA’s ETH and SOL positions are both natively staked via a regulated custodian. Institutional investors tend to have a relatively lower risk tolerance (particularly smart contract risk) and higher preference (or even requirement) for easy custodial support. Large funds will sometimes even just run their own validators to maximize economics and minimize risk.

Reversing this trend will take time for the LST industry as a whole. While LSTs are probably strictly “better” than native staking at the limit, they’re not there today. The additional risk and lack of custodial support isn’t adequately compensated for.

However, Stride is well-positioned on this front. Stride has always placed an incredibly high emphasis on institutional-quality safety and security, for example:

  • Minimalist Design – Stride keeps a minimalist design tailored for liquid staking, which reduces the attack surface, simplifies processes, and reduces edge cases. It’s not implemented as a series of custom smart contracts on top of another general-purpose chain.
  • Audits – Stride uses incredibly battle-tested code which has been fully audited by several different firms, and they receive ongoing quarterly audits from Informal Systems.
  • IBC Rate Limiting Module – On top of fail safes, Stride built and upstreamed an IBC rate limiting module that caps the amount of funds that may be withdrawn from the network. Configurable rate limits can apply to different assets with varying logic.
  • Economic Security – Stride is secured by the Cosmos Hub validators, giving it some of the most reputable, performant, and economically secure validators in crypto.
  • Sovereignty – Under a worst-case scenario, the sovereignty and forkability of an app-chain is incredibly valuable in recovering from failure.

Additionally, Stride has been working long and hard to get institutional custody for both STRD and all of its stTokens set up, and this finally just came online this past week. This is attractive for other Cosmos chains, as most Cosmos assets have historically lacked good custodial support. With Stride’s stTokens supported, these chains will automatically get custody support for free via their stTokens. In other words, even if your chain’s token isn’t important enough for custodians to care, you could automatically get your stToken supported.

Lastly, it should be noted that there are various other regulatory considerations around staking and liquid staking in particular which may inhibit growth. The level of clarity will hopefully continue to improve here over time, though uncertainty remains for now.

Competitive Landscape

LSTs often lend themselves to winner-take-most dynamics, and Stride’s existing products have been no exception. Stride dominates its current markets with ~85-95% market share for ATOM, INJ, OSMO, EVMOS, and JUNO.

The only other traditional Cosmos LSTs today (pStake and Quicksilver) have standalone chains with de minimis market share of a few million dollars. There’s always been speculation that LSPs could launch on Neutron (a general-purpose DeFi chain), though there are no plans to do so. MilkyWay is deployed on top of Osmosis (another DeFi chain), though it only provides milkTIA.

As a comparison, Lido has ~75% market share of Ethereum LSTs. Solana is more balanced, with no single LST controlling >50% of the total LST market. Marinade and Jito are in the lead, both with ~40% market share.

It’s difficult for a long-tail to gain market share because LSTs display strong network effects:

  • Security – Nobody wants to get rugged on their coin that they think is about to 100x just to earn a few percent of extra yield. Compromised multisig keys, contract bugs, etc. present severe tail risk. Users want LSPs that have a long track record of operating without issues, use battle-tested and audited protocols, etc.
  • Liquidity – Deep stToken/Token trading liquidity is needed for users to quickly move between their positions with negligible price impact. Much of the value of LSTs comes from their ability to be efficiently swapped.
  • Integrations – Similarly, LST holders want to be able to do stuff with their money. That means using it as gas on chains that allow it, depositing it into DeFi protocols wherever they want as collateral, etc. Smaller LSTs are less likely to get these integrations set up.
  • Moneyness – LSTs like stETH are broadly competing as a form of money. Brand value and Lindy effects matter, and they accumulate as a result of the above points.

Celestia Liquid Staking

stTIA is special among Stride’s upcoming products, so we need to dig deeper here. Celestia carries a number of idiosyncrasies that require significant attention to detail:

  • Celestia’s minimalist architecture (without any native smart contract capabilities) means that TIA LSTs must be created by offchain providers such as Stride.
  • Celestia doesn’t have ICAs implemented yet, so Stride’s normal architecture is not possible.
  • The Celestia community has a strong set of core values that must be accounted for. Its desire to minimize chain complexity, leverage offchain governance over onchain governance, and retain credible neutrality are of particular importance here.
  • TIA is well-poised to act as modular money throughout its ecosystem of rollups, which is likely to drive LST adoption. In combination with TIA’s high market cap, this presents a huge market.

We’ll walk through each of these now.

Enshrined LSTs?

The most Celestia-aligned LSP would of course be one that is enshrined into the protocol itself. As discussed earlier, that’s far easier said than done. It generally isn’t feasible or desirable. This is particularly the case for Celestia, as it would directly oppose Celestia’s stated core values. Enshrined LSTs would severely increase the scope of onchain governance, add base layer complexity, and lack neutrality towards the app layer. Additionally, outsourcing LSTs brings all the usual benefits (e.g., highly performant validator management requires quite specialized governance knowledge, other LSPs can issue incentives, lower regulatory risk, etc.).

The real question for Celestia is what changes (if any) should it make such that out-of-protocol LSTs like stTIA can be safer, more aligned, and more competitive?

Interchain Accounts (ICAs) vs. Multisigs

Celestia initially launched without supporting ICAs, so it’s not possible for Stride to issue stTIA through its normal process today. The only available solution at this time is to launch stTIA with a trusted committee. While ICAs are better from a trust-minimization perspective, time-to-market matters for LSTs. Up until just yesterday, MilkyWay on Osmosis was the only TIA LST live, and it uses a 5-of-7 multisig to secure funds for this reason.

Stride will use 7 high-quality, slashable validators, who operate both the Stride and Celestia chains (Polkachu, Imperator, Strangelove, Stakecito, Lavender.Five, Enigma, and Staking Facilities). Collectively, they manage more than $2.7B of stake across the chains they support.

As explored in this great Celestia forum post by the Stride team, adding ICAs to Celestia offers the clearest way to improve the trust properties of TIA liquid staking today. Optimistically, Celestia will enable ICA in their next upgrade. The Stride team is currently pushing this effort forward, putting forth the CIP required to implement ICAs:

This upgrade isn’t just beneficial to Stride. It improves Celestia’s interoperability more broadly by allowing for more complex trust-minimized applications; other staking solutions could also eventually take advantage of ICAs if they rebuild their products.

ZK-Rollup Endgame

For the longer term, Stride is looking into the best architectures beyond ICAs. Following on Mustafa’s post discussing how to possibly add SNARK accounts to Celestia, there’s now more exploratory work underway on how to add support.

As noted by Mustafa, Celestia intentionally keeps a minimal design:

“A core design choice of Celestia is to minimise on-chain state, thereby creating an overhead-minimised and minimal DA layer. This means that Celestia does not have an on-chain smart contract environment, and does not act as a “settlement layer” (i.e. a bridging hub) for rollups.”

Adding the minimal functionality to verify ZK-proofs seems to balance these core values well. Ideally, SNARK accounts would have a very similar impact on Celestia’s state machine as a normal account. This would add a very small footprint to Celestia, while allowing expressive offchain logic (e.g., rollups) to more trustlessly control accounts on Celestia. Most relevant to our conversation here is building the logic required to run an LSP on Celestia (e.g., setting validator delegate weights, staking TIA, claiming rewards, etc.), running it offchain (e.g., as a rollup), then having the Celestia base layer just verify the proof.

Stride has started working with Sovereign Labs to spec out how to build this maximally secure and aligned ZK-rollup for stTIA:

Copy-staking Validator Selection

In response to valuable feedback from the Celestia community, Stride will use copy-staking delegation for Celestia validators underneath. Importantly, Stride will remove the 30-32 validator cap that it normally uses to more accurately cover the entire Celestia validator set. CEXs and high commission validators (>10% commission) will still be excluded to ensure validator set health and performance, but otherwise the validator set will be distributed based on the weights of Celestia’s own validator set.

Of Celestia’s set of 100 validators, 86 meet this criteria. Stride is currently delegating to all of them. Stride normally limits its other host chain validator sets to 32 today because their current design delegates using a single ICA transaction, so the transaction needs to be kept small enough to fit within a single block’s gas limit. This cap will eventually be removed for all Stride validator sets as they’re working to refactor the code to batch delegations, allowing them to delegate across as many validators as they want.

Regardless, this won’t be a bottleneck for Celestia, as they’re not even using ICAs to start. The multisig committee can handle the batching, allowing them to delegate to the full eligible validator set. Assuming Celestia enables ICAs in the future and Stride migrates to using them, they’ll use the refactored code to keep the large validator set.

Copy-staking offers the clearest path to respecting the sovereignty and choices of Celestia’s own community in the near-term. It copies the decentralized validator set that native TIA stakers have already chosen. This contrasts with MilkyWay’s model of whitelisting 12 validators of their choice which they delegate to.

The main downside to copy-staking is that users delegating their own stake can often pick a top-heavy validator set, so copying their decisions may not be the most decentralized option. Celestia’s validator set distribution looks good at the moment though, so this seems appropriate as the best starting point today:

Source: Data from NG explorer as of 1/18/23

Additionally, a very far off problem could occur if and when stTIA represents a majority of TIA staking. For example, let’s say 99% of TIA is staked via stTIA. Then in this scenario, Stride would be copying the delegate selection preferences of the 1% of native TIA stakers. This would be problematic, as it would only take 1% of stake to influence the entire validator set distribution. This is of no concern at launch though, since stTIA would be instead copying the 99% of native stake, but it’s something to keep in mind as it grows.

The natural question to ask is why don’t you just let stTIA holders pick their own delegates then? Why can’t users just pick their delegate themselves when they mint stTIA (instead of copying the remaining native stakers)? Unfortunately, it’s not so simple. For example, an attacker could mint stTIA, delegate their stake to a malicious validator, sell the stTIA for TIA, and repeat the process to constantly shift around stake weights. You can read this paper on The Principal-Agent Problem in Liquid Staking for more details on these types of attacks.

Lastly, note that Stride’s core staking logic runs at a slightly slower pace for stTIA (every 24 hours) vs. its other stTokens (every 6 hours, as described earlier). This is a short-term result of deviating from their typical ICA architecture, and will eventually be modified in line with their standard 6-hour cadence. In practice, the difference in yield from refreshing at a slightly slower pace is de minimis.

Host Chain Alignment

Host chain alignment is arguably the most challenging fundamental problem in designing robust LSPs. How do we ensure that out-of-protocol LSPs are incentivized to do what is best for the host chain, and not just themselves? How can Celestia know that Stride will always do what’s best for Celestia, and not just what’s best for Stride?

As I discussed in my Proof of Governance post, you basically end up with two options that approach similar outcomes. You can either have your own governance mechanism directly pick validators (in which case the staking mechanism isn’t necessary), or you can build out-of-protocol LSPs that are aligned with the underlying host chain’s own governance:

We’ve seen Stride take two approaches to validator selection to align with the host chain’s incentives:

  • Copy-staking – Stride will copy Celestia’s existing validator set for its own delegation. This is aligned with Celestia by respecting the choices of its own community.
  • Host Chain Council – The Cosmos Hub and Osmosis vote for aligned council members. These councils put forth their preferred validator set to be used underneath Stride’s stTokens.

Both scenarios are aligned in that they respect their host chains’ communities and decisions. However, they are not entirely binding. Stride governance still ultimately has the power to supersede the decisions here. They may choose to appoint a completely different validator set at any time, deviating from copy-staking and evading the host chain councils.

This is the same exact conflict that fuels most of the debate over Lido. Lido governance can in theory go rogue and launch attacks on Ethereum. However, as noted in Mike’s great post on Lido attack vectors, these attacks appear unable to permanently damage the system, and in fact they mostly harm the LSP itself. In other words, incentives are naturally mostly aligned for LSPs. You don’t kill the golden goose. LSPs are incentivized to keep their host chains happy and healthy because they make money proportional to that.

However, that’s not always good enough. So, can we do better? I think so. Lido’s solution to this is dual governance. The TLDR is that stETH holders will be able to veto decisions made by LDO governance. stETH holders serve as a reasonable proxy for the entire Ethereum community here. You can refer to this presentation by Sam Kozin for more details on thresholds for vetoing, reconciliation procedures, etc.

So, can this work for stTIA? Can we give stTIA holders veto rights against STRD governance decisions regarding its validator set? On the face of it, it sounds quite nice. Dual governance strikes a great balance between:

  • Not overburdening stToken holders – stETH and stTIA holders don’t generally want to keep track of the day-to-day of managing validators and such. Specialized LSP governance should deal with this. The users just want to own their asset and get some yield.
  • Giving stToken holders power – However, stToken holders want to be safe from the tail-risk scenarios which would devalue the asset they’re holding. Veto rights should give them just enough power to stop the really bad stuff while not needing to deal with governance under normal circumstances.

However, this comes with some issues. As has been discussed regarding Lido on Ethereum, stETH holders are only a subset of the Ethereum community. They’re not representative of everyone. Lido is also exploring future dual governance versions that may include ETH holders in some capacity as well, but even the entire set of ETH holders doesn’t represent all of Ethereum. The same ideas apply to Celestia here. However, as Hasu has previously pointed out, this is really just a fundamental tradeoff inherent to PoS.

The other issue is just that stTIA will be much smaller than stETH at launch. There’s over $20bn of stETH out there, so it’s far from trivial to buy up a bunch of stETH and start griefing governance. However, buying up a large proportion of the stTIA supply may be a more plausible attack vector early on. This is especially true because stToken vetoes need to have some relatively low and conservative thresholds as not all stToken holders will be able to act quickly (e.g., positions locked in Defi, difficulties in cross-chain voting, etc.).

This problem of granting stToken holders governance rights cross-chain and while locked in DeFi is actually something that Stride has been working on for quite some time (e.g., allowing stATOM holders on Osmosis to vote on Hub governance). This could even be possible within DeFi if the user’s stToken is locked for some amount of time (to mimic the unbonding window), though challenges remain for edge cases (e.g., what if a user’s collateral needs to be liquidated). This is still a work in progress.

For now, the below appears to be clearly the best path for both Celestia’s health and Stride’s success:

  • Stride shipped the best version of stTIA possible today. Under the hood, they delegate to Celestia validators with copy-staking across the full eligible validator set. This is currently 86/100 validators.
  • When ICAs are hopefully added to Celestia, Stride will adopt them to improve its security model.
  • Stride will continue to explore the best technical architectures beyond ICAs, including ZK-rollups.
  • Stride will continue to work with the Celestia community on finding the best design to ensure incentive alignment. This must balance giving the Celestia community power without overburdening their own governance. This is likely to be an iterative and experimental process (and could well involve giving both stTIA and TIA holders some form of veto power over decisions which affect Celestia).
  • The Celestia community, including Stride, will continue to explore potential changes to Celestia itself to regulate and foster safe LSTs. This may include certain aspects of the LSM, or entirely different designs.

In any case, the key driving spirit for Stride as noted in their Celestia forum post on building safer and more aligned LSTs is this:

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

(st)TIA is Modular Money

LSTs Compete as Money

Building safe and aligned LSTs is particularly important when the asset at hand is trying to be money. We’ve all heard that TIA is modular money, but can stTIA be modular money?

Moneyness is a key feature that LSTs compete on, hence their incredibly strong network effects. As with ETH, it’s not the native asset TIA itself that’s really competing as money long-term anyway. It is necessarily a wrapped and bridged representation given the ecosystem’s multi-chain architecture, so why not make it an LST as well?

We see this playing out in the Ethereum ecosystem, where stETH is poised to become the dominant money. This is particularly true for rollups, where base ETH will no longer hold its special place. We now see Ethereum L2s aggressively chasing yield-bearing assets there. We’re likely to see something very similar in the Celestia context. If you’re going to use TIA on a rollup, why wouldn’t you use stTIA?

In both cases, it’s essential that the LST in question is built to be maximally safe and aligned, thus mimicking the moneyness of the base asset. ETH may have a shot at being money, but some YOLO restaked ETH LST built on a 1/1 multisig with one validator doesn’t.

However, stETH does have a shot if it can create a decentralized validator set (i.e., the Staking Router) with constrained governance (dual governance). Lido’s stated purpose is to keep Ethereum decentralized, accessible to all, and resistant to censorship. This makes a lot of sense – these features are prerequisites to being money. An LSP is incentivized to make sure the base asset has great monetary properties, then mimic its properties as close as possible and enhance them through its LST representation.

The same is true of stTIA, and Stride is focused squarely on this vision.

Stride – The Modular Money Bridging Hub

Celestia’s minimalist architecture creates a vacuum for some other chain to necessarily serve as the default TIA bridging hub for rollups, and Stride is the only chain poised to fill it:

  • Asset Issuer – You want to get assets directly from the source when possible. stTIA is likely to actually be preferable for rollups vs. bridged TIA for the reasons described. Stride is also clearly positioned to be the asset issuer for many of the most useful tokens in the broader IBC ecosystem, thus its centrality in these trade routes exists naturally. To the extent that base TIA is also used on rollups, Stride would still be the logical routing hub.
  • Safe & secure – As detailed earlier, Stride has an incredible focus on safety and security. This includes a focused architecture with battle-tested code, diverse and routine audits, IBC rate-limiting, high economic security, decentralized validators, and full stack sovereignty.
  • Reliable – Stride has shown a long track record of operational excellence and performance, while other Cosmos chains have had reliability issues such as extended downtime.
  • Neutral – This is the most important point. Other candidates such as Osmosis or Neutron are directly competitive with their potential connections. Stride’s functionality is entirely restricted to LSTs. Stride does not host any native DeFi.

Let’s think strategically from the perspective of potential TIA/stTIA importers (e.g., Celestia rollups). You don’t want bridged assets from a direct competitor because this gives them leverage over you, and you’re drawn into their politics.

Imagine you’re building a rollup, and you want it to be the TIA/stTIA DeFi hub. This should be the cool place where users go to trade TIA/stTIA with deep liquidity, use it as collateral, buy NFTs with it, whatever. Well then you don’t want your TIA and stTIA to be bridged representations inextricably linked to a direct competitor whose stated goal is to fulfill the exact same role (TIA/stTIA DeFi hub). Imagine trying to get your rollup to be the primary TIA/stTIA trading venue if Stride had a native stableswap DEX with stTIA/TIA deployed on its own chain.

We see the unfortunate but predictable results of head-to-head competition even between Osmosis and Neutron themselves, including accusations of poaching from each other and some rather avoidable beef.

Osmosis and Neutron both have some great teams, but the “grow the pie” mindset is challenging in practice when many of the biggest “Cosmos app-chains” aren’t really app-chains. They’re general-purpose direct competitors going for the same apps and users.

Osmosis is best-known for its DEX, but it’s actually a full-service chain that continues to vertically integrate, with apps such as:

  • ICNS – The Interchain Name Service is deployed on Osmosis and directly competes with Stargaze Names to be the ENS of Cosmos.
  • MilkyWay – MilkyWay received a grant and token swap to deploy its LSP on Osmosis and issue milkTIA from there.
  • UX Chain – Osmosis is merging with UX Chain (f.k.a. Umee) to expand its DeFi offerings, such as borrow/lend.
  • Mars Protocol – A borrow/lend protocol with outposts on both Osmosis and Neutron.
  • Astroport – DeFi protocol which also has a Neutron outpost, but could be coming to Osmosis:

L2s looking to import Cosmos-native assets like TIA and stTIA don’t want to get into Cosmos politics or give leverage to competitors. They just want a place to get assets from. No more, no less.

Stride is the neutral, reliable, and secure asset issuer poised to serve as this routing hub. Stride is an appchain. It’s an LSP. It issues LSTs, and it sends them to people. It’s essential that Stride does not allow for any native DeFi activity such as trading, borrowing, lending, etc. on its own chain. As with Celestia’s focus on data availability, Stride’s biggest advantage is focusing on its single purpose. Do one thing, and do it well.

As a result of all this, stTIA is the obvious choice for many of these modular chains:

The only snag would be that Stride only has IBC bridging today, but there’s a lot of other chains that aren’t IBC-compatible. Stride would need to add some sort of permissionless interoperability solution to make this work, maybe something like…

stTIA Airdrop Eligibility

Airdrop FOMO has historically been a meaningful drag on Cosmos LST adoption.

Cosmos has a history of airdropping to stakers, and TIA staking is currently one of the hottest airdrop farms. TIA stakers seem to be expecting several large airdrops, with protocols such as Dymension, Saga, and AltLayer all including them in their eligibility criteria. AltLayer’s also included milkTIA which is a great sign that projects will start including LSTs (stTIA was of course not live for this snapshot, as it launched yesterday).

The concern for LST adoption is that some protocols may only include native stakers. That’s often happened with traditional Cosmos airdrops. As a result, Cosmos asset holders have historically been afraid to use LSTs and miss out on airdrops.

stTIA has the potential to reverse this trend.

Following Cosmos’ troubles in the past few years, there’s a growing realization that protocols should be doing the exact opposite when formulating their airdrop criteria. At the risk of getting myself excluded from future airdrops, native TIA stakers are largely comprised of early locked Celestia investors that will immediately dump your airdrop (hypothetically). These are not a prime target audience.

From a protocol perspective, it makes little sense to airdrop native stakers at all. You dilute a finite pool across many disinterested parties. Conversely, LST holders (particularly ones who also use their LSTs within DeFi) demonstrate that they are among the most active and involved community members. These are the users you actually want to attract.

Cosmos LSTs have historically just been an afterthought. They were small, and overlooking them simply wasn’t a concern for projects hastily setting airdrop criteria. However, stTIA is already a large market, and in particular one that is systemically important to the protocols doing the airdrops. If you’re building a chain that wants to attract stTIA liquidity, it’s logical to reward and attract these users directly rather than idle native stakers.

It also just requires work and connections to set more nuanced airdrops. It’s easier to blindly set airdrop criteria for all native stakers rather than map out LST holders. However, Stride has successfully demonstrated this in the past, helping teams like Neutron ensure that stATOM holders were accurately captured in their airdrop criteria. stATOM holders and DeFi users were also eligible to receive Dymension, Pyth, and Aether.

Stride will need to continue working with the biggest upcoming modular projects here.

I’m optimistic that the Celestia ecosystem will learn from the mistakes of Cosmos. Locking up all of the capital in your ecosystem as dead money to airdrop farm is an easy path to smothering hopes for a lively DeFi ecosystem built around modular money.

Obviously everyone needs to make their own decision here, and there’s no guarantees of anything if you’re speculating on airdrops of magic internet coins. But this is a legitimate and important area for protocols to spend time thinking about, no different than all the attention around Saga phone airdrops bootstrapping adoption. The incentives will matter here.

Stride Economics & STRD Token

Stride Economics

As noted earlier, Stride sends 15% of its applicable revenues to the Cosmos Hub:

Governors take their standard commissions out of the revenues flowing to Stride here. After that, a 5% community tax is taken out and sent to the Stride community pool, which is governed by the Stride DAO. The remainder, which is the large majority of value, is then sent along to all STRD stakers. This means that in addition to STRD rewards, STRD stakers also continuously earn a basket of all stTokens that Stride issues. It serves as a direct index on all of them.

As noted earlier, the amount of STRD inflation for staking rewards is incredibly low (<1% of total supply per annum, and gets cut in half every year). Fees also aren’t that high on Stride itself. The vast majority of Stride’s revenue comes from the stToken staking rewards. Staking services are one of the few highly revenue-generative businesses in crypto.

This is particularly true when the customers in question have relatively high inflation rates, as that’s the basis upon which Stride’s 10% fee applies. This means that reductions in inflation of course reduce the marginal revenue of an LSP. However, most new projects will continue to launch with high inflation rates, far more than offsetting the gradual reduction of maturing protocols. For example, Celestia’s current APR is >16% p.a.

Token Distribution

As outlined in the initial tokenomics post, STRD’s max supply is 100mm. The approximate allocations at genesis are shown below:

A total of ~89mm STRD currently exists today. The approximate allocations at present are shown here:

The sale of 3mm STRD to locked post-launch investors was made from the Incentives Program to diversify assets, and was approved by the Stride DAO in 2023. 3.5mm STRD will soon be added to this bucket of locked investors in conjunction with the current raise. These tokens will come from the Stride Association’s Strategic Reserve, to again diversify asset holdings.

You’ll notice that several of the allocations above weren’t actually fully minted at genesis. New block-by-block STRD emissions are split between four targets, until they each reach their allotted caps:

Stride’s current aggregate inflation rate is technically ~4.58%, but this is mostly due to the idiosyncrasy described where most of it is actually filling up the Stride DAO controlled buckets to get to the max allocation. The amount of inflation going into circulation to STRD stakers is only ~0.73% p.a. (4.58% x 16.04%). All of these inflation schedules undergo a halvening every year.

STRD Airdrops & Incentives

Stride currently has >22mm STRD earmarked for incentives and airdrops (>$94mm at time of writing, with STRD/USD at $4.20), sitting in two accounts:

Governance can transfer tokens from the module account to the distribution multisig for the Stride Association to use for stToken incentives. The DAO very recently moved an additional 9mm STRD over.

The Stride DAO is well behind the initial mandate to distribute 20mm STRD in the first year of existence, so it’s got a lot of dry powder. These savings provide Stride with a large warchest to incentivize LST adoption, and that’s exactly what they just did for stTIA, allocating 5mm STRD in now ongoing incentives and airdrops for stTIA holders. Not points, just real STRD.

Conclusion

Cosmos has always been ahead of the curve. So many of the core innovations in crypto continue to come out of Cosmos, and LSTs are no exception.

However, Cosmos has of course lacked some practicality and execution historically. It’s had the tech, but it’s struggled to acquire the users and volume proportional to the mindshare it holds. The wave of modular chains, all built around Celestia, are now set to change that.

Stride sits right in the middle of this fusion of the old Cosmos and new Cosmos. Stride is focused solely on LSTs, and they’ve been consistently offering the best-in-class stTokens as a result. Do one thing and do it well. Now, that means becoming the central asset issuer and neutral bridging hub for modular money.

Disclaimer: The views expressed in this post are solely those of the author in their individual capacity and are not the views of DBA Crypto, LLC or its affiliates (together with its affiliates, “DBA”).

This content is provided for informational purposes only, and should not be relied upon as the basis for an investment decision, and is not, and should not be assumed to be, complete. The contents herein are not to be construed as legal, business, or tax advice. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. This post does not constitute investment advice or an offer to sell or a solicitation of an offer to purchase any limited partner interests in any investment vehicle managed by DBA.

Certain information contained within has been obtained from third-party sources. While taken from sources believed to be reliable, DBA makes no representations about the accuracy of the information.

The author of this report has material personal investments in TIA, stETH, ETH, jitoSOL, and SOL. DBA is an investor in STRD, ETH, SOL, and Eclipse Laboratories, Inc.