Sharing this section from my newsletter, in case its helpful for the discussion:
In addition to the points raised in the forum, here are a few limitations that, in my opinion, are worth discussing before moving forward with the proposed Liquid Staking Model:
Limiting liquid staking:
While the cap proposed (25%) could be up for debate, I think that having the parameter implemented is a must for the hub’s safety in the interest of protecting it from potential attacks. Eventually the community will decide on an optimal percentage as the LSD landscape becomes more developed.
However, one issue with limiting Liquid Staking is that, based on the technical implementation proposed, it won’t only apply to Liquid Staking Providers (LSDs) but to anyone using Interchain Accounts (ICA) to stake $ATOM.
E.g. a DAO on Juno that natively stake their $ATOM via ICA.
→ A possible solution could be to apply this cap only to LSDs by separating them from other ICAs.
At its core, the idea of encouraging validators to put their capital at stake could only be beneficial for the network. However some points were not considered in the proposed implementation:
- It requires validators to bond capital to be eligible without any guarantees of receiving delegations because the selection mechanisms are still controlled by Liquid Staking Providers, which is the decisive issue here.
- It affects liquid staking providers who addressed the flawed distribution mechanisms at hand, as well as certain validators: Quicksilver, a liquid staking provider, allows users to delegate to a validator of their choice. Which eliminates the issue at hand.
If implemented, the LSM will force certain validators to put up additional capital to retain their delegations.
E.g. a user who wants to instantly liquid stake his bonded $ATOM with the same validator won’t be able to if his validator does not ‘validator-bond’ additional capital.
→ A closer look needs to be taken at delegation distribution mechanisms by LSDs to evaluate which ones are flawed and implement the Validator-Bond mechanism accordingly.
→ If a ‘Validator-Bond’ for liquid staking delegations is applied at a protocol level, it makes sense to distribute delegations pro-rata between all validators putting capital at stake.
This will further decentralize the Hub Set and incentivize all validators to have skin in the game.
Instant liquid staking:
I’m in full support of the feature but I wanted to float the idea of adding an instant non-liquid staking mechanism that allows users to switch back to normal staking by burning their LSDs. The feature could be useful in case of exploits to a Liquid Staking Provider, where users would like to switch back to native staking without waiting during an un-bonding period that could, temporarily, decrease the network’s security.