Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Three layers of slashing coverage are available for every participant staking through the Liquid Collective protocol
Slashing Coverage enables certain Liquid Collective partners to reimburse LsETH holders following a slashing incident. Liquid Collective's Slashing Coverage Program is included in the LsETH User Agreement; as such, participation in the program requires no further action than holding LsETH.
Liquid Collective's Slashing Coverage Program includes three layers of coverage: Nexus Mutual Coverage, the Slashing Coverage Treasury, and the Node Operator Commitment. The program covers both network-wide events—such as network outages—and node operator failures.
You can find more details about Liquid Collective's Slashing Coverage Program in this blog post.
Nexus Mutual is the leading provider of decentralized crypto-native protection, having secured billions of dollars in value held in smart contracts. Nexus Mutual’s bespoke Slashing Coverage for Liquid Collective is fully scalable coverage that dynamically adjusts with the protocol's assets on platform (AoP) and provides access to Nexus Mutual's slashing coverage directly from a user's custody account at platforms such as Coinbase or Bitcoin Suisse.
Liquid Collective’s Slashing Coverage Treasury allocates a percentage of all network rewards to provide coverage for slashing coverage deductibles on network-wide slashing incidents. The Treasury continues to accrue network rewards unless deployed.
Node operators supporting Liquid Collective's active set provide coverage for deductibles, up to a cap, against slashing incidents and missed rewards incurred due to the fault of their infrastructure.
The Slashing Coverage Fund is in charge of injecting coverage funds into the system. In the case of a slashing event on one of the validators of the system, the Slashing Coverage Fund can be supplied with ETH to be used to repay slashing losses. When funds are sent to the Slashing Coverage Fund, the system will attempt to pull everything until the fund is empty.
The amount pulled is always capped by the reporting upper bound, just like the execution layer fees. This means that the supplied ETH will probably be injected in the system in multiple oracle report rounds.
The Slashing Coverage Fund contract enables the Liquid Collective Slashing Coverage Program. The contract receives the funds to distribute for the slashing coverage, which are used to cover losses that may occur on the consensus layer due to slashing events. The contract acts as a temporary buffer for funds that can be pulled in case of a loss.
Funds are supplied to the Slashing Coverage Fund contract when a qualified slashing event has occurred.
Computation and assignation of deductibles following a slashing incident are performed off-chain according to Liquid Collective's Slashing Coverage Program.
Partners assigned with a deductible can reimburse by posting the deductible (in ETH) to Liquid Collective's CoverageFund smart contract. ETH in the CoverageFund contract are periodically pulled into the system, accounted into the Conversion Rate, and eventually introduced into the staking flow.
Liquid Collective's CoverageFund contract is designed to only accept ETH from allowlisted accounts with a specific DONATOR permission.
When pulling funds from the CoverageFund contract the system does not mint any new LsETH and so the operation results in a replacement of any shortfalls that may have occurred from a slashing event, which applies to every LsETH holder.
No fees are taken on the received funds
The funds are entirely distributed to LsETH holders
No new LsETH are minted
Funds are distributed by increasing the Conversion Rate of LsETH
Funds from the CoverageFund contract are pulled into the system upon successful Oracle reports after Execution Layer fees have been pulled and rewards have been accounted, so no fee is charged on the cover funds pulled.
The amount pulled from the CoverageFund contract respects the Conversion Rate's variation bounds, so a slashing reimbursement cannot disrupt the Conversion Rate. On every Oracle report the system accounts for network rewards (CL + EL) then collects the gross fee, then attempts to pull funds from the CoverageFund contract up to the authorized maximum to remain within Conversion Rate's variation bounds.
In other words, if ETH is available in the contract, River 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 Slashing Coverage Funds to be pulled entirely into the system, ensuring a gradual variation of the Conversion Rate.
Liquid Collective's protocol architecture on Ethereum
River is the core smart contract in the protocol. River manages:
LsETH Token
User Deposits: River allows users to perform ETH deposits and receive receipt tokens (mint LsETH) in return.
The Oracle contract is responsible for feeding the River contract with the balance position of the validator nodes on the consensus layer. It relies on a set of Oracle Operators that periodically report data from the consensus layer to the execution layer; it is currently configured to report every 24 hours.
The Oracle contract helps synchronize a quorum of Oracle Operators to report the same consensus layer data. In particular, the Oracle contract makes sure that the core River contract receives data only after the Oracle contract has received identical reports from a quorum of Oracle Operators.
The Node Operators Registry:
Manages Node Operators that have been approved to receive ETH delegation
Enables Node Operators to register validators
Selects the next validators to receive delegation, attempting even distribution so all Node Operators get a fair delegation
The Allowlist contract manages the permissions of who can deposit to the protocol. The protocol requires participants to use an allowlisted wallet to deposit ETH and redeem LsETH.
The ELFeeRecipient contract is the contract that receives execution layer fees, including priority fees and MEV network rewards.
The Withdraw contract is the contract that perceives withdrawn funds resulting from both validator’s full and partial exits. All Liquid Collective validator keys have their withdrawal credentials set to the address of the Withdraw contract. Withdrawn funds are automatically pushed to the Withdraw contract by design of the Ethereum protocol. Funds on the Withdraw contract are periodically pulled by River contract on every Oracle report.
The Liquid Collective protocol smart contract was upgraded to enable LsETH redemptions in May of 2023. Liquid Collective upgradability relies on the upgradeable proxy pattern enabling any functional upgrade to the smart contracts.
In its current form, the River smart contract always sets the validator withdrawal credentials to the address of the Liquid Collective Withdraw contract, which is an upgradeable proxy Smart Contract.
Upgradability of both contracts is governed in a decentralized fashion by the protocol's administrators through the Liquid Collective DAO.
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.
The Liquid Collective protocol’s Redemption Buffer holds ETH that is pending to be supplied for redemption satisfactions.
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.
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.
Users can deposit and stake any amount of ETH
Liquid Collective allows users to deposit and stake any amount of ETH, not just 32 ETH (the minimum required to operate a full validator). Deposited ETH are gathered into an ETH smart contract account as fungible bulk. ETH in the account are regularly delegated to validators in a round-robin manner as the account reaches a balance of 32 ETH.
Each staker retains legal and beneficial ownership of an amount of ETH that is equivalent to the amount of ETH that was deposited by the staker, as evidenced by its . Receipt tokens like LsETH evidence legal and beneficial ownership of the deposited token, and ownership of the token is maintained throughout the life of the receipt token.
The Liquid Collective protocol is non-custodial. Deposited ETH is sent by the protocol to the Ethereum deposit contract. LsETH is also self-custodied, so LsETH holders have complete control over their LsETH and can pick any preferred custody solution.
Provide users with protections over protocol access for compliance, while ensuring composability with the rest of the DeFi ecosystem
Liquid Collective is designed to provide users with protections over protocol access via know-your-customer (KYC) and anti-money-laundering (AML) verification, while still ensuring composability with the rest of the DeFi ecosystem.
This facilitates compliance by providing the level of counterparty risk management required for enterprises and institutions to participate in staking on the protocol.
The Liquid Collective protocol:
Requires users to be on the Allowlist before they can deposit ETH or redeem LsETH
Enables users to transfer LsETH freely
Liquid Collective works with a variety of Platforms, including trading venues and custodians, to provide a seamless on-ramp for the protocol’s stakers. KYC’d users who utilize a Platform’s services to allowlist their wallet can deposit to Liquid Collective and mint LsTokens.
Participation in Liquid Collective's smart contracts is restricted to allowlisted wallet addresses. This is meant for compliance purposes, ensuring that any user who wants to stake first completes a review and approval process (typically a know-your-business (KYB)/ know-your-customer (KYC) process).
The Liquid Collective Allowlist smart contract holds:
An Allowlister, which is a trusted party responsible for allowing users to participate in the Liquid Collective protocol. Typically (ex. a custodial Platform performing KYC/AML checks on their customers) submit a user's wallet address to the Allowlister for subsequent addition to the Allowlist
An Allowlist of depositors with their permissions over the protocol (deposit, withdraw)
When a depositor wants to stake with the Liquid Collective protocol, their address must first be added to the Allowlist and be granted the corresponding permissions. Learn more about the type of Platforms that add users to the Allowlist in the .
To meet the compliance needs of Liquid Collective participants, the Liquid Collective protocol has an "access denial" mechanism for blocking individual Ethereum addresses from sending, receiving, minting, redeeming or claiming LsETH. The protocol does not have any mechanism for forcing a transfer of LsETH, reversing a transfer of LsETH or otherwise altering the balance of LsETH at an address.
The Liquid Collective's policy is that access will only be denied where there is a determination that not denying access to an address presents a threat to the security, integrity or reliability of the protocol. Examples of such circumstances include security breaches or legal requirements.
The roles in Liquid Collective's Ethereum implementation, and staking infrastructure overview.
The teams building and operating Liquid Collective work together to ensure the smooth functioning of the protocol and provide a seamless and secure Ethereum staking experience. You can learn more about Liquid Collective's approach to working with these roles in our .
Platforms provide a seamless on-ramp and access for users to interact with the Liquid Collective protocol. There are two types of Liquid Collective Platforms. Platforms either enable minting and redemption of LsETH, or enable secondary interactions.
In the Liquid Collective protocol's Platforms are also referred to as Allowlisters, as Platforms that enable minting and redemption curently function as the agents responsible for adding users to the Allowlist.
You can learn more about Liquid Collective Platforms in the .
Wallet Providers and Custody Providers offer LsETH token storage and signing infrastructure. Wallet and Custody Providers enable Platforms to easily access and distribute LsETH to their users through custody and/or embedded minting services. In some cases, these Providers and Platforms are the same entities.
Service Providers provide development, consulting, attestation, legal, or technological services to the Liquid Collective. Liquid Collective seeks to collaborate with existing web3 teams in the development of the protocol’s liquid staking offering.
Examples of Liquid Collective Service Providers include , , , and Hypernative.
Node Operators run the Ethereum validator infrastructure on Liquid Collective, registering validator keys with the protocol, performing validation duties, and earning network rewards for doing so. Liquid Collective does not run validator infrastructure, but instead delegates that critical task to proven Node Operators that meet high performance standards.
You can learn more about Liquid Collective Node Operators in the .
Infrastructure providers, operating a daemon app to report Ethereum consensus layer data to the Liquid Collective protocol. This data is necessary so the Liquid Collective protocol can account for the network rewards earned by validators.
Liquid Collective is designed to provide a secure and enterprise-grade liquid staking solution which necessitates sanctions checks on the protocol’s active validator set. Liquid Collective Node Operators must meet certain protocol performance and compliance requirements, and have the capacity to scale to a large number of validator nodes.
Liquid Collective works only with security-focused Node Operators that institute best practices to generate network rewards, including:
operating multi-region, multi-client infrastructure
offering technical support teams
maintaining security posturing (including double-sign protection)
To reduce the risk impact of validator operations, and to increase decentralization, Liquid Collective delegates tokens to multiple independent validator Node Operators. The staked tokens are 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. As a result, the risk is distributed, which should minimize staked ETH exposure to any one operator.
Consensus Layer Deposits: River orchestrates the delegation of ETH to validators and deposits to the official .
Requests by third parties for denial of access to an address must be submitted in writing to . This policy and compliance with a request do not constitute acknowledgment or attornment by The Liquid Foundation or any other participant in the Liquid Collective to laws to which that participant is not already subject.
Oracles report to Liquid Collective's core contract on the balance of underlying staked tokens plus accrued staking rewards, minus any slashing penalties. This information informs for deposit and withdrawal (when supported, after withdrawals are enabled on Ethereum), alongside supporting DeFi reporting.
Node Operators in Liquid Collective's active set also support the protocol's by providing coverage for deductibles, up to a cap, against slashing incidents and missed rewards incurred due to the fault of their infrastructure.
You can find in-depth technical documentation on Liquid Collective's Ethereum validator infrastructure in .
Liquid Collective protocol metadata
Liquid Collective protocol smart contracts expose a metadata URI that resolves to an IPFS directory containing resource files about the protocol.
Metadata directory contains different public resources such as:
Protocol Terms & Conditions
Marketing resources such as Liquid Collective logo pack
Security Audits reports
etc.
Any user can access the metadata by getting the IPFS URI from the River smart contracts and then retrieving the metadata directory from IPFS.
Below is an example of an RPC call to get Liquid Collective metadata URI using cast
