If external LSTs limit the rate at which users can redeem their tokens, then users have more of an incentive to use an LST that does not have such a restriction, for example one created using the native tooling.
Thats a good point, and I guess we assume some level of “good governance” from users in their selection of the external LST (and implicit social contracts that has on redeemability). I’m trying to pin down if theres any clear things we can say, if we don’t assume that though, since the space of anti-competitive moves is probably quite large. E.g. we can say that the LST won’t have governance that will rug money to a centralized actor, as thats entirely uneffective protocol governance.
Something I realized with the current stTIA / milkTIA situation going on right now, is that there is a bound on how close the derivative price needs to be the underlying, if the derivative is under-priced.
E.g. redemption rate is 1 derivative token = 2 underlying token. But the spot price is 1 derivative token = 1 underlying token.
Theres a “free 2x” arb to swap underlying to derivative, and then redeem. This has costs on:
capital constraints to execute to arb
loss of underlying’s staking APR for the unbonding period
cost of liquidity lockup for the unbonding period
For stTIA right now, this is leading to it being underpriced by ~1% today! (This almost perfectly tracks the staking APR of Tia for 3 weeks)
So anti-competitive worsening of redemption rates, can lead to worse pegs wrt. the derivative being undervalued.
You can simply not have an LST that is a basket of validators as a primitive.
Whether or not that is permisionless (Rocket Pool) or permissioned (Lido) does not even matter. In fact a basket that is permissionless, performs worse.
Having liquid staking enshrined into the protocol by itself is also not a good idea. Only large validators will be able to bootstrap liquidity for their LSTs.
So you really want validator specific LSTs, but you also want liquidity for it.
That’s exactly how we designed Tenderize and the only logical approach to LSTs in the long run.
Liquid Staked Token per Validator
Shared Liquidity for these validator LSTs
Create your own Lido, compose validator LSTs, be liquid.
Hey nico, thanks for commenting. Do you mind elaborating on the differences between a basket of validator tokens and what you described? naively, they seem identical.
A basket means a subset of validators on the network
E.g. If Celestia LST “Abc” only stakes to 10/100 validators , and it becomes really popular, there is a real danger of stake centralising to only 10 validators who are also now in a cartel together.
I agree validation should be separated from governance. What is missing in this thread is dialogue about the notion of using a ST to LST g/w slashing curve, which increases the cost of LST to LST moves based on block count move amounts and validator set changes per time step within an epoch , the slashing curve should be hockey stick steep for the LST vampires , really these moves are speculator powered algorithms designed for one thing MEV which leads to monopoly standing for those driving such moves, which means per epoch in-chain or bridge to chain slashing curves acting as LST 2 LST gateways supporting such moves should say within the 7 sec epoch be slashed to up to 75% and be throttled how many blocks of LST they can convert per step, say 25% per step, so there is a tangible cost to making even one move, and than the number of blocks moved per step should also shrink per step within that epoch. Likely essential functions to ensure the longevity of any dPOS project and keep them distributed. Slashing fees go to the slashing bridge or slashing chain treasury and can only be used for development? Like/same validator sets(by reputation score) have LST to LST moves happen instantly with minimal fee.
Without the ability to choose a validator, a liquid staking protocol is exactly a cartel.
The multisigs that have entered the scene have muddied the waters further, because there is no way for celestia to control this practice without labeling accounts, as I described in my first post in this thread, and later abandoned.
Unfortunately my suggestion was the absolute opposite of governance minimization, and should be left there as a counter-example of what a good idea is. Thank god I took a shower after writing and came to my senses.
So, I think that we have returned to the classical liquid staking conondrum:
anyone can make a liquid staking product
cexes
contracts
chains
celestia itself
unless we begin to treat accounts in an unequal manner (we should not do this) then Celestia will have no control over Cartelization.
…which is why, I suppose, the best path forward on this could really be having a frank look at the risk pricing implications of liquid staking.
Today, liquid staking users:
gain mobility at the cost of using the liquid staking protocol
retain slash risk
@rreive – how to build your hockey stick, without treating different accounts differently?
reality the multisigs being used by stride and mikyway are indistinguishable from normal user accounts, so it’s super inadvisable to attempt to treat them differently, programmatically.
The notion that all accounts can perform all actions, is a hill I’m willing to die on.
however
Being strongly convicted about user accounts having equal capabilities at all times, is a blocker to the prevention of harm & cartelization by liquid staking protocols.
