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.
6 Likes
Cem from Sovereign Labs here. We’re looking forward to speccing out the end-game of Celestia liquid staking with the Stride team!
6 Likes
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.
5 Likes
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.
3 Likes
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.
3 Likes
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.
7 Likes
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.
4 Likes
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?
5 Likes
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.
3 Likes
Hey Neel, what are the top reasons for rollups to bootstrap TIA liquidity unless they use TIA as a gas token?
4 Likes
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.
3 Likes
Copying this comment from the CIP to preserve for posterity:
[question] does this proposal recommend enabling one or both parts?
- The controlling portion of interchain accounts
- The hosting portion of interchain accounts
- The controlling and hosting portion of interchain accounts
I think it’s either 2 or 3 but think it could be clarified.
4 Likes
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.
3 Likes
Definitely - this proposal is to add the host portion of interchain accounts.
1 Like
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
3 Likes
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
2 Likes
I don’t have any objections with including the feegrant messages. Do the CIP authors have any feedback about including those messages?
1 Like
No objections to adding these!
Opened a PR here [CIP-14] Add FeeGrants msgs to AllowMessages by asalzmann · Pull Request #110 · celestiaorg/CIPs · GitHub @agouin
3 Likes
same, no objections and great to see ICA host getting used for multiple use cases
1 Like
Thanks @nashqueue for bumping this on X https://twitter.com/NashQueue/status/1783925993398305256
All delegation strategies for liquid staking tokens (which aggregate stake across validators) have tradeoffs. One example of a such a tradeoff is user choice and safety. To illustrate this: if I can spin up a validator, delegate to that validator through the LSP, and self-slash, then I socializing losses across all LST holders (high choice/low safety). Every delegation method has pros/cons (a few strategies listed below).
Zeroing in on your question about copy-staking
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?
It’s true that if 50% of voting power is copy staked, then native stake has double the power relative to a system with no LSP, which increases the power native stakers have. This lowers the cost of an attack, if the LSP has no restrictions on delegations (imo the economic cost to attack L1s is understudied/poorly defined, but that’s a separate point). However, I don’t foresee this being an issue because the staking system on Stride can be modified to prevent such attacks (it already does to some degree). E.g. a restriction on Stride today is that no validator can receive g.t. 10% of stake. Another restriction that could be added is on validator churn - e.g. if there’s high churn, stTIA holders (or TIA governance) could veto redelegations. There’s a balance to strike between the LSP being unopinionated and remaining safe - “copy staking with minimal restrictions” is probably as unopinionated as you’d want to go with an LSP (not all communities will want this, but we’ve heard from Celestia/Osmosis that they do).
My personal view is that it’d be healthy to supplement copy-staking with a committee or governance model, once the LSP has gained more trust in the ecosystem. For Celestia, my sense is this would require Stride becoming trust minimized (separate discussion, but one path to achieving this would be through SNARK accounts as discussed in the post). In practice committees/governance pick more distributed sets than those that emerge organically through user choice in (D)PoS (see Ethereum vs. Lido stake distribution).