Technical Documentation

Technical Documentation

The ether.fi-Liquid1 vault was adapted from the Sommelier โ€œCellarsโ€ infrastructure by Seven Seas (the team that built the Cellars architecture). See the Sommelier smart contract docs for more details on the original architecture.

User Interface

Depositing

When users deposit into the vault, they receive an ERC-4626 compatible token representing their position. The token is yield-bearing, meaning that the value of the position will automatically be reflected in the redemption price (in contrast with a rebasing token whose balance increases over time). LP tokens are backed 1:1 to eETH. While LP tokens are priced using the market price of eETH, the LP token price can change marginally due to volatile strategies within the vault, such as PT-eETH. Users may notice very small fluctuations in the number of LP tokens they get per asset token deposited.

Deposits are handled in the smart contract via the deposit and mint functions. Once a user receives their vault share tokens, they may use transfer and transferFrom to freely transfer the tokens.

Withdrawing

Withdrawals in ether.fi-Liquid1 are completed through the Withdrawal Queue. A user submits a withdrawal request with a deadline for the withdrawal to be completed, a discount value, and the number of shares they want to redeem.

A solver will then fulfill the withdrawal request on behalf of the user within the deadline (assuming the request can be feasibly fulfilled). The discount is meant to compensate solvers for the gas costs of fulfilling the withdraw. Users pay a very small gas fee when initiating the withdrawal but the fee for actually redeeming the shares for assets is paid by the solver.

Unfilled withdrawal requests: During the Pending Withdrawal period, if the LP token price falls below the target LP token price (what the seller has asked for from the solver), it may not be filled by the Solver and will expire at the end of the withdrawal period.

Why withdrawals are queued: There is a security benefit to forcing withdrawals to go through the Queue: by preventing round trip transactions (depositing and withdrawing in a single transaction) the vault mitigates any atomic arbitrage issues.

LP token balance changes: Liquid allocates a portion of it's funds to Pendle's PT-eETH token. PT-eETH is designed to appreciate and match the price of it's underlying asset (eETH) at maturity, although it can be volatile in short-term periods. Users may see brief fluctuations in their LP token balances due to this volatility, but if they hold their Liquid Position to maturity, their token balances will return to normal and the user will not incur any permanent loss from this. The Current PT-eETH Maturity Date is June 26th, 2024. To learn more about PT, check out Pendle's documentation here.

Fees

The ether.fi-Liquid1 vault charges an annualized 2% platform fee based on vault TVL. The fee is computed daily by the smart contract.

This means that each day 2% / 365 = 0.0055% of TVL is saved in the smart contract as platform fee.

There are no deposit fees, performance fees, or exit fees.

Smart Contracts & Architecture

Smart Contracts

The ether.fi-Liquid1 vault was adapted from the Sommelier โ€œCellarsโ€ infrastructure by Seven Seas (the team that built the Cellars architecture). See the Sommelier smart contract docs for more details on the original architecture.

Some of the content below is reproduced from the Sommelier docs where relevant.

Architecture

The ether.fi-Liquid1 architecture is based on a โ€œhub-and-spokeโ€ model with a core vault contract responsible for user interactions (minting and redeeming) and auxiliary โ€œadaptorโ€ contracts that enable the vault to take DeFi positions. The architecture is composed of the following 4 components:

  • Registry - contains global configuration data for the ether.fi-Liquid1 vault, including permissions for what adaptors and positions the vault can utilize. Owned by a Timelock (which is subsequently owned by the Admin).

  • PriceRouter - provides pricing information about the vaultโ€™s assets to the vault, typically using Chainlink (but in some cases Redstone). The router additionally prices complex multi-token vault positions such as LP positions.

  • Cellar (vault) - user-facing ERC4626 contract where strategists deploy assets to earn yield. The Strategist can make adjustments to vault positions via .

    • Note: This vault departs from the ERC4626 standard of totalAssets. According to the standard, totalAssets must not revert. For this vault, totalAssets may revert. Integrators should take care to note and handle this difference.

  • Adaptors - integration contracts that allow the vault to interact with an external DeFi protocol. Adaptors are case-specific, and the vault may use multiple adaptors during complex DeFi operations.

Benefits to this Architecture

  • Increased Security: Key security features of this vault included constrained actions which limit the vault to interacting with only pre-approved protocols and assets, rebalance deviation which computes total assets before and after rebalance and reverts the transaction if the change in value exceeds a threshold, and multiple roles each with the ability to only call a subset of functions on the vault.

  • Off-Chain Computation: Unique architecture that allows Liquid to ingest data input from off-chain models. This keeps the strategy private as well as allows the vault to be fed information from data models.

Integrated DeFi Protocols

Pendle:

YT-eETH , PT-eETH , LP-eETH

Aave:

ETH lending

Morpho:

weETH supply/borrow

Balancer:

weETH / rETH pool , weETH / ETH pool

Aura:

weETH / rETH pool

Uniswap V3:

weETH / ETH 1bps pool , weETH / ETH 5bps pool

Convex: weETH / WETH pool

Roles

Admin

The Admin is a multi-sig consisting of members from both the strategy team and the ether.fi community. This role is meant to act as a neutral party that can quickly act during rare but time-sensitive scenarios.

Timelock

The Timelock (owned by the Admin) gates operations that are not time-sensitive. For example, adding a new position to the vault is gated by the Timelock (and hence is telegraphed in advance).

Strategist

The Strategist is responsible for submitting rebalance signals to the vault. There are significant limitations to the actions that the Strategist can take - the actions are confined to utilizing the set of adaptors and positions (gated by the Registry which is subsequently owned by the Timelock) to optimize vault performance.

Security

There are several layers of security built into the smart contracts.

  1. Constrained actions - The vault only has the capability to interact with pre-approved protocols and assets. Rebalances can only be executed using the set of adaptors and positions in the Registry. This places a hard constraint on what actions the vault can take.

  2. Rebalance deviation - On every rebalance, the vault computes the total assets before and after the rebalance and reverts the transaction if the change in value exceeds a threshold. This acts as a catch-all safety check on any vault operation.

  3. Multiple roles - There are various roles each with the ability to only call a subset of functions on the vault. For example, the Strategist can only rebalance the vault but does not have access to other sensitive functions.

The system has been operating for over a year in production (on Sommelier), and has weathered several black swan market events (USDC de-peg, Curve hacks, etc.).

Audits & Code

Smart Contract Audit (January 15, 2024 to January 22, 2023): https://0xmacro.com/library/audits/sommelier-16a.html

Smart Contract Audit (January 23, 2024 to January 31, 2024.): https://0xmacro.com/library/audits/sommelier-16b.html

Smart Contract Audit (July 31, 2023 to August 4, 2023):

https://0xmacro.com/library/audits/sommelier-9.html

Redstone Oracle Pricing: https://0xmacro.com/library/audits/sommelier-12.html

Pendle Contract Audit: https://0xmacro.com/library/audits/sevenSeas-2.html

Multiple Roles Contract Audit: https://0xmacro.com/library/audits/sevenSeas-1.html

Github Source Code Audit: https://github.com/PeggyJV/cellar-contracts

Last updated