Defending Against LST Monopolies

[LST]

Great write up guys,

If I have to sum it up, the measures proposed above make it easier for competing LSTs to vampire attack the incumbent to prevent monopolies. While I think this is a good measure, I don’t think it will be completely effective. If we look at chains like the Cosmos Hub where the LSM allows for users to have complete movement between LSTs, the lower fees options are still not widely adopted and vampire attacks on the incumbent might not always be successful. This leads me to conclude that LST monopolies have a substantial social and liquidity component to them.

I think to actually prevent monopolies, alongside a dynamic unbonding period; a more direct approach is required and this should be done at the ICA level.

1. ICA connections have to be governance gated: I think it is unreasonable that any chain could connect to another chain without prior consent. There are many use cases where ICA could be subjectively undesirable. Governance gating ICA also gives the Celestia chain substantial power to regulate LSTs and prevent monopolies.

2. It should be more expensive to delegate to the incumbent after a certain threshold. If an ICA account is accumulating stake beyond a certain point the cost for the users to delegate to this account should increase.

3. This can be implemented through an in-protocol LST tax which should apply to all protocols and scale based on the amount of assets staked through a particular ICA. The scaling factor of the tax should be substantial enough wherein it makes monopolies impossible.

4. Such a tax implemented alongside the dynamic unbonding period will make it easier for users to switch to cheaper options.

5. Isn’t a tax the same as lower fees? When a new LST offers a basket with lower fees; the delta between the incumbent and the new LST is limited as the incumbent could lower fees to maintain a monopoly or the liquidity effects of the incumbent could undo the effects of any marginal cost reduction. A tax theoretically has no upper ceiling; meaning this delta could be substantial and impose heavy costs on delegators if they do not switch. This would make monopolies near impossible.

6. A LST tax could also be used to protect against principal agent based attacks that could affect a LST. This tax could be collected into a community pool to defend the peg of LSTs (or against other economic attacks).

Ultimately, I think the work done in the post is fantastic; and I also like that Celestia is one of the few communities where we are having this discussion before the train has left the station. I strongly believe that the dynamic unbonding period should be accompanied by a dynamic tax that scales by each ICA.

[evan]

Thanks for reading and putting forth a detailed response! Ideating is really good

While I think this is a good measure, I don’t think it will be completely effective.

wdyt of this paragraph? I tried to include it twice on purpose to emphasize the point that defending against monopolies does not necessarily mean no monopolies will exist.

The more value an LST captures, the larger the incentive is to fork it. It does not guarantee that no LST monopoly is formed, however it does ensure that if one does, it will extract the minimum amount of value.

Do you think this statement is true?

If we look at chains like the Cosmos Hub where the LSM allows for users to have complete movement between LSTs

If the LSM does allow for freely flowing between LSTs, this is a great point! My understanding of the LSM on the hub is that it doesn’t actually allow the free flowing between LSTs because validator tokens are not fungible. I could be missing something tho!

Even if they are freely flowing, per the second section that describes the dynamic queue doing so without limiting the net change in validator set is extremely unsafe. This is relying entirely on the LST to make attacks expensive!! Security is completely external to the protocol at that point.

These mechanisms minimize the friction to forking significantly while remaining safe, since in theory an LST can be forked and converted to in a single block, which aims squarely at establishing the incentive to minimize harm. We’re trying to avoid the worst case scenario, even long term, as there is no guarantee the best case scenario occurs.

ICA connections have to be governance gated

For other chains this might be an option, but Celestia is governance minimized. The separate issue I have with governance is that as long as we use tokens I don’t think this can be secure. Especially considering that the ones voting are essentially LST protocols, not necessarily validator and certainly not token holders.

LSTs make it significantly cheaper to attack the native protocol. To change to a malicious validator set, attackers no longer have to use the native token. Instead, they just have to attack the LST protocol.

It should be more expensive to delegate to the incumbent after a certain threshold. If an ICA account is accumulating stake beyond a certain point the cost for the users to delegate to this account should increase.

unfortunately I don’t think limiting accounts can be an effective form of regulation long term. Just like we see airdrop farmers manage thousands of accounts, chains can do the same thing and there’s no deterministic mechanism for measuring. Ethereum PoS is a futile effort to prevent DPoS imo

[evan]

Thanks for reading and responding!!

@HoytRen

When everyone sees I need 30 days for unbinding, but it’s possible for somebody could initialize unbinding after me but finish unbinding before me, I’m sure I will lose money.

The flat unbonding period is replaced with a dynamic one. So if you enter the queue, you would unbond before they do. It’s possible that they could batch their conversion of an LST with someone lower in the queue, however they couldn’t do that with a pure unbond if that makes sense.

Generally speaking, I believe it’s better to let a settlement layer or L2 handle these problems.

What I’m describing is effectively improving delegation and the unbinding period. While in theory this state could exist on an L2, considering it’s critical to consensus I think it makes sense to keep it on the L1

[evan]

@cmwaters

Why do the tokens need to be bundled together? Why can’t I just buy 100 LST for each of the 5 validators I choose than receiving 1 LST that represents 500 TIA that is evenly distributed across the 5 validators?

If there were only 100 types of LSTs it would make them more fungible than having numerous permutations of LSTs per basket of validators.

They don’t have to be and it’s definitely possible that they won’t!! I’m making assumptions based on past usage

Curated subsets of validators are useful because delegators can easily hedge slashing risk and staking profits, while also selecting for broader more subjective preferences such as decentralization, quality of setup, or to fund specific causes.

given that most attacker will try to exit within the first 10 minutes say, It might be good to have two queues:
Cumulative diff in validator set can’t exceed 1/3 in 3 months; and
Cumulative diff in validator set can’t exceed 5% in 10 minutes

This is an interesting idea! The initial proposed curve attempts to do something similar if I’m understanding correctly, but this could an improvement

Also, you’ve mentioned using a cumulative diff queue instead of a net diff queue i.e. What’s your view on the tradeoffs

That’s a great question. The above mech strictly uses a net queue, which naively provides the same amount of security. Could be wrong tho! Without a net queue, then I’m not sure we see this property

Pick a similar set of validators to others, since that enables the ability to quickly convert between different LSTs

If big LSTs get forked, they are more incentivized to change their composition.

Meaningfully changing the validator set likely means entering the queue, which means it won’t be earning fees. Interestingly, this also risks losing users to other LSTs. This is because delegators wanting to convert to the popular LST would be changing the validator set further, and therefore must wait in the queue. However, the opposite occurs if users want to convert away from the popular LST to the vampire or other existing LST. This is because converting away from an LST that just changed the validator set reduces the difference in the validator set, and thus the converters would be able to skip the queue!

[HoytRen]

Then we should clarify that the queue is a shared queue or each address has its private queue. if it’s a shared queue, we can’t expect it to get cleared, then when should a user exit? if it’s a private queue, the order can easily get into trouble.

When to start and end a batch has similar problems.

[faddat]

note:

I wrote this whole big old thing, and came to the conclusion that this method is just too coercive and that the higher value problem is likely pricing. The market driven approach described originally here, is better than the approach that I describe below.

I think Celestia should be her own liquid staking monopoly

To me, this proposal seems quite complex, and to @evan’s credit, he understands deeply that it doesn’t solve the fundamental underlying problem, “actually fix pos”. I tend to agree. Celestia is a particular joy because Of all of the work that has gone into addressing base layer problems. I’m not entirely sure that this proposal doesn’t actually create additional problems, there are two pieces of it that to me seem to be in inherent tension:

• Vampire attacks
• Slowing the rate of validator set change

The proposal seems to riff on the liquid staking module in a number of ways, and propose what seemed to me to be genuine improvements to it.

However, I believe that the proposed design does reduce the primacy of Celestia, especially when liquid staking is considered.

If Celestia is to make significant modifications to staking logic, I think it might make a lot more sense to make liquid staking a native part of Celestia, instead of building and adapter for liquid staking third parties.

historical background

To my knowledge, liquid staking was recognized as a need when it was very clear that centralized exchanges would set up liquid staking no matter what anybody did. I also think that this remains true to this day, and that there’s a real argument for that. However, since we are already having discussions about reworking the staking module, which indeed needs rework, I think that it may be a good idea to take a step back and examine whether or not it is favorable for celestia to support liquid staking by third party chains at all.

problems with liquid staking

To me, the biggest problem with liquid staking has always been that it pays the same as regular staking. Liquid staking does not provide the same level of economic security and stability as regular staking. Certainly, the ICA route for liquid staking is significantly better than using a multi-signature wallet or even a single signature wallet, to create a liquid staking setup.

But it still has the very real problem that regular stakers accept immobility of their tokens, as well as slash risk.

Liquid stakers on the other hand take far less risk. They accept only slash risk, and in analyses we’ve done internally, it’s actually quite possible to create an insurance fund to relieve liquid stakers of slash risk, or partially relieve them. This is because slashes are relatively rare.

why do delegators get slashed?

We slash delegators as a punishment for choosing a non-performant validator. Currently there are two slashing conditions:

• Uptime
• Equivocation (double signing)

But if it’s possible to to to eliminate slash risk through an insurance fund as described above, and I fully believe that it is, then liquid stakers gain a total advantage – regular stakers are accepting both immobility of their tokens and slash risk, while liquid stakers accept none of this.

proposed model

Celestia should never open the staking ICA port. Instead, Celestia should implement liquid staking at the base layer, and provide a mechanism that can eliminate staking rewards for known liquid staking products using multisignature accounts.

This is the best of all worlds for Celestia because Celestia will never need to accept the risks that come with liquid staking products other than her own.

Celestia’s liquid staking product should definitely include a tax. The tax could go to the community pool, or simply never be issued. This way, traditional stakers will be able to benefit fully from the immobility that they’ve chosen to accept.

I’d estimate that immobility is worth 60%, and I am getting this number from The fact that slashing is really genuinely rare and that most slashing events are very small, typically downtime slashes. The majority of double signing events that have occurred in Cosmos have been operator error. I can’t really say that there’s been a Byzantine equivocation slash, except for a very interesting incident on CRO where a validator was compromised and eventually the attacker double signed (or threatened to, I forget which) And that was very Byzantine but the attacker was most certainly not threatening consensus in the traditional understanding of equivocation.

benefits of proposed model

• Celestia controls her own security.
• Reward to traditional and liquid stakers is in line with the amount of risk taken by both.
• Anyone is free to build restaking on top of Celestia’s liquid staked Tia.
• Less danger will be posed by restaked Tia, because there are fewer layers.

downsides

• I don’t like the heavy-handed approach of using governance to mark liquid staking protocols… But if we are viewing them as a security and primacy risk (and we should) then I do think it makes sense.
  • One way to sidestep this would be to do nothing, as multisig risk is historically greater than slash risk or immobility risk.
  • This also goes against governance minimization, and could create contentious votes.
  • Even evan’s proposal good create incentives for liquid staking protocols to never move away from multi-signature wallets that provide the full benefit of direct staking.
  • I’m walking away from this post fairly conflicted about how to deal with even the current incentive problems of liquid staking protocols.
• The development burden of the actual liquid staking protocol is placed on Celestia (but I think that it is less than what is described in the above post)

be the monopoly

---

subsequent literal shower thoughts

The biggest weakness of this proposal is that it can do very little to deal with the risks posed by multi-signature liquid staking tokens without a governance mechanism.

The biggest strength that I see in @evan’s proposal is that it is fully Market driven. While at first I saw a tension between slowing the rate of change in the validator set and the rapid conversion of lsts, in the shower I realized that this combination allows for the market to make determinations, and frankly that’s preferable to decisions made by governance. Maybe the only caveat here is that so far in most scenarios for liquid staking, the market has tended toward natural monopolies.

My post needs to be edited tomorrow, to remove the governance crutch. If I can’t figure out how to remove that crutch, then the original proposal by Evan is probably better than mine. I still agree with @LST that taxes are good in this scenario, as I do think that it’s possible to create very meaningful methods to limit or even eliminate the risk of slashes.

[Bidon15]

Awesome blog post! I am wondering on what ideas can be born out of the following bullet points:

@evan

• Arguably, the unbonding mechanism is significantly more secure than the existing one.
• Third parties get to capture the value that would otherwise be captured by an LST protocol.
• It becomes trivial to delegate to a large curated subset of validators.
• Every Bridge is incentivized to control its own LST(s), which means we will have much more decentralized control of the validator set. Besides avoiding the externalities of a monopoly, this might further increase the cost and difficulty of an attack.
• LST creators are incentivized to come to consensus over a quality decentralized set of validators.

If we have a hypothesis that every bridge is going to have their own version of the LST, how should this look like from a technical pov? I understand that the easiest way to achieve this is a multisig based or ICA/stride upcoming way. But what other ways am I missing here?

Is it correct to assume to snark accounts can be the foundation layer for future LSTs as Aiden mentioned in this podcast?

Another point I am missing understanding is with custom LSTs, especially regarding the programmability of them. Let’s say a rollup has its own bridge to the DA Layer. Do you think it is feasible for rollup developers to enforce a rule that they get, let’s say, a 1% cut from their LST holders to fund whatever their community decides is necessary? While this is not a credibly neutral LST, we can see that there are users preferring more custom LSTs or versions of them (e.g., Blast).

If we come to the point of custom LST, how hard it will be for such rollup teams to develop their own version? Do you envision a module/library/framework for this? So in the end rollup teams can have their own curated list of aligned validators

[faddat]

@evan

My understanding of the LSM on the hub is that it doesn’t actually allow the free flowing between LSTs because validator tokens are not fungible. I could be missing something tho!

To my knowledge, this is correct.

@evan

For other chains this might be an option, but Celestia is governance minimized. The separate issue I have with governance is that as long as we use tokens I don’t think this can be secure. Especially considering that the ones voting are essentially LST protocols, not necessarily validator and certainly not token holders.

This is another problem with my proposal. I don’t know of another decent way to LST protocol accounts, and they could always be broken up into many many many many many many accounts.

Other than tokens, did you have thoughts on doing governance? I think that especially for larger chains, the current Cosmos style of doing governance is not ideal.

Of course the flip side of this is osmosis, which has used governance extremely heavily since the start and I think has gained a sense of community ownership from the use of governance.

@evan

Actually fixing Proof of Stake.

I’m really interested to hear more thoughts on fundamental problems in proof of stake. I guess that this conversation does center on several of them:

• Governance
• Misaligned incentives in liquid staking vs regular staking
• Relative inability of protocols to define liquid staking as they choose to because any account can stake.

@evan

Proof of Stake is still fundamentally flawed, but if we switch unbonding mechanisms we can at least buy some time to properly find a solution.

Just noting that this particular conversation thread is quite interesting to me, And I think that it’s somehow touches on a well-placed discontent with the current state of governance, since at present, governance votes line up to consensus notes very neatly, that was an intentional feature of the POS design of Cosmos, to my knowledge.

But I think that this has created perverse incentives over time. There are persistent rumors that governance votes are sold as a profit model for validators choosing to charge 0% for their services.

I think that I believe these rumors.

Although I was initially against it, because the validators serve as a sort of a senate for the chain and community, I think that it makes sense to decouple the validation and governance, or allow stakers to decide if they would like their validator to participate in governance on their behalf.

[LST]

Hey, thanks for the reply. Here are my thoughts:

I do agree with you that a dynamic unbonding period and validator set movement restrictions will prevent a specific type of economic attack wherein the LST protocol is compromised and all stake moves to one validator to perform an attack on Celestia. But if a LST monopoly is compromised, theoretically the attacker doesn’t have to move any stake at all to attack the chain (in a lower capacity, however) .

To the 2nd question, I do not think it will extract the minimum value, it will extract a lower value. Again, my examples are from the Cosmos Hub, where despite there being massively cheaper options; delegators still delegate to the monopoly because of more integrations, greater chance of airdrop inclusion, deeper liquidity, etc.

On the 3rd point, on the Cosmos Hub right now its theoretically possible to undelegate into LSM shares and rebond those shares with other LST protocols. With Quicksilver, any valdiator share should work as it allows for free selection of validators and with pStake I think (might be wrong) they automatically redelegate delegation shares to meet their set.

I do agree that the dynamic queue is a safer version of the LSM.

I think that instead of trying to protect against a monopoly we should just try preventing them. Apart from specific economic attacks LST monopolies have very adverse social consequences. You will essentially have a gatekeeper on all TIA DeFi that is a single team. You will have all validator choice being made by this entity, which will create a client-provider relationship between all Celestia valdiators and one team.

LSTs are an inherently monopolizing instrument, most chains are prey to LST monopolies. These monopolies are enabled by the fundamental flaws in dPos. I think for Celestia the ideal situation would be to have 10-20 decently sized LST providers with varied validator distribution mechanisms and varied product offering/DeFi strategies. This will create maximum benefit for users while minimizing fees and social monopolies.

With regards to ICA being governance gated, there can be any other way to determine ICA eligibility. It could be made into a CIP or determined by any other appropriate decision making mechanism; doesn’t have to be token governance.

You can prevent one chain from launching multiple ICAs, if its gated by some rough social consensus. Every time you establish an ICA connection it is specified over an IBC connection which is between two chains. So if a new ICA connection being proposed is suspected to be a ghost account of an existing provider, then it can easily be rejected; and the provider attempting this be kicked out or penalized.

I think the ICA governance if done via CIPs would be in line with the vision for the ‘Core Values of the Celestia Social Layer’ outlined by Mustafa.

To conclude, I think if we are trying to add logic to Celestia which protects against LST monopolies, it should prevent them. The adverse social consequences of LST monopolies have a 100% chance of happening when compared with an economic attack (which though more harmful) has a lower chance of occurring. I would still very strongly argue for a LST tax, as it acts as a stable liquidity premium for using LST protocols and has a strong effect on completely preventing monopolies (maybe there is a better way to deliver a tax than gating ICA).

If monopolies are absolutely prevented, there would be no need to defend against monopolies.

PS: To absolutely prevent monopolies I am arguing for the LST tax alongside dynamic unbonding (which would be crucial to allow for migration of stake between LSTs).

[evan]

@faddat

Currently there are two slashing conditions:

• Uptime

what about social slashing? considering its critical to PoS’s strategy of maintaining crypto-economic security then I don’t think that it can be ignored.

They accept only slash risk, and in analyses we’ve done internally, it’s actually quite possible to create an insurance fund to relieve liquid stakers of slash risk, or partially relieve them.

I’d be curious to read more about the insurance fund! does there need to be an oracle for payouts?

the market has tended toward natural monopolies

yeah definitely. I purposefully used the word defending against, instead of preventing here. There could definitely still be a monopoly, users just have a more credible threat against that monopoly, specifically when it comes to it absorbing profits. If there’s no value to capture from an LST, then there will likely form a monopoly. However we are avoiding the catastrophy that is a monopoly that captures too much value.

did you have thoughts on doing governance?

until there’s good onchain id, no. even then, social consensus is best even if its really slow.

[evan]

@LST

if a LST monopoly is compromised, theoretically the attacker doesn’t have to move any stake at all to attack the chain

mind expanding on this attack? is there an attack that doesn’t require a quorum or half quorum of validators to collude, or does it require collusion? The attack I’m describing can occur currently within a single block and no collusion.

@LST

I do not think it will extract the minimum value, it will extract a lower value.

yeah definitely fair. after I wrote that comment, I realized that since I did not do any formal calculations this was definitley not a claim I was comfortable making and edited it.

delegators still delegate to the monopoly because of more integrations

if bridges have the ability to fork and instantly convert, then I think we’ll see more bridges create their own. the bridge is already forcing the new mint of an asset, so integrations are technically broken with each bridge path. if users are already bridging point to point (like what we see now in cosmos) then chains might as well create their own LST. especially if it earns them significant revenue. again, if there is no value being captured, then it will likely still be a monopoly. If there is value being captured, then there is nothing an LST creator can do to stop a bridge from forking them an arbitrary number of times.

@LST

You can prevent one chain from launching multiple ICAs, if its gated by some rough social consensus. Every time you establish an ICA connection it is specified over an IBC connection which is between two chains. So if a new ICA connection being proposed is suspected to be a ghost account of an existing provider, then it can easily be rejected; and the provider attempting this be kicked out or penalized.

in the future, its possible there are no breaking upgrades for a year plus, do you think that would be sufficient? Any controversy would also delay decisions. I don’t think social consensus is a viable mechanism for determining these things. As we just saw, without ICA liquid staked assets still occur.

To conclude, I think if we are trying to add logic to Celestia which protects against LST monopolies, it should prevent them.

tbc, that is the point of this post! to attempt to prevent them. but since there are no guaranteed ways of doing that, it at least reduces the harm done. in the best scenario, it also prevents them. in the worst, it protects against them.

it acts as a stable liquidity premium for using LST protocols and has a strong effect on completely preventing monopolies

is there a way to guarantee that this tax is enforced? are we just incentivizing using a multisig or otherwise external lsts?

also fwiw, I totally get why monopolies are bad

[evan]

@faddat

Celestia should implement liquid staking at the base layer, and provide a mechanism that can eliminate staking rewards for known liquid staking products using multisignature accounts.

This is the best of all worlds for Celestia because Celestia will never need to accept the risks that come with liquid staking products other than her own.

Celestia’s liquid staking product should definitely include a tax.

someone has to pick the validator subset used for the LST in order for the LST to work. this can’t be done on celestia imo since one of celestia’s goals is to be governance minimized. the only other mechanism would be for social consensus to effectively hardcode the validator set, which ruins the protocol being permissionless.

[faddat]

@evan

this can’t be done on celestia imo since one of celestia’s goals is to be governance minimized. the only other mechanism would be for social consensus to effectively hardcode the validator set, which ruins the protocol being permissionless.

So actually this relates to my shower thoughts. In the end, although I enjoyed writing the post, I may have come around fully to your point of view, the really critical distinction is that you’ve come up with a way to make the determination of vals by lsts fully Market driven. By the time I had finished my post, I had already struck on my own misgivings about relying too heavily on governance.

By the time I had finished my shower, I had realized that that was actually the critical difference between the two plans.

Neither plan does much about cexes, pricing, or multisigs (I consider pricing a really critical item) but the one you posted had the really clear advantage of being Market driven.

You figure that we might be able to fix pricing?

Mobility is worth a lot.

Slashes are worth a lot less.

Current lsts allow for mobility and slash exposure. Imo, it won’t be long until the lst provides for a slash insurance fund.

[faddat]

@evan

what about social slashing? considering its critical to PoS’s strategy of maintaining crypto-economic security then I don’t think that it can be ignored.

I’m in support of social slashing. Does Celestia currently support the ability to slash socially?

PS: when you say social slashing, are you referring to a governance proposal to slash a particular validator?

I also think that social slashing needs to be considered very carefully, but overall I’m in support of its implementation. The best example of this would be sunflower validator on the hub. They are clearly Byzantine but they have enough vote power to stay there.

[evan]

@faddat

Does Celestia currently support the ability to slash socially?

by social slashing, I mean a hardfork that includes a script to manually change the state to slash validators, so yeah it does support it but every blockchain does by that definition.

[ValarDragon]

Thanks for the writeup on this!

The point for queue cutting in line was quite cool! In my head, I’m thinking of it as a “coincidence of wants” situation, which we want to enable because:

• For security we want rate limits in validator power changes
• We want to enable more secure methods to move between validators, to lower the LST advantage

I don’t get how were solving the problem if there are anti-competitive strategies deployed by LST’s (or even just lack of update for queues from LST’s)

Lets assume a large LST (stLargeTia) exists in the first place. I want to make a new LST (vampTia).

vampTia wants to incentivize converting stLargeTia to vampTia. They want to do this by making a contract that:

• Sends your stLargeTia to vampTia contract
• vampTia starts unbond of stLargeTia
• {someone comes in with some Tia capital to clear things, could even be protocol controlled} to make a new vampTia stake position that offsets stLargeTia. The stLargeTia unbond “should be instant” due to offsetting, but it depends on the stLargeTia updating for this. Then the liquidity here is freed up.

However there are two things stLargeTia could do that are anti-competitive here,

• They could adversarially delay how long it takes from user action, until an unbonding request starts
• They could just “not implement” the queue cancellation logic. E.g. they send underlying funds to you after the initial unbond time finishes, not when the unbond truly completes. (or they send funds back to you at e.g. max(1 month, unbond queue time) – which gives vampTia the same liquidity crunch problem again)

Do we rely on the social layer for these issues still? I think not implementing queue cancellation will be a serious issue

[evan]

@ValarDragon

They could adversarially delay how long it takes from user action, until an unbonding request starts

yeah very true! This deserves more thought, as it is likely more complex than what I mentioned above. The comment below makes the assumption that the delay is universal for all users, but that doesn’t have to be true.

@evan

As long as the LST is redeemable by users, then even external LSTs are forkable. 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.

[ValarDragon]

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.

[evan]

@ValarDragon

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)

wow, what a great observation!

[nico_tenderize]

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.

1. Liquid Staked Token per Validator
2. Shared Liquidity for these validator LSTs
3. Create your own Lido, compose validator LSTs, be liquid.