# Safe Liquid Staking

This document is largely in response to the article Evan wrote on [Defending Against LST Monopolies](https://hackmd.io/@cIFNimXuR8eiNlZuI5vvpw/BJwH-mJO6#) and tries to articulate my thoughts to the problem and proposes a few approaches to solving it.

There are two opposing forces at play:

1. Users want liquidity. They want it as it gives them options. They are able to quickly change the risk they choose to be exposed to. Liquidity enables users to earn yield from staking and combine that with yield from other defi products.
2. The protocol's security depends on illiquidity. Consensus provides fault tolerance up to 1/3; beyond that detection of faults is not instantaneous. The network must wait for the partition to heal in order for the fault to be detected. The longer we can delay an attacker from exiting the system the greater the chance they are detected.

This I deem as the primary threat. The secondary threat was the focus of Evan's piece which is the strong centralising forces that exist around LSTs. These could potentially cause a single LST provider to obtain control of greater than 1/3 of the total voting power. The crux of Evan's solution, as I understand it, was to add tooling in-protocol that a) kept issuance controlled by the protocol and b) essentially made it easy to curate validator set selection. The motivation seems to be making in-protocol LSTs more attractive for users than any other alternative.

I want to focus on this primary threat that I illustrated above. Specifically an equivocation attack where an attacker produces a fork for some economic gain. Censorship attacks are harder to detect and are best remedied with redundant DA layers that a rollup can switch between. What we know is that after performing the attack, there is at least 1/3 of the voting power that is slashable that the attacker will want to sell.

With liquid staking, this is relatively straight forward to do: the attacker converts their stake to liquid stake, bridges it to an exchange platform and dumps it. The buyers are then eventually slashed.

Where we can try balance the two aforementioned forces is on the volume. Attackers are likely to want to sell at a higher volume than the normal user exchanges. This is where some form of rate limiting could be effective. As Evan mentioned, we can use staking queues (something also brought up a lot in Ethereum circles) to rate limit flows.

If we assume that liquidity is superior to bonded stake, then let's simplify the model by saying that all stake is liquid - that is a user delegates to a validator and gets a token back that can be transferred to a peer, bridged over for some arbitrary use, or returned back into the native token (undelegated). The tokens usage is rate limited. Delegating and undelegating (and redelegating) may be delayed depending on how much the validator set has changed. A chain may set multiple limits, for example: There can't be a 5% change in the validator set within 10 minutes and a 34% validator set change in 1 month.

Without delving into baskets, this is roughly the same as what Evan has proposed. The problem that isn't covered is that this rate limits undelegations but it does not rate limit directly exchanging the LST on a third party chain. To clarify the example: I own LSTs representing a third of the voting power (delegated to validators I control). These LSTs are bridged on another chain. I perform the attack and simultaneously sell all my LSTs before being detected. Put another way, I don't have to wait to undelegate if I can simply transfer ownership to another user.

What is missing is that the chain, through IBC, loses the ability to control how ownership of the token is transferred.

I propose to solve this as follows:

1. We introduce a second independent rate limiting queue which tracks transfer of ownership of an LST from one account to another in units of the underlying voting power it represents. That is if I want to send some LST tokens to another account, even although the voting power distribution does not change at all, I may have to wait for some fixed amount of blocks until my transfer. As an example the rule may be that there can't be more than 5% of voting power transferred in 10 minutes of blocks.
2. We create a modified version of the IBC transfer module specific to LSTs. Unlike the transfer module which only tracks the sum of all tokens on counterparty chains, this module would track the total locked LSTs per account. The module would allow for atomic exchanges by granting the counterparty chain the ability to move LSTs from one locked account to another respecting the rules of the queue.

Atomic exchanges would be performed as follows: User A agrees to exhange 1 LST for 10 USDT from user B. Both the 10 USDT and 1 LST become escrowed. An IBC message is produced to be sent to the origin chain of the (Celestia in this case). The origin chain receives the message and adds the transfer of 1 LST from user A to user B on the queue of that chain. There is a hook that catches when this transfer is finally executed. The hook triggers a message back to the chain where the exchange occurred informing that the chain can release the respective tokens to their new owners.

This doesn't stop third party LST providers from proposing their own "off-chain"/multisig solution, but gives users a on-chain secure means of having liquid staked tokens.

There still remain some outstanding problems. The main one is preventing queue spam where a user is able to completely saturate the queues such that no other user can perform the staking operations they would like. This also adds a fair amount of complexity to the state machine. In addition, I've simplified the process as there would need to be extra logic for acknoledgements and handling of timeouts and cancellations.