FAQ
Protocol Security
How is the Liquid Collective protocol secured?
The Liquid Collective protocol implements a number of best practices:
Best-in-class node operators providing enterprise-grade staking infrastructure
Non-custodial staking framework reduces counterparty risk
Multiple code audits from top security teams
Partnerships with industry leader technology providers
DAO governance and decision making process alongside industry leaders
Is the Liquid Collective protocol audited?
Liquid Collective engaged independent security firms Halborn and Spearbit to perform security audits of the protocol. Every protocol feature deployed to mainnet has previously been reviewed by at least one of those teams.
Where is staked ETH custodied?
Liquid Collective is non-custodial. Ethereum deposited to Liquid Collective is custodied by the Ethereum deposit contract.
Why isn't the ETH deposited to Ethereum's deposit contract in the same transaction that I sign to deposit the ETH and mint LsETH?
ETH deposited by stakers is accumulated in the River smart contract and accounted in the protocol Deposit Buffer. Every day on the Oracle report, River programmatically commits the portion of ETH to be deposited to the Ethereum consensus layer. This portion of ETH may comprise all or part of the Deposit Buffer depending on other parameters, such as the current redemption demand. At the time of deposit, one or more validators are programmatically selected to be funded and committed ETH is deposited to the Ethereum deposit contract.
The length of time between when ETH is deposited to mint LsETH and when that ETH is deposited to the Ethereum deposit contract depends on network demand. For example, in times of high ETH deposit and low LsETH redemption volumes, the deposited ETH will be deposited to the deposit contract after the following Oracle report (12 hours on average), whereas minimal deposit or high redemption volumes may increase the time that deposited ETH is idle in the River smart contract.
What is the Slashing Coverage Program?
Liquid Collective collaborated with Nexus Mutual, an industry leader in providing decentralized slashing coverage. Liquid Collective’s Slashing Coverage Program provides web3-native slashing coverage to every LsETH holder. This program is designed to protect against network-wide events—such as network outages—and node operator failures.
The program offers three tiers of coverage:
Nexus Mutual Coverage
Slashing Coverage Treasury
Node Operator Commitment
Does Liquid Collective utilize multisig?
An administrative multisig is made up of a variety of Liquid Collective ecosystem participants. Over time, governance decisions will be executed through an increasingly programmable, smart contract-based execution system.
Where are the withdrawal keys and validator keys (public and private) held?
Public withdrawal keys are set to the Liquid Collective protocol smart contract address during the validator onboarding process. Once set, this address can’t be changed, as it is governed by the Ethereum protocol when setting Type 1 (0x01) address.
Validator public keys are submitted by Node Operators to the Liquid Collective Node Operators Registry. Validator private keys are owned and securely managed by the Node Operators.
Tokens
What can you do with LsETH?
LsETH is a fully composable ERC-20 token following the cToken model. As integrations are built, you will be able to:
Hold LsETH and accrue network rewards
Exchange LsETH for another token
Use LsETH as collateral to participate in a wide range of DeFi activities
What is Liquid Collective’s strategy for DeFi integrations?
Liquid Collective’s strategy is to create the industry standard for liquid staking. Over the medium- to long-term Liquid Collective expects LsTokens to be adopted in every corner of DeFi and web3.
Does Liquid Collective intend to offer a governance token?
Liquid Collective expects to issue a token to enable a broad and dispersed community of industry participants to govern its protocol.
How do the cToken and aToken models compare?
The Liquid Collective protocol uses a cToken model for LsETH. The cToken model evidences ownership of a staked token plus any accrued staking rewards, and less any slashing penalties and fees. As such, the conversion rate between the receipt token and the corresponding tokens continues to reflect the staked tokens + staking rewards - penalties and fees. This conversion rate is computed as the total balance of staked ETH over the total supply of LsETH. The aToken model, however, continuously updates the supply of a representative token to track the underlying token 1:1. The aToken model can also be referred to as a rebase token model.
Unlike aTokens, cTokens are Ethereum ERC-20 compliant and are more widely adopted (and thus more useful) than other forms of receipt tokens in DeFi today. The composability of cTokens, and their wider adoption, were factors in the selection of the cToken model for the design of Liquid Collective’s LsTokens. (See also “Tax Implications” question below).
What is the Protocol Conversion Rate?
LsETH protocol Conversion Rate—the amount of ETH for which LsETH can be redeemed.
The value of the Conversion Rate reflects the amount of ETH staked plus any Ethereum staking rewards that the stake has accrued, minus any potential penalties (e.g., slashing) imposed by the network and protocol service fees. As such the Conversion Rate for LsETH is not fixed 1:1 LsETH:ETH—instead, the Conversion Rate increases over time as the underlying staked ETH accrues more rewards.
Do the smart contracts implement any Conversion Rate smoothing?
Yes, there is an overall variation bound for the Liquid Collective protocol’s internal conversion rate so that anomalous actions (e.g. a large execution layer reward or a slashing reimbursement from the Slashing Coverage Treasury) should not disrupt the conversion rate.
On every Oracle report, execution layer fees are pulled from the ELFeeRecipient contract up to the maximum amount that is authorized to remain within the conversion rate's variation bounds. Any remaining execution layer fees are pulled on the following Oracle report. Similarly, in the case of a Slashing Coverage reimbursement from the Slashing Coverage treasury, on every Oracle report the system programmatically accounts for network rewards (consensus layer and execution layer), collects the gross fee, and then attempts to pull funds from the CoverageFund contract up to the maximum amount that is authorized to remain within the conversion rate's variation bounds.
In other words, if ETH is available in the applicable smart contract, the River contract is designed so that it will attempt to pull as much ETH as possible, up to the upper bound allowed by the Oracle contract. This smoothing mechanism means that it may take multiple Oracle cycles for execution layer fees or Slashing Coverage funds to be pulled entirely into the system, which should ensure a gradual variation of the conversion rate.
Ethereum network rewards
Does the Liquid Collective protocol automatically stake ETH nework rewards received?
Yes. When Ethereum network rewards (including both consensus layer rewards and execution layer fees) are received by the Liquid Collective protocol, they are pulled into the River smart contract and automatically added to the protocol’s deposit queue. This is designed to promote operational efficiency, and is fully onchain and managed by the protocol.
Where does the logic for skimming network rewards take place? Is that at the protocol level or do Node Operators perform this function?
Skimming (or partial withdrawals of network rewards earned by validators) is automatically executed by the Ethereum protocol. Liquid Collective requires that all validators set their withdrawal credentials to the Liquid Collective Withdrawal contract to ensure that skimmed ETH is automatically transferred to Liquid Collective’s Withdrawal contract without Node Operators needing to take any action.
On every Oracle report, any ETH that has been skimmed to the Withdrawal contract is automatically pulled into the River contract. The ETH pulled into the smart contract is then automatically entered into the Deposit Queue, where it is either automatically staked as it reaches a fungible bulk of 32 ETH or used to fulfill LsETH redemption requests.
How often does network reward skimming happen?
Skimming is executed automatically by the Ethereum protocol and depends on the total number of active validators. As of May 1, 2023, skimming of network rewards happens approximately every 5 days. Because all Liquid Collective validators’ withdrawal credentials are set to the Liquid Collective Withdrawal contract, the Withdrawal contract automatically receives skimmed ETH each time a Liquid Collective validator’s network rewards are skimmed by the Ethereum protocol.
What are the tax implications of participating in Liquid Staking?
While the status of liquid staking activities under the Internal Revenue Code of 1986, as amended, remains uncertain, certain market views have developed around the U.S. tax consequences of liquid staking, including the following:
Depositing ETH and receiving LsETH may not be deemed a taxable event. Unlike a traditional token exchange (e.g., trading ETH for another token), depositing ETH is not a token exchange. LsETH is a receipt token that evidences legal and beneficial ownership of the staked ETH.
Additionally, because LsETH is based on the cToken model, the accrual of network rewards may not be deemed taxable events, especially when compared to the unit incremental basis in aToken models (or standard staking) for the accrual of network rewards.
Notwithstanding the views outlined above, all liquid staking participants are strongly encouraged to consult with qualified accountants to understand tax implications of staking and liquid staking. Non-US based users should consult their local jurisdiction.
Protocol Operation
Is there an entry queue when staking with the Liquid Collective protocol?
LsETH is minted upon depositing ETH to the Liquid Collective protocol. As such, stakers begin participating in staking with the Liquid Collective protocol immediately upon submitting a transaction to deposit ETH and mint LsETH.
Once ETH is deposited to the Liquid Collective protocol, it is automatically entered into the protocol’s Deposit Buffer, where it is either deposited to the Ethereum deposit contract to be staked as it reaches a fungible bulk of 32 ETH, or used to fulfill LsETH redemption requests. These processes are programmatically managed by the protocol’s smart contracts to promote the staking efficiency of the protocol. Once deposited to the Etheruem deposit contract, all staking is subject to the Ethereum network’s validator activation queue and network-specific restrictions. You can learn more about LsETH deposits and redemptions here.
How many Node Operators does Liquid Collective anticipate using? What are the intended limits on a per operator basis?
At launch, the Liquid Collective protocol will have support from a diversity of industry leading-node operators. Additionally, it is anticipated that the number of node operators will continue to grow over time as more node operators collaborate join Liquid Collective.
How are Node Operators chosen to be funded?
Stake is distributed across Node Operators in a round-robin manner so that the Liquid Collective protocol is supported by a broad and dispersed active validator set. When funding validator keys, the River smart contract considers all validator keys available to be funded, and automatically funds a validator key that belongs to the Node Operator that is currently operating the least number of funded validators.
Will Validators be able to run MEV Boost?
MEV Boost may be able to provide stakers with access to greater network rewards without compromising Liquid Collective’s extended values of trust and transparency, because MEV is distributed in a secure, fair, and transparent manner. Node operators supporting the protocol’s active validator set may run MEV Boost middleware, provided that it is commercially reasonable and secure to do so. The Liquid Collective protocol automatically stakes execution layer fees, including MEV, to increase the protocol’s overall reward rate.
What is the Protocol Service Fee?
The Liquid Collective protocol charges a service fee set at 10.0% of network rewards. Liquid Collective’s service fee is split amongst Node Operators, Platforms, Wallet & Custody Providers, Service Providers, the protocol's Slashing Coverage Treasury, and the Liquid Collective DAO, which comprises a broad and dispersed community of protocol participants. All service fees are distributed in LsTokens, which are the native receipt tokens of the protocol (e.g. LsETH).
Who is in the validator set? How is the stake distributed?
Liquid Collective will be launching with an initial set of enterprise-grade, security-focused validators which include Node Operators such as Figment, Coinbase Cloud, and Staked. The stake will be distributed across validators in a round-robin manner so that the Liquid Collective protocol is supported by a broad and dispersed active validator set.
If someone deposits in increments of 32 ETH does this guarantee them a dedicated valdiator?
No. Deposited ETH is gathered into the River smart contract as a fungible bulk, and ETH in the contract is regularly delegated to validators in a round-robin manner as the contract reaches a balance of 32 ETH. The Liquid Collective protocol’s Deposit Buffer gathers ETH pending to be deposited to Ethereum’s consensus layer. The Deposit Buffer (and Redemption Buffer) is designed to programmatically manage efficient flows in and out of the protocol between Ethereum’s execution and consensus layers.
Example:
Assume there is 0 ETH in Liquid Collective protocol Deposit Buffer
Alice: Deposits 1 ETH at 1pm
Bob: Deposits 32 ETH at 2pm
Alice's 1 ETH and Bob's 31 ETH would fund a validator, with 1 ETH remaining in the contract until an additional 31 ETH is deposited in the contract
Does the deposit buffer prioritize consensus layer deposits over fulfilling LsETH redemptions? For example, assuming there is 32 ETH worth of redemption requests and a deposit of 32 ETH is sent, will the 32 ETH be sent to the consensus layer or fulfill the outstanding redemption requests?
Unsupplied redemption demand is prioritized. On every Oracle report, the Liquid Collective protocol starts by assessing the unsupplied redemption demand and uses ETH from the Deposit Buffer to satisfy those redemption requests. Once redemption demand is satisfied, the remaining Deposit Buffer will automatically deposit ETH to the consensus layer.
Why can't redemptions be instantly claimed if there is enough supply in the Redemption Buffer?
This is by technological design. The Liquid Collective protocol was designed to ensure fairness across all users and respect network-specific restrictions. The ability to instantly claim could create an incentive for users to front-run potential network events, such as slashing. A design that allows for redemptions to be instantly claimed could potentially benefit more sophisticated users who are trying to create arbitrage opportunities, while hurting less sophisticated users who are only seeking to redeem their LsETH. To protect against this scenario, all LsETH redemption requests must wait to be claimed until the next Oracle report, when a withdrawal event ID is emitted.
If I want to redeem an amount of LsETH equal to 1 ETH, do I have to wait until other users have submitted redemption requests totaling the 32 ETH required to exit a full validator, and then wait for the full Ethereum validator withdrawal period?
If you submit a redemption request equal to 1 ETH, and there is currently at least 1 ETH in Liquid Collective protocol’s Deposit Queue, the Liquid Collective protocol will automatically fulfill your redemption request by using the ETH from the Deposit Queue that has not yet entered the Ethereum deposit contract. This process is automated by the smart contract and designed to reduce transactional inefficiencies and costs (e.g., gas).
If you submit a redemption request equal to 1 ETH and there is less than 1 ETH in the Deposit Queue, the 1 ETH redemption request will trigger a validator exit request, and your 1 ETH redemption request will be satisfied once the full Ethereum validator withdrawal process is complete. In this case, the other 31 ETH included in that validator exit will be automatically used to fulfill other redemption requests or re-entered into the Deposit Queue to fund a new validator key.
Before withdrawals were enabled, I only interacted with the River contract. After withdrawals, do I need to interact with the Redeem Manager contract?
No, you should only need to interact with the main River contract for both deposit and redemption workflows.
What's the difference between a redeem request being 'satisfied' and 'claimed'?
After a user requests a redemption there is a time delay before the user’s ETH is available on the protocol to convert the LsETH to ETH.
An LsETH redemption request with the status of ‘satisfied’ means that sufficient ETH is available on the protocol, at that point in time, and the request can be claimed. Technically this means that sufficient ETH supply has been reported to the Withdraw Stack following validator exits or rebalancing from the Deposit Buffer.
A ‘claimed’ status for a redemption request means that the user has claimed the request and the ETH has been transferred to the user’s wallet.
Can the Withdrawal Stack be longer than the Redemption Queue?
The Withdrawal Stack should always be shorter than the Redemption Queue. The Liquid Collective protocol’s Withdrawal Stack automatically facilitates the movement of ETH to the protocol’s Redemption Buffer as needed, where it can be claimed based on the first-come-first-serve order of the Redemption Queue.
The Withdrawal Stack should always be shorter than the Redemption Queue to ensure a redemption request remains pending at least up until the next Oracle report before being claimed, and that consensus layer data is reported. This is designed to prevent sophisticated users from front-running a possible slashing event by redeeming before slashing penalties are reported into the LsETH conversion rate. For a visual of how the Redemption Queue and Withdrawal Stack interact, see this diagram.
Can the Withdraw contract ever have more ETH in it than is accrued between calls of reportConsensusLayerData()?
For redemption requests that require a validator exit to satisfy a request, the validator key is submitted to be exited from Ethereum’s consensus layer and the ETH is withdrawn to the protocol as per the Ethereum protocol’s design.
At every Oracle report, when accounting for accrued network rewards, the accumulated withdraw ETH is pulled from the Withdraw contract into the River contract. Then, the River contract programmatically manages the flow of ETH between the protocol’s Deposit and Redemption Buffers.
Only ETH withdrawn from Liquid Collective validators (skimmed or fully exited per a request from the protocol) are pulled by the River contract from the Withdraw contract. The Liquid Collective protocol’s design aims to ensure that if the ETH was transferred in any other way to the Withdraw contract it will never be pulled into the River contract, nor can it be accounted for in the protocol conversion rate. That ETH is expected to remain in the Withdraw contract.
The Ethereum protocol does not allow the Liquid Collective protocol to fully control what ETH is sent to the Withdraw contract. For example, someone could decide to sacrifice ETH and transfer it to the Withdraw contract (e.g., through a self-destruct transaction). The Liquid Collective protocol’s design described above aims to ensure that only valid, withdrawn ETH from Liquid Collective validators (as reported by the Oracle) is pulled into the River contract and accounted into the totalSupply and conversion rate calculations. Any invalid ETH will be left untouched in the Withdraw contract.
Does the totalUnderlyingSupply view function on the River smart contract represent the total amount of ETH that is pending and actively staked?
Yes, it includes ETH that has been deposited but is pending to be staked, ETH that is actively staked, and any network rewards received.
TotalUnderlyingSupply includes:
ETH deposited by stakers in the River contract
ETH deposited to the Ethereum deposit contract and pending activation on the consensus layer (as reported by the Oracle)
Active ETH on the consensus layer (as reported by the Oracle)
Execution layer fees pulled from the ELFeeRecipient contract on the Oracle report
Coverage ETH pulled from the CoverageFunds contract on the Oracle report
Last updated