Technical Documentation
How the Liquid Vaults work.
All ether.fi Liquid Vaults are built on Veda’s Boring Architecture.
This architecture is based on:
Non-upgradeable core contracts
Modular components that can be attached or replaced
Strict role separation
Hard constraints on vault actions
The vault token contract itself remains constant. Functionality is extended or modified by attaching external modules through a role registry. This design significantly reduces the attack surface while still allowing flexibility.
The system integrates LayerZero, allowing vault tokens to function across multiple blockchains. For comprehensive protocol details, refer to the official Veda smart contract documentation.
*Note: The Liquid HYPE Yield Vault is powered by Midas and uses separate contracts - see the Liquid HYPE Yield Vault documentation for details specific to that vault.
User Flow
Depositing
Users deposit supported assets through the Teller contract.
How it works
Users deposit approved ERC20 tokens or the native token
Deposits mint BoringVault shares, issued as an ERC20 token
These shares represent the user’s proportional ownership of the vault
Key rules
The Teller maintains an allowlist of supported deposit assets
Deposits are blocked if the Teller is paused
Users must approve the BoringVault (not the Teller) to spend the asset
Approval can be done via standard ERC20 approval
Or via permit signatures, if supported
Slippage protection
Users can specify a minimum number of shares to receive
If fewer shares would be minted, the transaction reverts
Execution
Assets are transferred into the BoringVault
Shares are minted to the user
All happens atomically in a single transaction
Withdrawing
Withdrawals are handled via a dedicated Boring Queue per vault.
How it works
User holds BoringVault shares
User approves the Boring Queue to spend those shares
User submits a withdrawal request
Withdrawal request parameters
Output token
Minimum output amount
The minimum output amount acts as on-chain protection against unfavorable execution.
Timing constraints Each vault defines:
A minimum delay before a withdrawal becomes executable
A maximum fulfillment window after which the request expires
These constraints are enforced directly by the queue contract.
Managing requests
Requests can be replaced or canceled before fulfillment
If canceled, shares are returned to the user
Fulfillment
Withdrawals are fulfilled by Veda’s solver
The solver must meet the user’s minimum output requirement
Shares are consumed and the output token is delivered atomically
Fees
Vaults may charge a platform fee set in the Accountant
Fee range: 0% to 2%
No performance fees are charged by any vault
Smart Contracts & Architecture
Core components
The BoringVault was built from the ground up to be the most secure and flexible framework for building enterprise-grade DeFi products by Veda Labs. Here are the official docs by veda
Architecture
BoringVault
The central vault contract.
Holds user assets
Mints and burns vault shares
Keeps internal logic intentionally minimal
Delegates functionality to external modules
This design improves both security and composability.
Teller
Handles all user-facing deposit actions.
Responsibilities:
Accepts deposits
Enforces share lock rules
Refunds deposits when protections are triggered
Manages cross-chain token bridging
Hook (Optional)
Executes custom logic before share transfers.
Common use cases:
Transfer restrictions
Share lockups
Compliance and whitelisting logic
Manager
Executes vault strategies and rebalances.
Uses Merkle proofs to verify allowed actions
Can only execute strategies pre-approved by Admin
Prevents unauthorized or arbitrary vault behavior
Accountant
Manages the vault exchange rate.
Responsibilities:
Calculates share-to-asset conversion
Enforces bounds on rate changes
Can pause updates during abnormal conditions
BoringOnChainQueue
Handles withdrawals.
Receives vault shares from users
Works with the atomic solver to execute withdrawals
Ensures timing and minimum output constraints are respected
DecoderAndSanitizer
Security layer for external protocol interactions.
Decodes calldata
Sanitizes parameters
Ensures only intended operations are executed
Oracle
Tracks vault value and yield.
Built-in safeguards include:
Maximum update frequency
Maximum deviation thresholds
This ensures accurate and reliable reporting.
Benefits to this Architecture
The vault itself is simple and does not execute strategies or complex logic directly, reducing the attack surface.
External modules handle deposits, accounting, strategy execution, and withdrawals, allowing upgrades or customizations without redeploying the vault.
Managers use Merkle proofs to ensure only authorized, predefined strategies are executed, preventing unauthorized actions.
Decoder and Sanitizer modules ensure interactions with external protocols are secure and only execute intended operations.
Roles
Admin
The Admin is a multi-sig consisting of members from both the veda team and the ether.fi team. This role is meant to act as a neutral party that is responsible for defining the whitelisted protocols and assets and the actions and parameter the strategist can perform. The admin is also able to make changes to the modules connected to the boring vault, ie the withdrawal queue, teller accountatn etc.
Strategist
The Strategist is responsible for submitting rebalance signals to the vault. There are significant limitations to the actions that the Strategist. The strategist rebalances the vault by making manage call with a merkle proof, and the merkle root is set by admin therefore they can only rebalanced based what was whitelisted by the admin. All strategists are multisigs unless there is very limited whitelisted actions with low risk actions.
Pauser
Hypernative, and other trusted entities have the ability to pause the vaults as a safety and control mechanism.
Security
There are several layers of security built into the smart contracts.
Constrained actions - The vault only has the capability to interact with pre-approved protocols and assets using merkle proofs. Rebalances can only be executed using the set of protocols and add assets that are encoded in the merkle root. This places a hard constraint on what actions the vault can take and what parameters can be passed to a protocol
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.
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.
Non-upgradeable core - The token contract is very simple there should never be upgraded even if it was possible in our case it is not possible. All modules attached the boring vault is swappable if new feature need to be added or during a security concern.
Audits & Code
Waiting on Veda
Last updated