Deposits & Redemptions
Staking ETH to mint LsETH, and redeeming LsETH for ETH, on Liquid Collective
Liquid Collective users can deposit ETH to stake on Ethereum. Users can also redeem LsETH for the underlying staked ETH plus network rewards earned, and minus any fees or penalties.
Note: Depending on the amount of ETH the protocol's Deposit Buffer, a validator may need to be exited from Ethereum to service a LsETH redemption request. When a validator is exited, it is subject to the Ethereum network's variable exit and withdrawal queues, which can take minutes to days. It's recommended to review the current maximum exit queue and withdraw queue times here.
Deposit and Redemption Buffers
The Liquid Collective protocol automatically maintains ETH Deposit and Redemption Buffers. These buffers are designed to ensure that flows in and out of the protocol are managed efficiently between Ethereum’s execution and consensus layers, which enables seamless redemptions of LsETH for ETH via automatic rebalancing.
The protocol’s Deposit Buffer includes ETH pending to be deposited to Ethereum’s consensus layer, while the Redemption Buffer includes ETH pending to be supplied for redemptions.
ETH deposits enter the Deposit Buffer to be programmatically staked in Ethereum’s consensus layer
Ethereum execution layer fees received by Liquid Collective validators automatically enter the Deposit Buffer to be programmatically staked
Ethereum consensus layer network rewards received by Liquid Collective validators automatically enter the Deposit Buffer to be programmatically staked
Withdrawn validator consensus layer ETH from validator full exits, or slashed validator exits, automatically enter the Redemption Buffer to fund LsETH redemptions
Funds from Liquid Collective’s Slashing Coverage Program enter the Deposit Buffer according to the Slashing Coverage Program to be programmatically staked
Queues, stacks, and buffers
In addition to the Liquid Collective protocol’s Deposit and Redemption Buffers, the protocol’s Withdrawal Stack, along with Ethereum’s activation and exit queues, play an important role in deposits and redemptions on the Liquid Collective protocol.
Name | Owner | Role |
Activation Queue | Ethereum Consensus Protocol | Ethereum’s Activation Queue rate limits the number of new validators that can be activated on the network to protect the network’s stability. The Activation Queue can result in a waiting time to activate stake on Ethereum. Learn more here. |
Exit Queue | Ethereum Consensus Protocol | Ethereum’s Exit Queue rate limits the speed at which validators can leave the network to protect the network’s stability, and to ensure that slashing penalties are applied as necessary. The Exit Queue can result in a waiting time to withdraw stake from Ethereum. Learn more here. |
Redemption Queue | Liquid Collective Protocol | The Liquid Collective protocol’s Redemption Queue facilitates the satisfaction of redemption requests in the same order as they have been requested. The first-in-first-out Redemption Queue is intended to protect against a race for claims in the event of high withdrawal demand. |
Withdrawal Stack | Liquid Collective Protocol | The Liquid Collective protocol’s Withdrawal Stack automatically facilitates the movement of ETH to the protocol’s Redemption Buffer. This ETH may be sourced by validator exits from the consensus layer or rebalanced from the protocol’s Deposit Buffer. |
Redemption Buffer | Liquid Collective Protocol | The Liquid Collective protocol’s Redemption Buffer holds ETH that is pending to be supplied for redemption satisfactions. |
Deposit Buffer | Liquid Collective Protocol | The Liquid Collective protocol’s Deposit Buffer holds ETH pending to be deposited to Ethereum’s consensus layer, or that can be rebalanced to the Withdrawal Stack to programmatically facilitate redemption satisfactions. This ETH may be sourced from user deposits, network rewards (consensus layer & execution layer), the protocol’s Slashing Coverage Program, or rebalanced from the protocol’s Withdrawal Stack. |
Visualization of Withdrawal Stack, Redemption Queue, and Deposit and Redemption Buffers
Below is a step-by-step diagram showing how a request will flow through the protocol’s buffers and stacks.
Deposit ETH
When a user deposits ETH they receive the LsETH receipt token at the current Conversion Rate, which evidences legal and beneficial ownership of the staked token, plus network rewards received and minus any fees or penalties.
Deposited ETH automatically enters the Liquid Collective protocol’s Deposit Buffer. As ETH in the Deposit Buffer reaches a fungible bulk of 32 ETH it is programmatically staked, funding new validator keys and being pushed to Etheruem’s activation queue.
LsETH are minted on deposit, so depositing does not affect the Conversion Rate.
Example
Assuming
totalETHSupply = 125 ETH
totalLsETHSupply = 100 LsETH
So conversionRate = 125 / 100 = 1.25
A user deposits 10 ETH and receives 10 / 1.25 = 8 LsETH
And the new conversionRate = (125+10) / (100+8) = 1.25 remains unchanged
Note: Figures above are just examples and do not reflect reality or projections.
Interface level smart contract flow
For more technical audiences, a sequence diagram showing the interaction between smart contracts is included below:
For those that want to view a stack trace, we recommend using a tool like Tenderly.
Here is a sample transaction hash on mainnet: Deposit: 0xace4dc0272645d9e0120f25a478d1b7375cc42dd4b1c0369bd00d02847e54e25 Oracle Report: 0x67d44ab16ece7c2adcc97b538359f4c21fc10a09413d7014962c5dc5b79e4cb0
Redeem LsETH
The LsETH receipt token can be redeemed for ETH at the current Conversion Rate, to effectively withdraw the staked token plus network rewards received and minus any fees or penalties.
Redemption requests on the Liquid Collective protocol cannot be canceled once they have been made. This is because validator exits cannot be canceled on Ethereum once they have been triggered.
Three-stage redemption process
LsETH redemptions take place via a three-stage process performed programmatically by the Liquid Collective protocol:
Request: the LsETH holder requests a redemption via a Platform (e.g. in the Coinbase Prime app), surrendering the amount of LsETH that they would like to redeem. This LsETH will eventually be burned.
Satisfaction: after the protocol completes any required validator exits and the corresponding amount of ETH is withdrawn as according to the protocol Conversion Rate, the request is satisfied and can be claimed at any time.
Claim: the redemption request is claimed, triggering the actual transfer of ETH to the redeemer.
Redemption architecture
When a LsETH holder requests a redemption the request is added to the protocol’s Redemption Queue. On each Oracle report, completed approximately every 24 hours, the protocol assesses the unsupplied ETH demand for redemptions.
When there is unsupplied ETH demand:
The Liquid Collective protocol programmatically rebalances ETH between the deposit and Redemption Buffers to preserve capital efficiency by minimizing consensus layer operations. The protocol prioritizes moving ETH from the Deposit Buffer to the Redemption Buffer to satisfy the unsupplied redemption requests.
If there is still unsupplied redemption demand, the protocol requests validator exits by signaling Node Operators. Upon receiving this request, the appropriate number of validators are entered to Ethereum’s exit queue, where they are subject to Ethereum’s exit queue timeline.
All Liquid Collective validator keys have their withdrawal credentials set to the address of Liquid Collective’s Withdraw contract, which is automatically pulled to the Redemption Buffer upon Oracle report. The withdrawn ETH is then used by the protocol to satisfy the unsupplied redemptions.
A user decides they want to redeem their LsETH for ETH via the Liquid Collective protocol
A user's redemption request is enqueued in the Redemption Queue pending satisfaction
On each Oracle report, the Liquid Collective protocol evaluates pending LsETH redemption requests and programmatically pulls any ETH from the Deposit Buffer to the Redemption Buffer to satisfy the requests
If the balance in the Deposit Buffer is insufficient to satisfy all pending redemption requests the Liquid Collective protocol initiates the exit of a corresponding amount of ETH by programmatically requesting Node Operators to submit validator exits
Any redemption request that has been satisfied by the Buffer can be immediately claimed by the user
For redemption requests that require a validator exit to satisfy, the validator key enters Ethereum’s exit queue, waits the full network withdrawal time, and, once exited, the validator’s ETH balance is automatically sent by Ethereum to Liquid Collective’s withdrawal address
On the Oracle report following the validator exit, the withdrawn ETH satisfies pending redemption requests
The user can now claim their ETH
Most stakers can complete this process easily via their preferred Liquid Collective Platform (e.g. in the Coinbase Prime app). At the protocol level, at a high level this request process is executed via interacting with the LsETH contract interface.
When a redemption request is submitted by calling the requestRedeem function, a redeem request id is returned by either using the Alluvial /redeems endpoint or subscribing to RequestedRedeem events.
To indicate whether the request has been satisfied, the redeem request id can be submitted along with calling the resolveRedeemRequests function to return withdrawal events corresponding to that redeem request id.
Once satisfied, the request can be claimed by calling ClaimRedeemRequests along with the redeem request id and corresponding withdrawal event id, which returns a list of claim statuses.
Interface level smart contract flow
For more technical audiences, a sequence diagram showing the interaction between smart contracts is included below:
For those that want to view a stack trace, we recommend using a tool like Tenderly.
Here is a sample transaction hash on mainnet: Request Redeem: 0x996bab264e831a12618c9e942b2d30a410c62db908c16efbd9fc5e44e30b1f5c Oracle Report: 0x67d44ab16ece7c2adcc97b538359f4c21fc10a09413d7014962c5dc5b79e4cb0
Redeem status matrix
Status Satisfaction | Status Claim | Meaning |
PENDING_SATISFACTION | NOT_CLAIMED | Redeem is in process of being satisfied and cannot be claimed yet. |
FULLY_SATISFIED | NOT_CLAIMED | Redeem request is fully satisfied thus can be claimed. |
FULLY_SATISFIED | FULLY_CLAIMED | Redeem was fully claimed after getting fully satisfied. All funds have been sent to the recipient and redeem can not be claimed again. |
PARTIALLY_SATISFIED | NOT_CLAIMED | Redeem request is partially satisfied and thus can be partially claimed and will require to claim again later on. User may decide to either a) claim now to receive part of the funds and proceed with other claim(s) later on, or b) wait for the request to be FULLY_SATISFIED so that only a single claim is required. |
PENDING_SATISFACTION | PARTIALLY_CLAIMED | Request was partially claimed and is pending satisfaction for the remaining part. The request can not be claimed yet. |
FULLY_SATISFIED | PARTIALLY_CLAIMED | Request was partially claimed and is now fully satisfied so can be claimed again to collect the remaining part. |
PARTIALLY_SATISFIED | PARTIALLY_CLAIMED | Request was partially claimed and is now partially satisfied, thus can be partially claimed and will require another claim later. |
Platforms can learn more about this process in the Platform redemption guide
Redemptions and the Conversion Rate
When a user redeems LsETH the user will receive ETH at the current Conversion Rate. The Conversion Rate is applied at the time of satisfaction, and capped by the Conversion Rate at the time of request. This design is intended to ensure a fair Conversion Rate is applied for redeemers while protecting the protocol from premature redemptions.
LsETH are burned on withdrawal, so withdrawing does not affect the protocol’s Conversion Rate.
Example
Assuming
totalETHSupply = 162 ETH
totalLsETHSupply = 108 LsETH
So conversionRate = 162 / 108 = 1.5
A user converts 8 LsETH and receives 8 * 1.5 = 12 ETH
And the new conversionRate = (162-12) / (108-8) = 1.5 remains unchanged
Note: Figures above are just examples and do not reflect reality or projections.
Interface level smart contract flow
For more technical audiences, a sequence diagram showing the interaction between smart contracts is included below:
For those that want to view a stack trace, we recommend using a tool like Tenderly.
Here is a sample transaction hash on mainnet: Request Redeem: 0xd8c39cf80d388c8ce55b519336b5f53074805156b5d416e96116c90dc73b2577 Oracle Report: 0x67d44ab16ece7c2adcc97b538359f4c21fc10a09413d7014962c5dc5b79e4cb0
Last updated
