Can you elaborate on this please? Helpful to understand the downside.
We support this and would vote yes.
i suppose the scope of possibilities is wide depending on the initial conditions of the LSM LSD LP being proposed. If the assumption is that the entire capacity of the 25% LSD LP is immediately gobbled up, the risk is reduced compared to allowing it to reach capacity based on organic demand.
this leads to the issue of why would ATOM volunteer to expose itself to bridge risks of LSDs and their silo’d liquidity for zero compensation. cosmos LSDs have not demonstrated a demand nor utility warranting atom take them on as a counter party. LSDs in the cosmos arent like ETH LSDs which had no ability to unbond after 21 days and have a much higher bar for staking as an individual user. Cosmos LSDs dont have those problems to solve for, cosmos LSDs are searching for a problem and it seems negligent to create a market for LSDs while ATOM shoulders unreasonable risk without compensation if the unforced outcome of cosmos LSDs is failure.
It seems unwise to tie the success of ATOM to the success of untested and unproven LSD providers.
without the LSM there is no more Atom LSD ?
No, but thats kind of the point. why push so much of the LSD risk onto ATOM without any compensation to ATOM, and lack of demand/utility warranting an irreversible and hasty dependency?
i feel your comment meant like “why are you creating LSDs with this module” as if they don’t exist yet and more importantly as if they would not grow without it.
isn’t setting some limits a good thing ?
how this module could allow more potential gov manipulations than if there were no module of that kind ?
happy to learn more if i missed something.
Roughly, yes. I assume that LSDs will spread by atom APY since they compound every 6 hours or however long.
The gov manipulation is an issue if there is a substantial gap between the LSD issuance cap and number of LSDs issued.
so while i think a hard cap for LSD issuance is necessary, my gripe is mostly with the implied creation of new LSDs all of a sudden. Assuming that LSDs will grow by APY on average, i would advocate for APY being the rate at which LSDs are allowed to grow and a cap below 25% until a case for raising the cap can be made.
does the cap apply to total supply or bonded supply? if total supply, it should be substantially lower than 25%.
on the other hand, It doesnt seem likely that cosmos LSDs will be listed on CEXs, so ATOM will remain the liquid asset. it makes no sense to create an NFT LSD LP on ATOM
I very much support the LS module & appreciate the effort put into writing this piece
Couple of points:
1- Why allow any user to validator-bond? Seems to weaken the purpose of the concept
2- How is this concept better than a self-stake requirement for validators?
So that validator teams no longer need to commingle funds.
If a validator team has many people on it they can each put their own weight behind it.
One place where I am concerned about this requirement is actually notional delegations program. We delegate to other validators on chains where we have large holdings. That includes the cosmos hub. Over the next week, I’m speaking with various LSM teams and will be trying to get a feel for how this would affect Notional and our delegation program. It is our preference to delegate to smaller validators because we would like to help people enter the cosmos.
Wont the LSM effectively increase the circulating supply by <57mm ATOM at 25% of the staked supply?
ATOM should at very least collect a 10% fee on all LSM volume* kicked back to ATOM delegators.
As far as I understand, validator-bonded ATOM will only be illiquid as long as the full 250x LS cap has been filled. If let’s say there is 1ATOM validator-bonded, but only 50 ATOM Liquid Staked (out of the 250 cap) to that validator, then 0.8ATOM can be removed as validator-bond. However, since one wallet can only do one or the other (bond or validator-bond), it would mean that if the full amount of 1ATOM came from 1 wallet, that wallet would indeed not be able to withdraw.
No, I don’t think that’s part of the code at this point. That would require a tight collaboration between the LS provider and the LSM as the LSM wouldn’t know which LS provider you would use…
Agree with this, see my point 2.A above.
The main improvement here imo is that the validator-bond is related to the amount of delegations (from LS), while the self-stake requirement is just an absolute number.
I don’t think that feature would weaken the module, quite the contrary. I’d say that some node operator companies have their assets distributed in several cold wallets. In our case, at Stakely, we don’t leave most of our assets in our validator wallets. Having that flexibility allows many validators to participate in a more optimal way with this LSM.
In case this feature is not implemented, I’d say that there should be a way of increasing your bond-validator stake other than just self-stake.
As far as I understood, making your delegation be counted as bond-validator is optional and it does not give any benefits to the delegator. In fact, it could lock your delegation, so I don’t think a common user would use it.
A much needed feature imho to facilitate the migration of existing staked tokens to liquid representation without unbonding. Not to mention this can also prevent users to make use for derivatives & hedging to cover for unbonding periods.
A big yes here !
I am Philipp from ERIS Protocol, a LST provider on Terra, Migaloo, Kujira, Terra Classic, Juno and soon Injective. We do closely watch also Cosmos Hub and have an expansion plan in place to also support liquid staking on the Hub through ERIS. We currently have ~ 2.5 M $ TVL and have received a sizeable grant from the terra community.
The prop should be split into two distinctive proposals.
- Add the LSM for the ability to convert staked ATOM to LSM shares
- Add the regulation
These are distinct topics that also should be decided distinctively and not trying to get one through by adding the other and vice versa.
The regulation favors incumbent LST providers and regulates the free DeFi market based on bad LST models!
Our governance model is completely different to other LSTs, only allowing users locking the LST itself in a curve style gauge to leverage their voting power. In this way users decide both the delegations and governance and still have control over the network. As they are locking e.g. ampATOM or ATOM-ampATOM LP for Cosmos Hub they have a vested interest into the health of the system and the mentioned risks are mitigated.
Users and validators with staked interests in ATOM will still own their delegation and governance power!
https:// docs. erisprotocol. com/products/amp-governance/
Governance risk: Using Amp Governance, users and the open market decides on the governance.
Validator corruption risk: Using Amp Governance, Validators wanting to receive delegations will have a curve style bidding war in locking capital to receive delegations. This leads to exactly the opposite of validator corruption. You will enable validators to have a strong vested interest in the chain.
Vote power concentration risk: Using Amp Governance, users and the open market decides on the delegations.
Cascading liquidations risk: This requires multiple products / apps to be deployed to keep stability and is our main goal as LST provider. Our just launched Arb Vault on Terra showcases how we hold the peg between LUNA-LSTs which can also be deployed for other LST pairs on other chains. https:// docs. erisprotocol. com/products/arb-vault/
In total this is the ecosystem we can provide for stabilization and fair + market based approach.
https:// docs. erisprotocol. com/vision/#stable-lsd-economy
We do not have a token and are self & community funded to be able to provide the best value to the cosmos ecosystem instead of extracting value and maximizing profits like some of our competitors.
I strongly call upon the Cosmos Hub community to reconsider introducing regulation based on bad protocols / actors and also not favoring incumbent LST providers.
So my vote is clear:
- Add the LSM: YES
- Introduce regulation: NO / NWV
- Both in a single proposal: NO / NWV
If a regulation is followed up on, it should be applied to specific providers and not being generalized.
I recently created a Twitter thread discussing this topic. I don’t often make threads on Twitter, so please forgive me if it’s not perfect, but it’s not essential for you to read it.
TL;DR: Regulations of this kind can be bypassed through various methods. For the sake of brevity in this comment, I’ll share the most robust and difficult-to-refute bypass method: implementing MPC-based addresses directly into the liquid staking offering. This approach cannot be regulated, as the L1 wouldn’t be able to programmatically determine if it’s part of a liquid staking provider’s offering. Addresses in such a protocol would appear the same to the L1 as regular stakers. An example of how this protocol could work is by sharding a private key for any chain, storing some of the shards in a Secret Contract, and some off-chain. This means that even if the secret contract was compromised, the funds wouldn’t be lost since, for instance, 49 shares would be stored in the contract and 51 shares outside the contract. Other design approaches for an MPC-based LSD offering are equally effective.
Here’s the thread, and feel free to point out any inaccuracies or poke holes in my argument. In my opinion, these regulations merely increase the barrier to bypass rules; a well-funded and skilled team could still bypass them.
ps I love the iqlusion module discussed here, and hope it comes to secret network, with our own params ofc.
Allow LS to exist and thrive, just OUTSIDE of the Cosmos Hub.
Yes the existence of protocol controlled private keys enables bypassing in protocol regulation and the existence of protocol controlled private keys should moderate the ambitions of people who believe that complete regulation of liquid staking is possible.
The regulations proposed here are designed to incentivize liquid staking and hub governance alignment.
Thanks for the response. I do think however that they will simply be bypassed and thus are the weakest part of the pitch. But again, I really like the LSM module and think it should go upstream into the SDK. I’ve been wanting that for a long time so I appreciate all the work you do.
Commenting as a Stride contributor - we support this prop and feel it balances LST safety and UX improvements well. It makes LSTs safer (global cap), validators more aligned (validator bond factor), and the onboarding UX easier.