# Euler Docs
> Modular lending infrastructure for configurable markets and vaults.
## FAQ
### Start
#### What is Euler?
Euler is modular onchain lending infrastructure. EVK vaults each hold one underlying asset and can lend it to eligible borrowers. Explicit collateral relationships connect vaults into markets, while the EVC coordinates accounts, sub-accounts, controllers, operators, and batched actions.
EulerEarn vaults provide a separate aggregation layer: users hold one Earn share position while configured roles allocate the deposited asset among enabled strategies.
#### Where should I start?
* To understand the protocol, read [Vaults](/learn/vaults) and [Markets](/learn/markets).
* To supply, borrow, use Earn, or manage a position, start with [Use](/use/getting-started).
* To integrate contracts or data, start with [Build](/build).
* To launch or operate vaults and markets, start with [Curate](/curate).
#### What is the difference between a vault and a market?
A vault is an ERC-4626 contract for one underlying asset, with its own configuration and roles. A market is the set of collateral and liability relationships between vaults. The liability vault controls which collateral vaults it accepts and applies the relevant oracle route, LTVs, caps, and account checks.
Related: [Vault types](/learn/vault-types) and [Markets](/learn/markets).
### Use Euler
#### What should I check before supplying or borrowing?
For supply, check the vault asset, available liquidity, caps, fees, governor or curator, interest-rate model, and any reward source. For borrowing, also check accepted collateral, oracle routes, borrow and liquidation LTVs, liquidation settings, and the position's health after the transaction.
#### How do I assess vault risk?
Review the vault together with its connected market: assets, collateral relationships, liquidity, caps, oracle routes, interest-rate model, LTVs, liquidation settings, hooks, governance, and addresses authorized to change configuration. These checks do not remove smart-contract, oracle, liquidity, collateral, governance, or total-loss risk.
#### How does EulerEarn work?
An Earn vault accepts one asset and issues ERC-4626 shares. Configured roles manage enabled strategies, caps, queues, allocation, and fees. Before depositing, review those roles, the strategy set, current allocation, withdrawal liquidity, loss accounting, and fees.
#### Who controls a vault or market?
Authority is deployment-specific. Review the onchain governor, curator, allocator, guardian, operator, timelock, and fee-recipient addresses, then inspect the exact permissions assigned to each. A role label alone does not establish authority.
Related: [Managing positions](/use/managing-positions), [EulerEarn](/use/euler-earn), and [Risk curators](/learn/risk-curators).
### Launch and operate
#### How do I create a vault or market?
Choose the asset and market topology, deploy or select the required vaults, configure collateral relationships, oracle routes, IRMs, caps, LTVs, liquidation settings, hooks, and governance, then publish labels and verify the deployed state. Use the [Launch toolkit](/launch) for the sequence and [Curate](/curate) for operating guidance.
#### How do I launch an Earn vault?
Define the deposit asset, strategy set, roles, caps, supply and withdrawal queues, allocation process, fees, liquidity plan, labels, and user-facing disclosures. Start with the [Earn launch guide](/curate/vaults/euler-earn/introduction).
#### How do I choose an oracle route?
Identify the base asset, quote asset, and unit of account; then review the adapter, data source, update behavior, decimals, route precedence, manipulation resistance, and failure behavior. ERC-4626 share resolution is optional and should be used only when the vault conversion is the intended and reviewed pricing path.
Related: [Creator UI](/curate/vaults/evk/creator-ui), [Oracle router deployment](/curate/deploy-oracle-router), and [Governance contracts](/curate/governance-contracts).
### Integrate
#### Which data source should I use?
Use the [Data API](/build/data-querying/euler-v3-api) for indexed and historical data, [lens contracts](/build/data-querying/lens-contracts) for aggregated onchain reads, and direct contract calls or simulation for execution-sensitive state. Use [vault metadata](/build/data-querying/perspectives) for display context; metadata and known-vault status are not safety verdicts.
#### How should I build transactions?
Use the [Euler SDK](/build/sdk) for app-level planning, approvals, simulation, and execution. Use the [EVC integration guide](/build/evc/integration-guide) for lower-level batching, sub-accounts, controllers, collateral, operators, and permits. Verify chain, addresses, calldata, state changes, approvals, and post-transaction health before signing.
#### Where are contract addresses and ABIs?
Use [Contract addresses](/build/contract-addresses) and the [Euler interfaces repository](https://github.com/euler-xyz/euler-interfaces). Confirm the target chain, deployment version, bytecode, and interface before constructing a call.
### Security
#### Where do I find audits or report a vulnerability?
Use the [audit index](/security/audits) to identify reports for the exact component and revision. Follow the current [Cantina bounty page](/security/bug-bounty) for scope, testing rules, eligibility, and submission instructions. Never test against production contracts or user funds unless the controlling rules expressly authorize the exact action.
## Glossary
### Core protocol components
| Term | Definition |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **EVC** | The Ethereum Vault Connector (EVC) is the account coordination layer used by Euler-compatible vaults. It handles batching, collateral checks, sub-accounts, operator permissions, and controller relationships across vaults. |
| **EVK** | The Euler Vault Kit (EVK) is the framework for creating Euler credit vaults. EVK vaults are ERC-4626 vaults with lending and borrowing logic, one underlying asset, and configurable parameters such as caps, oracles, interest-rate models, collateral relationships, hooks, and governance. |
| **EPO** | The Euler Price Oracle (EPO) is a modular onchain pricing system. Oracle adapters and components implement the `IPriceOracle` interface and can be composed into the pricing routes used by Euler vaults and oracle routers. |
| **IRM** | Interest Rate Model (IRM) is a contract that provides a vault's borrow-rate input from vault state or another configured rule. Supply APY is derived from borrow APY, utilization, fees, and vault accounting rather than being set independently by the IRM. |
| **Hook Target** | A contract that can check, restrict, or block selected vault operations before they execute. Hook Targets are configured per vault and should be reviewed for the specific operations they affect. |
### Financial metrics
| Term | Definition |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Health score** | Health score represents the buffer between an account's risk-adjusted collateral value and its liabilities. At raw onchain values, the standard EVK no-violation comparison requires risk-adjusted collateral to be greater than liability; equality can enter liquidation calculation. A displayed value of 1 may be rounded, so consult raw values and transaction simulation. |
| **TTL** | Time to Liquidation. An estimate of how long it would take for an account to reach the liquidation threshold if prices stayed the same while interest continued accruing at current rates. |
| **NAV** | Net Asset Value (NAV) represents the total value of a user's account, measured as the total value of their deposits minus the total value of their debts. |
| **APY** | Annual Percentage Yield (APY) is an annualized rate with a stated compounding convention. EVK base supply and borrow rates are displayed as APY; reward campaigns generally provide APR estimates, even when an interface adds them to an APY breakdown. |
| **ROE** | Return on Equity (ROE) is an annualized estimate of net rate exposure divided by equity, where Euler account and portfolio calculations use Net Asset Value: supplied value minus borrowed value. ROE can change with rates, rewards, intrinsic yield, prices, and position size and is not realized profit. |
| **LTV** | Loan-to-Value (LTV) compares debt value with collateral value. A configured borrow LTV limits new borrowing for a collateral-vault pair; current position LTV describes the account's present ratio. |
| **Utilization** | The share of an EVK vault's assets currently borrowed: `borrows / (cash + borrows)`. Many utilization-based IRMs increase borrow rates as utilization rises. |
### Risk management
| Term | Definition |
| ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Liquidation** | Standard EVK liquidation transfers selected debt from the violated account to the liquidator and transfers collateral in the other direction at the calculated discount. The resulting liquidator account must pass the applicable controller, collateral, vault, and EVC checks. |
| **Liquidation discount (sometimes called liquidation bonus)** | The liquidation discount determines how much collateral a standard EVK liquidator can receive when taking over selected debt from a liquidatable account; the configured maximum and account health bound the discount. |
| **Isolated Risk** | A market structure where risk is scoped by vault and market configuration. Isolation can limit direct risk propagation between configured market sets, but connected collateral, oracle routes, liquidity, governance, and market conditions can still create dependencies. |
### Technical terms
| Term | Definition |
| ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **ERC-4626** | A tokenized vault standard that provides a unified interface for yield-bearing vaults. Euler V2 vaults are ERC-4626 compliant, making them compatible with other DeFi protocols. |
| **Rehypothecation** | The use of deposited assets as collateral while they remain supplied to a vault. Whether a deposit can support borrowing depends on the connected vaults and collateral configuration. |
| **Batching (multicall-style execution)** | EVC batching groups calls into one execution context and can defer configured account-status checks until the end of the batch; individual calls can still revert and the final account checks must pass. |
| **Permit2** | An approval mechanism that can let users authorize token transfers through signatures where supported by the integration and wallet flow. |
### Protocol features
| Term | Definition |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Non-borrowable Vault** | A vault where deposited assets can be used as collateral but cannot be borrowed from that vault. |
| **Cross-collateralization** | The ability to use assets from one vault as collateral to borrow from another vault, enabled by the EVC. |
| **Sub-accounts** | Virtual accounts within the EVC that allow users to manage multiple positions with different risk parameters. |
| **Operator** | An address authorized by an EVC account owner to perform ordinary actions on a selected account with broad authority. Operator authorization is account-level rather than a set of granular permissions; owner-only EVC administration remains with the owner. |
### Read next
* [Vaults](/learn/vaults)
* [Introduction](/introduction)
* [Reference](/reference)
## Euler - The Modular Lending Platform
By Euler Labs
### Introduction
Euler is a flexible platform for decentralized lending and borrowing, designed to adapt and grow with the evolving world of DeFi. Euler’s modular design and institutional-grade security empower builders to create and manage custom lending markets in a fully permissionless way, tailored precisely to their needs.
At the product layer, Euler v2 is a system of ERC-4626 vaults built using a custom-built vault development kit, called the EVK, and chained together using the EVC. The vault kit is agnostic about governance, upgradability, oracles, and much else. Different vault classes support different use-cases, giving users freedom through choice and modularity. Euler v2 will launch with several initial classes of vaults built on the EVK. Builders can customise and integrate these as they wish, or design their own vaults with just a few clicks.
**Escrowed collateral** vaults hold deposits that can be used as collateral for taking out loans from other vaults, but do not earn their depositors interest because they do not allow borrowing. They are ungoverned.
**Governed** vaults hold deposits that can both be used as collateral and borrowed, earning depositors additional yield. A DAO, risk manager, or individual manages these vaults, controlling risk, interest rates, loan-to-value, and other risk parameters. They are suited for passive lenders who trust the governor's management.
**Ungoverned** vaults have fixed parameters with no active governor to manage risk, making them suited to lenders who prefer to manage their own risk. They come in two types:
* **0x** ungoverned vaults have zero exposure to governance through their collaterals
* **nzx** ungoverned vaults have non-zero exposure to governance because they may accept collateral with governance exposure
**Yield aggregator** vaults are a special class of governed vaults that aggregate passive lender assets that can be directed by the vault governor to flow into any underlying ERC4626 vault, including both ungoverned or governed Euler vaults, but also external vaults like sDAI. The vault governor manages risk/reward by altering flows into underlying vaults with different properties.
#### Synthetic assets
The modular architecture of Euler v2 enables not only vanilla lending and borrowing via vaults, but also the creation of collateralized debt positions and synthetic assets. These can benefit from deep collateral liquidity inside Euler, advanced risk management and trading features provided by the EVC, and be bolstered by FeeFlow (see below). As well as synthetic assets already planned for governance by Euler DAO, the architecture of Euler enables the creation of a product class where new synthetic assets can be created in a permissionless fashion. More will be revealed about Euler synthetics in the near future.
#### Reward Streams: permissionless rewards without staking
RewardStreams is an innovative open-source module empowering projects to seamlessly stream rewards to users of new markets in a permissionless manner. This module is a robust and adaptable implementation of the billion-dollar algorithm, enabling the simultaneous distribution of multiple reward tokens.
Unlike traditional methods, users can subscribe to receive their preferred rewards without the need to transfer their vault shares to a staking smart contract. This unique feature allows suppliers to earn rewards while concurrently taking out loans, presenting a dynamic and efficient approach to incentivizing and engaging users.
#### Fee Flow: reverse Dutch auctions for fees
FeeFlow is a new and powerful open-source module that provides the Euler DAO with greater control over fees generated on Euler markets, maximising ecosystem growth. This powerful tool enables the auctioning of fees to accumulate assets such as ETH, stETH, USDC, or potentially even EUL, amplifying the DAO's financial flexibility. Alternatively, these fees can be utilised to acquire DAO-backed synthetic assets, providing organic demand and helping to stabilise the asset. In this scenario, the synthetic asset becomes a valuable instrument within Euler's market ecosystem, creating new and diverse trading opportunities
FeeFlow employs a reverse Dutch auction mechanism, periodically auctioning off fees by systematically reducing the auction price as fees accumulate. In Euler v2, vault creators can set fees, ensuring a passive income stream while sharing a portion with the Euler DAO in a decentralised, efficient, and MEV-resistant manner. This innovative approach enables the DAO to convert fees from various assets into a unified, accumulated token.
#### Free Market Liquidations
Euler v2 allows more advanced vault creators to customise and design their own liquidation flow, but the EVK comes equipped with Euler v1’s innovative reverse Dutch auction liquidation flow as standard. This mechanism was popular with borrowers and traders on Euler v1, where bonuses for liquidators on large loans were \<0.7%, the cheapest of any DeFi lending protocol. This not only protects borrowers, but also helps protect lenders by maintaining the solvency of pools. Ultimately, the less collateral paid to MEV bots by borrowers, the better.
### Ethereum Vault Connector (EVC)
The EVC is an interoperability layer and powerful primitive enabling vault creators in the Euler ecosystem to bootstrap new lending products easily by connecting vaults together and recognizing existing deposits in far away vaults as collateral. Whilst a key module inside Euler v2, the EVC is an open-source project supported by Euler Labs that anyone can launch products on. The white paper and development documentation can be found at evc.wtf.
One of the goals of the EVC is to abstract away many of the features common to all credit-based protocols in order to let developers focus on product features tailored to specific types of users. In this way it helps developers build their own lending protocols, stablecoins, yield aggregators, margin trading apps, and much else. In the long run, it is expected to usher in a wave of innovation in lending as it supports lending products backed not only ERC20 tokens, but also irregular asset classes, such as RWAs, NFTs, IOUs, synthetics, and more. Growth of vaults designed to work with the EVC expands the Euler ecosystem and leads to more flexibility for lenders and borrowers alike. This leads to higher yields and powerful network effects over the long term.
#### Account Managers for advanced trading and risk management
For developers building on the EVC, it provides a range of important features for more advanced users of lending protocols out of the box. These include multicall-like batching, flash liquidity for efficient refinancing of loans, simulations, gasless transactions, and more.
One of the powerful features of the EVC is account manager functionality implemented through a smart contract called an operator. Operators can be smart contracts or EOAs that can be delegated responsibility to act on a user’s behalf. Amongst other use cases, this feature can be used to implement advanced trading and risk management strategies, including conditional orders like stop-loss and take-profit, custom liquidation flows, or intent-based systems. Developers can build their own operator smart contracts to implement risk management and position automation strategies and make them available to users as separate products.
The EVC is a multicall contract with a special user authentication layer. It allows any external contracts to be called without needing adaptor contracts. This not only means that all the functionality is accessible to both EOAs and smart contract wallets, but also allows for limitless expansion of the ecosystem through the development of new EVC-compatible products in a permissionless fashion.
Although the EVC allows only one outstanding liability at any given time, it provides each address with 256 virtual addresses (“sub-accounts”), which provide a gas-efficient way for users to isolate and manage risk without the need to maintain multiple separate wallet accounts.
#### Collateral direct from a user’s wallet
An alternative path to creating a collateral-only asset is to create an ERC20Collateral token, which is a simple extension to the ERC20 token standard to enforce compatibility with the EVC. Project making use of this extension can unlock an entirely new wave of composability. Users are no longer required to deposit their tokens into vaults in order to use them as collateral, they can do so directly from their wallet. This helps them retain their governance rights and other token privileges, whilst also helping avoid generating unnecessary taxable events.
Whenever the user's balance decreases (outgoing transfer/token burn), the token contract calls into the EVC to check whether the outstanding loan rules are not violated. With an addition of a simple modifier which routes transfer calls through the EVC, mentioned account status checks can be deferred until the end of a batch of multiple operations, allowing a user to freely use their tokens within a batch as long as their account is solvent at the end. ERC20Collateral also makes the token compatible with EVC sub-accounts system out of the box.
### Use-cases and examples
#### Leverage by chaining LRT/LST/ETH vaults
* Create an vault for each major LST allowing all major LRTs as collateral.
* Create a WETH vault that allows each of those major LSTs and each of the LRTs as collateral.
* Use-case: LRTs depositors borrow LSTs, and LRTs + LSTs depositors borrow WETH, swap, re-deposit, and leverage their yield.
Consequence: this special Euler WETH vault has the highest demand for borrowing of any vault in DeFi.
#### Leveraged liquidity provision
* Create a WETH vault and a LST vault that allow WETH/LST LP as collateral.
* Use-case: LP token holders borrow more WETH and LST against their LP tokens and deposit into an AMM to get more LP tokens.
* Consequence: LP token holders can leverage their LP positions whilst using simple, gas-efficient AMM protocols.
#### Impermanent loss hedge
* Create a WETH/USDC LP token vault that allows WETH and USDC as collateral.
* Use-case: WETH and USDC token holders can borrow LP tokens to hedge or go short.
* Consequence: LP token holders earn additional yield on their tokens, helping compensate against impermanent loss.
#### USD carry trades
* Create a custom vault pair that allows USDC to borrow USDT, and USDT to borrow USDC on high leverage.
* Use-case: if USDC APY is higher than USDT APY, users can deposit USDC, borrow USDT, swap to USDC, and re-deposit to carry out a carry trade.
* Consequence: users can hedge exposure to stablecoin depeg risk, carry out interest rate arbitrage, and profit from carry trades.
#### Margin-trading real-world assets
* Create a vault for USDC allowing a high-yielding RWAs as collateral, using hooks to enable secondary-transfer restrictions to be observed.
* Use-case: RWA depositors borrow USDC at lower yield, swap to more RWA, and re-deposit, looping to go long.
* Consequence: Margin trading on real-world assets as RWA depositors can leverage their yield and earn the interest rate spread on leverage
### Long-term picture
The ability to lend and borrow digital assets is the foundation on which DeFi is built. Lending protocols are typically composed with decentralised exchanges (DEXs) in order to hedge risk and construct leveraged positions. In this way, borrowers pay interest to lenders, forming the foundation for capital markets in DeFi. Whilst lenders today have many options from which to earn sustainable and passive forms of yield, the trading experience for borrowers and traders remains remarkably poor.
Monolithic lending protocols restrict borrowing with limited asset selections and conservative, one-size-fits-all loan-to-value (LTV) requirements, and then punish traders with heavy fines when they face liquidation. Meanwhile, isolated lending markets offer more flexibility, but often fragment liquidity and increase net costs for traders by disallowing rehypothecation and therefore extra yield on collateral. Moreover, in many cases traders are forced to navigate multiple protocols, governance systems, and user interfaces, paying leveraged fees to each along the way. Together, these market constraints and inefficiencies mean that many traders end up turning to CeFi platforms and relying on perpetual futures markets to put on trades, rather than using decentralised spot markets. This means lower yields for DeFi lenders and, consequently, lower liquidity in less capital efficiency in DeFi across the board.
Euler v2 is a modular lending platform that aims to fix these problems and become the primary liquidity layer for DeFi. Monolithic lending protocols like Aave v3 help foster greater capital efficiency because they pool collateral used for different purposes together and enable rehypothecation. However, they only allow new collateral types to be added under restrictive economic conditions and typically only via governance actions. Isolated lending protocols like Compound v3 or Morpho Blue tend to allow greater flexibility in collateral use, but tend to fragment collateral and prevent rehypothecation, leading to lower capital efficiency.
Euler’s modular architecture helps to solve the liquidity fragmentation problem associated with isolated pools by allowing permissionless creation of vaults that can use any other vault in the broader ecosystem as collateral. This ability to connect together different types of vaults from different product lines via the EVC provides unparalleled flexibility and modularity for lenders, borrowers, builders, traders, and more.
Thanks to the modular design of the system, this can all be achieved without compromising on security or risk management. Vault-chaining via the EVC promises to enable new yield opportunities available nowhere else in DeFi today. With time, whole new product lines can be innovated and brought into the ecosystem helping to power vast network effects. Real-world assets, non-fungible tokens, IOUs for un-collateralised lending, peer-to-peer lending, oracle-free lending, and much more, are all possible directions for the growth of the ecosystem. With this design, together with other developments yet to be announced, Euler aims to become a global liquidity layer and one-stop shop for lending, borrowing, and trading on EVM-based networks.
### Acknowledgements
With special thanks to Certora, Alberto Cuesta Cañada, Christoph Michel, and StErMi for helpful feedback on some of the mechanisms described herein.
## Reference
Use this index to find Euler's canonical sources. For executable behavior, rely on deployed contracts and the relevant versioned repository.
| Need | Canonical source |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| Deployment addresses | [Contract addresses](/build/contract-addresses) and the [Euler interfaces repository](https://github.com/euler-xyz/euler-interfaces) |
| ABIs and Solidity interfaces | [Euler interfaces](https://github.com/euler-xyz/euler-interfaces) and the relevant versioned contract repository |
| Indexed API schemas | [Euler Data API V3](/build/data-querying/euler-v3-api) and its [OpenAPI document](https://v3.euler.finance/v3/openapi.json) |
| Current aggregated onchain reads | [Lens contracts](/build/data-querying/lens-contracts) |
| Display metadata and known-vault status | [Vault metadata](/build/data-querying/perspectives) and [labels](/curate/vaults/labeling) |
| EUL token addresses and routes | [EUL addresses](/EUL/addresses) and [Multichain](/EUL/multichain) |
| Governance proposals and treasury context | [DAO proposals](/euler-dao/proposals) and [DAO treasury](/euler-dao/treasury) |
| Security review scope | [Audit index](/security/audits) and the linked report for the exact component and revision |
For concepts and historical context, use the [Glossary](/glossary) and [Lite paper](/lite-paper). For task-oriented navigation, start with [Learn](/learn/vaults), [Use](/use/getting-started), [Build](/build), or [Curate](/curate).
## Coming from Aave or Morpho?
If you know Aave or Morpho, Euler's core actions will feel familiar: supply, borrow, monitor account health, repay, and withdraw. The main difference is how lending markets are assembled.
The comparison below is about protocol structure, not relative risk or performance.
* Aave is built around shared lending markets, with asset-specific controls and risk settings applied inside those markets.
* Morpho is built around immutable market definitions, often paired with curator-managed vault allocation.
* Euler is built around isolated vaults that can connect into configurable markets. Each market defines its collateral, caps, oracle routes, LTVs, hooks, and governance.
On Aave, you typically start from a reserve or market. On Morpho, you start from a market or vault. On Euler, start from a vault, then inspect how it connects to other vaults. The vault view shows the asset, accepted collateral, governor, oracle, interest-rate model, and limits that define the position.
### Quick translation
| If you know\... | In Euler, think... |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------ |
| Aave reserve | A lending vault for one asset. |
| Aave market | A group of connected lending vaults. |
| Morpho Blue market | A lending relationship between a loan asset, collateral asset, oracle, rate model, and LTV. |
| MetaMorpho vault | The closest analogue is an EulerEarn vault: one user position with allocation across configured strategies. |
| Account health | A controller checks each Euler account against the collateral enabled for that account. Sibling sub-accounts are checked separately. |
### How Aave, Morpho, and Euler compare
| Question | Aave | Morpho | Euler |
| --------------------------- | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| What is the starting point? | A shared lending market with listed reserves. | An isolated market definition, often accessed through vaults. | Isolated vaults that can connect into configurable markets. |
| How are assets added? | Assets are listed through governance or market-specific configuration. | Markets are defined by loan asset, collateral asset, oracle, rate model, and LTV choices. | Curators or builders deploy and configure vaults for assets, then connect them as supply, borrow, or collateral assets with the relevant parameters. |
| How is risk isolated? | Risk settings apply across the market and its listed assets. | Each isolated market has its own risk settings, and vaults may allocate across markets. | Risk can be isolated at the vault or market level, while collateral can still compose where configured. |
| How does collateral work? | Listed assets can be enabled as collateral within a market. | Each market pairs a loan asset with a collateral asset. | Vaults can accept other vault positions as collateral, so curators and builders can choose which vaults support which borrowing markets. |
| What should users inspect? | Reserve configuration, caps, rates, collateral settings, and liquidation rules. | Market parameters, vault allocation, curator choices, oracle, rate model, and LTV. | Vault asset, collateral relationships, governor or curator depending on configuration, caps, LTVs, oracle routes, hooks, liquidity, and liquidation settings. |
### Where to start
| Goal | Start here |
| ----------------------- | ------------------------------------------------------------------------------------------------------------ |
| Supply or borrow | [Use Euler](/use/getting-started), then review [Vaults](/learn/vaults) and [Markets](/learn/markets). |
| Use an Earn vault | [EulerEarn](/use/euler-earn). |
| Launch a lending market | [Curate](/curate) and the [EVK introduction](/curate/vaults/evk/introduction). |
| Create an Earn vault | [EulerEarn vaults](/curate/vaults/euler-earn/introduction). |
| Build an integration | [Build](/build), the [Euler SDK](/build/sdk), and the [EVC integration guide](/build/evc/integration-guide). |
## Protocol introduction
**Euler V2** is a modular lending protocol built around independent vaults. Suppliers can lend assets, borrowers can use accepted collateral to borrow, and curators can assemble markets for different assets and risk preferences. EulerEarn adds single-asset vaults that allocate deposits across configured strategies.
The protocol is permissionless: using the **Euler Vault Kit (EVK)**, anyone can deploy a configurable lending vault for an ERC20 asset. A market is formed by connecting vaults and choosing which collateral relationships, price oracles, interest-rate models, caps, and risk parameters apply. This design supports anything from a single collateral-and-debt pair to a larger cluster of connected vaults without forcing every user into one shared pool.
### What you can do
* **Supply:** deposit an asset into an EVK lending vault or EulerEarn vault and receive ERC-4626 shares.
* **Borrow:** provide collateral in a separate account and borrow from a vault that accepts it.
* **Multiply:** use the app's prepared borrow-and-swap flow to build a leveraged position where a route is available.
* **Curate:** deploy and configure vaults, connect collateral, and manage supported parameters.
* **Build:** integrate with EVK vaults and coordinate multi-vault actions through the EVC.
### Key concepts
* [**Euler Vault Kit (EVK):**](/learn/vaults) The smart contract framework used to create and manage individual lending and borrowing vaults. Each EVK vault is an ERC-4626 vault with borrowing logic.
* **Vaults:** Lending vaults for a specific underlying asset. Users deposit assets and receive shares. Deposits may serve as collateral where another vault accepts them. Some vaults are **non-borrowable**, meaning deposits can be used as collateral but cannot be borrowed from that vault.
* [**Oracles:**](/learn/price-oracles) Price feed contracts used for collateral valuation, debt valuation, and liquidation checks. Euler V2 supports multiple oracle types, including Chainlink, Pyth, Redstone, and Chronicle, with custom configurations per vault or router.
* [**Interest-rate models (IRMs):**](/learn/interest-rates#irm-types) Configured models that provide a vault's borrow-rate input according to the model's logic. Supplier returns are derived from borrower interest, utilisation, fees, and vault accounting. Not every IRM is utilisation-based.
* **Hook Targets:** Optional contracts that can check, restrict, or block selected vault operations before actions such as deposit, borrow, or liquidation. Hooks call designated **Hook Target** contracts, such as `HookTargetAccessControl` or `HookTargetAccessControlKeyring`, that implement the configured logic.
* [**Ethereum Vault Connector (EVC):**](/build/evc) A core contract that acts as an alternate entry point for EVK vaults. The EVC coordinates cross-vault actions, batching, deferred checks, sub-accounts, operator permissions, and [permit-based execution (EIP-712)](https://eips.ethereum.org/EIPS/eip-712).
* **Controller (EVC Context):** When a user borrows from a vault via the EVC, they designate that vault (or another contract) as a Controller for their EVC account. This grants the Controller authority over the user's enabled collateral set within the EVC, allowing it to enforce the borrowing vault's rules (e.g., prevent collateral withdrawal, seize collateral via `controlCollateral` during liquidation).
* **Risk Management:** V2 uses isolated vaults and markets, vault-to-vault loan-to-value factors, caps, oracle configuration, and liquidation mechanisms. A vault's risk profile depends on its live configuration and market conditions.
### Euler V2 vs v1
While sharing the goal of efficient lending and borrowing, Euler V2 differs significantly from earlier versions:
* **Architecture:** Earlier versions had a single, monolithic pool for all assets with cross-collateralization. V2 uses **isolated, permissionlessly deployable vaults** via the EVK.
* **Risk:** Earlier shared-pool exposure is replaced by vault-specific assets, collateral links, oracle routes, LTVs, caps, and governance settings. Risk follows those settings and any connected collateral relationships.
* **Asset Listing:** Earlier versions combined permissionless listing with governance-managed risk tiers. V2 keeps listing permissionless through **permissionless vault creation** for any ERC20, with risk parameters set by the vault creator instead of governance.
* **Oracles:** V2 introduces a configurable oracle framework supporting multiple providers and per-vault or per-router configurations.
* **Modularity:** V2 lets IRMs, oracles, hook targets, and governance models be tailored per market.
### Lending position mechanics
1. A supplier deposits an underlying asset into an EVK vault and receives ERC-4626 shares. Withdrawals depend on the vault's available liquidity and contract limits.
2. A borrower enables accepted collateral in an EVC account and designates a liability controller. The liability vault values collateral and debt through its configured oracle route and enforces borrow LTV, liquidation LTV, caps, and account checks.
3. Borrower interest accrues to the liability vault according to its interest-rate model. Suppliers receive the corresponding vault accounting, after configured fees, while available liquidity changes as assets are borrowed or repaid.
4. If the account no longer satisfies the liability vault's collateral requirements, it can become eligible for liquidation. See [Liquidations](/learn/liquidations) for the mechanism and [Portfolio and liquidation](/use/portfolio#liquidation-risk) for monitoring guidance.
### Continue
* To supply or use Earn vaults: [Use Euler](/use/getting-started).
* To integrate contracts, data, or transactions: [Build](/build).
* To configure vaults, collateral, or governance: [Curate](/curate).
* To review position failure modes and security controls: [Liquidations](/learn/liquidations) and [Security and risk](/security).
* To inspect scoped evidence for a particular contract version or commit: [Audit reports](/security/audits).
## Launch toolkit
Launching includes more than deploying contracts. The deployed configuration, governance, metadata, integrations, monitoring, and user-facing risk context all need an owner and a verification step.
This checklist is non-exhaustive. It is not certification or a substitute for reviewing the contracts and live deployment.
### Launch sequence
| Step | Decide and verify | Start with |
| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1. Define the product | Choose EVK market, standalone vault, vault cluster, or Earn vault; identify intended users and dependencies. | [Products](/products), [Vault types](/learn/vault-types), [Markets](/learn/markets) |
| 2. Design the configuration | For EVK, select assets, collateral relationships, oracle routes, IRM, caps, LTVs, liquidation settings, hooks, and fees. For Earn, select the asset, strategies, roles, caps, queues, allocation process, liquidity plan, and fees. | [Curate](/curate), [EVK introduction](/curate/vaults/evk/introduction), [Earn introduction](/curate/vaults/euler-earn/introduction) |
| 3. Deploy | Use the Creator UI or reviewed scripts for EVK, or the Earn deployment guide for an Earn vault. | [Creator UI](/curate/vaults/evk/creator-ui), [EVK deployment](/curate/vaults/evk/deployment-and-management), [Earn deployment](/curate/vaults/euler-earn/deployment-and-management) |
| 4. Assign control | Set governors, timelocks, emergency roles, allocators, curators, fee recipients, and operational ownership. | [Governance contracts](/curate/governance-contracts), [Pause and upgrade](/security/pause-and-upgrade) |
| 5. Verify deployed state | Read addresses, bytecode, assets, routes, parameters, roles, queues, and permissions from the target chain; simulate representative actions. | [Contract addresses](/build/contract-addresses), [Data querying](/build/data-querying) |
| 6. Publish context | Add labels, metadata, entity information, notices, and links needed by users and integrators. | [Labels and metadata](/curate/vaults/labeling) |
| 7. Test integrations | Check app discovery, deposits, borrows, repayments, withdrawals, liquidations, allocation, monitoring, and failure paths that apply. | [Build](/build), [Euler SDK](/build/sdk) |
| 8. Handoff operations | Record owners for monitoring, parameter changes, governance execution, incident response, communications, and post-launch verification. | [Curate](/curate), [Security](/security) |
### Final review
Before making the deployment available to users, confirm:
* **Market risk:** collateral exposure, oracle behavior, caps, LTVs, liquidity, liquidation incentives, hooks, fees, and connected-vault dependencies.
* **Control:** current role holders, selector permissions, timelocks, upgradeability, pause paths, signer policy, and recovery limits.
* **User context:** asset and product labels, governance disclosures, reward and APY sources, withdrawal constraints, deprecation notices, and support ownership.
* **Execution:** representative transactions simulate successfully against the intended chain and addresses, with expected approvals, calldata, events, and post-state.
For Earn-specific roles, strategies, queues, caps, fees, and allocation checks, use the [EulerEarn launch guide](/curate/vaults/euler-earn/introduction). For EulerSwap 2, verify the exact version and connected deployment before applying version-specific controls.
## Agents and LLMs
Euler documentation is available below in formats optimized for agents. Verify live state and simulate any transaction before execution.
### Agent-readable docs
| Endpoint | Use |
| ------------------ | -------------------------------------------------------------------- |
| `/llms.txt` | Compact route and mechanism index. Start here. |
| `/llms-pages.json` | Resolve pages by route, audience, task, mechanism, and risk context. |
| `/llms-full.txt` | Full generated docs context after selecting a task or area. |
| [`/faq`](/faq) | Concise answers and task routing for common questions. |
Loading order:
1. Load `/llms.txt` and select the relevant docs pages.
2. Load `/llms-full.txt` only when broader context is needed.
3. Read current indexed and onchain state on the target chain.
4. Simulate the complete action and require the intended signer to review final calldata.
### Euler agent skills
Install the core vault skill:
```bash
npx add-skill euler-xyz/agent-skills --skill euler-vaults
```
Install all Euler skills:
```bash
npx add-skill euler-xyz/agent-skills --skill euler-vaults --skill euler-irm-oracles --skill euler-earn --skill euler-advanced --skill euler-data
```
| Skill | Use |
| ------------------- | ---------------------------------------------------------------------- |
| `euler-vaults` | Vault operations, EVC orchestration, architecture, risk, and security. |
| `euler-irm-oracles` | Oracle adapters, EulerRouter configuration, and IRM selection. |
| `euler-earn` | Earn creation, strategies, roles, queues, and allocation. |
| `euler-advanced` | Hooks, flash loans, debt transfer, Fee Flow, and EUL rewards. |
| `euler-data` | Lens contracts, subgraphs, interfaces, and deployment data. |
### Primary repositories
| Repository | Scope |
| --------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| [Agent skills](https://github.com/euler-xyz/agent-skills) | Installable Euler context for coding agents. |
| [Euler Vault Kit](https://github.com/euler-xyz/euler-vault-kit) | EVK credit-vault contracts. |
| [Ethereum Vault Connector](https://github.com/euler-xyz/ethereum-vault-connector) | Account coordination, batching, operators, and permits. |
| [Euler Price Oracle](https://github.com/euler-xyz/euler-price-oracle) | Oracle adapters, routing, and quote interfaces. |
| [Euler interfaces](https://github.com/euler-xyz/euler-interfaces) | Deployment addresses, ABIs, and interfaces. |
| [Euler SDKs](https://github.com/euler-xyz/euler-sdks) | TypeScript SDK packages and examples. |
| [EVK periphery](https://github.com/euler-xyz/evk-periphery) | Lenses, factories, governors, perspectives, and other periphery. |
| [EulerEarn](https://github.com/euler-xyz/euler-earn) | Earn vault contracts and allocation roles. |
| [EulerSwap](https://github.com/euler-xyz/euler-swap) | EulerSwap contracts. |
| [Liquidation bot v3](https://github.com/euler-xyz/liquidation-bot-v3) | Reference liquidation monitoring and execution implementation. |
### Agent action checklist
| Action | Start with | Verify before acting |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ |
| Supply | [Supply](/use/supply-assets), [review](/use/supply-review), [SDK](/build/sdk) | Chain, vault, asset, account, allowance or Permit2 path, cap, hooks, expected shares, post-state |
| Borrow | [Borrow](/use/borrow-assets), [risk](/use/borrow-risk), [SDK](/build/sdk) | Controller, collateral, oracle route, caps, liquidity, borrow and liquidation LTVs, rate, health after borrow |
| Withdraw or redeem | [Manage positions](/use/managing-positions), [SDK](/build/sdk) | Shares, assets owed, liquidity, debt, controller, health after withdrawal, strategy queue where relevant |
| Use EulerEarn | [Earn user guide](/use/euler-earn), [integrator guide](/build/earn-integrator-guide) | Asset, share decimals, strategies, allocation, roles, fees, caps, queues, liquidity, loss accounting |
| Build an EVC batch | [EVC integration](/build/evc/integration-guide), [SDK](/build/sdk) | Account, controller, collateral, item order, approvals, simulation, final status checks |
| Configure an EVK vault | [Launch](/launch), [Creator UI](/curate/vaults/evk/creator-ui) | Asset, oracle and unit, IRM, caps, LTVs, liquidation settings, hooks, governor, timelock, labels |
| Configure an oracle route | [Oracle router](/curate/deploy-oracle-router), [Price Oracles](/learn/price-oracles) | Base, quote, unit, adapters, precedence, share conversion, freshness, manipulation and failure behavior |
| Configure hooks | [Hooks implementation](/curate/vaults/evk/hooks-custom-logic), [Hooks concept](/learn/hooks) | Hooked operations, address, access control, revert behavior, reentrancy, gas, upgrade and emergency process, tests |
| Operate EulerSwap | [EulerSwap 2](/curate/euler-swap) | Exact version and deployment, pool and LP account, authority, parameters, expiry, fees, liquidity, LTVs, oracle routes, quote limits |
| Resolve metadata | [Vault metadata](/build/data-querying/perspectives), [labels](/curate/vaults/labeling) | Chain, vault, metadata response, known-vault response, onchain roles, criteria and source scope |
| Resolve contracts | [Contract addresses](/build/contract-addresses), [Euler interfaces](https://github.com/euler-xyz/euler-interfaces) | Chain, address source, ABI, bytecode, version, proxy or implementation status |
Never infer execution safety from labels, APY, a successful simulation alone, or a previous deployment. Read the current target state and review the final transaction.
## Products
Euler's core building block is the vault. EVK vaults can stand alone or connect into lending markets, while EulerEarn vaults allocate deposits across approved strategies. The app, SDK, data services, and Euler Lite provide different ways to use or build on these products.
Vaults can form isolated collateral-debt pairs, pooled borrow markets with selected collateral, or cross-collateralized clusters. Each market configures its own collateral relationships, oracles, interest-rate models, hooks, caps, governance, and liquidation parameters.
### Product lines
EVK vaults are the primitive the rest of the stack is built from: isolated markets connect them for lending and borrowing, and EulerEarn allocates deposits across them.
The building blockEVK vaults
ERC-4626 lending vaults with borrow support, hooks, caps, governance, and configurable collateral relationships. Every Euler market and Earn product is built from these vaults.
EVK vaults connected into collateral and borrow markets with scoped risk. Use them for asset-specific lending, tokenized asset markets, and markets with custom collateral, oracle, cap, and LTV configuration.
### Explore the mechanics
* [Markets](/learn/markets): isolated pairs, multi-collateral markets, and cross-collateralized clusters.
* [Price Oracles](/learn/price-oracles): valuation routes and units of account.
* [Interest Rate Models](/learn/interest-rates): how vault borrow rates respond to utilization or time.
* [Hooks](/learn/hooks): operation-specific policy checks and custom logic.
* [Curate](/curate): deployment, configuration, governance, and operations.
## Annual Percentage Yield
Annual Percentage Yield (APY) expresses a rate as an annualized percentage using an assumed compounding method. On Euler, displayed rates can combine borrower-funded lending yield, an asset's intrinsic yield, and campaign rewards. These components have different sources and risks, and all can change.
### Annualization
If `r_p` is the rate for one compounding period and `n` is the number of periods in a year:
```text
APY = (1 + r_p)^n - 1
```
Before comparing rates, check whether each source reports APR or APY, its compounding convention and sampling time, and whether it includes fees, intrinsic yield, or rewards.
### EVK lending and borrowing rates
EVK interest-rate models return a per-second compounded borrow rate called SPY, scaled by `1e27`. Euler's `Utils` lens uses an average Gregorian year of `365.2425 × 86,400` seconds:
```text
borrow APY = (1 + borrow SPY)^seconds_per_year − 1
utilization = borrows / (cash + borrows)
supply APY = borrow APY × utilization × (1 − interestFee)
```
Here, `borrow SPY` is the unscaled per-second rate and `interestFee` is the normalized fee fraction. The IRM supplies the borrow-rate input; utilization, fees, and vault accounting determine the supplier rate. High supply APY can indicate high utilization and limited withdrawal liquidity.
### Rate components
* **Lending APY:** interest paid by borrowers, after the effect of utilization and the configured interest fee.
* **Intrinsic APY:** yield produced by the underlying asset or its protocol rather than EVK borrowing.
* **Reward APR:** the estimated annualized value of a campaign. It is not compounded by the EVK vault.
* **Borrow APY:** the annualized cost of debt from the liability vault's rate model.
An interface may combine these into a headline or net rate. Adding APR and APY percentage points is a display convention; it does not make campaign rewards protocol-compounded yield.
### What to verify
* Separate lending, intrinsic, borrowing, and reward components.
* Check the rate timestamp, annualization method, utilization, liquidity, IRM, and live fee configuration.
* Confirm campaign eligibility, funding, vesting, claimability, and whether rewards are already included.
* Account separately for token-price changes, slippage, gas, external fees, taxes, and redemption constraints.
* For debt positions, review oracle and liquidation risk; APY does not include liquidation losses.
### Sources
* [EVK periphery `Utils` lens](https://github.com/euler-xyz/evk-periphery/blob/master/src/Lens/Utils.sol)
* [Euler SDK APY example](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/examples/vaults/fetch-apys-example.ts)
### Read next
* [Interest rates](/learn/interest-rates)
* [Rewards](/use/rewards)
* [Return on equity](/use/return-on-equity)
## Borrow assets
**Figure 1:** The Borrow page of Euler
Borrowing on Euler lets you use accepted collateral to borrow from a liability vault. Borrowing starts from **Borrow**. After you open a position, it appears in **Portfolio** under Positions.
:::info
Multiply is available directly from the Borrow page. After selecting a borrow pair, use the tabs at the top of the pair page to switch between **Borrow** and **Multiply**.
:::
### What borrowing does
When you borrow:
* You supply or select collateral accepted by the borrow vault.
* The borrow vault records debt through the Ethereum Vault Connector, or EVC.
* Borrowing capacity depends on collateral value, the oracle route, borrow LTV, available liquidity, and caps. Liquidation LTV separately determines when the position becomes eligible for liquidation.
* Borrowers pay interest based on the vault's [Interest Rate Model](/learn/interest-rates#interest-rate-models).
* The position can become liquidatable if collateral no longer supports the debt.
:::warning
Borrowing involves liquidation risk. Monitor health score, LTV, rates, oracle behavior, collateral price, debt price, and available liquidity after opening a position.
:::
### Find a borrow pair
The **Borrow** page ([app.euler.finance/borrow](https://app.euler.finance/borrow)) lists available collateral and debt pairs.
Each row shows the risk manager, collateral asset, debt asset, Supply APY, Borrow APY, Net APY, Max ROE, maximum multiplier, Max LTV, utilization, and available liquidity. Sort or filter the table, then open a pair to review details.
:::warning
Review the specific pair before borrowing. Relevant fields include collateral asset, debt asset, risk manager, oracle route, Max LTV, Liquidation LTV, utilization, borrow cap, available liquidity, and liquidation discount.
:::
### Borrow flow
1. Choose a pair from **Borrow**.
2. Enter the debt asset amount.
3. Select collateral from wallet assets or an existing deposited balance where supported.
4. Approve token spending if your wallet asks.
5. Review borrowed amount, collateral amount, health score, LTV, liquidation price where shown, oracle route, rates, liquidity, token approvals, and gas estimate.
6. Confirm the transaction in your wallet.
The borrowed asset is sent according to the app flow, and the position appears in Portfolio.
Read next: [Borrow review and risk](/use/borrow-risk), [Portfolio and liquidation](/use/portfolio#liquidation-risk), and [Managing positions](/use/managing-positions).
## Borrow review and risk
Use this page before opening or changing a Borrow position. Borrowing creates debt, and the position must keep enough risk-adjusted collateral to remain valid.
### Pair and position details
Borrow and Multiply share the same pair details page. Use the **Borrow** and **Multiply** tabs at the top to switch between forms.
Review:
* **Supply APY:** displayed annualized rate for the collateral asset.
* **Borrow APY:** displayed annualized base interest cost for the debt asset; inspect any intrinsic-yield or reward-APR adjustments separately in the breakdown.
* **Max ROE:** app estimate for the configured pair. It is not a forecast.
* **LLTV:** liquidation loan-to-value ratio.
* **Liquidity:** available liquidity for borrowing.
* **Oracle:** price route used for the pair.
* **Collateral and debt vault details:** risk parameters, risk manager, exposure, utilization, caps, and related metadata.
Open the rate breakdown to distinguish the base lending or borrowing rate from any intrinsic APY and reward APR included in the displayed rate.
**Figure 1:** APY breakdown
### After borrowing
Borrow positions appear under the Positions tab in Portfolio. Monitor:
* Health score and liquidation price where shown.
* Current LTV versus liquidation LTV.
* Collateral price, debt price, oracle updates, and rate changes.
* Borrow liquidity, withdrawal liquidity, and caps.
* Available actions such as repay, borrow more, add collateral, withdraw excess collateral, and swap-based actions where supported.
### Liquidation risk
A standard EVK account can enter liquidation when, at raw onchain values, its risk-adjusted collateral is not greater than its liability. A displayed health score may be rounded.
To reduce risk, keep a buffer above liquidation, repay debt, add collateral, reduce leverage, or close the position before health falls too far.
For the liquidation process and monitoring guidance, read [Portfolio and liquidation](/use/portfolio#liquidation-risk). See also [Borrow assets](/use/borrow-assets) and [Liquidations](/learn/liquidations).
## EulerEarn
EulerEarn lets you deposit one asset into a vault that allocates across a configured set of strategies, including Euler lending vaults and, where enabled, external ERC-4626 strategies. Instead of choosing and rebalancing several strategies yourself, you hold one ERC-4626 share position while the Earn vault's Curator and Allocators manage its strategy set and allocations within onchain limits.
This can simplify how you access a curated group of strategies, but the vault you choose still matters. Its manager, strategies, caps, queues, fees, recent performance, and available withdrawal liquidity can differ from other Earn vaults.
### At a glance
* **You deposit:** one underlying asset, such as the token named on the vault page.
* **You receive:** ERC-4626 shares representing your claim on that Earn vault.
* **The vault allocates:** across enabled strategies, subject to strategy caps and the configured supply and withdrawal queues.
* **Configured roles manage it:** the Owner, Curator, Allocators, and Guardian have different powers.
* **You can monitor:** recent APY, current allocations, management addresses, fees, rebalancing activity, and available liquidity.
### How Earn works
1. You deposit the vault's underlying asset and receive shares.
2. Configured roles enable strategies, set caps and queues, and move assets among strategies within the vault's rules.
3. Interest and other strategy results flow into the Earn vault's accounting. A configured performance fee can mint shares to the fee recipient.
4. To withdraw, the vault uses its withdrawal queue to recover assets from strategies. The amount available now can be lower than the accounting value of your shares.
### Roles and responsibilities
Roles are hierarchical in the documented implementation: the Owner can perform Curator, Allocator, and Guardian actions, while the Curator can also perform Allocator actions. A vault can have more than one Allocator.
* **Owner:** assigns roles and controls high-level settings, including fees and metadata.
* **Curator:** manages strategy caps and can perform allocation and queue actions.
* **Allocator:** sets queues and reallocates assets among enabled strategies within their caps.
* **Guardian:** can revoke specific pending cap, strategy-removal, Guardian, and timelock actions. The Guardian is not a general veto over all vault activity.
* **Fee recipient:** receives performance-fee shares when a fee is configured. This address is not a management role by itself.
After the applicable timelock, action-specific acceptance methods such as `acceptCap`, `acceptGuardian`, and `acceptTimelock` can be called by anyone. Check the current role addresses, pending actions, and timelock onchain when these details are material to your decision.
Earn vaults require a strategy to be recognized by the configured factory before it can be enabled or its cap increased. That check applies to those configuration changes; it does not continuously approve every allocation made within an existing cap.
### Read the vault page
Use the vault page to understand what you are depositing into:
* **Total assets or supply:** the vault's accounting value. This is not necessarily the amount available for immediate withdrawal.
* **Liquidity or maximum withdrawal:** a point-in-time view of assets currently withdrawable through the configured queue.
* **Recent APY:** annualized historical performance over the displayed window, not a forecast. Check whether the interface includes rewards and fees.
* **Exposure:** the strategies to which assets are currently allocated, including allocation amount or percentage where shown.
* **Management:** the Owner, Curator, Guardian, Allocator, fee recipient, fee, and timelock fields surfaced by the interface.
* **Rebalancing and activity:** indexed records of allocation changes and user deposits or withdrawals.
* **Addresses:** the underlying token and Earn vault contracts for the selected network.
Labels and metadata help with discovery, but they do not replace checking the vault address and live configuration.
### Deposit
1. Open **Earn** in the app and connect your wallet on the intended network.
2. Compare vaults by underlying asset, manager, recent APY, exposure, fees, and liquidity.
3. Open a vault and review its strategies, roles, caps, queues, pending actions, and recent allocation activity.
4. Enter an amount and review the expected shares and current deposit limit.
5. Approve the underlying token if prompted, then check the chain, target contract, amount, receiver, and allowance in your wallet before confirming.
A token approval or permit can require a separate signature or transaction. Previewed shares and limits can also change before execution.
### Withdraw
1. Open the vault or your position and select **Withdraw**.
2. Compare the accounting value of your shares with the amount currently available to withdraw.
3. Enter an amount, review the receiver and transaction, and confirm it in your wallet.
Withdrawals depend on the liquidity available through the withdrawal queue. A strategy can be fully utilized, subject to its own withdrawal limit, or temporarily unable to return assets. If the full amount is unavailable, a smaller withdrawal may work, but future liquidity is not assured.
### Losses and withdrawal shortfalls
An Earn vault tracks both assets represented by strategy shares and a `lostAssets` accounting value. If a strategy realizes a shortfall or is force-removed while assets remain in it, the amount represented by the vault and the amount currently withdrawable can fall.
The displayed share conversion does not always show that effect immediately because recognized gaps can remain in reported `totalAssets()`. Check `lostAssets`, represented strategy assets, and `maxWithdraw` together rather than treating an unchanged displayed share value as evidence that no loss occurred.
For the contract-level accounting and recovery paths, review the [EulerEarn source repository](https://github.com/euler-xyz/euler-earn).
### Fees and performance
An Earn vault can charge a performance fee, paid by minting shares to its configured fee recipient under the vault's accounting. Check the current fee and recipient for the specific vault.
Recent APY can reflect lending rates, rewards, allocation changes, fees, and the selected measurement window. It is most useful for understanding what happened over that period; it does not tell you what the next period will produce.
### Before depositing
Review:
* the underlying asset and vault contract address;
* the Curator, Allocators, Owner, Guardian, and their permissions;
* enabled strategies, caps, supply queue, and withdrawal queue;
* recent allocation and management activity;
* current withdrawable liquidity and any recorded `lostAssets`;
* performance fee and fee recipient; and
* strategy, oracle, market, smart-contract, and role dependencies.
### Troubleshooting
* **Approval or deposit fails:** verify network, token and vault addresses, balance, gas, allowance or Permit2 expiry, current deposit limit, and the decoded revert.
* **Displayed APY changes sharply:** check the measurement window, vault size, allocation changes, rewards, and data freshness.
* **Withdrawal reverts:** refresh the current maximum withdrawal, inspect queue and strategy liquidity, verify your share balance and receiver, and preserve the exact revert for diagnosis.
* **Accounting value differs from withdrawable amount:** inspect `lostAssets`, strategy assets, queue liquidity, and strategy limits.
### Technical resources
* [EulerEarn integrator guide](/build/earn-integrator-guide)
* [EulerEarn audits](/security/earn-audits)
* [EulerEarn contracts and source](https://github.com/euler-xyz/euler-earn)
## Getting Started with Euler V2
Use the Euler app to supply assets, deposit into EulerEarn, borrow against collateral, or open a Multiply position.
### Connecting Your Wallet
**Figure 1:** Connect a Wallet modal upon clicking the "Connect" button on the top right
1. Open the [Euler app](https://app.euler.finance/).
2. Select **Connect** in the top-right corner and choose a supported browser or WalletConnect wallet.
3. Verify the account and network before approving the connection.
### Understanding the Interface
The main navigation contains:
* **Portfolio:** Review Net APY, ROE, supplied and borrowed value, net asset value, positions, deposits, claimable rewards, and account activity.
* **Explore:** Browse available Euler markets and opportunities.
* **Earn:** Find EulerEarn vaults that allocate deposits across configured strategies.
* **Lend:** Find lending vaults and compare Supply APY, risk manager, exposure, utilization, and available liquidity.
* **Borrow:** Find collateral/debt pairs. After opening a pair, switch between the **Borrow** and **Multiply** forms.
#### Key Concepts from UI
* **Accounts:** Direct deposits use your main account (`0`). The app generally opens each Borrow or Multiply position in a separate EVC sub-account.
* **Collateral source:** A position can use assets from your wallet or an eligible deposited balance.
* **Batched actions:** The app can combine compatible position actions into one atomic transaction. An approval or permit may still require a separate wallet prompt.
* **Vaults and pairs:** Lending uses individual vaults. Borrow and Multiply use a collateral-vault/debt-vault pair.
* **LTVs:** **Borrow LTV** determines borrowing power. **Liquidation LTV (LLTV)** determines when a position becomes eligible for liquidation.
* **Health score:** A Borrow or Multiply position may become eligible for liquidation when its health score reaches 1 or below.
* **Risk management:** Review the current risk manager, oracle, LTVs, caps, and other configurable parameters before using a market.
#### Where Do My Positions and Deposits Live?
The app stores different workflows separately:
* **Direct deposits:** Live in your main wallet address (account `0`).
* **Borrow/Multiply positions:** The Euler app generally opens each position in a separate sub-account (account 1, 2, 3, etc.), which is a unique address linked to your wallet.
Sub-accounts share the first 19 bytes of the owner address and differ in the final byte. The app manages their selection during normal use.
Continue to [Supply assets](/use/supply-assets), [Borrow assets](/use/borrow-assets), [Multiply](/use/multiply-strategies), or [EulerEarn](/use/euler-earn).
## Manage Multiply
Multiply positions appear alongside Borrow positions under **Portfolio > Positions**. Monitor them more closely than unleveraged positions because price, rate, liquidity, and swap execution changes have a larger effect on equity.
### What to monitor
* **Health score and liquidation price:** keep a buffer above liquidation.
* **Net rate or ROE:** app estimates can change after rates, rewards, or utilization change.
* **Collateral and debt prices:** adverse moves can reduce equity quickly.
* **Borrow and withdrawal liquidity:** low liquidity can affect opening, changing, or closing a position.
* **Swap execution:** entry, increase, repay, and close actions may depend on routing, price impact, and slippage.
### Transaction summary
**Figure 1:** Transaction summary in the Multiply form
Before signing, review expected amounts, route, price impact, slippage tolerance, gas estimate, token approvals, and resulting position health.
**Slippage** is the allowed difference between quote and execution. If execution moves beyond the tolerance, the transaction reverts.
**Price impact** is the effect your trade size has on execution price. Larger swaps can receive worse prices.
**Leveraged price impact** counts swap impact against margin rather than notional exposure. A small price impact on the full swap can be a larger percentage of your initial collateral.
### Available actions
* **Multiply:** increase exposure by borrowing, swapping, and adding collateral.
* **Repay:** reduce debt or unwind part of the loop.
* **Supply collateral:** add more collateral directly to the position.
* **Withdraw collateral:** remove excess collateral if the position remains valid.
Management actions can involve multiple protocol and swap steps. Review [Portfolio and liquidation](/use/portfolio#liquidation-risk), [Strategy profitability](/use/strategy-profitability), and [Managing positions](/use/managing-positions) before using or changing a Multiply position.
## Open Multiply
**Figure 1:** The Borrow page of Euler
Multiply is the leveraged position flow inside the Borrow page. It builds a larger collateral position by borrowing the debt asset, swapping it for more collateral, and supplying that collateral back into the position. Where a route is available, the app prepares these actions as a batch. A token approval or permit may still require a separate wallet prompt.
:::info
After selecting a borrow pair, toggle between the **Borrow** and **Multiply** forms at the top of the pair page. There is no separate Strategies entry point.
:::
### What Multiply does
When you choose a multiplier, the app estimates the sequence needed to borrow the debt asset, swap it into more collateral, and supply that collateral back into the position.
This lets you choose a target multiplier without manually repeating the borrow, swap, and supply loop. It increases exposure to the collateral asset, but it also adds debt and makes the position more sensitive to price moves, rates, liquidity, and swap execution.
### Find a Multiply pair
The **Borrow** page ([app.euler.finance/borrow](https://app.euler.finance/borrow)) lists collateral and debt pairs that can be opened as Borrow or Multiply positions where supported.
Each row can show the risk manager, asset pair, Borrow APY, Supply APY, Net APY, Max ROE, maximum multiplier, Max LTV, utilization, and available liquidity. Open a pair, then select the **Multiply** tab.
The Borrow and Multiply forms share the same pair page. Before choosing a pair, compare the collateral and debt assets, risk manager, current Supply and Borrow APYs, Max LTV and Liquidation LTV, oracle route, available liquidity, estimated Max ROE, and maximum multiplier. Headline rates and limits can change with vault and market conditions.
### Open a Multiply position
1. Select the **Multiply** tab on the pair page.
2. Enter the collateral amount you want to start with.
3. Set the multiplier.
4. Review multiplier, ROE, current price, liquidation price where shown, LTV, health score, swap route, expected amounts, price impact, slippage tolerance, gas estimate, and token approvals.
5. Confirm the transaction in your wallet.
**Figure 2:** The Multiply form on a Borrow pair page
### Review the swap
The transaction summary should show the debt amount being swapped, expected collateral received, route, price impact, and slippage tolerance.
* **Slippage tolerance** is the maximum adverse difference the transaction accepts between the quote and execution. If execution would return less than the permitted minimum, the transaction should revert.
* **Price impact** is the effect of the trade size on its execution price. Multiply swaps the borrowed amount needed to reach the target position, so the swap can be large relative to the margin you supplied.
### After opening
Multiply positions appear under **Positions** in Portfolio alongside Borrow positions. Use the position page to add collateral, repay debt, change the multiplier, or close the position where supported. See [Manage Multiply](/use/multiply-management) for the metrics and swap details to monitor.
:::warning
Multiply uses leverage. A smaller adverse price, rate, liquidity, or swap-execution move can affect the position faster than an unleveraged position. A positive displayed ROE does not include every cost or establish that the position will remain profitable.
:::
Read next: [Manage Multiply](/use/multiply-management), [Strategy profitability](/use/strategy-profitability), and [Portfolio and liquidation](/use/portfolio#liquidation-risk).
## Portfolio and liquidation
Portfolio is the main dashboard for your Euler activity. Use it after supplying, borrowing, opening a Multiply position, depositing into EulerEarn, or claiming rewards.
### Portfolio
The Portfolio header summarizes:
* **Net APY:** estimated net annualized return across the portfolio.
* **ROE:** estimated return on portfolio equity.
* **Total supplied:** supplied assets, including deposits and collateral inside positions.
* **Total borrowed:** borrowed assets across Borrow and Multiply positions.
* **Net asset value:** supplied value minus debt value in Euler.
Portfolio has four main areas:
* **Positions:** Borrow and Multiply positions. Each position shows collateral and debt assets, net asset value, ROE, multiplier where relevant, health score, current price, liquidation price where shown, and a link to the position detail page.
* **Deposits:** EulerEarn and direct lending deposits that are not automatically collateral for Borrow or Multiply positions. Rows show the asset, supplied amount, supply value, Supply APY, and available actions such as Supply, Withdraw, and Asset swap.
* **Rewards:** claimable rewards and their estimated market value. Reward eligibility and display timing depend on campaign rules and data-indexing updates. Verify the active campaign and claimable amount with the linked distributor before including rewards in position accounting.
* **Activity:** recent Euler activity for the viewed account.
**Figure 1:** Borrow and Multiply positions in Portfolio
**Figure 2:** Earn and direct lending deposits in Portfolio
The position detail page is where you add collateral, withdraw collateral, borrow more, repay debt, use Multiply, swap collateral, transfer shares, or disable collateral where the account remains valid.
### Liquidation risk
**Figure 3:** Position health display
A standard EVK account can enter liquidation when, at raw onchain values, its risk-adjusted collateral is not greater than its liability. A health score displayed as 1 may be rounded, so consult raw values and transaction simulation. During liquidation, a liquidator takes over selected debt and receives collateral at the current liquidation discount. The resulting liquidator account must satisfy the applicable controller, collateral, vault, and EVC checks.
A position can become liquidatable when risk-adjusted collateral falls relative to liabilities because of price or oracle changes, interest accrual, or parameter changes. Limited liquidity can make it harder or more expensive to reduce risk or unwind, but it does not itself determine account status. If a position remains below the threshold after one liquidation, it can be liquidated again.
To reduce liquidation risk:
* Keep health score above 1 with a buffer that fits the volatility and liquidity of the position.
* Watch liquidation price where shown, LTV, Liquidation LTV (LLTV), collateral price, debt price, rates, and available liquidity.
* Add collateral, repay debt, reduce leverage, or close the position before health falls too far.
* Treat third-party alerts as helpful but not guaranteed.
Euler uses a reverse Dutch auction style liquidation discount. A position only slightly below the threshold generally receives a smaller discount, while a deeply unhealthy position can offer a larger discount up to the vault's configured maximum. For the mechanism-level explanation, read [Liquidations](/learn/liquidations).
### Rewards and rEUL
Rewards appear in Portfolio when reward data is available. Claimable reward tokens show token amount, estimated market value, and claim actions.
If you claim rEUL, Portfolio shows the amount, accrued EUL amount, and maturity information. For details, read [Reward EUL](/EUL/reward-eul).
Read next: [Managing positions](/use/managing-positions), [Borrow](/use/borrow-assets), [Multiply](/use/multiply-strategies), and [Troubleshooting](/use/troubleshooting).
## Rewards
Rewards are campaign incentives for selected activities such as supplying, borrowing, providing collateral, or looping. They are separate from vault interest, so a position can have both a base rate and a reward rate.
Check the eligible action and account, campaign period, funding, reward token, caps, distributor, claim route, and whether the app already includes rewards in APY or ROE. Campaigns can change or end and may require opt-in or a claim.
### Merkl campaigns
[Merkl](https://app.merkl.xyz/) is a separate campaign and distribution system. Campaigns define eligible actions and calculate entitlements under their own rules. Verify the network, vault, action, period, methodology, token, caps, and claimable amount with the linked distributor.
### rEUL
rEUL is a reward instrument used by selected campaigns, not another name for Merkl rewards. Its vesting, early-redemption, and forfeiture rules are separate from campaign eligibility. See [Reward EUL](/EUL/reward-eul) before valuing it.
### Rewards in APY and ROE
Campaigns generally report reward **APR** based on estimated token value and eligible balances. It is not compounded by the EVK vault. Euler's ROE calculation can value eligible supply and borrow rewards and divide their rate contribution by NAV.
Before including rewards, verify eligibility for the address or sub-account, campaign funding and limits, token liquidity and vesting, and whether the displayed rate already includes them. Gas, taxes, token-price changes, and claim or redemption constraints can reduce realized value.
Euler SDK reward actions include `LEND`, `BORROW`, `BORROW_COLLATERAL`, and `LOOPING`. Eligibility can also depend on collateral, multiplier range, whitelist, or blacklist, so a headline APR may differ from the connected account's rate.
### Sources
* [Euler SDK reward attribution](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/rewards-service.md)
### Read next
* [Annual percentage yield](/use/annual-percentage-yield)
* [Return on equity](/use/return-on-equity)
* [Interest rates](/learn/interest-rates)
## Spy mode
**Spy Mode** is an advanced, read-only feature that lets you view the Euler app through another address. It is useful for reviewing public positions, studying account structure, or helping another user troubleshoot what they see in the app.
### How to activate spy mode
Add `?spy=` followed by the Ethereum address to the end of the app URL in your browser:
```text
https://app.euler.finance/portfolio?spy=0x1234...
```
Replace the example address with the address you want to view.
### What you can see
When Spy Mode is active, you can view public account information for that address, including:
* Portfolio overview, including supplied assets and debt
* Active Borrow and Multiply positions
* Deposit and collateral allocations
* Currently claimable rewards
Spy Mode is read-only. You can inspect the viewed address, but you cannot sign transactions, move funds, or modify that address's positions.
### Common uses
* **Support:** Help another user understand their portfolio without needing access to their wallet.
* **Strategy Review:** Inspect public positions to understand how an account is structured.
* **Research:** Review how addresses use Euler across supplied assets, debt positions, and rewards.
### Read next
* [Getting started](/use/getting-started)
* [Managing positions](/use/managing-positions)
* [Troubleshooting](/use/troubleshooting)
## Strategy Profitability
A displayed APY or projected ROE does not determine the realized outcome of a position. Supply and borrow rates, incentives, swap execution, gas costs, price movement, and liquidation can each affect the result. The sections below show how to review those components separately.
### Understanding strategy costs
A leveraged position can incur costs when it is opened, managed, and unwound. The exact path depends on the assets held, route availability, partial management actions, and whether debt is repaid from another source.
#### Swap costs
A typical full open-and-unwind position uses an entry swap to convert borrowed assets into collateral and a later exit swap to obtain the debt asset for repayment. Where swaps are used, review these components:
1. **Price impact:** Larger trades can receive a worse average execution price because they consume available liquidity. Compare the live routes and quotes shown for the exact swap size.
2. **Route fees:** A route may include fees charged by its DEX, pool, or aggregator. There is no universal fee range. Use the live quote and transaction details, and do not count an all-in execution difference again as a separate fee.
3. **Slippage tolerance:** This is the maximum execution movement permitted by the transaction. A wider tolerance can expose a transaction to worse execution or MEV; a narrower tolerance can cause it to revert during ordinary market movement.
4. **Notional exposure:** Swap costs apply to the amount actually swapped, not only to the position's initial equity. Leverage can make that amount materially larger, but the relationship depends on the specific route and position state.
#### Gas costs
Network and route conditions affect transaction costs. Gas can be particularly material for small or short-lived positions, frequent management, and multi-transaction workflows. Estimate it from the exact transaction path rather than applying one fixed amount.
#### Dynamic rates and incentives
Interest rates, APY, ROE, and reward estimates are snapshots. They can change with:
* vault utilization and available liquidity;
* the configured IRM and governor actions;
* reward-program terms and publication cadence;
* collateral and debt prices; and
* position balances as interest accrues.
### Analyzing a position
Separate cash flows and valuation assumptions rather than relying on one headline percentage.
#### Reward timing
Merkl reward eligibility, calculation, publication, and UI display can update on different schedules. A new position may show no rewards before a campaign update, but rewards should not be assumed until they are published as claimable under the campaign's rules. Check the active campaign and distributor data before including rewards in an outcome estimate.
#### Price and accounting inputs
The UI's Net Asset Value calculations use market prices, which can differ from execution prices, protocol oracle prices used for health checks, and a stablecoin's target peg.
For a reproducible estimate:
1. Record the underlying collateral and debt amounts, timestamp, chain, and position account.
2. State the valuation source for each asset. If an at-peg stablecoin scenario is useful, show it separately from observed market value.
3. Include accrued supply and borrow interest, currently claimable rewards, any previously claimed rewards tracked separately, entry and exit execution, route fees, gas, and any liquidation loss.
4. Distinguish realized cash flows from current mark-to-market values and forecast assumptions.
### Factors to monitor
* **Rates and rewards:** current supply and borrow rates, reward terms, and changes to the configured IRM or campaign.
* **Execution:** depth and quotes for the intended swap size, route fees, slippage bounds, and gas estimates.
* **Account risk:** health, LTV, liquidation thresholds, oracle prices, available liquidity, and sensitivity to collateral, debt, and rate changes.
* **Time horizon:** setup and unwind costs can dominate short holding periods, while rates, rewards, and market conditions can change over longer periods.
Any projected result is an estimate based on stated assumptions, not a forecast or a suitability assessment.
## Review and monitor supplied assets
Use this page after [supplying to a vault](/use/supply-assets), including an Earn vault. Vault state can change after deposit, so check Portfolio and the vault page before adding, withdrawing, or using the deposit as collateral.
### Find and compare vaults
The **Lend** page lists direct lending vaults. Compare the underlying asset and market, risk manager, current Supply APY, total supply, collateral exposure, utilization, and available liquidity. Open a vault to inspect its collateral relationships and live parameters rather than choosing from the headline rate alone.
### What to monitor
* **Supply APY:** displayed annualized rate. Open its breakdown to distinguish base lending APY from any intrinsic APY or reward APR. Each component can change independently.
* **Utilization:** how much supplied liquidity is currently borrowed. High utilization can increase rates and reduce available withdrawals.
* **Available liquidity:** assets available for withdrawal or borrowing.
* **Exposure:** collateral vaults connected to the supplied vault.
* **Governor and parameters:** who can manage selected settings, plus caps, fees, oracle routes, and liquidation settings.
* **Rewards:** active incentive APR estimates may be added to a headline rate and can change independently from the vault's base APY.
* **Earn allocation:** for Earn vaults, review strategy exposure, allocator activity, management roles, fees, and withdrawable liquidity.
**Figure 1:** Supply APY breakdown
### Deposits as a collateral source
Direct lending deposits are not automatically collateral for an existing Borrow or Multiply position. When opening a supported position, the app can use a deposited balance as the collateral source and prepare the actions that move or supply it into the separate position account. Review the source account, destination account, supplied amount, approvals, resulting LTV, health, and wallet prompt before signing.
### Withdrawing or changing exposure
Withdrawals depend on available vault liquidity and require a blockchain transaction. You may not be able to withdraw the full amount immediately if most assets in the vault are borrowed.
From Portfolio, direct lending deposits can support:
* **Supply:** add more assets to the same vault.
* **Withdraw:** remove assets when liquidity is available.
* **Asset swap:** exchange one deposited asset for another through the app's swap route where supported.
#### Earn withdrawals
For an Earn vault, withdrawability depends on the vault's cash, the liquidity and withdrawal behavior of allocated strategies, the withdrawal queue, allocation state, and any realized loss. Check the current `maxWithdraw` or `maxRedeem` result for the account before assuming the displayed share balance can be withdrawn immediately. A withdrawal may traverse configured strategies in queue order and can return less underlying than an earlier valuation if a strategy has recognized losses.
Read next: [Supply assets](/use/supply-assets), [Portfolio and liquidation](/use/portfolio), [Vaults](/learn/vaults), and [Markets](/learn/markets).
## Troubleshooting
Record the network, page URL, vault and account addresses, intended action, and exact error before changing settings or retrying. Never share a seed phrase, private key, password, or signing secret.
### Common errors
#### `E_AccountLiquidity`
**Meaning:** The requested action would leave the account above the permitted borrow LTV or otherwise fail its account-status check. A position can remain below its liquidation LTV and still be unable to take a risk-increasing action.
**Action:** Reduce the borrow or withdrawal, add eligible collateral, or repay debt. Review the controller vault, enabled collateral, current oracle values, borrow LTV, and liquidation LTV before retrying.
#### `E_InsufficientCash`
**Meaning:** The vault does not have enough available underlying liquidity for the requested withdrawal or borrow. This can also affect collateral-to-repay flows when the source vault lacks liquidity.
**Action:** Reduce the amount or wait for liquidity to return. Check the target vault's available liquidity before resubmitting.
#### `E_RepayTooMuch`
**Meaning:** The requested repayment exceeds the current debt amount after interest and rounding.
**Action:** Use **Max** when available or submit an amount below the displayed total debt.
#### `E_SupplyCapExceeded` or `E_BorrowCapExceeded`
**Meaning:** The requested action would exceed the relevant vault cap.
**Action:** Reduce the amount or wait for capped supply or capped borrows, respectively, to fall. A curator may be able to change a cap only if the deployed roles authorize it.
#### Multiple wallet extensions active
Multiple extensions can compete for the wallet-provider connection and signing request. Disable extensions you are not using, refresh the page, reconnect the intended wallet, and retry.
#### RPC issues
An unavailable or stale RPC can prevent simulation, reads, or transaction submission. Switch to another RPC you trust, confirm the wallet is on the intended network, and check whether a transaction hash was produced before retrying.
#### Gasless signatures unsupported
Some wallets handle the typed-data signatures used for gasless (Permit2) approvals poorly. If signature prompts fail or approvals stall, open **Settings** using the gear button in the top-right corner and disable **Gasless signatures** to fall back to standard approval transactions, then retry the flow.
### Basic checks
1. Reconnect the wallet and confirm the account and network.
2. Refresh the page after disabling conflicting extensions or changing RPC.
3. Inspect the wallet error and browser console; remove secrets before sharing logs.
4. If a transaction hash exists, inspect its status and revert data on the relevant explorer.
5. Recheck vault liquidity, caps, oracle state, account health, and approvals because state may have changed.
### Reporting an issue
Report issues and get user support in the [Euler community Discord](https://discord.euler.finance). If the issue is security related, report it through the [bug bounty](/security/bug-bounty) instead — never disclose a potential vulnerability publicly.
Include:
* action, page URL, and approximate time;
* network, public account or sub-account, and vault address;
* transaction hash, simulation result, and exact error;
* wallet, browser, device, and versions;
* redacted screenshots; and
* relevant console or network errors with API keys, authorization headers, cookies, RPC credentials, and personal information removed.
### Read next
* [Managing positions](/use/managing-positions)
* [Portfolio and liquidation](/use/portfolio#liquidation-risk)
* [Data querying](/build/data-querying)
## Managing positions
Position management happens in **Portfolio**. Direct lending and Earn deposits appear under Deposits; Borrow and Multiply positions appear under Positions with their own detail pages. Leveraged positions require closer monitoring because rates, prices, liquidity, and swap execution have a larger effect on equity.
### How to manage a Borrow or Multiply position
1. Open **Portfolio > Positions** and select the position.
2. Choose the action you want to take.
3. Review the resulting balances, debt, LTV, health score, and token approvals. For swaps, also check expected amounts, route, price impact, and slippage tolerance.
4. Confirm the transaction in your wallet.
### Managing deposits
For direct lending deposits, the available actions can include:
* **Supply:** Add more assets to the vault.
* **Withdraw:** Remove assets when liquidity is available.
* **Asset swap:** Exchange one deposited asset for another through the app's swap route where supported.
### Deposits as a collateral source
Direct lending deposits are not automatically collateral for an existing position. A supported Borrow or Multiply flow can use a deposit as its collateral source; see [Supply review](/use/supply-review#deposits-as-a-collateral-source).
### Managing Borrow/Multiply positions
**Figure 1:** The Position page of a USDC/USDT position
For your Borrow or Multiply positions, you have access to these actions in the UI:
#### Leverage and debt management
* **Multiply:** Increase exposure by borrowing, swapping, and adding collateral through the Multiply flow.
* **Repay:** Reduce debt by paying back borrowed assets from wallet assets, deposits, or collateral where supported.
* **Borrow:** Borrow additional assets against existing collateral when LTV and liquidity allow it.
#### Collateral management
* **Supply:** Add more collateral to your position.
* **Withdraw:** Remove collateral if the remaining position stays within LTV limits and liquidity is available.
* **Collateral Swap:** Exchange current collateral for a different asset through the app's swap route.
* **Transfer:** Transfer collateral shares to another account if the position remains valid.
* **Disable Collateral:** Stop using a specific asset as collateral if the position remains valid.
For liquidation mechanics, read [Portfolio and liquidation](/use/portfolio#liquidation-risk). For rate calculations, read [Interest rates](/learn/interest-rates) and [Strategy profitability](/use/strategy-profitability).
## Return on equity
Return on Equity (ROE) combines supply income and borrowing cost into an annualized estimate relative to a position's equity. It is useful for Borrow and Multiply positions, where a supply or borrow rate alone shows only one side.
Euler defines equity as supplied market value minus borrowed market value, also called Net Asset Value (NAV). ROE estimates rate exposure, not realized profit. Rates, rewards, prices, eligibility, execution costs, and liquidation risk can change.
### Base formula
Let `S` be supplied value, `B` borrowed value, `r_s` supply APY, and `r_b` borrow APY:
```text
equity = S − B
ROE = ((S × r_s) − (B × r_b)) / (S − B)
```
Supply and debt must use the same quote currency and price timestamp. ROE is undefined or not economically meaningful when equity is zero or negative.
A calculation divided by supplied value is net APY, not ROE:
```text
net APY = ((S × r_s) − (B × r_b)) / S
```
### Multiplier form
For multiplier `M = S / (S − B)`:
```text
ROE = (M × r_s) − ((M − 1) × r_b)
```
For a single collateral and debt pair where current `LTV = B / S`, `M = 1 / (1 − LTV)`. The position's current LTV is not its configured borrow limit.
### Example
For $1,000 supplied at 7.5% APY and $800 borrowed at 4.5% APY:
```text
equity = $1,000 − $800 = $200
multiplier = $1,000 / $200 = 5
ROE = (($1,000 × 7.5%) − ($800 × 4.5%)) / $200
= 19.5%
```
The same net rate amount is 3.9% when divided by the $1,000 supplied value. Leverage magnifies both positive and negative rate differences because equity is smaller than total supplied value.
### Rewards and intrinsic yield
Euler's SDK can include several contributions before dividing by equity:
```text
base lending = supplied value × base supply APY
base borrowing = −borrowed value × base borrow APY
supply rewards = supplied value × eligible LEND APR
borrow rewards = borrowed value × eligible BORROW or BORROW_COLLATERAL APR
loop rewards = equity × eligible LOOPING APR
intrinsic = supplied intrinsic yield − borrowed intrinsic yield
ROE = included contributions / equity
```
Campaign APR is an estimate, may depend on the connected account and campaign rules, and does not compound through the vault. See [Rewards](/use/rewards).
### Comparing ROE
Confirm that figures use NAV as equity, the same price timestamp and annualization conventions, and comparable rate, reward, and intrinsic-yield components. Check whether reward eligibility is account-specific and whether gas, swaps, slippage, taxes, external fees, and liquidation losses are excluded.
**Max ROE** applies rates to a modeled maximum multiplier. It is not a forecast or a promise that the position can be opened or maintained at that size.
### Sources
* [Euler SDK account and portfolio computed properties](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/account-computed-properties.md)
* [Euler SDK reward attribution](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/rewards-service.md)
### Read next
* [Annual percentage yield](/use/annual-percentage-yield)
* [Rewards](/use/rewards)
* [Strategy profitability](/use/strategy-profitability)
* [Liquidations](/learn/liquidations)
## Supply assets
**Figure 1:** The Lend page of Euler
Supplying assets on Euler means depositing tokens into a vault. Most supply flows deposit into lending vaults, where borrowers may use available liquidity and suppliers receive vault shares that track their claim on the vault's assets. EulerEarn is also a vault-based supply flow: users deposit one asset into an Earn vault and hold shares while the vault allocates across its configured strategies.
Portfolio groups direct deposits under **Deposits**. They are separate from collateral supplied inside a Borrow or Multiply position, although deposited assets can be selected as a collateral source when opening a new position.
### What supplying does
When you supply assets:
* The vault mints shares to your account.
* Borrowers may borrow from that vault if borrowing is enabled and liquidity is available.
* Borrowers pay interest according to the vault's [Interest Rate Model](/learn/interest-rates#interest-rate-models).
* The vault share price changes as interest, fees, losses, and other configured mechanics apply.
The displayed **Supply APY** is an annualized rate based on current or recent conditions. It can change with utilization, rewards, intrinsic yield, vault parameters, and market conditions.
### Find a vault
The **Lend** page ([app.euler.finance/lend](https://app.euler.finance/lend)) lists available lending vaults for supplying assets. The **Earn** page lists Earn vaults, which are single-position ERC-4626 vaults for curated strategy allocation.
Each row shows the asset, market name where available, risk manager, Supply APY, total supply, collateral exposure, utilization, and available liquidity. Sort or filter the table, then open a vault to review its live details.
:::warning
Supplying is not principal-protected. A position can lose value through bad debt, oracle or market failure, smart-contract failure, governance or configuration changes, or an impaired underlying asset. Available liquidity may also limit or delay withdrawal. Review the vault, collateral configuration, oracle route, caps, governance, current liquidity, and APY breakdown before supplying.
:::
### Supply flow
1. Choose a vault from **Lend** or a vault details page.
2. Enter the amount to supply.
3. Approve token spending if your wallet asks. Euler uses gasless Permit2 signatures by default; to fall back to standard approval transactions, open **Settings** using the gear button in the top-right corner and disable **Gasless signatures**.
4. Review deposit amount, expected shares, APY, token approval, risk manager, exposure, utilization, liquidity, and caps.
5. Confirm the transaction in your wallet.
After the transaction confirms, the supplied asset appears in **Portfolio** under Deposits.
Read next: [EulerEarn](/use/euler-earn), [Review and monitor supplied assets](/use/supply-review), [Portfolio and liquidation](/use/portfolio), and [Managing positions](/use/managing-positions).
## Application Security
### Network Security
#### HSTS
`app.euler.finance` returns an HTTP Strict Transport Security (HSTS) header, which instructs supporting browsers to use HTTPS for the origin.
#### DNSSEC
`euler.finance` publishes a DNSSEC delegation record, enabling resolvers to validate signed DNS data for the zone.
#### DDoS Protection
`app.euler.finance` is served through Cloudflare's edge network. Cloudflare provides DDoS protection for applications proxied through its network.
### Application Layer Security
#### Content Security Policy (CSP)
`app.euler.finance` returns a Content Security Policy (CSP) that restricts permitted resource origins and script execution. CSP can reduce risk from some content-injection attacks, including cross-site scripting.
#### Email Security
`euler.finance` and `euler.xyz` publish SPF and DMARC records. These records help receiving mail systems evaluate authorized senders and specify how authentication failures should be handled.
### Further Security Resources
* See [Euler Protocol audits](/security/audits) for component-specific security reviews.
* See the [Bug Bounty Program](/security/bug-bounty) to report a vulnerability.
## Security review and verification record
:::tip[Deployed Code Verification]
Euler verifies security-relevant deployments at the **bytecode level**. Onchain bytecode is matched to a build from an exact source commit, then compared with the latest audited baseline. Browse the [per-chain reports](https://github.com/euler-xyz/euler-interfaces/tree/master/verify) or reproduce them with [euler-verifier](https://github.com/euler-xyz/euler-verifier) and public RPC endpoints.
:::
Euler has commissioned audits and focused reviews across its core contracts, oracles, periphery, integrations, and applications. The record also includes formal verification, fuzzing, penetration tests, and security competitions.
### Security competitions and Capture the Flag contests
* [**$1.25M Cantina Security Competition**](https://cantina.xyz/competitions/41306bb9-2bb8-4da6-95c3-66b85e11639f) — More than 600 participants reviewed the scoped contracts. No high- or medium-severity findings were identified; low-severity and informational findings were rewarded, with $200,000 allocated to researchers.
* [**$3.5M Hats Finance CTF Challenge**](https://hatsfinance.medium.com/join-the-ultimate-3-5m-euler-ctf-challenge-powered-by-hats-finance-1a4e8396907b) — Approximately $3.5 million in live funds was placed in Euler markets. After 13 days, no funds were compromised.
### Review records
| Date | Scope | Review type | Security firm | Report URL |
| ----------------- | --------------------------------------------------- | --------------------------- | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 11 March 2026 | EVK Periphery (Oracle, Hook, SwapVerifier) | Security review | BailSec | [BailSec EVK Periphery Oracle Hook SwapVerifier Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/BailSec%20EVK%20Periphery%20Oracle%20Hook%20SwapVerifier.pdf) |
| 10 March 2026 | CoW Protocol: Euler Integration | Security review | Cantina | Report pending publication |
| 24 February 2026 | Euler Lite (Web2 Pentest) - AI | Penetration test | FailSafe | Private report |
| 4 February 2026 | Layer Credit | Security review | yAudit | Private report |
| 4 February 2026 | EVK Swap Verifier Update | Security review | yAudit | [yAudit SwapVerifier Update Report](https://github.com/euler-xyz/evk-periphery/blob/80306d40645e0d5be78ade613d35d29e551ff75f/audits/yAudit%20SwapVerifier%20update.pdf) |
| 18 November 2025 | EVK Periphery - SWARM - AI | Security review | FailSafe | Private report |
| 14 October 2025 | ERC20Synth & Auxiliary Contracts | Security review | Spearbit | [Spearbit ERC20Synth and Auxiliary Contracts Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/Spearbit%20ERC20Synth%20and%20auxiliary%20contracts.pdf) |
| 14 October 2025 | ERC20Synth & Auxiliary Contracts | Security review | Electisec | [Electisec ERC20Synth and Auxiliary Contracts Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/Electisec%20ERC20Synth%20and%20auxiliary%20contracts.pdf) |
| 1 August 2025 | HookTargetMarketStatus | Security review | CD Security | [CD Security HookTargetMarketStatus Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/CD%20Security%20HookTargetMarketStatus.pdf) |
| 13 June 2025 | IRMLinearKinky | Security review | Supremacy | [Supremacy IRMLinearKinky Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/Supremacy%20IRMLinearKinky.pdf) |
| 1 June 2025 | EUL ERC20 | Security review | BailSec | [BailSec EUL ERC20 Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/BailSec%20EUL%20ERC20.pdf) |
| 22 April 2025 | CapRiskSteward | Security review | MixBytes | [MixBytes CapRiskSteward Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/MixBytes%20CapRiskSteward.pdf) |
| 22 April 2025 | HookTargetStakeDelegator | Security review | MixBytes | [MixBytes HookTargetStakeDelegator Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/MixBytes%20HookTargetStakeDelegator.pdf) |
| 11 March 2025 | GovernorAccessControlEmergencyFactory | Security review | Electisec | [Electisec GovernorAccessControlEmergencyFactory Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/Electisec%20GovernorAccessControlEmergencyFactory.pdf) |
| 18 February 2025 | EPO (PR#78, PR#79) | Security review | Electisec | [Electisec EPO Report](https://github.com/euler-xyz/euler-price-oracle/blob/master/audits/Euler_Price_Oracle_Electisec_Report.pdf) |
| 5 February 2025 | Adaptive IRM | Security review | Electisec | [Electisec Adaptive IRM Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/Electisec%20Adaptive%20IRM.pdf) |
| 4 February 2025 | setLTV | Security review | Electisec | [Electisec setLTV Report](https://github.com/euler-xyz/euler-vault-kit/blob/master/audits/Electisec_setLTV_report.pdf) |
| 20 January 2025 | EVK | Security review | Cantina | [M4rio.eth SetLTV Report](https://github.com/euler-xyz/euler-vault-kit/blob/master/audits/M4rio.eth_setLTV_report.pdf) |
| 2 December 2024 | EVK Periphery - ERC20 Burnable Mintable | Security review | BailSec | [BailSec ERC20BurnableMintable Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/BailSec%20ERC20BurnableMintable.pdf) |
| 29 October 2024 | EVK Periphery - rEUL wrapped locked token | Security review | CDSecurity | [CDSecurity rEUL ERC20 wrapped locked token Report](https://github.com/euler-xyz/evk-periphery/blob/03127c4e0428d993f94afd8fbfb46147d0319991/audits/CDSecurity%20ERC20%20Wrapper%20Locked.pdf) |
| 21 October 2024 | EVK Periphery - CompatCheck Polygon and Avalanche | Security review | yAudit | [yAudit Compatibility Polygon and Avalanche Report](https://github.com/euler-xyz/evk-periphery/blob/a6e08f772228187f97dbb44e615b396e69f17852/audits/yAudit_Euler_Deployment_Polygon_Avalanche_Report.pdf) |
| 18 October 2024 | EVK Periphery - custom liquidator & selector access | Security review | yAudit | [yAudit EVK Custom Liquidator & Selector Access Control Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/yAudit%20EVK%20Custom%20Liquidator%20%26%20Selector%20Access%20Control.pdf) |
| 2 October 2024 | EVK Periphery - rEUL | Security review | yAudit | [yAudit rEUL ERC20 wrapped locked token Report](https://github.com/euler-xyz/evk-periphery/blob/03127c4e0428d993f94afd8fbfb46147d0319991/audits/yAudit%20rEUL%20ERC20%20Wrapper%20Locked.pdf) |
| 20 September 2024 | EVK Periphery Forta Firewall hooks | Security review | yAudit - Forta Firewall Attestation hooks | [yAudit - EVK Periphery - Forta Firewall hooks Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/yAudit%20Euler%20Hook%20Target%20Firewall.pdf) |
| 5 September 2024 | EPO | Security review | yAudit | [yAudit EPO Update review Report](https://github.com/euler-xyz/euler-price-oracle/blob/master/audits/Euler_Price_Oracle_yAudit_OracleUpdate_Report.pdf) |
| 12 August 2024 | Web2 infrastructure | Penetration test | Ruptura | Private report |
| 8 August 2024 | EVK Periphery - Vault Pause Guardian | Security review | yAudit | [yAudit - EVK Periphery - Vault Pause Guardian Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/yAudit%20EVK%20Periphery%20Guardians.pdf) |
| 20 July 2024 | Origami Oracle Adapters | Security review | yAudit | [yAudit Origami Oracle Adapters Report](https://github.com/euler-xyz/origami-oracle-adapters/blob/master/audits/yAudit_origami_oracles.pdf) |
| 8 July 2024 | Euler V2 | Security review | yAudit | [yAudit CodeCompetition Fixes review](https://github.com/euler-xyz/ethereum-vault-connector/blob/master/audits/Euler%20yAudit%20Code%20Competition%20Fixes%20report.pdf) |
| 17 June 2024 | EVK Periphery | Security review | yAudit | [yAudit EVK Periphery Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/yAudit%20EVK%20Periphery.pdf) |
| 14 June 2024 | Synths | Security review | OpenZeppelin | [OpenZeppelin Synths Report](https://github.com/euler-xyz/euler-vault-kit/blob/master/audits/OpenZeppelin_Synths_report.pdf) |
| 9 May 2024 | Reward Streams | Security review | Mixbytes | [Mixbytes Reward Streams Report](https://github.com/euler-xyz/reward-streams/blob/master/audits/Euler%20MixBytes%20report.pdf) |
| 1 May 2024 | Reward Streams | Security review | Hunter Security | [Hunter Security Reward Streams Report](https://github.com/euler-xyz/reward-streams/blob/master/audits/Euler%20Hunter%20Security%20report.pdf) |
| 29 April 2024 | EPO | Security review | ChainSecurity | [ChainSecurity Oracle Report](https://github.com/euler-xyz/euler-price-oracle/blob/master/audits/Euler_Price_Oracle_ChainSecurity_Report.pdf) |
| 22 April 2024 | EVK | Security review | ChainSecurity | [ChainSecurity EVK Report](https://github.com/euler-xyz/euler-vault-kit/blob/master/audits/ChainSecurity_EVK_report.pdf) |
| 22 April 2024 | Euler V2 | Security competition review | Cantina CodeCompetition | [Cantina CodeCompetition Report](https://github.com/euler-xyz/ethereum-vault-connector/blob/master/audits/Euler%20Cantina%20Code%20Competition%20report.pdf) |
| 8 April 2024 | EVC | Security review | ChainSecurity | [ChainSecurity EVC Report](https://github.com/euler-xyz/ethereum-vault-connector/blob/master/audits/Euler%20ChainSecurity%20report.pdf) |
| 8 April 2024 | EVK | Security review | Spearbit | [Spearbit EVK Report](https://github.com/euler-xyz/euler-vault-kit/blob/master/audits/Spearbit_EVK_report.pdf) |
| 8 April 2024 | EPO | Security review | Spearbit | [Spearbit EPO Report](https://github.com/euler-xyz/euler-price-oracle/blob/master/audits/Euler_Price_Oracle_Spearbit_Report_DRAFT.pdf) |
| 8 April 2024 | EVK | Security review | OpenZeppelin | [OpenZeppelin EVK Report](https://github.com/euler-xyz/euler-vault-kit/blob/master/audits/OpenZeppelin_EVK_report.pdf) |
| 8 April 2024 | EPO | Security review | OpenZeppelin | [OpenZeppelin Oracle Report](https://github.com/euler-xyz/euler-price-oracle/blob/master/audits/Euler_Price_Oracle_OpenZeppelin_Report.pdf) |
| 1 April 2024 | Euler V2 | Security review | Spearbit VCISO cmichel - EulerV2 | Report not publicly available |
| 25 March 2024 | Euler V2 | Security review | yAudit | [yAudit Euler V2 Report](https://github.com/euler-xyz/euler-vault-kit/blob/master/audits/yAudit_EVK_report.pdf) |
| 18 March 2024 | EVC | Security review | Omniscia | [Omniscia EVC Report](https://omniscia.io/reports/euler-finance-ethereum-vault-connector-6602c8d3423c1b0018ff01b6/) |
| 18 March 2024 | EVK | Security review | Omniscia | [Omniscia EVK Report](https://omniscia.io/reports/euler-finance-vault-kit-66000e2fe7dba400187a4aed/) |
| 18 March 2024 | EPO | Security review | Omniscia | [Omniscia EPO Report](https://omniscia.io/reports/euler-finance-evk-price-oracles-660812035fc1c30018641b22/) |
| 18 March 2024 | EVC | Security review | OpenZeppelin | [OpenZeppelin EVC Report](https://github.com/euler-xyz/ethereum-vault-connector/blob/master/audits/Euler%20OpenZeppelin%20report.pdf) |
| 7 March 2024 | EVK | Security review | Certora | [Certora EVK Report](https://github.com/euler-xyz/euler-vault-kit/blob/master/audits/Certora_EVK_report.pdf) |
| 19 February 2024 | FeeFlow | Security review | Ottersec - FeeFlow | [Ottersec FeeFlow Report](https://github.com/euler-xyz/fee-flow/blob/main/audits/FeeFlow%20Ottersec%20Report.pdf) |
| 12 February 2024 | FeeFlow | Security review | Team Omega | [Team Omega FeeFlow Report](https://github.com/euler-xyz/fee-flow/blob/main/audits/FeeFlow%20Team%20Omega%20Report.pdf) |
| 6 February 2024 | FeeFlow | Security review | Zellic | [Zellic FeeFlow Report](https://github.com/euler-xyz/fee-flow/blob/main/audits/FeeFlow%20Zellic%20Report.pdf) |
| 5 February 2024 | EVK & EVC Playground | Fuzzing | Victor Martinez Fuzzing Suite | [Fuzzing Suite Report](https://github.com/euler-xyz/euler-vault-kit/blob/master/audits/EnigmaDark_EVK_report.pdf) |
| 5 February 2024 | Euler V2 | Formal verification | Certora Formal Verification | Report not publicly available |
| 30 January 2024 | EVC | Security review | Trail of Bits | [Trail of Bits EVC Report](https://github.com/euler-xyz/ethereum-vault-connector/blob/master/audits/Euler%20Trail%20of%20Bits%20report.pdf) |
| 10 January 2024 | EVC | Security review | Hunter Security | [Hunter Security EVC Report](https://github.com/euler-xyz/ethereum-vault-connector/blob/master/audits/Euler%20Hunter%20Security%20report.pdf) |
| December 2023 | Euler V2 (EVC & EVK) | Security review | Alberto Cuesta Cañada | Report not publicly available |
| 4 December 2023 | EVC | Security review | yAudit | [yAudit EVC Report](https://github.com/euler-xyz/ethereum-vault-connector/blob/master/audits/Euler%20yAudit%20report%20\(EVC\).pdf) |
| 22 November 2023 | EVC | Manual verification | Certora Manual Verification | [Certora EVC Report](https://github.com/euler-xyz/ethereum-vault-connector/blob/master/audits/Euler%20Certora%20report.pdf) |
| 1 October 2023 | Euler V2 | Security review | Spearbit VCISO cmichel\&StErMi | Report not publicly available |
### Read next
* [Monitoring, pause, and upgrade](/security/pause-and-upgrade#monitoring-and-response)
* [Bug bounty](/security/bug-bounty)
## Bug bounty
### Up to $7.5 million for a qualifying finding
Euler runs a live Cantina bug bounty covering the Euler Vault Kit (EVK), Ethereum Vault Connector (EVC), Euler Price Oracle (EPO), supporting components, EulerEarn, EulerSwap, and the web interface.
[View the live bounty, scope, and terms on Cantina](https://cantina.xyz/bounties/4d285eee-602e-440a-845e-25e155cec26a)
### Submitting a finding
Document the affected component, impact, reproduction steps, and any required proof of concept. Submit through the [official Cantina bounty page](https://cantina.xyz/bounties/4d285eee-602e-440a-845e-25e155cec26a) and follow its responsible-disclosure process.
For qualifying emergency action during an active or imminent exploit, review Euler's [SEAL Safe Harbor](/security/seal-safe-harbor).
## EulerEarn security reviews
| Date | Scope | Review type | Reviewer | Report URL |
| ------------ | --------- | ------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------ |
| Aug 12, 2025 | EulerEarn | Audit | Pashov Audit Group | [Pashov Audit Group EulerEarn](https://github.com/euler-xyz/euler-earn/blob/master/audits/Pashov_Audit_Group_report.pdf) |
| Jul 23, 2025 | EulerEarn | Formal verification | Certora | [Certora EulerEarn](https://github.com/euler-xyz/euler-earn/blob/master/audits/Certora_EulerEarn_report.pdf) |
| Jul 1, 2025 | EulerEarn | Audit | Sigma Prime | [Sigma Prime EulerEarn](https://github.com/euler-xyz/euler-earn/blob/master/audits/Sigma_Prime_EulerEarn_report.pdf) |
### Read next
* [Audits](/security/audits)
* [Bug bounty](/security/bug-bounty)
## Pause and upgrade mechanisms
Euler deployments can use factory-level pause and upgrade controls, vault-level governors, or immutable configurations. The available response depends on the contracts and roles selected for that deployment.
The canonical upgradeable EVK factory uses a `FactoryGovernor` to separate pause, unpause, and upgrade authority. Other factories and vaults can use different arrangements, so verify the relevant addresses and roles onchain.
### Factory-level controls
An EVK factory can assign its `upgradeAdmin` to a [`FactoryGovernor`](/build/periphery/factory-governor). In that arrangement:
* `PAUSE_GUARDIAN_ROLE` can install a `ReadOnlyProxy` around the current implementation, causing state-changing calls through affected upgradeable vault proxies to revert while views remain available.
* `UNPAUSE_ADMIN_ROLE` can restore the implementation retained by the latest read-only proxy.
* `DEFAULT_ADMIN_ROLE` can use `adminCall` to call the factory, including calls that change its implementation.
A factory action applies to upgradeable vaults that resolve their implementation through that factory. It does not apply to immutable vaults or contracts outside the factory.
### Vault-level controls
EVK contracts are governance agnostic. A vault's governor can be any address: an EOA or multisig holding direct control over every governable setting, or a purpose-built governance contract with selector-specific, wildcard, timelocked, or emergency permissions. Whether any such controls are used is a choice made by each vault's curator or risk manager, not a protocol guarantee — verify the actual arrangement onchain rather than assuming one. Depending on the configuration, authorized callers may lower LTVs or caps, replace the IRM, or pause selected operations through a hook.
Vault governance and factory governance are separate. The EVault's oracle or router address and unit of account are creation-time proxy metadata. If the configured oracle is a router, its routes can be changed only through that router's own governance.
### Timelocks
Some deployments route governance actions through a `TimelockController`; many do not, and a governor holding direct, undelayed control is a common configuration. Where a timelock is used, its proposer can queue an operation, cancellers can cancel it, and an executor can execute it after the delay. An open executor role allows any address to execute an operation once it is ready; it does not allow that address to create or modify the proposal.
Emergency and selector-specific roles can follow different timing. Review the exact role assignments and permissions rather than assuming a change is delayed at all, or that every change uses the same delay.
### Monitoring and response
Monitoring responsibilities are split. Platform-level monitoring focuses on critical, implementation-level threats to the EVK contracts themselves; a confirmed threat of that kind can lead to a factory-level pause of upgradeable vaults. Monitoring of individual vaults and markets — oracle behavior, governance and role changes, liquidity, positions, and contract events — is the responsibility of each vault's curator or risk manager and of the integrators building on those vaults. Euler does not guarantee or supervise how individual vaults and markets are managed. Alerts should map to a named owner and a response available under the deployed contracts.
A response might include a factory pause for implementation-level issues, a vault-governance action by the vault's own governor, or user and integrator communication. Immutable vaults may have no governor-controlled pause or upgrade path.
For a specific deployment, verify:
1. the factory, implementation, governor, and timelock addresses;
2. current role membership and selector permissions;
3. delays, proposers, cancellers, and executors;
4. emergency actions and whether they bypass a timelock;
5. recent events and pending operations; and
6. the exit, repayment, and liquidation behavior available during a pause.
### Read next
* [Factory Governor](/build/periphery/factory-governor)
* [Governor contracts](/build/periphery/governors)
## SEAL Safe Harbor
Euler has a [SEAL (Security Alliance) Whitehat Safe Harbor registry entry](https://safeharbor.securityalliance.org/database/euler) linking its agreement and onchain registry transaction. The agreement and registry define the covered actions, contracts, chains, recovery addresses, protections, and rewards.
### When It Applies
Use Euler's [bug bounty program](/security/bug-bounty) for responsible disclosure. Safe Harbor is for qualifying action during an active or imminent exploit; it does not authorize routine testing on production systems.
### How It Works
To qualify, a whitehat must follow the agreement and registry requirements, act only within the listed scope, and return rescued assets to the designated recovery address within 72 hours.
### Accountability & Rewards
The registry lists Cantina KYC, a 10% bounty, a $2.5 million individual cap, a $2.5 million aggregate cap, and non-retainability. Review the current registry and agreement before acting.
## Securitize integration reviews
| Date | Scope | Review type | Security firm | Report URL |
| ---------------- | -------------------------- | --------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 21 November 2025 | ERC4626 & Vault Securitize | Security review | yAudit | [yAudit ERC4626 and Vault Securitize Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/yAudit%20ERC4626%20and%20Vault%20Securitize.pdf) |
| 6 November 2025 | ERC4626 & Vault Securitize | Security review | Pashov Audit Group | [Pashov Group ERC4626 and Vault Securitize Report](https://github.com/euler-xyz/evk-periphery/blob/master/audits/Pashov%20Group%20ERC4626%20and%20Vault%20Securitize.pdf) |
### Read next
* [Audits](/security/audits)
* [Bug bounty](/security/bug-bounty)
## EulerSwap security reviews
### EulerSwap live CTF competition
During the [**$500K EulerSwap Live CTF**](https://cantina.xyz/competitions/a188a03f-4631-4b58-82ce-a5818a6df332) in June 2025, no contestant removed the posted USDC/USDT liquidity from the mainnet competition deployment.
### Audit reports
| Date | Scope | Review type | Security firm | Report URL |
| ------------------ | --------- | --------------- | --------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| September 18, 2025 | EulerSwap | Security review | Cantina Managed | [Cantina Managed EulerSwap September 18](https://github.com/euler-xyz/euler-swap/blob/master/audits/report-cantinacode-euler-0901.pdf) |
| May 26, 2025 | EulerSwap | Security review | Cyfrin | [Cyfrin EulerSwap](https://github.com/euler-xyz/euler-swap/blob/master/audits/2025-05-26-cyfrin-eulerswap-v2.0.pdf) |
| May 3, 2025 | EulerSwap | Security review | Cantina | [Cantina Managed EulerSwap May 3](https://github.com/euler-xyz/euler-swap/blob/master/audits/report-cantinacode-uniswap-euler-0422.pdf) |
| March 31, 2025 | EulerSwap | Security review | ChainSecurity | [ChainSecurity EulerSwap](https://github.com/euler-xyz/euler-swap/blob/master/audits/ChainSecurity_EulerSwap_audit.pdf) |
| March 29, 2025 | EulerSwap | Security review | Cantina | [Cantina Managed EulerSwap Mar 29](https://github.com/euler-xyz/euler-swap/blob/master/audits/report-euler-swap-050325.pdf) |
| February 17, 2025 | EulerSwap | Security review | Fuzzland | [Fuzzland EulerSwap](https://github.com/euler-xyz/euler-swap/blob/master/audits/eulerswap-audit-report.pdf) |
### Read next
* [Audits](/security/audits)
* [Bug bounty](/security/bug-bounty)
## Operators
### Introduction
An operator is an address—an EOA or smart contract—that an account owner authorises through the EVC to act for a selected account or sub-account. Operator permission is broad and binary for that account; it is not the same as a limited token allowance.
### Understanding Operators
The operator system lets an account owner authorise an operator address for a specific sub-account. An operator can then perform account actions wherever EVC operator authentication is accepted. The account owner retains owner-only EVC administration, including changing operator authorisation.
### Operators in production: EulerSwap
[EulerSwap](/curate/euler-swap) is built directly on this feature. Each EulerSwap pool is a contract that the liquidity provider installs as an EVC operator for their Euler account; the pool factory refuses to deploy a pool whose operator authorisation is not in place. When a swap executes, the pool uses that operator authority to act on the account — withdrawing supplied inventory from its lending vaults and, where configured, borrowing the remaining output against the account's collateral — so liquidity is provided just-in-time without the pool holding reserves. The owner keeps EVC administration throughout, and revoking the operator is how a pool is decommissioned.
### Potential Features
The operator system enables several other capabilities that can be implemented to enhance the user experience and enable more sophisticated interactions with the protocol:
**Automated Trading Strategies**: Operators could be used to implement automated trading systems that execute trades based on predefined conditions. This could include features like stop-loss orders, take-profit targets, or trailing stops without requiring manual intervention.
**Position Management**: EOAs or smart contracts could be authorized to manage positions, enabling more complex strategies that might involve multiple steps or require precise timing. This would be particularly useful for professional traders or automated trading systems.
**Risk Management**: The system could support automated risk management features like dynamic collateral rebalancing, automated deleveraging during high volatility, or portfolio-wide stop-loss mechanisms.
### Scope and Revocation
**Binary permissions:** Operator permission is binary for each selected sub-account. The operator may perform any account action for which EVC operator authentication is accepted, including actions that move shares, withdraw assets, create debt, or batch calls. This does not transfer owner-only EVC administration, such as changing operator authorization or owner security modes.
**Revocation:** The account owner can revoke operator authorization through the applicable EVC owner action. Revocation stops later authorized actions but does not reverse actions the operator already completed.
**Review requirements:** Verify the operator address, intended sub-account, supported actions, and revocation process before authorizing it. Ordinary account actions can materially change or empty the position.
### Best Practices
* Delegate only the sub-accounts the operator needs.
* Use separate sub-accounts for unrelated operators or strategies.
* Review operator settings periodically and revoke permissions that are no longer needed.
* Prefer services with clear documentation, verifiable contract addresses, and an explained security and revocation model.
* Monitor operator activity as part of monitoring the underlying position.
### Read next
* [Sub-accounts](/learn/sub-accounts)
* [EVC](/build/evc)
* [EVC integration](/build/evc/integration-guide)
## Curators
Curators configure or operate selected vault parameters. Their responsibilities vary by vault type, governance model, and role assignment.
Curator authority depends on the deployed contracts and assigned roles. Parameter and allocation decisions can affect collateral eligibility, LTVs, caps, oracle routes, liquidation settings, liquidity, fees, and user-facing metadata. Users should review each role address and its exact permissions before supplying, borrowing, or using an Earn vault.
### Credit vault risk management
In credit vaults, configured governors or other authorized roles can manage supported parameters that affect depositors and borrowers. The goal is to define collateral and debt relationships that are understandable, monitorable, and consistent with the intended market design.
#### Collateral selection
Collateral selection defines which vault shares can support borrowing from a liability vault. Curators should review asset liquidity, volatility, oracle availability, market depth, legal or access constraints where relevant, and correlation with the borrowed asset. Poor collateral selection can expose depositors to bad debt, especially if the collateral becomes hard to price or liquidate.
#### Loan-to-value management
Once collateral assets are selected, the role authorized by the vault sets loan-to-value (LTV) ratios. These ratios come in two forms: the maximum LTV, which caps how much users can borrow, and the liquidation LTV, which determines when a position becomes eligible for liquidation. The liquidation LTV is typically set higher than the maximum LTV, providing a buffer against immediate liquidations even if prices move against borrowers who have taken out maximum loans.
Where authorized, a role can adjust some LTV ratios over time through LTV ramping. Ramping can make liquidation LTV changes gradual, but the chosen duration and target still affect borrowers. Users should monitor pending or active LTV changes.
#### Pricing and oracle selection
Pricing affects borrow capacity, liquidations, and vault accounting. The configured oracle route values both collateral and debt assets for the controller's checks. While USD is common as a unit of account, other units such as ETH may be used when appropriate for the assets involved.
Euler's oracle-agnostic design lets the authorized role configure supported oracle providers and router configurations. Examples include Chainlink, Pyth, Redstone, Chronicle, and custom oracle routes where appropriate. Each route has tradeoffs, including data freshness, liquidity sensitivity, manipulation resistance, and operational complexity.
#### Supply and borrow caps
To manage risk exposure effectively, curators can implement supply and borrow caps. These caps limit how much of an asset can be deposited or borrowed, providing an additional layer of risk control. While these caps can be temporarily exceeded within a transaction batch, if a cap remains exceeded when checks run, the system only allows operations that do not increase the violation relative to the start of the batch.
#### Advanced controls
Available controls depend on the vault contracts and assigned roles. A governor may configure supported vault parameters and a hook target; the hook enforces only its programmed checks. Pause, guardian, curator, allocator, fee-recipient, cap, oracle, and other powers may belong to different addresses. Document each deployed role and timelock instead of assuming that one “risk curator” controls every capability.
### Earn vault risk management
In Earn vaults, curators manage which strategies can receive allocations and may set strategy caps or related constraints. Earn vaults can allocate to Euler lending vaults and, where configured, other ERC-4626 strategies.
#### Strategy management
Curators can enable or disable specific strategies, influencing where deposits may be allocated. They should monitor strategy risk, liquidity, caps, rates, withdrawal behavior, and market conditions before making allocation changes.
#### Liquidity management
Earn vault configuration can define supply and withdrawal queues. These queues affect how deposits are allocated and how withdrawals are sourced. Liquidity in an Earn vault depends on the idle balance, strategy liquidity, caps, and withdrawal queue behavior.
#### User protection
Timelocks can give users time to observe pending role or parameter changes. Timelocks do not make a vault risk-free, but they can make governance changes easier to monitor.
### Security considerations
Role labels do not grant authority beyond the deployed contracts, but authorized parameter and allocation changes can materially affect user outcomes. Poor collateral selection, overly aggressive LTVs, weak oracle routes, high caps, insufficient liquidity, or unclear governance controls can increase bad debt, liquidation, or withdrawal risk.
Before using a curator-managed vault, review:
* Curator or governor identity.
* Role permissions and timelocks.
* Accepted collateral and connected markets.
* Oracle routes and fallback behavior.
* Supply caps, borrow caps, borrow LTV, and liquidation LTV.
* Liquidation discount and cool-off settings.
* Earn vault allocation queue, withdrawal queue, strategy caps, and fees.
* Recent or pending parameter changes.
For curator workflows, use [Curate](/curate).
## Sub-accounts
The Ethereum Vault Connector (EVC) gives one wallet 256 account IDs, each represented by a derived address. A sub-account can hold its own collateral, controller, and liability state while remaining under the same controlling wallet.
This lets users keep positions separate without maintaining another signing key and native gas balance for each one. For example, a user can keep a USDC/WETH borrow in one sub-account, a separate Multiply position in another, and authorize an operator for only one of them. EVC-aware integrations can also batch supported actions across sub-accounts.
:::warning
**Never send regular assets directly to a sub-account address.** Apart from the primary account (ID 0, the wallet's own address), sub-account addresses have no private key, so no transaction can ever be signed from them: ordinary ERC-20 tokens or ETH transferred straight to a sub-account address are permanently unrecoverable. The exception is EVK vault share tokens, which the owner can move out of a sub-account through the EVC. Fund sub-accounts only through the app or an EVC-aware integration.
:::
### Why use separate sub-accounts?
* Keep collateral and debt for unrelated positions separate.
* Use different controllers or collateral sets without combining every position.
* Grant an [operator](/learn/operators) access to one position without authorizing it for all positions.
* Manage several positions from one wallet and, where supported, batch their actions through the EVC.
Sub-accounts separate account state, but they do not create a new owner. A compromised owner or shared operator can still affect every account it controls, and different positions may still share vault, oracle, and market dependencies.
### Important considerations
**Derived account identities**: Sub-account addresses are derived EVC account identities. They are intended for EVC-aware vault and external-contract flows, including use as an on-behalf-of account. Do not send ordinary ERC-20 tokens directly to a derived sub-account address, and do not assume a non-EVC-aware contract recognizes its relationship to the owner. Use an integration that explicitly supports EVC sub-accounts.
**Position isolation:** Review each position separately and also consider the wallet's total exposure across sub-accounts.
**Batched actions:** The EVC can batch compatible actions, but token approvals, controller rules, authentication, and final account checks still apply.
### Read next
* [Euler V2 introduction](/introduction)
* [Build](/build)
* [Curate](/curate)
## Vault types
Euler uses different vault configurations for different jobs. An EVK vault can be governed, use the canonical escrow configuration, or be finalized without an active vault governor. An EulerEarn vault holds one underlying asset and allocates it across configured ERC-4626 strategies.
These names describe how a vault is intended to operate; they do not establish who controls every connected contract. Authority is deployment-specific. Review the live vault, factory and implementation, oracle router, collateral vaults, hooks, and assigned roles before deciding which settings can change.
### Quick comparison
| Type | What it does | Deployment-specific authority to review | What to check |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Governed EVK vault | Lends one asset under parameters that can be managed after deployment. | The active vault governor and any separate roles governing connected contracts. | Governor, caps, collateral list, oracle, IRM, LTVs, liquidation settings, hooks, fees, and timelocks. |
| Escrow vault | Holds one asset in the canonical non-borrowable, ungoverned EVK configuration so its shares can be used as collateral elsewhere. | There is no vault governor. Governors of liability vaults set the LTVs, oracle, and liquidation terms applied to its shares. | Perspective verification, underlying asset, accepting liability vaults, and their LTVs. |
| Finalized or ungoverned vault | Has no active vault governor to change EVault-governed parameters. | Any remaining factory upgrade authority and governance of dependencies such as oracle routers or connected collateral vaults. | Finalization status, implementation, collateral, oracle route, caps, liquidity, and liquidation behavior. |
| EulerEarn vault | Accepts one asset and allocates it across enabled ERC-4626 strategies. | The Owner, Curator, Allocators, Guardian, factory checks, and any strategy-specific roles. | Strategies, caps, supply and withdrawal queues, role permissions, liquidity, fees, timelocks, and withdrawal behavior. |
### Governed EVK vaults
A governed EVK vault has an active governor that can update supported vault parameters. Depending on the deployment, those parameters can include collateral relationships, supply and borrow caps, the interest-rate model, oracle configuration, fees, hooks, or liquidation settings.
The governor controls only the actions authorized by the deployed EVault. Connected contracts can have different owners or governors. Before using a governed vault, identify each role address, its exact permissions, applicable timelocks, and recent or pending changes.
### Escrow vaults
An escrow vault is a specific configuration verified by the Escrowed Collateral Perspective, not a generic name for every vault with borrowing disabled. A canonical escrow vault:
* Is the perspective-recognized singleton escrow vault for its underlying asset.
* Its underlying asset is not another vault deployed by that EVK factory.
* Has no vault governor, oracle, unit of account, interest-rate model, supply or borrow caps, hooks, configuration flags, fee receiver, collateral LTVs, liquidation discount, or liquidation cool-off time.
These properties make it a simple, reusable collateral container. It cannot be borrowed from and does not earn borrower-paid lending interest. Each liability vault that accepts the escrow shares has its own governor, LTVs, oracle, and liquidation settings.
### Finalized or ungoverned vaults
A finalized or ungoverned vault has no active vault governor, so the parameters controlled by EVault governance cannot be updated. Changing those parameters generally requires a new vault deployment.
This does not make every dependency or market condition immutable. A separately governed oracle router, collateral vault, or hook can retain its own authority. A vault deployed behind an upgradeable beacon can also retain factory-level implementation risk unless that authority is removed for the specific deployment. Oracle prices, liquidity, collateral volatility, utilization, adaptive rate behavior, and liquidation conditions can continue to change.
### EulerEarn vaults
EulerEarn vaults pool one underlying asset into one ERC-4626 share position and allocate capital across configured ERC-4626 strategies. Strategies can include Euler lending vaults and, where enabled, external ERC-4626 vaults.
Review an Earn vault as both a share vault and an allocation system. Check its Owner, Curator, Allocators, Guardian, factory requirements, enabled strategies, caps, supply and withdrawal queues, fees, timelocks, `lostAssets`, and available withdrawal liquidity. Each underlying strategy adds its own contracts, governance, oracle, liquidity, and market dependencies.
### Labels and discovery
Vault classifications and metadata are maintained by the Euler Labs team in the [`euler-labels`](https://github.com/euler-xyz/euler-labels) repository and served through [public known-vault endpoints](/build/data-querying/perspectives).
:::warning[Known does not mean safe]
"Known" is discovery metadata, not a safety endorsement or ongoing monitoring. Euler Labs reviews the initial configuration at listing. External governors can change governed-vault parameters; finalized and canonical escrow vaults have no active vault governor. Inspect live roles and configuration before using a vault.
:::
### Who Runs the Markets
Euler Labs does not run or govern any governed EVK vault. External governors, curators, and risk managers manage governed vaults; finalized, ungoverned, and canonical escrow vaults have no active vault governor. Use the [known-vault endpoints](/build/data-querying/perspectives) and live onchain roles to identify who controls each vault.
### Read next
* [Euler V2 introduction](/introduction)
* [Vault metadata](/build/data-querying/perspectives)
* [Liquidations](/learn/liquidations)
* [Risk curators](/learn/risk-curators)
## Vaults
Vaults are the building blocks of Euler. An **EVK vault** creates a lending market for one underlying asset under its own configuration. An **EulerEarn vault** gives a user one deposit position while allocating the same underlying asset among enabled strategies. Both issue ERC-4626 shares, but they solve different problems.
Use an EVK vault when you want to supply directly to a particular lending vault, borrow from it, or use its shares as accepted collateral in another vault. Use an Earn vault when you prefer one share position whose configured roles manage allocation across a set of strategies.
### EVK vaults
EVK vaults extend [ERC-4626](https://eips.ethereum.org/EIPS/eip-4626) with lending and borrowing functionality. Each vault holds one underlying asset; suppliers receive vault shares, and borrower interest accrues to the vault subject to its configured fees. Unlike many strategy vaults, an EVK vault's core yield source is borrowing from that vault rather than an external investment strategy.
:::note
While vaults can be interacted with directly, the recommended approach is to use the [**Ethereum Vault Connector (EVC)**](/build/evc) as the primary entry point. The EVC provides batching, sub-accounts, simulations, and other features for multi-step account flows.
:::
The architecture of an EVK vault consists of several key components working together:
* **Underlying Asset**: The ERC-20 token held by the vault, with each vault holding exactly one type of asset
* **EVault**: The primary entry point contract implementing common vault logic:
* Tracks deposits and borrows
* Validates position health
* Permits liquidations
* Uses static modules for code organization
* **Price Oracle**: Uses the vault's configured oracle route to value collateral and liability for onchain account checks
* **IRM (Interest Rate Model)**: Determines borrowing rates to incentivize or discourage borrowing based on market conditions
* **ProtocolConfig**: Global protocol-level configuration supporting fee destinations and splits. Euler protocol fees are currently set to zero.
* **DToken**: A read-only ERC-20 interface for debt amounts, making debt modifications visible in block explorers and trackable by tax-accounting software
#### Governance and risk management
EVK vaults can be either governed or finalized (ungoverned), offering different approaches to risk management:
Governed vaults are actively managed by a governor or risk curator who can adjust parameters like accepted collateral, borrowing limits, and pricing models as market conditions evolve. This approach can reduce the amount of parameter management a user performs directly, but it also means users depend on the curator's decisions and operating process.
Finalized vaults have their vault-level governor revoked, so EVault parameters controlled by that governor can no longer be changed. Other authority is deployment-specific: a separately governed oracle router or connected collateral vault can still change, and a vault deployed behind an upgradeable beacon can still depend on the factory's upgrade administrator. Review the deployed contracts and every connected role before treating a vault as fixed.
### Earn vaults
Earn vaults are designed for users who want one position with allocation across configured strategies instead of manually moving assets among individual lending vaults or other ERC-4626 strategies. Built on the ERC-4626 standard, they accept one deposited asset and issue shares that represent the user's claim on the Earn vault.
Curators and allocators manage the strategy set, caps, queues, rebalancing, and liquidity plan within the vault's configured permissions. This delegates day-to-day allocation decisions while keeping allocations and role addresses visible onchain. Users still need to choose the Earn vault and evaluate its manager, strategies, fees, and withdrawal liquidity.
#### Key features
Earn vaults provide a single deposit and withdrawal interface while allocation happens inside the vault. Configured roles can manage allocations only through actions authorized by the deployed contracts. Outcomes still depend on strategy performance, fees, liquidity, allocation decisions, role permissions, and market conditions.
### Vault composition
One of Euler's main vault design features is the ability to compose vaults together. By linking EVK vaults as collateral for one another, creators can design various forms of markets. These can range from simple isolated collateral-debt pairs to complex, cross-collateralized clusters.
Risk curators and asset managers can layer Earn vaults on top of EVK vaults to allocate deposits across selected strategies. This composability enables more complex products, but each layer adds dependencies that users and curators should review.
For more detailed information about the implementation and technical specifications, please refer to the [Euler Vault Kit repository](https://github.com/euler-xyz/euler-vault-kit).
## Hooks
Hooks are optional policy checks attached to an EVK vault. They let a vault apply additional rules to selected operations—such as deposit, withdraw, transfer, borrow, repay, or liquidation—without changing the vault's core accounting logic. Common uses include access control, emergency pauses, exposure limits, and other market-specific invariants.
A vault's hook configuration contains a **hook target** contract and a bitfield identifying the **hooked operations**. When a selected operation runs, the vault calls the hook target with the operation's calldata and caller context. If the hook returns successfully, the vault continues; if it reverts, the entire operation reverts. Operations not selected in the bitfield bypass the hook. A separate vault-status hook can check post-transaction conditions when the EVC completes a batch.
The hook target becomes part of the vault's security and availability boundary. Users and integrators should review which operations are hooked, the target's code and privileged roles, whether it can be upgraded or paused, and whether a failure could block repayments, withdrawals, or liquidations.
### Common patterns
Access policyPermissioned deposits or borrows
Restrict selected actions to approved users, institutions, market makers, or borrowers with an assigned credit line.
A hook can enforce an onchain allowlist or credential state, but it does not itself verify identity or establish legal eligibility.
Emergency responsePause or circuit breaker
Block risky operations during an oracle incident, liquidity stress event, exploit response, or asset-specific disruption.
Design pauses narrowly when possible so de-risking actions, such as repay, can remain available.
Market invariantUtilization or exposure caps
Run a post-condition check at vault status time to prevent utilization, exposure, or concentration from moving beyond a configured bound.
Useful for utilization ceilings, per-account limits, issuer exposure, or collateral-count limits.
Position qualityMinimum debt or dust prevention
Reject transactions that would create positions too small to monitor, repay, or liquidate economically.
Avoid broad rules that accidentally block repayments, liquidations, or account cleanup flows.
Permissioned assetRWA transfer and redemption controls
For tokenized asset markets, hooks can enforce specified onchain conditions supplied by an allowlist, credential contract, issuer, or other system.
Whether the condition source satisfies KYC, KYB, sanctions, accreditation, jurisdiction, issuer, or transfer-agent requirements depends on the offchain process and responsible parties. A hook does not itself establish legal or regulatory compliance.
### Designing hook policies
Hook policies should be specific about which operation they control and what happens when the policy fails. Common patterns include:
* **Deposit-only restrictions**: allow anyone to withdraw or repay, but restrict new deposits or borrows to approved accounts.
* **Borrow restrictions**: allow public supply while limiting debt creation to approved borrowers or configured credit lines.
* **Transfer restrictions**: restrict vault-share transfers when the share token represents exposure to a permissioned or RWA-backed product.
* **Status-check restrictions**: enforce post-transaction invariants such as utilization ceilings, exposure limits, or per-account concentration limits.
* **Emergency restrictions**: temporarily block risky actions while allowing de-risking actions such as repay or withdraw where appropriate.
Operators should test hooks against normal user flows, liquidations, EVC batches, sub-accounts, and integrator assumptions. A hook that is too broad can accidentally block required actions or make a vault behave differently from a standard ERC-4626 integration.
### Implementation details
When a hooked operation runs, the vault calls the hook target with the same `msg.data` and trailing caller context. Ordinary operation hooks receive the EVC-authenticated caller; the final vault-status hook receives `address(evc)` and therefore carries no authenticated-account identity in that trailer. The hook target must satisfy `IHookTarget.isHookTarget()`; it can handle selected selectors in explicit functions or a fallback and return successfully or revert. It does not need to implement the full vault interface.
For more detailed information about the implementation and examples, please refer to the [EVK Periphery repository](https://github.com/euler-xyz/evk-periphery/tree/master/src/HookTarget).
### Read next
* [Advanced concepts](/introduction)
* [RWA Vaults](/build/rwa-vaults)
* [Hooks and custom logic](/curate/vaults/evk/hooks-custom-logic)
* [Build](/build)
* [Curate](/curate)
## Interest Rate Models
Interest rates are how Euler balances lenders who want yield with borrowers who want liquidity. Borrowers pay interest on outstanding debt, lenders receive yield from that interest, and each vault uses its configured Interest Rate Model (IRM) to decide the current borrow rate.
The most important input is usually utilization: how much of the supplied liquidity is currently borrowed. When utilization rises, liquidity becomes scarcer, so borrowing normally becomes more expensive.
### The common pattern
Vault stateSupply, borrows, utilization, and the current point in time.
Interest Rate ModelThe vault's configured rule for turning state into a borrow rate.
Market ratesBorrow cost, lender yield, and any configured vault-level fee.
### IRM types
Euler supports several IRM styles. The diagrams below use utilization on the horizontal axis and borrow rate on the vertical axis, except the cyclical model, which changes by time instead of utilization.
Linear KinkGentle until the kink, steep after it
Rates climb steadily while a vault has normal spare liquidity. After the kink, the slope gets much steeper to discourage over-utilization.
Low utilizationKinkHigh utilization
Linear KinkyA smoother curve with aggressive tail risk pricing
Rates still respond to utilization, but the post-kink region bends upward. The shape parameter controls how hard the rate accelerates near full utilization.
Linear startShapeSteeper tail
Adaptive CurveThe curve moves when utilization stays off target
The vault has a target utilization. If utilization stays above target, the model moves rates up over time. If it stays below target, rates drift down within configured bounds.
Below targetTargetAbove target
Fixed Cyclical BinaryTwo fixed rates that alternate on a schedule
This model is time-based rather than utilization-based. It switches between a primary rate and a secondary rate for special market designs.
Primary rateTimeSecondary rate
The comparison above summarizes the supported model shapes. For constructor parameters, units, and deployment checks, use [Interest-rate models](/curate/interest-rate-models).
### Fee structure
Euler does not currently charge protocol fees. In April 2026, Fee Flow was turned off and Euler protocol fees were set to 0% across live and future deployments. The DAO can reintroduce protocol fees through future governance. See [Reduce Euler Protocol Fees to Zero](https://forum.euler.finance/t/proposal-reduce-euler-protocol-fees-to-zero/1835/1).
Curators and vault governors can still configure vault-level fees where supported by the vault. For EVK vaults, the `interestFee` parameter can allocate a portion of borrower interest to the configured fee receiver.
EVK interest fees are denominated in vault shares. This means that unwithdrawn curator fees continue to participate in changes to the vault's asset-per-share value.
### Rate dynamics in practice
For utilization-responsive IRMs, higher borrowing demand can produce the following feedback loop:
1. Utilization increases
2. Interest rates rise
3. Borrowers face higher costs
4. Lenders earn higher yields
5. If a vault-level fee is configured, the fee receiver accrues more fees
The loop can continue until supply, borrowing, or market conditions establish a new equilibrium. Time-based models such as Fixed Cyclical Binary do not derive their rate from utilization.
### Read next
* [APY](/use/annual-percentage-yield)
* [ROE](/use/return-on-equity)
* [Rewards](/use/rewards)
* [Price Oracles](/learn/price-oracles)
## Liquidations
Euler's standard liquidation mechanism is among the most efficient in DeFi because it avoids paying a large fixed liquidation bonus. Its reverse Dutch auction starts at zero discount at the liquidation threshold and increases linearly only as health worsens, allowing competition to clear positions at the lowest bonus the market will accept.
### Low bonuses through price discovery
The auction is the main source of efficiency. Position transfer provides an additional capital-efficiency advantage for liquidators.
Reverse Dutch auctionThe bonus starts at zero
Euler does not grant a large fixed bonus. The discount starts at zero at the threshold and rises linearly with the health shortfall until a liquidator executes or the configured maximum is reached.
Zero at thresholdLowest viable bonusMaximum cap
Additional efficiencyDebt and collateral move together
After the auction determines the bonus, the liquidator inherits selected debt and receives discounted collateral in one operation. No full repayment asset is required upfront.
No upfront repaymentPosition movesManage debt afterward
Unlike a fixed-bonus system, Euler does not overpay liquidators for positions that are only slightly unhealthy. Competition can settle them close to the threshold with minimal collateral loss, while deeper shortfalls offer progressively more incentive. Position transfer then lowers the capital required to execute.
### How it works
Euler compares the account's risk-adjusted collateral with its liability:
```text
health = risk-adjusted collateral value / liability value
```
When risk-adjusted collateral no longer exceeds liability, the account is eligible for liquidation. A displayed health value may be rounded, so raw values and transaction simulation are more reliable near the threshold.
During liquidation:
1. The liquidator chooses a liability and an enabled collateral asset.
2. The liquidator takes over some or all of the account's debt.
3. The liquidator receives collateral at a discount that increases as health falls, up to the vault's configured maximum.
4. The transfer is capped by the debt and collateral actually available, and the liquidator's resulting account must pass its required checks.
The liquidator must enable the liability vault as a controller and enable the received vault shares as collateral. Because the available collateral caps the transaction, a liquidator cannot receive more collateral than the unhealthy account holds.
### What affects the outcome
* **Liquidation LTV** determines when collateral no longer sufficiently covers the debt.
* **Maximum liquidation discount** limits the incentive available to liquidators.
* **Cool-off time**, when configured, delays liquidation after the account's last successful status check.
* **Market liquidity** should be checked for both the collateral and debt assets. Liquidators need to sell or hedge received collateral and manage or repay inherited debt; thin liquidity can make liquidation unattractive even when an account is eligible.
* **Oracle prices, gas, and slippage** affect whether a liquidation is practical and profitable.
If liquidation exhausts an account's collateral and qualifying debt remains, the vault can socialize the remaining loss across depositors only when that behavior is enabled and the contract's conditions are met.
:::warning
Oracle values may differ from secondary-market prices. Borrowers should keep a safety margin above the liquidation threshold and understand the oracle route, liquidation LTV, maximum discount, and available liquidity for their position.
:::
### Liquidation bot
A liquidation opportunity is not guaranteed profit. Liquidators must account for the inherited debt, collateral liquidity, oracle behavior, gas, slippage, and the health of their resulting account.
Developers can start with the [liquidation bot guide](/build/liquidation-bot), which links to Euler's open-source liquidation infrastructure and EVC flow.
### Read next
* [Review borrow risk](/use/borrow-risk)
* [Portfolio and liquidation risk](/use/portfolio#liquidation-risk)
* [Markets](/learn/markets)
## Markets
A market on Euler is not one shared pool with one fixed risk model. It is a set of explicit vault relationships. The liability vault acting as controller decides which vault shares it accepts as collateral and applies the oracle route, LTVs, caps, and account checks for debt in that vault.
This makes Euler markets flexible. A market can be a simple isolated pair, a multi-collateral borrow market, or a cross-collateralized cluster where several vaults both lend and serve as collateral.
### How markets fit together
VaultsEach vault holds one underlying asset and can define supply, borrow, cap, fee, oracle, and governance settings.
RelationshipsCollateral and borrow links define which vaults can support debt in other vaults.
PositionsUsers supply, borrow, and manage collateral while the EVC coordinates the applicable controller checks.
The [Ethereum Vault Connector](/build/evc) coordinates authenticated calls, batching, controllers, collateral, operators, and sub-accounts. Solvency is enforced by the applicable controller vault's checks; the EVC does not create borrowing relationships or guarantee solvency independently.
### Market designs
The diagrams below show common market shapes. Green arrows show collateral support, amber arrows show borrowing direction, and dashed lines represent extra dependencies that can improve capital efficiency while increasing review requirements.
Simple pairOne collateral vault, one borrow vault
The most isolated design. One asset backs borrowing from one lending vault, which keeps the market easy to reason about.
ETH collateral vaultPairUSDC borrow vault
Rehypothecated pairBoth vaults can lend and back borrowing
Each side can be used as collateral for the other side. Supplied assets can earn yield while also supporting a borrow position.
Vault ATwo-wayVault B
Multiple collateralMany collateral vaults support one borrow vault
A single lending vault can accept several collateral assets, reducing liquidity fragmentation and creating more borrowing options.
ETH, DAI, UNICollateral setUSDC borrow vault
Cross-collateralized clusterSeveral vaults can lend and collateralize each other
This is more capital-efficient, but risk can travel across the cluster if one asset, oracle, or vault configuration fails.
ETHClusterstETH / USDC
Custom marketMarket creators can compose vaults in many shapes
Euler can connect new vaults to existing vaults, isolate specific assets, or create specialized clusters. Each added connection should be reviewed for caps, LTVs, oracles, liquidity, hooks, monitoring, and governance.
New vaultsComposable linksExisting markets
### What to review
Before using or launching a market, review the relationships between vaults:
| Area | Why it matters |
| ----------------------------- | ----------------------------------------------------------------------- |
| Collateral links | Define which assets can support borrowing and where risk can travel. |
| LTVs and liquidation settings | Determine borrowing capacity and liquidation behavior. |
| Oracles | Price collateral and debt for account health checks. |
| Caps | Limit supply or borrow exposure in a vault. |
| Liquidity | Affects withdrawals, borrowing availability, and liquidation execution. |
| Governance and monitoring | Determine who can update parameters and respond to market changes. |
### Creating a market
To learn how markets work in more technical detail and how to deploy your own versions of any of those described here, visit [Curate](/curate). You'll find guides on configuring vault parameters, adding custom hooks, implementing advanced functionality, and governing vault risk.
## Price Oracles
Price oracles convert token balances into a common unit of account for collateral valuation, borrow capacity, and liquidation checks.
Oracle flowFrom market prices to your position health
Price sourcesMarket feeds, exchange rates, and configured reference prices publish values for assets.
Oracle routeEuler follows the route selected for the vault and converts assets into a common reference.
Your positionThe configured vault oracle values collateral and liability for borrow-capacity and liquidation checks.
Collateral valueWhat your supplied assets count for
Debt valueWhat your borrowed assets count against
Health checksWhether the account remains above liquidation thresholds
### Why prices matter
Oracle prices affect the numbers users see and the rules the protocol enforces.
| Area | What the oracle helps determine |
| ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| Collateral value | How much your supplied collateral is worth for a specific market |
| Debt value | How much your borrow position is worth in the same reference terms |
| Borrow capacity | Whether you can borrow more without crossing the market's limits |
| Liquidation checks | Whether a position has fallen below the required collateral level |
| Informational prices in an interface may use different sources from the vault's onchain oracle. | |
### Adapters, providers, and routers
The oracle system is modular, so it can support additional price sources without changing vault logic. The Euler Price Oracle library separates two roles:
* **Adapters** connect to one external feed or onchain pricing system and normalize its output. Adapters in the library are immutable, ungoverned, bidirectional contracts with observable configuration.
* **`EulerRouter`** maps asset pairs to providers, can resolve approved ERC-4626 shares through `convertToAssets`, and can send unresolved pairs to a fallback provider. Its configuration can remain governed or be finalized by revoking its governor.
The router's fallback is not automatic failover for a broken primary feed. It is consulted only when no pair-specific provider resolves the request after any configured vault-share conversion. If a configured provider reverts, the router propagates that error rather than switching to the fallback.
The library supports feeds such as Chainlink, Chronicle, Pyth, and RedStone, as well as onchain and rate-based sources. Curators deploy adapter instances for the feeds their markets need — the [Oracle Deployer](https://oracle-deployer.euler.finance) supports the available adapter types; see the [Euler Price Oracle repository](https://github.com/euler-xyz/euler-price-oracle) for the implementations.
### Route examples
A vault requests a quote in its configured unit of account. The router selects the price source for that asset pair.
Case 1Direct feed
A major asset can often be priced from a direct provider route, such as ETH to USD.
Check the provider, heartbeat, staleness behavior, and unit of account.
Case 2Vault share pricing
If collateral is a vault share, the route first converts shares into the underlying asset value.
Check what drives the share exchange rate and whether the share vault has its own risks.
Case 3CrossAdapter route
A CrossAdapter can chain two bidirectional providers through a shared asset.
Check both providers and the shared asset. CrossAdapter returns mid-point quotes and does not support distinct bid/ask pricing.
### Price sources are not all the same
Markets can use different pricing approaches based on their assets and risk model.
| Pricing approach | Plain-English meaning | User-facing trade-off |
| ------------------------- | ------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------- |
| Market-based prices | Prices are informed by active markets and liquidity. | They can track current markets closely, but may move quickly during volatile periods. |
| Reference or fixed prices | A configured reference is used, such as treating a stable asset as close to one dollar. | This can reduce noise, but may lag reality if the asset moves away from the reference. |
| Exchange-rate prices | A token is valued through its relationship to another asset, such as a share token and its underlying asset. | This is useful for yield-bearing or wrapped assets, but users should understand what drives the exchange rate. |
| Derived routes | A price is calculated through one or more intermediate assets. | This can make more markets possible, but each step adds a dependency. |
### Unit of account
A unit of account is the common reference used to compare collateral and debt. It may be USDC, ETH, WBTC, or another asset. The oracle route converts both sides of a position into that unit before borrow capacity and liquidation checks are evaluated.
### ERC-4626 share pricing
`EulerRouter` can price an ERC-4626 share by calling `convertToAssets`, then routing from the underlying asset to the requested quote asset.
Only vaults with suitable exchange-rate accounting should use this path. ERC-4626 does not require `convertToAssets` to resist manipulation, and its result does not account for liquidity, fees, slippage, or withdrawal restrictions.
### CrossAdapter
`CrossAdapter` chains two providers through a shared asset. For example, it can quote `wstETH/USD` through `wstETH/stETH` and `stETH/USD`. Both providers must support both directions. `CrossAdapter` uses `getQuote` and does not provide separate bid and ask amounts.
### What users should check
* Which asset is used as collateral and which asset is borrowed?
* What oracle route or price source is shown for that pair?
* Does the price source follow fast-moving market prices, a configured reference, or an exchange rate?
* How much room does the position have before liquidation?
* Is the market curated, and who can update parameters such as oracle routes or risk settings?
### When prices can feel different
Vault oracle prices can differ from exchange or aggregator prices because of update schedules, reference prices, exchange-rate routes, or conservative risk settings. Check the vault's configured route when evaluating collateral values and borrow limits.
### For builders and curators
Inspect configured routes onchain with the [Lens contracts](/build/data-querying/lens-contracts), use the [Deploy Oracle Router](/curate/deploy-oracle-router) guide to configure them, and see the [Euler Price Oracle repository](https://github.com/euler-xyz/euler-price-oracle) for implementation details.
## DAO proposals
Euler governance can use several systems, each with a different role:
1. **Forum:** public discussion and review.
2. **Snapshot:** offchain signed voting under the Euler space's current strategies and rules.
3. **Safe, timelock, or governor execution:** the transaction that changes contract state or moves assets.
A Snapshot result normally records an offchain governance signal. Onchain execution is a separate step unless the proposal uses a specifically configured execution module.
### Create a proposal
* Open a [forum](https://forum.euler.finance/) thread describing the motivation, requested actions, risks, and executable calldata where applicable.
* Check the live [Euler Snapshot space](https://snapshot.org/#/s\:eulerdao.eth) for the current proposal threshold, voting strategies, quorum, voting period, and delegation behavior.
* Identify the Safe, governor, timelock, module, or other executor that would carry out the decision.
* Create the proposal in the system appropriate to that decision.
* After voting, link the execution transaction. If no transaction follows, label the result as a signaling vote.
### Read next
* [DAO treasury](/euler-dao/treasury)
* [EUL overview](/EUL/overview)
## Treasury
The DAO holds EUL tokens in the Treasury. EUL token holders can participate in governance, while transactions from the Treasury require approval under its multisig signing policy.
The address for the Treasury is: [0xC7C5aFDB61e08BE3e2FB09098412b5706EB5c550](https://etherscan.io/address/0xC7C5aFDB61e08BE3e2FB09098412b5706EB5c550).
### New issuance
The [Ethereum EUL token contract](https://etherscan.io/address/0xd9fcd98c322942075a5c3860693e9f4f03aae07b#code) allows its `ADMIN_ROLE` holder to mint 2.718% of total supply no more than once every 365 days. Minted tokens are sent to the address returned by the contract's `treasury()` function.
That address is the Legacy Treasury: [0x25Aa4a183800EcaB962d84ccC7ada58d4e126992](https://etherscan.io/address/0x25Aa4a183800EcaB962d84ccC7ada58d4e126992).
### Read next
* [EUL overview](/EUL/overview)
* [DAO proposals](/euler-dao/proposals)
* [Fee Flow](/EUL/fee-flow)
## Attack vectors
This page is a non-exhaustive threat-review framework, not a security certification or complete launch checklist. For each dependency, document the failure mode, tests, monitoring, mitigations, and incident response for the exact deployment.
### Oracle manipulation and stale prices
A manipulated, stale, unavailable, incorrectly scaled, or misrouted oracle can distort borrowing power and liquidation. Test route precedence, decimals, update cadence, stale-data behavior, bounds, fallbacks, and governance changes. Monitor every dependency in the configured quote path.
### ERC-4626 conversion and donation attacks
Share-price conversion can be manipulated or economically unrealizable. `convertToAssets` can omit redemption liquidity, fees, slippage, gates, and user restrictions. Test donation/inflation scenarios, rounding at small supply, nested-vault recursion, and stressed redemption before using share conversion in solvency pricing.
See [Donation attacks](/curate/vaults/evk/donation-attacks) and [Oracle router configuration](/curate/deploy-oracle-router).
### Malicious assets, hooks, and callbacks
Tokens can have transfer fees, rebases, callbacks, nonstandard return values, blacklists, freezes, or upgradeable behavior. Hooks can revert operations, call external systems, or introduce new state and availability dependencies. Test deposits, withdrawals, borrows, repayments, transfers, liquidations, and EVC batches against each relevant behavior.
### Governance and role compromise
A compromised or misconfigured governor, guardian, operator, allocator, or oracle-router role can change only its authorized settings, but those settings may materially affect users. Inventory permissions, timelocks, emergency bypasses, ownership, upgrade paths, and signer security. Monitor role and parameter changes from deployed state.
### Caps, LTVs, IRMs, and liquidation settings
Incorrect units or assumptions can create excessive borrowing power, extreme rates, unavailable liquidity, or ineffective liquidation. Simulate boundary utilization, oracle moves, cap exhaustion, LTV ramps, rate extremes, cool-off periods, and maximum liquidation discounts. Verify raw contract units rather than copying UI display values.
### Liquidity and liquidation failure
A position can be liquidatable while collateral cannot be sold, transferred, or redeemed, or while the liability vault lacks necessary liquidity. Test liquidator eligibility, swap depth, slippage, oracle-update requirements, restricted tokens, and stressed withdrawals. Monitor account health, usable liquidity, liquidation participation, and failed transactions separately.
### Correlation, recursion, and bad debt
Correlated collateral and liability assets can fail together. Nested vaults and cross-collateral relationships add recursive dependencies, while shared liability or collateral vaults can transmit stress beyond an apparently isolated pair. Model common-dependency failures and document the vault's configured bad-debt handling.
### Review output
Record the exact contracts, versions, chain, parameters, role addresses, assumptions, tests, monitors, alerts, and response owner. Re-run the review when any dependency or configuration changes.
### Read next
* [Launch toolkit](/launch)
* [Vault types](/learn/vault-types)
* [Liquidations](/learn/liquidations)
* [Governance contracts](/curate/governance-contracts)
## Deploy an oracle router
When a liability vault accepts collateral, it needs a reliable way to value the collateral and liability asset in the vault's unit of account. An EVK vault can use any compatible `IPriceOracle`; `EulerRouter` is the standard composable option for combining direct pair oracles, ERC-4626 conversions, and a fallback.
For a cluster of connected vaults, a shared router can make pricing paths easier to manage consistently. The router and unit of account are selected when each vault is created, so map the complete pricing path before deployment.
### Before you deploy
Deploy your own oracle adapters for the routes your vaults need rather than reusing adapters found onchain. The [Oracle Deployer](https://oracle-deployer.euler.finance) supports deployment of the available adapter types, and deploying your own keeps the configuration and provenance of every route under your control. If you do reuse an existing adapter, confirm the network, contract address, source, quote unit, update behavior, and governance first.
### Quick start
1. **Map every required price.** Define how each liability and collateral asset will be quoted in the vault's unit of account.
2. **Deploy adapters.** Use the [Oracle Deployer](https://oracle-deployer.euler.finance) for the available adapter types. Check decimals, update cadence, stale-price handling, bounds, and failure behavior.
3. **Deploy or select an `EulerRouter`.** Open the [EVK Vault Manager](https://create.euler.finance/) and choose **Oracle Router**. To deploy, connect the intended governor account on the intended network, choose **Deploy New Oracle Router**, and confirm the transaction. The connected account is set as the initial governor. Record the router's network, address, governor, fallback, and source version.
4. **Add direct pair oracles.** Configure the base/quote pairs that should resolve directly.
5. **Resolve ERC-4626 vaults where needed.** Use `govSetResolvedVault` when a share price should be derived through `convertToAssets`.
6. **Assign the oracle to the liability vault.** Verify the router and unit of account, then test every collateral/liability quote before launch.
### How the router resolves prices
`EulerRouter` resolves a quote in this order:
1. base and quote are the same asset;
2. a configured direct pair oracle;
3. configured ERC-4626 resolved-vault conversion;
4. the configured fallback oracle.
A direct pair oracle therefore takes precedence over resolved-vault conversion.
### ERC-4626 pricing paths
Resolving an ERC-4626 vault lets the router convert shares into the underlying asset with `convertToAssets`. A nested route can combine several conversions and an adapter. For example:
```text
esDAI → sDAI → DAI → USD
```
Check every edge in the path, including decimals, rounding, recursive dependencies, source freshness, redemption liquidity, fees, restrictions, and fallback behavior. `convertToAssets` reports an accounting conversion; it does not establish that the assets can be redeemed immediately at that value.
### Governance and testing
Router governance and vault governance are separate unless a deployment deliberately assigns them to the same controller. Verify who can change pair oracles, resolved vaults, and fallbacks, and whether those changes are delayed.
Before launch, test normal quotes as well as stale, unavailable, extreme-price, recursive, and restricted-redemption cases. Recheck the deployed route after every governance change.
### Read next
* [Price oracles](/learn/price-oracles)
* [Launch toolkit](/launch)
* [Attack vectors](/curate/attack-vectors)
* [Governance contracts](/curate/governance-contracts)
## Governance Contracts
Governance contracts are essential for secure, flexible, and upgradeable management of Euler Vault Kit (EVK) vaults and oracle routers. They enable fine-grained control over vault operations, risk parameters, and emergency responses, balancing the need for rapid intervention with robust user protection.
### Key Principles
Governance contracts in Euler are designed for security and flexibility, but their deployment and management require careful attention. All governance contracts must be deployed from existing, audited factories—there is no UI for these deployments, so users should rely on scripts or block explorers to perform the process. The standard Creator UI does not support the full suite of governor contracts and is only compatible with multisigs. As a result, risk curators and advanced users are encouraged to use [euler-vault-scripts](https://github.com/euler-xyz/euler-vault-scripts) or develop their own custom management tools for managing clusters and advanced governance scenarios.
To ensure consistent and secure governance across all protocol components, governor contracts should be installed not only on vaults but also on the oracle router. This approach provides fine-grained control and robust protection for both lending markets and their associated price feeds.
### Recommended Architecture
The recommended governance suite is illustrated below. It features dual timelocks (admin and wildcard), a risk steward, guardian, and emergency roles, all allowing for the operations to be (optionally) batched via the EVC. This architecture enables:
* Time-delayed governance for transparency and user protection
* Emergency response capabilities for rapid risk mitigation
* Role separation for operational and administrative security
### Components
* **`GovernorAccessControlEmergency`:** Selector-based access control contracts for fine-grained permissioning and emergency actions.
* **`CapRiskSteward`:** Specialized risk management contract that allows authorized users to adjust supply and borrow caps within predefined safety limits and cooldowns, and to update interest rate models (IRMs) only to those deployed by a recognized factory.
* **`GovernorAccessControlEmergencyFactory`:** Factory for deploying the full governance suite, including timelocks and emergency roles.
* **`CapRiskStewardFactory`:** Factory for deploying CapRiskSteward contracts that work alongside selector-based governors for delegated, but limited, risk management that can bypass timelock controllers.
### Deployment & Management
#### Deployment Process
1. Prepare timelock parameters:
* Set `minDelay` (minimum 1 day) for both admin and wildcard timelocks
* Define proposers, cancellers, and executors for each timelock
* Identify emergency guardians for rapid response capabilities
2. Deploy through `GovernorAccessControlEmergencyFactory`:
* Call `deploy` with the prepared parameters
* Record the addresses of deployed contracts
3. Install governance:
* Set the `GovernorAccessControlEmergency` as governor for your vault(s)
* Install the same governor on your oracle router
* If using `CapRiskSteward` for delegated risk management:
* Deploy `CapRiskSteward` via `CapRiskStewardFactory`, providing the governor access control contract, IRM factory addresses and the admin address
* Grant `setInterestRateModel.selector` and `setCaps.selector` roles to the `CapRiskSteward` on the governor contract
* Assign the wildcard role on the `CapRiskSteward` to a multisig or other trusted address
## Interest-rate models
An interest-rate model (IRM) calculates an EVK vault's borrow rate as utilization changes. The supply rate follows from borrowing, utilization, fees, and vault accounting. Model choice affects borrower costs, supplier returns, utilization, and available liquidity.
Contract parameters use per-second rate units, while interfaces commonly display annualized values. Verify the required units and conversion before using a displayed percentage in a deployment transaction.
### IRM types
The models below are examples rather than an exhaustive list. Check the model address, source, factory, network, deployment inputs, and current interface support before assigning one to a vault.
#### Linear Kink IRM
A two-slope utilization curve increases linearly to a kink and then more steeply above it. `EulerKinkIRMFactory.deploy` takes `baseRate`, `slope1`, `slope2`, and `kink`.
The curve does not adapt automatically. A governed vault can replace its IRM if market conditions or its mandate change; a finalized (ungoverned) vault cannot.
#### Linear Kinky IRM
This model uses a nonlinear post-kink shape. Factory inputs include `baseRate`, `slope`, `shape`, `kink`, and `cutoff`. Test how the shape and cutoff affect rates across the full utilization range.
#### Adaptive Curve IRM
An adaptive model changes its rate over time in response to utilization relative to a target. This can reduce the need for manual updates, while making the current rate dependent on past utilization. Verify the exact preset or deployment and its configured bounds.
#### Fixed Cyclical Binary IRM
This model alternates between `primaryRate` and `secondaryRate` according to `primaryDuration`, `secondaryDuration`, and `startTimestamp`. Borrow costs change with time even when utilization is unchanged.
### Review before assignment
Before assigning or replacing an IRM:
* verify its address, source version, network, and factory;
* inspect the raw parameters and derive representative displayed rates;
* simulate zero, target or kink, stressed, and near-full utilization;
* assess the effect on borrowing, withdrawals, refinancing, and liquidations;
* identify who can replace the vault's IRM and whether changes are delayed; and
* monitor unexpected rates and utilization after deployment.
A recognized factory helps identify how a model was deployed. The chosen parameters and resulting rate curve still need to be evaluated for the vault.
### Read next
* [Interest rates](/learn/interest-rates)
* [Launch toolkit](/launch)
* [Governance contracts](/curate/governance-contracts)
* [Attack vectors](/curate/attack-vectors)
## Curate on Euler
Create and operate EVK markets, EulerEarn vaults, and EulerSwap pools. These guides cover deployment, configuration, governance, metadata, and ongoing management.
### Choose a product
| Product | Start here | Operations |
| ----------------------------- | ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| EVK market, vault, or cluster | [Creator UI](/curate/vaults/evk/creator-ui) or [deployment scripts](/curate/vaults/evk/deployment-and-management) | Assets, collateral graph, oracle routes, IRM, caps, LTVs, liquidation settings, hooks, fees, governance, and labels |
| EulerEarn vault | [Earn introduction](/curate/vaults/euler-earn/introduction) | Strategies, roles, caps, queues, allocation, liquidity, fees, loss accounting, and metadata |
| EulerSwap pool | [EulerSwap 2](/curate/euler-swap) | Pool version, LP account, vault pair, manager and hook authority, parameters, fees, liquidity, quotes, and decommissioning state |
| Metadata and discovery | [Labels and metadata](/curate/vaults/labeling) | Vault, product, entity, asset, notice, and known-vault sources; metadata is not a safety verdict |
| Governance or response | [Governance contracts](/curate/governance-contracts) | Role membership, selectors, timelocks, upgradeability, pause paths, signer policy, and recovery limits |
### Shared tools
* [Launch toolkit](/launch) — plan a production launch and operational handoff.
* [Oracle router](/curate/deploy-oracle-router) and [interest-rate models](/curate/interest-rate-models) — configure pricing and rates.
* [Labels and metadata](/curate/vaults/labeling) — make vaults and products discoverable.
* [Governance contracts](/curate/governance-contracts) — assign and manage permissions.
* [Attack vectors](/curate/attack-vectors) — review common risks before launch.
Before deploying, verify contract addresses, parameters, permissions, and monitoring on the target chain. Use [Build](/build) for SDK, API, and direct contract integrations.
## Labels and metadata
The [`euler-labels`](https://github.com/euler-xyz/euler-labels) repository provides human-readable names, descriptions, logos, and product groupings used by Euler applications. This metadata helps users identify entities, products, lending vaults, Earn vaults, points programs, and asset restrictions.
### Choose the metadata file
The repository uses these files for each supported chain:
* `entities.json` for organization identity and display information;
* `products.json` for EVK lending products and per-vault display overrides;
* `points.json` for points programs;
* optional `earn-vaults.json` for Earn vault discovery; and
* optional `assets.json` for chain-specific asset rules.
Cross-chain asset rules can also live in `all/assets.json`. Lending-vault overrides belong in `products.json.vaultOverrides`; there is no standalone `vaults.json`.
### Submit metadata
1. Fork the [euler-labels repository](https://github.com/euler-xyz/euler-labels).
2. Read the current README and schemas.
3. Add or update the relevant files under the numeric chain ID.
4. Add any referenced logo files.
5. Run `npm run verify` against the proposed files.
6. Open a pull request and resolve verifier and reviewer feedback.
Use checksummed addresses and examples that pass the current verifier.
### Add entities and products
Use `entities.json` for factual information about an organization. Use `products.json` to group EVK lending vaults and define product-level display metadata.
Markers use the tags schema, for example:
```json
{
"tags": ["governance limited"]
}
```
Tags can be set on a product, a vault entry, or in `vaultOverrides`; other examples in use include `"keyring"` and `"suppress high utilisation warning"`.
### Add Earn vaults
Use `earn-vaults.json` for Earn discovery and supported entry metadata. Earn vaults are separate from EVK lending-product groupings.
Follow the current repository schema for exact fields and file shape.
### Add asset rules
Use chain-specific `assets.json` for address-scoped rules and `all/assets.json` for supported cross-chain matches. Exact symbol and name match keys use the arrays `symbols` and `names`.
Fields such as `block`, `restricted`, labels, and group aliases are metadata consumed by applications. Each integration decides how to apply and update them.
### Write descriptions
Keep descriptions factual and maintainable. Identify the object and the party that configures it without implying endorsement. For example:
```text
An EVK lending product for selected assets, configured by Example DAO.
```
Labels describe the object shown in an interface. Verify onchain role holders, vault configuration, and asset details from the deployed contracts when those facts affect an integration or transaction.
### Read next
* [Curate](/curate)
* [Vault types](/learn/vault-types)
* [Launch toolkit](/launch)
## Creator UI
The [Creator UI](https://create.euler.finance/) is a guided interface for deploying and managing EVK vaults. For repeatable clusters, custom governance, or scripted changes, use [Deployment and management](/curate/vaults/evk/deployment-and-management) instead.
### Deploy a vault
1. Plan the underlying asset, collateral relationships, oracle routes, unit of account, IRM, caps, LTVs, hooks, and governance.
2. Deploy or select the required oracle router and adapters.
3. Open [Creator UI](https://create.euler.finance/), choose **Vault** (`/vault`), select the underlying asset, router, and unit of account, then review the deployment transaction.
4. Open the deployed vault at `/manage-vault/$vaultAddress` and configure its remaining parameters and roles.
5. Verify every address, parameter, permission, and event from deployed state.
The landing page exposes **Vault**, **Oracle Router**, **Oracle Adapter**, and **IRM**. **Address Book** is in the top navigation. Existing routers use `/oracle/$routerAddress`; IRM deployment uses `/configure-irm`. Prefer UI navigation over constructing undocumented routes.
### Manage an existing vault
The management dashboard groups immutable vault identity, configurable settings, collateral relationships, oracle routes, rewards, and hooks. Before signing a change, review the network, vault, asset, router, unit of account, governor, caps, LTVs, hooks, rewards, metadata, and governance process.
#### Vault info
This section displays immutable details about the vault, such as the vault symbol, address, underlying asset, oracle router, and unit of account. These parameters are set at creation and cannot be changed later. They provide essential context for the vault's operation and risk profile.
#### Settings
* **Governor:** The address with governance rights over the vault. Common practice is to transfer this role to a multisig or governance contract after initial setup. Revoking governance by setting it to `address(0)` makes the vault immutable; do this only if no further parameter changes should be possible.
* **Fee receiver:** The address that receives the vault-receiver portion of converted interest-fee shares after the applicable protocol split. This can be a treasury, DAO, curator, or other beneficiary. Review control of this address before launch.
* **Interest Rate Model:** The contract that supplies the vault's borrow-rate input. Choose a model that matches the risk and utilization profile of your vault.
* **Supply Cap / Borrow Cap:** These parameters limit the total amount of assets that can be supplied to or borrowed from the vault. Caps can be used to bound exposure while a market is new or changing.
* **Interest Fee:** The fraction of accrued borrower interest allocated as fee shares. The applicable protocol fee share splits those shares between the vault fee receiver and protocol fee receiver; it is not an additional fee on top. Verify all deployed settings and recipients rather than inferring them from a proposal or global claim.
* **Maximum Liquidation Discount:** Sets the upper bound on the discount offered to liquidators. Too high a discount can penalize borrowers; too low may fail to incentivize liquidations.
* **Liquidation Cool Off Time:** The minimum time that must pass after the account's last successful status check before it can be liquidated. It is not measured from when the position first becomes unhealthy. This delay helps mitigate self-liquidation attacks, but setting it too high can delay necessary liquidations.
* **Debt Socialization:** When enabled, a liquidation can socialize debt that remains after the violator's collateral has been exhausted. This occurs only when debt remains after the liquidation, the account has no collateral left, and the pre-liquidation liability value meets the protocol's minimum threshold. The remaining debt is removed without assets entering the vault, causing a loss to depositors through a reduction in share value.
##### Supply and borrow caps
Supply and borrow caps are denominated in the vault's underlying asset. The Creator UI handles EVK's compact onchain encoding, but scripts and integrations should use the current `AmountCap` implementation rather than treating the displayed amount as the raw stored value.
An encoded value of `0` represents an unlimited cap. Use the EVK library when reading or writing caps onchain:
```solidity
import {AmountCap, AmountCapLib} from "evk/EVault/shared/types/AmountCap.sol";
uint256 decoded = AmountCapLib.resolve(AmountCap.wrap(encoded));
```
Reference: [`AmountCap.sol`](https://github.com/euler-xyz/euler-vault-kit/blob/master/src/EVault/shared/types/AmountCap.sol)
#### Collaterals
**Add Collateral:** Here you can configure which other vaults' shares can be used as collateral, and set their Loan-to-Value (LTV) ratios. Review collateral liquidity, volatility, oracle route, governance, caps, and liquidation behavior before adding collateral.
##### Adding and configuring collateral assets
When you add a new collateral to your vault, the UI will prompt you to set two key risk parameters:
* **Liquidation LTV:** The collateral-adjustment ratio used for liquidation health. A position becomes eligible when its liability is not less than collateral value after applying the configured liquidation LTV.
* **Borrow LTV:** The maximum loan-to-value ratio at which new borrowing is permitted. This is typically set lower than the liquidation LTV to provide a safety buffer and reduce the risk of immediate liquidations after borrowing.
##### Oracle router configuration
When adding a new collateral, the oracle router configured for this vault must be able to price the underlying asset of the collateral vault in terms of the vault's unit of account, such as USD. This is managed through the **Set Oracle Configuration** option. If the oracle router cannot provide this price, borrowing against the collateral will not be possible.
Choose the route deliberately. A configured direct share-token pair oracle takes precedence and short-circuits resolved-vault routing. Configure that direct route only when it is intended; if the route should call the ERC-4626 vault's `convertToAssets()` and then price its underlying asset, use **Add Resolved Vault to Oracle** and ensure no direct pair route overrides it. Review precedence, donation/inflation behavior, decimals, redeemability, liquidity, restrictions, recursive dependencies, and whether the conversion represents realizable value.
See [Oracle router deployment](/curate/deploy-oracle-router) for precedence and safety checks. The router must produce the required collateral-share quote for risk checks, LTV calculations, and liquidations; the same two-step path is not mandatory for every collateral.
##### Oracle configuration
Deploy your own oracle adapters for the routes the vault needs — the [Oracle Deployer](https://oracle-deployer.euler.finance) supports the available adapter types — rather than reusing adapters found onchain. If you do reuse one, verify its configuration and provenance first.
#### Underlying asset oracle config
The Oracle Config section allows you to configure the oracle for the underlying asset of your vault. The router must be able to price the vault's underlying asset in terms of the unit of account, such as USD. This pricing route is used for risk checks and debt valuation. If the oracle router cannot provide this price, borrowing against collateral in that liability vault will not be possible.
:::warning
**Important**
All oracle adapters used must conform to the `IPriceOracle` interface as described in the [**Price Oracles doc**](/learn/price-oracles). Interface conformance standardizes how vaults request quotes; it does not by itself prove that an oracle route is suitable for a market.
:::
#### Rewards
Use [Merkl](https://app.merkl.xyz/) for reward campaigns. It supports campaign scheduling, eligibility criteria, and analytics. Review campaign terms and how rewards are displayed before using rewards in public vault materials.
#### Hook settings
**Hook Target & Operations:** Install a hook contract to add custom checks or restrictions to selected vault operations. You can selectively enable or disable hooks for operations such as `deposit`, `withdraw`, `mint`, `redeem`, `borrow`, `repay`, `transfer`, `liquidate`, and more. Poorly designed hooks can break vault functionality or introduce risk, so custom hooks should be reviewed and tested before use.
:::info
**Important**
In the current EVK implementation, a new vault starts with every supported operation-hook bit selected and a zero hook target, which disables those operations. The creator must deliberately configure the hook target or unhook operations as required. A hook gates only the selected operations. It does not by itself perform identity verification, sanctions screening, legal review, or make a vault compliant; document stale-data, failure, upgrade, bypass, and emergency-control behavior. Verify these initialization defaults against the deployed EVK version.
:::
### Managing existing vaults and escrow
* **Manage Existing Vault:** Enter a vault address to manage its configuration or view details.
* **Deploy/Search Escrow:** Escrow Vaults are ungoverned vaults designed to act as simple, reusable collateral buckets (see [Vault Types](/learn/vault-types)). There's usually no need to create new Escrow Vaults unless you need one for a new asset. Existing Escrow Vaults can be reused by anyone in the ecosystem.
:::note
Not all non-borrowable vaults need to be ungoverned Escrow Vaults. You can also deploy governed vaults that are initially non-borrowable. If you configure such a vault with an oracle router and the appropriate unit of account, governance may be able to enable borrowing later.
:::
## Deployment and management of EVK vaults
There are two main ways to deploy and manage **Euler Vault Kit (EVK)** vaults, each suited to different users and workflows:
### Creator UI ([create.euler.finance](https://create.euler.finance/))
**Best for:** Guided deployments, experimentation, and simple single-vault or small-cluster workflows.
* The [create.euler.finance](https://create.euler.finance/) web interface guides creators through deploying a vault, selecting assets and oracle routers, configuring common parameters, and managing existing vault settings.
* Use the [Creator UI guide](/curate/vaults/evk/creator-ui) for screen-by-screen routing through vault creation, collateral settings, caps, hooks, rewards, and launch metadata.
* Each vault is configured one by one. For large clusters, custom governance contracts, or repeatable operations, review scripts before launch.
* Creator UI management is limited to vaults and governance operations supported by the current UI. Vaults controlled through a [governor contract](../../../build/periphery/governors) may require scripts or that governor's own execution workflow.
### Foundry scripts ([`euler-vault-scripts`](https://github.com/euler-xyz/euler-vault-scripts))
**Best for:** Power users, protocol developers, and teams managing clusters or advanced configurations.
* The [`euler-vault-scripts`](https://github.com/euler-xyz/euler-vault-scripts) repository provides a script-based approach for defining, deploying, and managing clusters of EVK vaults. It is intended for advanced users who need more automation and support for complex market configurations, including governance contract integration and emergency operations.
* Clusters are defined in Solidity scripts, allowing you to specify assets, LTVs, oracles, caps, IRMs, and more in a programmable way. The system supports delta management, so only changes are applied when updating an existing cluster.
* The scripts are compatible with Safe multisigs, timelocks, and risk stewards, making them suitable for production deployments and multisig-managed markets.
* For detailed usage, code snippets, and advanced management workflows, see the dedicated [`euler-vault-scripts` guide](./euler-vault-scripts).
## Donation attacks
### Introduction
This scenario illustrates a worst-case hypothetical attack on a lending protocol that relies on exchange-rate manipulation of ERC-4626 vaults. Specifically, it focuses on a protocol that lists an ERC-4626 share token as both collateral and a borrowable asset, and uses the vault's share-to-asset conversion to value those shares in terms of the underlying asset.
This scenario depends on the exact assumptions below. Exploring it helps identify mitigations that can reduce similar risks in other configurations.
The described sequence requires direct donations to change the share conversion consumed by lending valuation. EVK's internal cash accounting breaks that assumption for an EVK vault's own shares. It does not make every ERC-4626 collateral or oracle integration safe: external share vaults, oracle routes, recursive collateral paths, liquidity, and redeemability can introduce different risks.
### Attack
#### Initial Setup
**System Configuration**:
* ERC-4626 Vault: Allows depositing ABC to receive wABC
* Lending Protocol: Uses the ABC/wABC exchange rate to value wABC
* Collateral & Borrowing Rules:
* wABC as Collateral to borrow USDC: 0.8 LTV (80% of wABC value can be borrowed)
* USDC as Collateral to borrow wABC: 0.8 LTV (80% of USDC value can be borrowed)
#### Required attack conditions
The numerical sequence previously shown here did not reconcile share supply, account balances, collateral, and debt. The mechanism is clearer when stated as the conditions an attacker would need:
1. **Manipulable share conversion:** unsolicited underlying transfers must increase the share-to-asset conversion used by the lending protocol's valuation path.
2. **Useful market relationships:** the affected share token must be accepted in collateral or borrowing relationships that let the attacker turn the manipulated valuation into extractable assets.
3. **Concentrated share supply:** the attacker must be able to reduce effective outstanding share supply enough that a donation materially changes the conversion rate, while retaining or controlling shares that benefit from the change.
4. **Sufficient liquidity and limits:** available liquidity, supply caps, borrow caps, LTVs, and liquidation constraints must permit the position and extraction path.
5. **Economic viability:** assets extracted must exceed donations, financing costs, swap costs, transaction fees, liquidation losses, and any flash-loan fee.
If any required condition fails, this exact path fails. A complete assessment must trace the vault's actual accounting, share ownership, oracle route, connected markets, caps, liquidity, and every asset movement. ERC-4626 conformance alone neither proves nor disproves exposure.
### Prevention Strategies
#### 1. Prevent Exchange Rate Manipulation
The attack relies on manipulating the exchange rate within an ERC-4626 vault. Under the exact accounting assumption described here, internal balance tracking that excludes unsolicited transfers from the share conversion removes the required manipulable-conversion condition. Integrators must verify the actual vault accounting and oracle path rather than infer this property from ERC-4626 conformance.
#### 2. Avoid Vulnerable Vaults as Collateral
For ERC-4626 vaults where the exchange rate can be altered by donations, a simple mitigation strategy is to:
* Avoid listing these vaults as collateral or
* Prevent them from being borrowable in the lending protocol
Under the example's assumptions, either measure removes one of the required collateral or borrow relationships. Other market relationships can create different paths.
#### 3. Implement Supply and Borrow Caps
If vulnerable ERC-4626 vaults must be used as collateral and borrowing assets, additional safeguards can reduce the risk:
* Set conservative supply and borrow caps that do not exceed the total circulating supply of the vault's share tokens
* Caps can bound exposure and increase attack cost under the configured limits, but do not by themselves prove that an attack is unprofitable
#### 4. Use a Wrapped Exchange Rate Oracle
A carefully designed wrapped exchange rate oracle can bound extreme or rapid reported exchange-rate changes:
* Cap exchange rate increases within a set threshold
* Limit the rate of change within a single block, potentially breaking this exact atomic sequence
* This can force a multi-block strategy and add market risk without proving the broader configuration safe
**Important Note**: Some existing wrapped exchange rate oracles may still be vulnerable to this type of attack. For example, certain price feeds from third-party oracle providers report the redemption price of an asset. However, this redemption price might internally use the ERC-4626 exchange rate, which can be manipulated through donation attacks.
### Conclusion
This hypothetical attack demonstrates how exchange rate manipulation in ERC-4626 vaults can be exploited to target lending protocols that allow vulnerable vaults as both collateral and borrowable assets.
For an EVK vault's own shares, internal cash accounting breaks the direct-donation assumption used in this example. This is a mitigation of the described mechanism under its stated assumptions, not a guarantee for external ERC-4626 collateral, oracle routing, liquidity, redemption restrictions, caps, or recursive dependencies. Supply and borrow caps can bound exposure but do not establish unprofitability or safety.
## Cluster deployment and management using scripts
The [`euler-vault-scripts`](https://github.com/euler-xyz/euler-vault-scripts) repository provides a script-based framework for deploying, configuring, and managing clusters of EVK vaults. It is intended for advanced users, DAOs, and protocol developers who need automation and support for complex, governed markets.
### What is a cluster?
A cluster is a collection of vaults that accept each other as collateral and share a common governor. Clusters are defined and managed in Solidity scripts, enabling programmable and reproducible market deployments that can be reviewed before execution.
### Key features
* Automated deployment and delta management
* Support for Safe multisigs, timelocks, and risk stewards
* Batching, emergency operations, and governance contract integration
### Defining a cluster: example
Below are annotated snippets from a typical cluster script (`Cluster.s.sol`).
#### 1. Define cluster assets
```solidity
function defineCluster() internal override {
// List the assets for which vaults will be deployed
cluster.assets = [WETH, USDC, USDT, sUSDS];
}
```
*This sets up the vaults in your cluster. Each asset will have its own vault. Do not define more than one vault per asset.*
#### 2. Configure cluster parameters
```solidity
function configureCluster() internal override {
// Set the governor addresses for vaults and oracle routers
cluster.oracleRoutersGovernor = getDeployer();
cluster.vaultsGovernor = getDeployer();
// Set the unit of account (e.g., USD)
cluster.unitOfAccount = USD;
// Percentage values use 1e4 = 100%.
cluster.feeReceiver = address(0);
cluster.interestFee = 0.1e4; // 10%
cluster.maxLiquidationDiscount = 0.15e4; // 15%
cluster.liquidationCoolOffTime = 1; // seconds
// Set hooks, config flags, etc. as needed
cluster.hookTarget = address(0);
cluster.hookedOps = 0;
cluster.configFlags = 0;
}
```
*This block configures governance, risk, and operational parameters for the cluster. You can override parameters per asset if needed.*
#### 3. Set oracle providers
```solidity
// Assign oracle adapters or external vaults for each asset
cluster.oracleProviders[WETH ] = "0x10674C8C1aE2072d4a75FE83f1E159425fd84E1D";
cluster.oracleProviders[USDC ] = "0x6213f24332D35519039f2afa7e3BffE105a37d3F";
cluster.oracleProviders[USDT ] = "0x587CABe0521f5065b561A6e68c25f338eD037FF9";
cluster.oracleProviders[sUSDS] = "ExternalVault|0xD0dAb9eDb2b1909802B03090eFBF14743E7Ff967";
```
*Assets used in priced borrowing relationships need the required quote route. Use `ExternalVault|` only when the intended route should consume a reviewed ERC-4626 `convertToAssets` conversion and no direct pair oracle should take precedence. Apply the manipulation, decimals, redeemability, liquidity, and recursive-dependency checks in [Oracle router deployment](/curate/deploy-oracle-router).*
Deploy your own oracle adapters for the intended routes — the [Oracle Deployer](https://oracle-deployer.euler.finance) supports the available adapter types — rather than reusing adapters discovered onchain. If you do reuse one, verify chain, address, source, update behavior, governance, and suitability for the intended route first.
#### 4. Set supply and borrow caps
```solidity
cluster.supplyCaps[WETH ] = 10_000;
cluster.supplyCaps[USDC ] = 10_000_000;
cluster.supplyCaps[USDT ] = 10_000_000;
cluster.supplyCaps[sUSDS] = 10_000_000;
cluster.borrowCaps[WETH ] = 9_000;
cluster.borrowCaps[USDC ] = 9_000_000;
cluster.borrowCaps[USDT ] = 9_000_000;
cluster.borrowCaps[sUSDS] = type(uint256).max; // no cap
```
*Caps control the maximum supply and borrowable amounts for each vault.*
#### 5. Assign interest rate models (IRMs)
```solidity
uint256[4] memory irmETH = [uint256(0), uint256(194425692), uint256(41617711740), uint256(3865470566)];
uint256[4] memory irmUSD = [uint256(0), uint256(399976852), uint256(39767751304), uint256(3865470566)];
cluster.kinkIRMParams[WETH ] = irmETH;
cluster.kinkIRMParams[USDC ] = irmUSD;
cluster.kinkIRMParams[USDT ] = irmUSD;
```
*Interest rate models are set per asset. Use the provided scripts/utilities or [Creator UI](https://create.euler.finance/) to generate IRM parameters as needed.*
#### 6. Configure LTVs and liquidation parameters
```solidity
// Liquidation LTV matrix: columns = liability vaults, rows = collateral vaults
cluster.ltvs = [
// WETH USDC USDT sUSDS
[uint16(0.00e4), 0.85e4, 0.85e4, 0.00e4], // WETH
[uint16(0.87e4), 0.00e4, 0.95e4, 0.00e4], // USDC
[uint16(0.87e4), 0.95e4, 0.00e4, 0.00e4], // USDT
[uint16(0.87e4), 0.95e4, 0.95e4, 0.00e4] // sUSDS
];
```
#### 7. Configure spread LTV
```solidity
// Set the spread LTV for the entire cluster
cluster.spreadLTV = 0.02e4; // 2% spread
```
*The spread LTV represents the difference between the liquidation threshold and the maximum LTV for all assets in the cluster. This creates a buffer zone before liquidation can occur, but it does not prevent liquidations during price moves, oracle updates, liquidity changes, or execution delays.*
### Environment setup and running scripts
#### Prerequisites
1. Install Foundry:
```bash
curl -L https://foundry.paradigm.xyz | bash
foundryup
```
2. Clone the repository:
```bash
git clone https://github.com/euler-xyz/euler-vault-scripts.git
cd euler-vault-scripts
```
3. Prepare the `.env` file using `.env.example` as a template. Define the RPC URLs for all the chain IDs you need. If you plan to submit transactions through Safe, define `SAFE_API_KEY` as described in the current repository README. Treat that README as the source of truth for current environment variables and command options.
4. Install dependencies:
```bash
./install.sh
```
5. Compile the contracts:
```bash
forge clean && forge compile
```
#### Running scripts
The scripts are experimental and provided as-is. Pin and review the repository revision you use, test the complete cluster configuration and scripts, run the documented dry run, and independently review every generated transaction and Safe payload before production execution. A successful dry run does not validate asset, oracle, liquidity, governance, cap, LTV, fee, or liquidation-risk choices.
Use the `ExecuteSolidityScript.sh` script to run the management script:
```bash
./script/ExecuteSolidityScript.sh script/clusters/[CLUSTER_FILE] [options]
```
Replace `[CLUSTER_FILE]` with your cluster-specific file name (e.g., `Cluster.s.sol`).
##### Important options:
* `--dry-run`: Simulates the script without executing transactions
* `--rpc-url URL|CHAIN_ID`: Required if `DEPLOYMENT_RPC_URL` not defined in `.env`
* `--account ACCOUNT` or `--ledger`: Required if `DEPLOYER_KEY` not defined in `.env`
* `--batch-via-safe`: Creates a batch payload file for Safe multisig execution
* `--safe-address SAFE_ADDRESS`: Authorized Safe multisig address
* `--timelock-address`: Schedules transactions in the timelock controller
* `--risk-steward-address`: Executes transactions via the risk steward contract
##### Example commands:
Initial deployment:
```bash
./script/ExecuteSolidityScript.sh ./script/clusters/Cluster.s.sol --account DEPLOYER --rpc-url 1
```
Managing a deployed cluster with governance contracts:
```bash
./script/ExecuteSolidityScript.sh ./script/clusters/Cluster.s.sol --batch-via-safe --safe-address DAO --timelock-address wildcard --rpc-url 1
```
#### Important notes
* Always use `--dry-run` first, then inspect the target chain, callers, destinations, calldata, values, role paths, and resulting state before signing
* Environment variables in `.env` take precedence over command line arguments
* After deployment, commit the generated `.json` files in the scripts directory as they serve as the deployed contracts addresses cache
### Further reading and references
* [euler-vault-scripts README](https://github.com/euler-xyz/euler-vault-scripts/blob/master/README.md)
* [Cluster.s.sol example](https://github.com/euler-xyz/euler-vault-scripts/blob/master/script/clusters/Cluster.s.sol)
### Read next
* [Curate](/curate)
* [Launch toolkit](/launch)
* [Final review](/launch#final-review)
## Hooks and custom logic
The [**Euler Vault Kit (EVK)**](/curate/vaults/evk/overview) provides a flexible hooking system that allows vault governors to extend vault functionality or restrict certain operations. This guide explains how hooks work and provides examples of common use cases.
### Hook system overview
Hooks are implemented through a hook configuration that consists of two parameters:
* The hook target: The address of a contract that implements the hook logic
* The hooked operations: A bitfield that specifies which operations should trigger the hook
When a hooked operation is invoked, the vault will:
1. Check if the operation is enabled in the hooked ops bitfield
2. Call the hook target with the same `msg.data` that was provided to the vault
3. Append the EVC-authenticated caller as trailing calldata
4. Revert the operation if the hook call fails
#### Hook target implementation
Every hook target contract must implement the `isHookTarget()` function, which returns a special function selector (magic value). This function checks that the contract is coded to be a hook target. Depending on the use case, `isHookTarget()` can be further strengthened by checking whether the calling address is a proxy deployed by a recognized EVault factory. Example implementation can be as follows:
```solidity
function isHookTarget() external view returns (bytes4) {
if (eVaultFactory.isProxy(msg.sender)) return this.isHookTarget.selector;
else return 0;
}
```
### Example use cases
#### Access control
The [`HookTargetAccessControl`](https://github.com/euler-xyz/evk-periphery/blob/master/src/HookTarget/HookTargetAccessControl.sol) contract demonstrates how to implement role-based access control for vault operations. This is useful for:
* Restricting deposits to whitelisted addresses
* Limiting borrowing to specific users
* Implementing KYC/AML requirements
* Implementing KYB or entity-level eligibility requirements
* Enforcing allowlists for permissioned or RWA-backed vaults
* Creating permissioned vaults for institutional users
Access-control hooks are commonly used when eligibility is determined offchain and then published onchain through roles, allowlists, credential registries, or a custom policy contract. The hook should check the EVC-authenticated account appended to calldata, not only `msg.sender`, because vault operations may be routed through EVC batches, operators, or integration contracts.
#### Circuit breakers
Hooks can be used as vault-level circuit breakers for selected operations. A circuit-breaker hook can revert when a configured condition is active, such as:
* Pausing new deposits or borrows during oracle, liquidity, or asset incidents
* Blocking transfers of vault shares during an issuer or transfer-agent event
* Disabling flash loans or other high-risk actions during an exploit response
* Enforcing utilization, exposure, or concentration ceilings during status checks
* Allowing de-risking actions such as repay or withdraw while blocking actions that increase exposure
Design circuit breakers narrowly. Broad pauses can protect against some incidents, but they can also interrupt normal operations, integrations, liquidations, or user exits if they are applied to the wrong operation set.
#### Compliance and RWA controls
For tokenized asset and RWA markets, hooks can encode operation-level rules that match the vault's eligibility and transfer assumptions. Common examples include:
* Requiring KYC/KYB approval before `deposit`, `mint`, `borrow`, or `transfer`
* Checking jurisdiction, sanctions, accreditation, investor-type, or entity-status registries
* Enforcing per-account exposure limits or minimum position sizes
* Restricting vault-share transfers to approved recipients
* Blocking new exposure when the underlying asset, issuer, custodian, oracle, or redemption process is paused
Hooks gate only selected hooked EVK operations using configured onchain conditions. They do not by themselves perform legal review, identity verification, KYC/KYB, sanctions screening, issuer administration, transfer-agent processing, determine legal eligibility, or make a vault or market compliant. Those outcomes depend on external data and processes, governance, and the exact operations covered. Document policy sources, stale-data and provider failures, upgrades, bypasses, privileged roles, revocation, and emergency behavior before launching a permissioned or RWA-related vault.
#### Other use cases
1. **Flash Loan Fees**
* Enforce a percentage fee on flash loans
* Collect fees in any token
* Scale fees with gas costs
2. **Utilization Caps**
* Block vault utilization from exceeding a threshold
* Implement dynamic caps based on market conditions
* Protect against high utilization risks
3. **Minimum Debt Sizes**
* Prevent creation of dust positions
* Set debt floors so liquidations are more likely to be economically viable
* Reduce gas costs for liquidators
4. **Custom Collateral Restrictions**
* Limit the number of collateral assets
* Implement custom collateral validation
* Add additional risk checks
### Limitations
1. **[ERC-4626](https://eips.ethereum.org/EIPS/eip-4626) Compliance**
* Some hook configurations may cause the vault to not be fully ERC-4626 compliant
* The `max*` functions may be inaccurate with hooks installed
2. **Operation Scope**
* Hooks can only affect operations specified in the hooked ops bitfield
* Hooks do not cover operations outside the configured bitfield, and some operations may not be hookable
* A reverting, unavailable, or gas-intensive hook can deny service to covered operations, including de-risking or liquidation paths if configured carelessly
3. **Gas Costs**
* Each hooked operation requires an additional external call
* Complex hook logic can significantly increase gas costs
* Consider the impact on user experience
## Euler Vault Kit introduction
The Euler Vault Kit (EVK) is a modular framework for building lending markets from ERC-4626 vaults. Each vault holds one underlying asset and can be configured with its own collateral relationships, oracle routes, LTVs, caps, interest-rate model, liquidation settings, hooks, fees, and governance.
EVK lets developers, curators, DAOs, and other market creators:
* launch lending markets for ERC-20 assets;
* configure risk parameters for each vault-to-vault relationship;
* choose governed or immutable deployments; and
* connect vaults into isolated pairs, multi-collateral markets, or larger clusters.
### Why build with EVK?
Multiple vaults for the same asset can coexist with different parameters. LTVs are set between individual liability and collateral vaults, so a market creator can isolate a pair or deliberately connect several vaults. Existing vaults can also be accepted as collateral to help bootstrap a new market, with the new vault inheriting dependencies on that collateral vault's configuration and liquidity.
Liquidations use a reverse Dutch auction-style discount rather than one fixed bonus. The discount increases as a position's health deteriorates, up to the maximum configured by the vault governor.
Hooks can add custom accounting, access rules, or conditions to selected operations. The creator also chooses the vault's oracle or router, unit of account, and interest-rate model. If the oracle is a router, its routes may be managed by a separate router governor.
EVK vaults work with the Ethereum Vault Connector (EVC). EVC batching supports flows such as one-transaction leverage, while operators let users delegate control of selected accounts to another address or contract for automation and other account workflows.
### Market structures
EVK supports several market structures:
* **Isolated pairs:** one collateral vault supports borrowing from one liability vault.
* **Multi-collateral markets:** a liability vault accepts several collateral vaults.
* **Vault clusters:** connected vaults accept one another as collateral across a broader market.
More connected structures can improve capital and liquidity reuse, but they also create dependencies between the participating vaults. Choose the structure that matches the intended assets, governance, and risk model.
:::tip
**Before you begin**
Plan the underlying assets, collateral relationships, oracle routes, unit of account, IRM, caps, LTVs, hooks, and governance before deploying. Review the [core concepts](/introduction) if you are new to Euler's architecture.
:::
:::note
**Creator UI and labels**
Use the [Creator UI](https://create.euler.finance/) to deploy or manage an EVK vault. Labels and public metadata help apps display and discover vaults; verify deployed addresses, roles, and configuration independently. See [Labels and metadata](/curate/vaults/labeling) and [Vault metadata](/build/data-querying/perspectives).
:::
## Overview
**The Euler Vault Kit (EVK)** is a system for constructing credit vaults: [ERC-4626](https://eips.ethereum.org/EIPS/eip-4626) vaults extended with lending and borrowing. Borrower interest is their core yield source, unlike many ERC-4626 implementations that allocate assets to external strategies. Users can borrow from a credit vault when they have sufficient eligible collateral in other credit vaults. The liability vault decides which credit vaults it accepts as collateral.
### Key components
#### Vault architecture
A vault consists of several components:
* **Underlying Asset**: The ERC-20 token held by the vault. Each vault holds exactly one underlying asset.
* **EVault**: The primary entry-point contract implementing common vault logic:
* Tracks deposits and borrows
* Accrues interest
* Validates position health
* Permits liquidations
* **Price Oracle**: Interfaces with external pricing systems to compute collateral and liability values
* **IRM (Interest Rate Model)**: Computes interest rates to incentivize borrowing behavior
* **ProtocolConfig**: Global protocol-level configuration controlling interest fee destinations and splits
* **Hook Target**: Optional contract that can implement custom logic for vault operations through hooks
* **DToken**: A read-only ERC-20 interface for debt amounts, making debt modifications visible in block explorers and trackable by tax-accounting software
#### Vault creation and governance
Vaults are created through a factory contract, which deploys a proxy pointing to the implementation contract. This pattern enables gas-efficient deployment and gives integrators a way to verify factory provenance. After creation, vaults can be either governed, where the creator retains or transfers governance rights, or finalized, where governance is revoked by setting governor to `address(0)`.
#### Upgradeability vs immutability
When creating a vault, a boolean `upgradeable` flag is specified:
* If `upgradeable` is true, the factory creates a beacon proxy, allowing the factory admin to upgrade the vault's implementation
* If `upgradeable` is false, the factory creates a minimal proxy contract, making the vault immutable
The factory has a configured `upgradeAdmin` that can change the implementation for upgradeable vaults. Verify its current holder and control path onchain for the selected deployment. Vault creators choose whether a factory-admin implementation change can affect their vault or whether its implementation is immutable.
:::info
The upgrade functionality is intended for critical bugs discovered in the vault implementation.
:::
#### Governance risk
The combination of upgradeability and governance creates different risk profiles:
| | Upgradeable | Immutable |
| ------------- | ------------------------ | --------- |
| **Governed** | Factory Admin + Governor | Governor |
| **Finalized** | Factory Admin | None |
Immutability removes specific change authorities but also removes their recovery options. See [EVK security](/curate/vaults/evk/security) for the resulting governance, oracle, collateral, and implementation tradeoffs.
### Core functionality
#### Exchange rate and shares
Vaults implement the ERC-4626 standard, where shares represent proportional claims on vault assets. The exchange rate grows as interest accrues, and shares maintain the same decimals as the underlying asset. The exchange rate is calculated as:
```
exchangeRate = (cash + totalBorrows + VIRTUAL_DEPOSIT) / (totalShares + VIRTUAL_DEPOSIT)
```
The virtual deposit mechanism mitigates manipulation through rounding-based "stealth deposits" and keeps the exchange rate well-defined even with zero shares.
#### Token transfers
Vaults use two internal abstractions for token movements:
* `pullAssets`: First attempts a Permit2-authorized transfer, then falls back to the underlying asset `transferFrom`
* `pushAssets`: Uses `transfer` on the underlying asset, with checks to prevent transfers to virtual sub-accounts
Permit2 can improve user experience by allowing approvals to be created as signed messages bundled into the same EVC batch as operations like `deposit`. Users need to approve the Permit2 contract once, and some users may already have done this when interacting with Uniswap or other apps.
With the advent of EIP-7702, the need for Permit2 is reduced, as EIP-7702 allows approvals to be bundled with transactions in a more native way. However, not all networks support EIP-7702 yet, and many wallets are still catching up. As a result, Permit2 remains useful for smoother user experiences across different environments and wallet implementations.
#### Internal balance tracking
The vault uses internal balance tracking instead of reading its own balance from the underlying asset. This prevents users from manipulating the exchange rate through direct transfers and is more gas efficient. However, this means that rebasing/fee-on-transfer tokens are not supported, as the vault cannot track unexpected balance changes.
#### Balance forwarding
Balance forwarding enables automated distribution of rewards while keeping gas costs low. When an account opts in, every time its balance changes an external contract is notified of the updated balance. This external contract has no special privileges in the vault, but its `balanceTrackerHook` method must not revert or use up all gas. In practice, reward campaigns for Euler vaults run on offchain platforms such as [Merkl](https://app.merkl.xyz/), which do not rely on balance forwarding.
#### Interest rate models and compounding
Interest Rate Models (IRMs) determine the interest rate based on the vault's state, typically using a function of utilization. The most common function is a "linear-kink" model that starts with a gradual slope and becomes steep at a target utilization value.
Interest is compounded deterministically every second using exponentiation. Because accrued interest is added to `totalBorrows`, it increases utilization. The amount of interest owed/earned is independent of how frequently the contract is interacted with, except for the effect of accumulator rounding.
IRMs return interest rates in terms of "second percent yield" (SPY) values, which are per-second compounded interest rates scaled by `1e27`. For consistency, conversion to annualized equivalents should use the number of seconds in the average Gregorian calendar year (365.2425 days).
#### Fees
Interest-fee settings and recipients are configuration-, deployment-, network-, and vault-dependent. Verify the current deployed settings for the relevant network and vault. A governance proposal alone does not prove that a change was executed.
Vault governors can configure the portion of accrued borrower interest allocated as fees through the `interestFee` parameter, subject to the applicable bounds. Accumulated fees are converted into vault shares. Once minted, those shares participate in the same asset-per-share changes as other shares.
The `ProtocolConfig` contract's `protocolFeeShare` determines how the accumulated `interestFee` shares are split between the vault's fee receiver and the protocol fee receiver, subject to the contract's cap. It is a split of the configured interest fee, not an additional percentage charged on top. Read the vault's `interestFee`, its fee receiver, and the applicable protocol share and receiver together.
#### Supply and borrow caps
Vault governors can configure:
* Supply cap: Limit on the amount of underlying assets that can be deposited
* Borrow cap: Limit on the amount that can be borrowed
Both caps are denominated in the underlying asset and are packed into 2-byte decimal floating point values. Caps can be transiently violated since they are only enforced at the end of a batch. If a cap was not in violation at the start of a batch but is at the end, the transaction will be reverted.
#### Dtoken (debt token)
Vaults provide a read-only ERC-20 interface for debts through the DToken contract. This interface tracks debt modifications through Transfer events and supports off-chain analysis and tax accounting. The DToken contract is the first (and only) contract created by EVault, so its address can be calculated from the vault's address and the nonce `1`.
### Sub-accounts
The EVC provides each user with 256 virtual account addresses, known as sub-accounts, that are separated from one another. This lets users manage multiple positions with different risk parameters while using a single wallet.
#### How sub-accounts work
In the EVC, every Ethereum address is associated with 256 accounts, which includes the primary account (referred to as the owner). These accounts are identified by IDs ranging from 0 to 255, with ID 0 specifically assigned to the owner account. To generate sub-account addresses, the system performs an XOR operation between the account ID and the Ethereum address. Additionally, the EVC keeps track of sub-account ownership through a look-up mapping called `ownerLookup`, which helps resolve sub-accounts back to their respective owner addresses.
##### Important considerations
* Sub-account addresses are internal to the EVC and compatible vaults
* Ordinary ERC-20 contracts cannot authenticate EVC ownership of a derived sub-account. Use an address that actually controls the token balance and allowance unless the exact external flow is EVC-aware and reviewed.
* The EVC maintains a look-up mapping to resolve sub-accounts to their owner addresses
* Sub-accounts are the only way an account can hold multiple Vault borrows concurrently in the EVK
### Risk management
#### Health checks
Vaults implement two critical health check methods:
* `checkAccountStatus`: Verifies account solvency
* `checkVaultStatus`: Ensures vault-level limits are respected
These methods are invoked by the EVC at appropriate times, typically after all operations in a batch have been performed.
#### LTV (loan-to-value)
Each collateral vault is configured with an LTV that determines the maximum borrow amount against collateral. The system supports separate borrowing and liquidation LTVs. The borrowing LTV is used to limit new borrows, while the liquidation LTV is used when liquidating existing positions. This gap helps compensate for pricing delays and uncertainty, requiring larger price movements to get liquidated right after the position was created. The liquidation LTV can be smoothly ramped down by the vault governor when a collateral needs to be phased out.
#### Liquidations
When an account's risk-adjusted collateral value reaches or falls below its liability value, the account becomes eligible for liquidation. The liquidation system uses a reverse Dutch auction mechanism that scales the discount proportionally with how deeply in violation the position is. The mechanism has several practical effects:
* Slightly unhealthy positions may not be profitable to liquidate
* As prices move against the position, the discount increases
* A liquidator may execute when the discount covers execution, pricing, gas, and market risk
The liquidation discount is limited by a maximum liquidation discount parameter that vault creators must set appropriately. The discount is proportional to how far below the threshold the account is, which means that in some cases a liquidator may prefer many small liquidations rather than one large liquidation.
#### Bad debt socialization
When enabled, bad debt socialization cancels uncollateralized debt and socializes the loss to all depositors. This can reduce first-withdrawer advantage during bad debt events, but it still means depositors absorb losses. Vault governors who do not want debt socialization can disable this functionality.
### Advanced features
#### Hooks system
The hooks system lets vault governors apply onchain conditions to selected vault operations. It can pause operations, require an onchain allowlist or attestation, add flash-loan fees, enforce utilization caps, or set minimum debt sizes. A hook does not itself perform identity verification, sanctions screening, legal review, or make a vault compliant; document its data freshness, failure, upgrade, bypass, and emergency behavior.
For a full technical reference, see the [EVK whitepaper](https://github.com/euler-xyz/euler-vault-kit/blob/master/docs/whitepaper.md) or the [EVK repository](https://github.com/euler-xyz/euler-vault-kit).
### Read next
* [Interact with EVK vaults](/build/evk/interacting-with-vaults)
* [EVK security](/curate/vaults/evk/security)
* [Euler SDK](/build/sdk)
* [Launch toolkit](/launch)
## Security Considerations
The [**Euler Vault Kit (EVK)**](/curate/vaults/evk/overview) is designed with security as a priority, but there are inherent limitations and risks that developers and users should be aware of. This document outlines key security considerations when working with EVK vaults.
### Known Limitations
#### Governance Risk
Vaults can be configured in different combinations of upgradeable/immutable and governed/finalised. Each combination presents different risk profiles:
* **Upgradeable + Governed**: Subject to both factory admin and governor risks
* **Immutable + Governed**: Subject only to governor risks
* **Upgradeable + Finalised**: Subject only to factory admin risks
* **Immutable + Finalised**: Removes the configured vault-governor and factory-upgrade change paths. Risks can remain in oracles, collateral vaults, tokens, hooks, external integrations, and other governed dependencies.
There are also risks to creating immutable/finalised vaults:
* If market conditions change, making a formerly safe collateral asset or price oracle unsafe, only governed vaults can be reconfigured
* If critical bugs are found in the Vault Kit code, the factory admin will only be able to fix upgradeable vaults
#### Collateral Validation
Using vaults with illiquid or manipulable underlying assets could threaten the safety of depositors. It's critical to evaluate the smart contract code that implements each collateral vault. A badly coded or malicious vault could:
* Refuse to release funds in a liquidation event
* Lie about the value of its holdings
* Have dangerous configurations that might encounter bad debt situations
#### Hooks Security Concerns
Hooks can implement condition checks that (maliciously or not) could prevent liquidations from succeeding. Vaults with hooks installed should be carefully audited to ensure they don't interfere with critical functions like liquidations.
#### Exchange Rate Manipulation
While EVK implements several protections against exchange rate manipulation (virtual deposits, internal balance tracking), these protections are not perfect for external vaults and assets accepted as collateral. In particular, empty or near-empty external collateral vaults may still be susceptible to manipulation attacks, which could affect the security of any vault accepting them as collateral. Vault governors should carefully evaluate the risk profile of each external vault before accepting it as collateral. Refer to [Donation attacks](/curate/vaults/evk/donation-attacks) for more information.
#### Overflows
There are several potential overflow conditions that could affect vault operations:
* If values such as total supply, borrows, and cash approach their upper limits, the accounting logic of the vault becomes undefined
* The interest accumulator could eventually overflow if interest rates remain extremely high for extended periods
#### Price Oracle Risks
While the oracle adapters themselves (at least those developed by Euler) are immutable, vaults that use a governed oracle router can update their pricing source as long as governance over the router is retained. If the router is finalized or governance is revoked, the oracle configuration becomes immutable. If a price oracle becomes unreliable or compromised and the router is still governed, it can be updated to point to a new, secure adapter. Vaults rely on their configured oracle (or router) for pricing collateral and liabilities, so robust governance and timely updates are critical for security.
#### Nested Vault Limitations
A nested vault is a vault whose underlying asset is the share token of another Euler vault. Using a nested vault as collateral for the vault that issued that underlying share token can cause liquidation to fail due to re-entrancy issues when pricing the nested collateral. While some EVK deployments attempted to prevent this at the code level, this approach introduced operational challenges and is being reconsidered. The risk remains low-severity and is best addressed through careful governance. Vault governors should be aware that using nested vaults as collateral in this configuration may result in failed liquidations and should evaluate this risk when configuring vaults.
### Security Best Practices
#### Vault Configuration
When configuring vaults:
1. Carefully select appropriate LTVs based on both the underlying asset's risk and the vault containing it
2. Consider using both borrowing and liquidation LTVs to protect against oracle price delays and manipulation
3. Configure a non-zero liquidation cool-off period to prevent certain types of price oracle attacks
4. Use LTV ramping when reducing the liquidation LTV to avoid unfair liquidations
#### Collateral Validation
Before accepting a vault as collateral:
1. Verify it was created by a trusted factory by calling the factory's `isProxy()` function
2. Evaluate the security of its underlying asset, price oracle, and configuration
3. Verify that its `transfer` method doesn't invoke any external contracts that could run attacker code
4. Be cautious with vaults that have hooks installed, as they may interfere with liquidations
#### Oracle Security
When selecting price oracles:
1. Use reliable and decentralized oracle solutions when possible
2. Consider using oracles with a non-zero bid-ask spread to communicate real-time pricing risks
3. For cross pricing, ensure that all price sources in the chain are reliable
#### Risk Management
For ongoing risk management:
1. Monitor positions for unhealthy debt-to-collateral ratios
2. Implement robust liquidation systems to ensure unhealthy positions are liquidated efficiently
3. Consider the implications of using a vault as collateral that itself accepts risky collateral
#### Governance Practices
If governing a vault:
1. Make governance actions transparent and predictable to users
2. Use timelocks for sensitive operations like changing LTVs or price oracles
3. Consider using limited governor contracts that can only perform specific actions
4. Have clear procedures for emergency responses to market events or discovered vulnerabilities
### Vault Security Features
#### Liquidation Cool-Off Period
The cool-off period prevents an account from being liquidated inside a block where it was previously healthy. This protection helps prevent certain types of price oracle attacks by forcing attackers to keep positions open between blocks, exposing them to potential risk.
#### LTV Ramping
When reducing liquidation LTVs, a ramp duration can be specified to linearly decrease the LTV over time. This protects borrowers from sudden LTV changes that could cause unfair liquidations.
#### Bad Debt Socialisation
Vaults have bad debt socialisation enabled by default to handle cases where a liquidation still leaves an account with outstanding debt. This prevents bank-run scenarios as it socializes losses to all depositors.
#### Internal Balance Tracking
Vaults track balances internally rather than depending on direct token balance checks. This prevents certain types of donation-based exchange rate manipulations.
## Allocator automation
The [Euler Allocator Bot](https://github.com/euler-xyz/euler-allocator-bot) can monitor Earn vault strategies and submit reallocations according to an operator's policy. Automation should implement an approved allocation mandate rather than choose the mandate itself.
### What to automate
An allocator can evaluate strategy returns, utilization, available liquidity, current allocations, caps, and queue order, then propose or execute moves within configured limits. Reallocation decisions should account for withdrawal capacity and concentration, not APY alone.
### Controls
Keep strategy allowlists, concentration and liquidity limits, transaction-size limits, key management, monitoring, and escalation procedures outside the optimizer. Simulate each transaction against current state and stop automation when inputs are stale, a strategy behaves unexpectedly, or execution repeatedly fails.
For the underlying roles, caps, queues, and reallocation mechanics, see the [allocator handbook](/curate/vaults/euler-earn/allocator-handbook).
## Allocator and manager handbook
This guide covers the onchain controls used to operate an EulerEarn vault. Allocation policy remains vault-specific: strategy selection, concentration, queue order, liquidity reserves, and return objectives should follow the vault's published mandate.
### Roles
* **Owner:** manages all vault settings and inherits Curator, Allocator, and Guardian powers.
* **Curator:** enables strategies, manages caps, and inherits Allocator powers.
* **Allocator:** updates queues and reallocates assets within the configured caps.
* **Guardian:** can revoke specific pending actions.
Monitor current role holders and pending actions onchain. Use multisignature or other controlled accounts where appropriate to the vault's operating model.
### Strategy acceptance and caps
A strategy must be accepted by the selected factory before it can be enabled or receive a cap increase. Acceptance is checked again when a pending cap increase completes.
* Cap decreases, including zero, are immediate.
* Cap increases wait for the current timelock and can be revoked while pending.
* The first accepted positive cap enables the strategy and adds it to the withdrawal queue.
* A zero cap stops new allocation but does not withdraw the existing balance or remove queue entries.
Track both cap headroom and the strategy's current `maxDeposit`. A strategy may be unable to accept the full remaining cap.
### Supply and withdrawal queues
Both queues support up to 30 entries.
**Supply queue:** deposits try strategies in order, bounded by cap headroom and `maxDeposit`. Reverting entries are skipped, but the deposit fails if the complete amount cannot be placed. Reject duplicate entries even though the contract permits them.
**Withdrawal queue:** withdrawals try strategies in order, bounded by tracked assets and `maxWithdraw`. Limited liquidity reduces `maxWithdraw`. During execution, a reverting withdrawal is skipped, but the transaction fails if the remaining strategies cannot provide the requested amount.
Set queue order from the vault's strategy and liquidity policy rather than APY alone. Consider utilization, current liquidity, correlated exposure, withdrawal demand, gas, and failure behavior.
### Reallocate assets
`reallocate` moves listed strategies toward specified target balances. Withdrawals earlier in the list fund supplies later in the list, targets must remain within caps, and the total supplied must equal the total withdrawn.
Before execution:
1. read current balances, caps, queues, pending actions, `maxDeposit`, and `maxWithdraw`;
2. build and simulate the exact ordered allocation;
3. check it against allowed-strategy, concentration, liquidity, and transaction policies;
4. submit and monitor confirmation; and
5. reconcile events with final balances and withdrawal capacity.
### Remove a strategy
#### Normal removal
1. Revoke any pending cap increase.
2. Set the cap to zero.
3. Reallocate recoverable assets to other enabled strategies.
4. Remove the strategy from the supply queue.
5. Once its tracked balance is zero, omit it from the withdrawal queue.
The empty-balance check uses the vault's tracked strategy balance rather than the strategy token's raw `balanceOf` value.
#### Forced removal
Use forced removal only when a strategy persistently reverts and cannot be emptied. With the cap at zero and no pending cap, Owner or Curator submits the removal. Owner, Curator, or Guardian can revoke it. After the timelock, Owner, Curator, or Allocator removes the strategy by omitting it from the withdrawal queue.
Forced removal excludes remaining tracked assets from the active strategy set. It does not transfer or recover them. Quantify the effect on represented assets and withdrawal capacity before proceeding, and communicate the impact to users.
### Fees
The Owner configures the fee separately after deployment. For a nonzero fee, set a nonzero recipient before setting the fee. The maximum is `0.5e18` (50%). Set the fee to zero before clearing the recipient.
Fee-setting calls accrue fees under the previous configuration before applying the change. The documented implementation does not have a separate harvest or yield-smearing operation.
### Monitoring and incident response
Monitor roles, pending actions, factory acceptance, caps, queues, strategy balances, conversions, `maxDeposit`, `maxWithdraw`, transaction failures, fees, and `lostAssets`.
* **Strategy risk signal:** revoke pending cap increases, reduce the cap to zero, simulate and reallocate recoverable assets, then update queues when removal checks pass.
* **Persistently reverting strategy:** stop new allocation, assess normal withdrawal, and use forced removal only if continued operation justifies its accounting impact.
* **Role or key compromise:** stop affected automation, use available uncompromised roles to revoke pending actions or replace roles, rotate keys, and reconcile every change made by the affected address.
### Automate allocation
Reallocation within the controls above can be automated with the [Euler Allocator Bot](https://github.com/euler-xyz/euler-allocator-bot); see [Allocator automation](/curate/vaults/euler-earn/allocator-automation) for what to automate and the guardrails to keep around it.
## Deployment and management of EulerEarn vaults
The [EulerEarn Creator UI](https://earn.euler.finance/) provides a guided way to deploy and manage Earn vaults. This page covers the main workflow and the settings that owners, curators, and allocators use most often.
For scripted deployments or advanced operations, see the [allocator and manager handbook](/curate/vaults/euler-earn/allocator-handbook).
### Deploy a vault
1. Connect your wallet and select the network.
2. Choose **Deploy Vault**.
3. Enter the underlying asset, vault name, symbol, initial owner, and timelock.
4. Review the network, factory, asset, owner, and deployment transaction before submitting.
5. Open the deployed vault from the dashboard to configure its strategy, roles, fees, and security settings.
The dashboard lists vaults associated with the connected address. Confirm the deployed address and current roles onchain before making changes.
### Manage a vault
The vault overview groups management actions into four areas:
* **Strategy:** enable or remove strategies, change caps, manage queues, and reallocate assets.
* **Roles:** assign the Curator, Allocators, and Guardian.
* **Fees:** set the performance fee and fee recipient.
* **Security:** review the timelock and pending actions.
### Strategies, caps, and queues
#### Enable a strategy
A strategy must be accepted by the selected factory. Submit a positive cap to begin the enablement process. Cap increases complete after the configured timelock; cap decreases, including a change to zero, are immediate.
The first accepted positive cap enables the strategy and appends it to the withdrawal queue. Review the strategy and its deployed configuration before enabling it.
#### Supply queue
The supply queue controls where new deposits are allocated. Owner, Curator, or Allocator can update it. Each entry must have a nonzero cap, and deposits try strategies in order until the full amount is placed.
Choose the order according to the vault's allocation policy, available capacity, liquidity, and strategy behavior. Avoid duplicate entries.
#### Withdrawal queue
The withdrawal queue controls the order in which strategies are used to fund withdrawals. When a strategy is first enabled, it is added automatically. Owner, Curator, or Allocator can reorder or remove existing entries.
Put more liquid strategies earlier when that matches the vault's mandate. A strategy with limited liquidity or a reverting call can reduce current withdrawal capacity.
#### Reallocate assets
Owner, Curator, or Allocator can use `reallocate` to move assets between enabled strategies within their caps. Read current balances, caps, queues, `maxDeposit`, and `maxWithdraw`, then simulate the exact transaction before submitting it.
#### Remove a strategy
For a strategy that remains operable:
1. Revoke any pending cap increase.
2. Set its cap to zero.
3. Reallocate available assets into other enabled strategies.
4. Remove it from the supply queue.
5. Once its tracked balance is zero, remove it from the withdrawal queue.
Forced removal is available for a strategy that persistently reverts and cannot be emptied. It follows a timelocked process and does not recover assets left in the strategy. See the [allocator handbook](/curate/vaults/euler-earn/allocator-handbook#forced-removal) before using it.
### Roles
* **Owner:** controls the vault and can perform Curator, Allocator, and Guardian actions.
* **Curator:** manages strategies and caps and can perform Allocator actions.
* **Allocator:** manages supply and withdrawal queues and reallocates assets. A vault can have multiple Allocators.
* **Guardian:** can revoke specific pending actions, including pending cap increases, guardian changes, timelock decreases, and forced removals.
Choose addresses and key controls that fit the vault's operating model. The Guardian is not a universal veto over every change.
### Performance fee
The Owner sets the performance fee and recipient after deployment. The maximum fee is 50%.
For a nonzero fee:
1. set a nonzero fee recipient; then
2. set the fee amount.
Set the fee to zero before clearing the recipient. Fee-setting calls accrue fees under the previous configuration before applying the change.
### Timelock
The initial timelock is selected at deployment. Increasing it is immediate; decreasing it requires a pending action that can complete only after the current delay. The timelock covers selected changes rather than every management action, so review which operations remain immediate.
### Before launch
Verify the deployed network, factory, vault, asset, roles, strategies, caps, queues, fee, timelock, pending actions, metadata, and current withdrawal capacity. Link users to the [EulerEarn guide](/use/euler-earn) and publish the vault's allocation and liquidity policy.
## EulerEarn for curators
EulerEarn lets curators create ERC-4626 vaults that allocate one deposited asset across multiple ERC-4626 strategies. Users receive a single share token, while the vault's configured roles manage strategy selection, allocation, caps, and withdrawal order.
This gives curators, DAOs, and other teams a transparent way to package an allocation strategy without building new deposit and accounting infrastructure for every product.
### What an Earn vault provides
* **Permissionless deployment:** any party can deploy an Earn vault through a factory supported on the selected network.
* **One user position:** depositors hold one ERC-4626 share token while the vault allocates its underlying asset across enabled strategies.
* **Role-based management:** the Owner, Curator, Allocators, and Guardian have defined responsibilities for strategy, allocation, and pending actions.
* **Configurable allocation:** caps and supply and withdrawal queues define where deposits can go and where withdrawals are sourced.
* **Configurable fees and timelocks:** the Owner can set a performance fee and configure delays for selected changes.
* **Immutable vault implementation:** the implementation used by a deployed vault is not upgraded through its vault roles, while roles, strategies, caps, queues, metadata, and fees remain configurable according to contract permissions.
### Plan the vault
Before deployment, define the vault's strategy mandate, accepted-strategy criteria, cap and concentration policy, supply and withdrawal queues, liquidity objective, performance fee, timelock, role controls, monitoring, and user-facing description.
A strategy must be accepted by the selected factory before it can be enabled or receive a cap increase. Factory acceptance checks compatibility with that factory's configured rules; curators should still review the strategy's implementation, initialization, accounting, liquidity, governance, and failure behavior.
### Continue
* [Deployment and management](/curate/vaults/euler-earn/deployment-and-management)
* [Allocator and manager handbook](/curate/vaults/euler-earn/allocator-handbook)
* [Allocator automation](/curate/vaults/euler-earn/allocator-automation)
* [EulerEarn audits](/security/earn-audits)
* [EulerEarn integrator guide](/build/earn-integrator-guide)
* [User guide](/use/euler-earn)
## EulerSwap: a vault-connected, single-LP AMM
### Overview
EulerSwap 2 is a single-LP automated market maker for executing swaps through an Euler account. Instead of depositing assets into a shared standalone AMM pool, the LP connects Euler supply vaults—and, optionally, borrow vaults—to a configurable market-making curve. Supplied assets remain in the LP's Euler positions while the pool uses the same account to settle swaps.
This design brings swap execution and lending positions into one account. The LP may receive swap fees while supplied assets may continue to earn lending interest. When borrowing is configured, the pool may also borrow an output-asset shortfall, subject to vault liquidity, lending relationships, oracle values, caps, account health, and final solvency checks.
### Key features
#### Swap fees alongside lending interest
An LP may receive swap fees while supplied assets continue to earn lending interest. External rewards may also apply when the connected position is eligible. These sources accrue independently and none is guaranteed by deploying a pool.
#### Rehypothecation and optional borrowing
Rehypothecation here means that supplied assets remain in Euler lending positions and can also support borrowing when the connected vault relationships permit it. EulerSwap uses available supplied inventory first. If the output inventory is insufficient, the pool may borrow the shortfall from its configured borrow vault.
Borrowing can make additional output available beyond the pool's current supplied inventory, but it does not guarantee executable depth or lower slippage. Vault liquidity, caps, LTV relationships, oracle values, account health, and final solvency checks can limit or prevent it. Incoming input repays enabled debt for that asset first; any remainder is deposited into its configured supply vault.
#### Customizable curves and fees
Authorized parties can update `DynamicParams`, including equilibrium and minimum reserves, directional prices and concentration, directional fees, expiration, and optional swap-hook settings.
Equilibrium is a curve setting rather than an oracle price, external market price, or account NAV target. Concentration changes the curve shape, and its effect depends on token direction, reserves, prices, and trade size. Review quotes and limits in both directions rather than treating one setting as universally preferable.
#### Single-LP management
Each pool belongs to one Euler account rather than combining liquidity from multiple LPs. The owner controls its configuration directly or through authorized managers. This model supports independently managed and protocol-owned liquidity, while leaving parameter selection, permissions, and ongoing monitoring with the owner and its managers.
The Euler account, vault addresses, and fee recipient are fixed in `StaticParams`. Changing one of these addresses requires a new installation or deployment.
### Mechanics
At a high level, an EulerSwap pool operates as an authorised EVC operator for a selected Euler account:
1. The account owner installs the pool as an operator for that account.
2. The pool reads the configured vault pair, curve parameters, account inventory, and relevant vault state to quote a swap.
3. During execution, input and output amounts are settled through the Euler account and its vaults. Available supplied inventory is used first; if output inventory is insufficient, the pool may borrow the shortfall only when the vault relationships and account health permit it.
4. Callback-based swaps can let an integration source the input during execution, but the transaction must still complete settlement and satisfy the pool's invariant and EVC/vault checks.
5. Interest, price changes, oracle state, and borrowing can change the account's health after deployment. A pool configuration does not remove liquidation or bad-debt risk.
The exact calls and mutable fields differ by EulerSwap generation. For EulerSwap 2 interfaces and deployment details, use versioned source and current deployment addresses rather than older interface screenshots.
### Comparison with standalone AMMs
EulerSwap combines an AMM curve with an Euler account. This changes where liquidity sits and which risks matter; it does not make the position universally more capital-efficient or safer.
| Dimension | EulerSwap | Standalone AMM, generally |
| ------------------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| Asset location | Assets remain in vaults associated with the provider's Euler account | Assets are deposited into the AMM's pool contracts |
| Available output | Can use supplied inventory and, when configured and healthy, borrowed output | Normally limited to assets already held by the pool |
| Lending interaction | Supplied balances may earn vault interest; borrowed balances accrue interest | Lending requires a separate integration or strategy |
| Account risk | Includes vault, oracle, borrowing, health, liquidation, and collateral-relationship risk | Primarily pool inventory, curve, token, oracle/integration, and contract risk |
| Curve configuration | Supports directional concentration, equilibrium, and fee parameters according to the deployed generation | Depends on the AMM design and pool type |
| Position boundary | The pool acts through a selected EVC account under its authorisation | Ownership is commonly represented by LP shares or a position NFT |
Compare exact deployed implementations, fee paths, oracle assumptions, and transaction simulations. Category labels are not substitutes for contract-level review.
### JIT liquidity, callbacks, and hooks
Just-in-time (JIT) liquidity means borrowing an output-asset shortfall during swap execution when a borrow vault is configured and the lending checks permit it. Supplied inventory is used first.
A flash swap is a separate callback-style flow. Callback execution and JIT vault borrowing are distinct mechanisms.
A pool can also configure a swap hook. Integrators should inspect the hook and account for any conditions it adds to execution or reconfiguration.
### Risk considerations
An EulerSwap LP position can include supplied inventory, debt, and AMM exposure. Outcomes depend on market direction, inventory, borrowing rates, liquidations, curve settings, fees, rewards, oracles, vault liquidity, managers, and hooks. Account health is an important risk signal, not a guarantee against loss.
See [LP considerations](/curate/euler-swap/lp-considerations) before configuring a pool.
### Integration checks
Before submitting a swap:
* confirm the EulerSwap version and pool address;
* inspect fixed and current dynamic parameters, managers, hook, expiration, and connected vaults;
* obtain a quote and limits through supported EulerSwap 2 interfaces such as `computeQuote` and `getLimits`;
* apply an execution bound; and
* account for reconfiguration, inventory changes, lending constraints, oracle movement, hook behavior, and slippage between quote and execution.
Direct EulerSwap 2 calls and periphery or Uniswap v4-hook routes are separate integration paths. Measure gas and execution behavior for the exact version, network, pool, and route used.
## Considerations for liquidity providers and curators
Providing liquidity through EulerSwap combines an AMM position with Euler supply positions and, when enabled, borrowing. LPs can configure the pool for a particular pair and strategy, but should monitor both its market-making exposure and the connected lending positions.
### Configure the pool
Equilibrium reserves, minimum reserves, directional prices, concentration, and fees shape quotes and inventory changes in each direction. Review both directions under a range of trade sizes before launch.
These settings are dynamic in EulerSwap 2. An authorized owner or manager can update them with `reconfigure`; changing equilibrium or fees does not generally require reinstalling the pool. A new installation is needed when fixed `StaticParams` must change.
Lower concentration does not always mean lower risk, and rebalancing does not guarantee a neutral position. Either change can affect depth, price impact, inventory, debt, slippage, liquidation exposure, and realized loss.
### Monitor inventory and debt
Track supplied inventory and debt separately for each asset, especially when the supply and borrow vaults differ. Output uses supplied inventory first and borrows only an optional shortfall. Incoming input repays enabled debt for that asset before any remainder is supplied.
Monitor:
* reserves, prices, concentration, fees, and expiration;
* manager permissions and hook configuration;
* supplied balances and debt for both assets;
* vault utilization, rates, caps, and available liquidity;
* oracle routes and account health; and
* quotes and execution bounds in both swap directions.
### LTV and liquidation
LTV is configured in the lending relationship between connected vaults, not in the EulerSwap curve. Borrowing can increase available swap liquidity, but it also adds interest costs and liquidation exposure. A pool may be unable to borrow when liquidity, caps, LTVs, oracle values, or final solvency checks do not permit it.
### Maintenance
Quotes can become stale after a pool reconfiguration, inventory change, interest accrual, vault or oracle update, or hook execution. Re-read state before transactions and allow for failed or delayed monitoring and execution.
Fee income, lending interest, and rewards should be tracked separately from inventory changes, borrowing costs, and realized losses. Their availability and value depend on activity and external conditions.
For operating instructions, verify that any interface or guide targets the same EulerSwap generation and deployed pool. Do not apply instructions from another interface or EulerSwap generation.
## Earn integrator guide
EulerEarn vaults package multiple yield strategies into a single ERC-4626 vault. An integration can generally treat an Earn position as a vault share while using Euler's SDK and data services to discover vaults, display positions, and prepare user actions.
### Choose an integration path
| Need | Start with |
| ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| Build application flows and work with Euler entities | [Euler SDK](/build/sdk) |
| Discover Earn vaults and query indexed vault data | [Euler Data API V3](/build/data-querying/euler-v3-api) |
| Display names, curators, and listing status | [Known vaults and metadata](/build/data-querying/perspectives) |
| Discover indexed account positions | [Subgraphs](/build/data-querying/subgraphs) |
| Read current protocol state | [Lens contracts](/build/data-querying/lens-contracts) or direct contract calls |
| Find deployments and version-matched interfaces | [Contract addresses](/build/contract-addresses) and [Euler interfaces](https://github.com/euler-xyz/euler-interfaces) |
For most TypeScript applications, the SDK is the best starting point. It brings together common reads, metadata, transaction planning, approvals, and simulation. Use the Data API for indexed and historical information, then confirm execution-sensitive state onchain.
### Typical integration flow
1. Discover supported Earn vaults and load their metadata.
2. Show the vault's underlying asset, share position, performance, allocation, and available liquidity.
3. Let users enter or exit through the supported SDK flow or the vault's standard ERC-4626 interface.
4. Simulate the final transaction against current chain state before submission.
5. Track the resulting position through the SDK, Data API, or your own indexer.
Simple integrations do not need to reproduce Euler's internal strategy-management logic. Advanced applications can add custom contract reads or [EVC batching](/build/evc/integration-guide) where a flow requires multiple atomic actions.
### Things to account for
* Earn vaults may use different assets and share decimals; format values from contract or SDK metadata.
* Quotes, previews, APYs, and withdrawal limits change with onchain state.
* Withdrawals depend on liquidity across the vault's strategies and withdrawal queue.
* Indexed services can lag the chain, so do not use them as the final authority for transaction validity.
* A vault appearing in Euler metadata is not a guarantee of future safety or performance.
See [Earn products](/build/earn-products) for the product model and [EulerEarn audits](/security/earn-audits) for security reviews.
## Euler Lite
[`euler-lite`](https://github.com/euler-xyz/euler-lite) is an open-source frontend codebase for Euler V2. It packages lending, borrowing, portfolio, rewards, and optional product pages into a self-hosted interface that operators can configure and theme.
Use Euler Lite as a starting codebase rather than assuming it supports every deployment or workflow. It uses the [Euler V2 SDK](https://github.com/euler-xyz/euler-sdks); verify the repository revision, configured chains, data sources, transaction plans, and contracts for your deployment.
### Product scope
Euler UI exposes the core flows a lending frontend needs:
* **Lend:** deposit assets into selected Euler vaults to earn yield.
* **Borrow:** open and manage debt positions against accepted collateral.
* **Portfolio:** track positions and performance.
* **Rewards:** show supported Merkl, Incentra, and Fuul reward programs.
* **Multichain:** configure networks represented in the app's supported chain registry and wallet setup. An unknown chain can require code, registry, address, and data-source changes.
* **Optional pages:** toggle Earn, Lend, Explore, entity branding, vault-type labels, reward integrations, policy links, and social links through configuration.
### Prerequisites
* **Node.js** 24+ (24.14.1 recommended)
* **npm**
* **Git**
* A **Reown Project ID** (formerly WalletConnect), obtainable at [reown.com](https://reown.com)
### Quick start
```bash
git clone https://github.com/euler-xyz/euler-lite
cd euler-lite
npm ci
cp .env.example .env
# Fill in required values (see below)
npm run dev
```
The app will be available at `http://localhost:3000`.
#### Required environment variables
| Variable | Description |
| ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- |
| `APPKIT_PROJECT_ID` (or `NUXT_PUBLIC_APP_KIT_PROJECT_ID`) | Reown (WalletConnect) project ID. |
| `NUXT_PUBLIC_APP_URL` | Your app's public URL. |
| `RPC_URL_` | RPC endpoint per chain (e.g. `RPC_URL_1` for Ethereum). |
| `SUBGRAPH_URL_` (or `NUXT_PUBLIC_SUBGRAPH_URI_`) | Subgraph URI per chain. `SUBGRAPH_URL_*` is server-only and preferred; `NUXT_PUBLIC_SUBGRAPH_URI_*` remains supported. |
The server reads `RPC_URL_` and the matching subgraph setting at startup. Environment variables alone do not establish complete support for an unknown chain; verify the app registry, wallet configuration, contract addresses, SDK adapters, and data sources.
```bash
# Ethereum Mainnet
RPC_URL_1=https://your-rpc-endpoint.com
SUBGRAPH_URL_1=https://your-subgraph-host/euler-mainnet/latest/gn
# Arbitrum
RPC_URL_42161=https://your-arbitrum-rpc.com
SUBGRAPH_URL_42161=https://your-subgraph-host/euler-arbitrum/latest/gn
```
#### API endpoints
| Variable | Default | Description |
| ---------------------------------------------- | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `V3_API_URL` (or `EULER_SDK_V3_API_URL`) | `https://v3.euler.finance` | Euler V3 upstream used by the internal server proxy and SDK configuration. |
| `EULER_SDK_V3_API_KEY` | — | Optional server-side V3 API key forwarded as `X-API-Key`. |
| `SWAP_API_URL` (or `NUXT_PUBLIC_SWAP_API_URL`) | — | Euler swap API. |
| `PYTH_API_KEY` | — | Optional server-side API key sent as Bearer authentication by the internal update proxy (`/api/internal/pyth/updates`) to its hard-coded `https://hermes.pyth.network` upstream. |
#### SDK data-source controls
| Variable | Default | Description |
| ---------------------------------- | ---------- | --------------------------------------------------------------------------------------------------- |
| `SERVER_VAULT_CACHE_SOURCE` | `fallback` | Server snapshot builder adapter chain: `fallback`, `onchain`, or `v3`. |
| `NUXT_PUBLIC_BROWSER_VAULT_SOURCE` | `fallback` | Browser fast SDK adapter chain: `fallback`, `onchain`, or `v3`. Plan-time SDK reads remain onchain. |
| `DISABLE_SERVER_VAULT_CACHE` | `false` | Disable internal server vault snapshots and let the browser use the configured RPC pipeline. |
| `DEPRECATED_CHAINS` | — | Comma-separated chain IDs shown collapsed in the chain selector and skipped by warm-cache cycles. |
| `ONCHAIN_SDK_CHAINS` | — | Chain selection for configured onchain SDK reads; verify current syntax in the repository. |
| `EVAULT_FETCH_CHUNK_CHAINS` | — | Chain selection for chunked EVault fetching; verify current syntax in the repository. |
The current implementation routes these server functions under internal paths such as `/api/internal/v3`, `/api/internal/pyth/updates`, and `/api/internal/vaults`. Treat internal routes as implementation details and verify them against the pinned repository revision before building integrations around them.
### Customization
Euler UI is designed to be rebranded with minimal code changes:
* **Theme colors:** edit the `THEME CONFIGURATION` section at the top of `assets/styles/variables.scss`. Accent, status, chart, and graph palettes (plus their light/dark overrides and derived shadows/glows) all flow from these CSS custom properties.
* **Logo:** the logo renders as an inline SVG using `currentColor`, so it follows the accent color by default. Set `NUXT_PUBLIC_CONFIG_LOGO_URL` to use a custom logo, with the built-in Euler logo as fallback.
* **Favicon:** replace `favicon.ico` and `favicon.svg` in `public/favicons/`.
* **Token icons:** drop overrides into `assets/tokens/.png`. Icons otherwise resolve from a unified server-side token list aggregating the Euler SDK list, DefiLlama, Uniswap, and Merkl.
* **Branding and feature flags:** toggle pages (Earn, Lend, Explore), entity branding, vault-type labels, reward integrations (Merkl, Incentra, Fuul), social links, policy URLs, titles, and more via `NUXT_PUBLIC_CONFIG_*` environment variables.
* **Curated Earn vaults:** point the app at your own labels repository with chain-specific `earn-vaults.json` files to restrict which EulerEarn vaults are shown. With the default `euler-xyz/euler-labels` repository, entries selected by the configured labels and discovery logic may appear. Verify the filtering behavior against the pinned Euler Lite and labels revisions.
See the repository [`README`](https://github.com/euler-xyz/euler-lite#readme) for the full list of `NUXT_PUBLIC_CONFIG_*` flags and SDK data-source controls.
### Security boundaries
Keep RPC credentials, API keys, signer material, and other secrets in server-only variables and a secret manager. Any `NUXT_PUBLIC_*` value is delivered to the browser and must be treated as public. Review which server endpoints proxy privileged upstreams, restrict CORS to intended origins, configure a content-security policy, rate-limit exposed endpoints, and avoid embedding unrestricted provider keys in client bundles.
Self-hosting also makes the operator responsible for dependency updates, domain and TLS configuration, wallet/app identifiers, policy links, monitoring, logging, incident response, and validation of every enabled chain and transaction flow.
### Build and deployment
```bash
npm run build
npm run preview # preview locally
```
The repository includes a Dockerfile with [Doppler](https://www.doppler.com/) integration for runtime secret injection:
```bash
docker build --build-arg APP_PORT=3000 -t euler-lite .
docker run -p 3000:3000 \
-e DOPPLER_TOKEN=your-doppler-token \
-e DOPPLER_PROJECT=euler-lite \
-e DOPPLER_CONFIG=production \
euler-lite
```
To run without Doppler, pass the required environment variables directly and override the default `CMD`:
```bash
docker run -p 3000:3000 \
-e V3_API_URL=https://v3.euler.finance \
-e EULER_SDK_V3_API_KEY=your-v3-api-key \
-e SWAP_API_URL=https://swap.euler.finance \
-e APPKIT_PROJECT_ID=your-project-id \
-e RPC_URL_1=https://your-rpc.com \
-e SUBGRAPH_URL_1=https://your-subgraph.com \
euler-lite node .output/server/index.mjs
```
### Repository
Source, issue tracker, and full configuration reference: [github.com/euler-xyz/euler-lite](https://github.com/euler-xyz/euler-lite).
### Read next
* [Build](/build)
* [Euler SDK](/build/sdk)
* [Reference](/reference)
## Liquidation bot
Liquidation bots monitor Euler accounts, identify unhealthy positions, simulate liquidation candidates, and may submit transactions under operator-defined constraints. Simulation and expected profit do not guarantee successful or profitable execution.
Read [Liquidations](/learn/liquidations) first if you need the protocol mechanics: health, reverse Dutch discounts, maximum liquidation discount, cool-off time, and bad-debt behavior.
### Reference implementation
[`liquidation-bot-v3`](https://github.com/euler-xyz/liquidation-bot-v3) is the reference liquidation bot for Euler V3. It is a Rust binary (built with Cargo) that runs as a long-lived process against a single chain.
On startup it does a one-shot historical sync from the Euler subgraph to discover every active borrower, then keeps account state fresh in three concurrent ways:
* It watches the EVC contract for on-chain events, so any new or changed account is picked up in real time.
* It polls the configured oracles (including Pyth) on a fixed interval. When a price moves, every account that depends on the affected oracle is re-evaluated.
* It runs a full resync and health check across every tracked account on a longer interval as a safety net.
When an account becomes unhealthy, the bot picks the most profitable borrow/collateral pair, gets a swap quote from the Euler swap API for the seized collateral, simulates the liquidation, and, if the result is profitable, submits it through the configured liquidator contract. Profit is routed to the configured profit receiver.
| Resource | Use |
| ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| [liquidation-bot-v3](https://github.com/euler-xyz/liquidation-bot-v3) | Reference bot for account monitoring, oracle polling, opportunity detection, simulation, execution, and operations. |
| [EVC integration guide](/build/evc/integration-guide#5-liquidations-with-controlcollateral) | Understand how liquidations are coordinated through EVC-controlled collateral movement. |
| [Data API](/build/data-querying/euler-v3-api) | Query indexed protocol data for vaults, accounts, prices, liquidations, and timelines. |
| [Lens contracts](/build/data-querying/lens-contracts) | Read on-chain account and vault state for monitoring and validation. |
### Configuration
The reference bot merges configuration from three layers (later layers override earlier ones):
1. An `RPC_URL_` environment variable, which seeds the RPC endpoint for the matching chain.
2. A `Config..toml` file loaded from the working directory. Ready-made files for every supported chain ship in the repository's `configs/` directory.
3. Other environment variables, mapped onto config fields by name (for example `EOA_PRIVATE_KEY`, `SUBGRAPH_URL_PREFIX`).
`CHAIN_ID` selects which config file is loaded and which `RPC_URL_` value is used. The shipped TOML files contain the chain-specific contract addresses and subgraph paths, but deliberately exclude secrets, RPC endpoints, and the subgraph host. Those are supplied through environment variables.
#### Required environment variables
| Variable | Purpose |
| --------------------- | -------------------------------------------------------------------------------------------- |
| `CHAIN_ID` | Selects which `Config..toml` is loaded. |
| `RPC_URL_` | RPC endpoint for the chain. The chain id in the name must match `CHAIN_ID`. |
| `SUBGRAPH_URL_PREFIX` | Subgraph host, joined with `subgraph_url_path` from the TOML file to form the full endpoint. |
| `EOA_ADDRESS` | Public address of the signing wallet. Validated against `EOA_PRIVATE_KEY` on startup. |
| `EOA_PRIVATE_KEY` | Private key for the signing wallet. |
#### Key config fields
The TOML files define everything chain-specific, including the contract addresses the bot depends on:
* `evc_address`, `swapper_address`, `liquidator_address`, and the `oracle_lens_address`, `account_lens_address`, `vault_lens_address`, and `utils_lens_address` lens contracts.
* an optional `[pyth]` table with `address` and `endpoint` keys (the endpoint must end with `/`; omit the whole table on chains without a Pyth deployment), and `wrapped_native_asset_address`.
* `swap_url` and `pricing_url` for collateral-to-debt quotes and profitability evaluation.
* `profit_receiver` for liquidation profit.
* `oracle_polling_interval_seconds` and `full_resync_and_check_interval_seconds` to tune how aggressively the bot tracks price moves and re-checks accounts.
* `simulation_mode` (spins up a local Anvil fork and settles every liquidation against the fork instead of the real network — useful for dry-running against live data).
* `enable_observability_api` and `vault_filter` (`None`, `Whitelist`, or `Blacklist`) to restrict which vaults the bot tracks.
On startup the bot validates the configuration: it confirms the RPC reports the expected chain id, the signing key matches the configured EOA, and every configured contract address has bytecode deployed. If any check fails, the bot exits.
#### Observability API
When `enable_observability_api` is enabled, the bot serves a read-only HTTP API on port `3000`:
> **Do not expose this service directly to the public internet.** The reference service binds `0.0.0.0:3000`, permits broad CORS, and `/accounts` exposes tracked positions. Bind privately where supported, firewall the port, or place it behind an authenticated reverse proxy. Restrict CORS, monitor access, and treat the service as operationally sensitive even though its methods are read-only.
* `GET /health` — current state (`Syncing`, `Healthy`, or `Error`).
* `GET /accounts` — tracked accounts with computed health, dependent oracles, and positions.
* `GET /oracles` — known oracles with their latest cached value.
### Supported chains
The `configs/` directory contains chain-specific configuration. Adding a chain requires compatible deployed contracts, valid addresses, RPC and subgraph/data access, oracle support, code-path compatibility, a reviewed `Config..toml`, and end-to-end simulation and submission testing. Confirm current support and addresses against the pinned repository and [Contract addresses](/build/contract-addresses) before production use.
### Run it
The bot is a Rust binary (Cargo, edition 2024). Build and run from a directory containing the relevant config file:
Load signing keys from a secret manager. Use a least-privilege, minimally funded signer; keep secrets out of shell history, process listings, and logs; and monitor simulation and submission failures. The environment exports below illustrate required names only and are not a recommended production secret-loading method.
```bash
cargo build --release
export CHAIN_ID=1
export RPC_URL_1="https://your-mainnet-rpc"
export SUBGRAPH_URL_PREFIX="https://your-subgraph-host/"
export EOA_ADDRESS="0xYourWalletAddress"
export EOA_PRIVATE_KEY="0xYourPrivateKey"
cd configs
../target/release/liquidation-bot-v3
```
A multi-stage Dockerfile is included. It uses [Doppler](https://www.doppler.com/) for secret injection by default; the entrypoint is straightforward to adapt if you supply environment variables another way. The image does not include Foundry, so `simulation_mode` (which spawns a local Anvil fork) requires adding Foundry to the image or running the bot outside Docker.
### Operator checklist
Use this non-exhaustive checklist before running a liquidation bot with real funds:
* Target chain, RPC endpoints, oracle polling and resync intervals, and retry behavior.
* Current EVC, lens, oracle, swapper, liquidator, and Pyth contract addresses for the chain.
* Account-health calculation against the controller vault's `accountLiquidity` behavior.
* Oracle routes, pull-oracle (Pyth) update requirements, and stale-price handling.
* Profit threshold, gas model, slippage limits, swap routing, and profit receiver.
* Secret-manager integration, least-privilege signer funding, nonce management, transaction replacement, and submission method.
* Observability API, metrics, logs, alerting, and incident response.
* A `simulation_mode` rehearsal against a fork and small-size runs before production sizing.
### Risks
Liquidation automation is competitive and operationally sensitive. A bot can lose money through stale data, reverted transactions, bad quotes, oracle updates, gas spikes, RPC failures, private-key compromise, or unexpected vault configuration. Treat the reference bot and dashboard as starting points, not guarantees.
### Read next
* [Liquidations](/learn/liquidations)
* [Interact with Euler](/build/evc/integration-guide)
* [Data querying](/build/data-querying)
* [Audits](/security/audits)
## Euler SDK
The Euler V2 SDK is the recommended TypeScript entry point for applications, bots, scripts, and operational tooling built on Euler V2. It reads protocol data, composes Ethereum Vault Connector (EVC) batches, simulates transactions, resolves approvals, and executes plans from frontend or backend clients.
The SDK package lives in the [`euler-sdks`](https://github.com/euler-xyz/euler-sdks/tree/main/packages/euler-v2-sdk) monorepo. Use this page as the high-level entry point, then follow the package docs and runnable examples for implementation details.
### What the SDK Provides
* Fetching account, vault, wallet, and market data
* Planning and composing EVC transaction batches
* Resolving approvals (standard `approve` and Permit2 paths)
* Simulating and estimating transaction plans with optional state overrides
* Swaps, pricing, rewards, labels, FeeFlow, and deployed address resolution
* Oracle adapter metadata and checks (provider, methodology, validation)
The SDK is built with dependency injection: use `buildEulerSDK()` for the default setup, run individual services in isolation, or plug in custom implementations.
### Installation
Use the latest stable release:
```bash
npm install @eulerxyz/euler-v2-sdk
```
### Minimal Setup
```typescript
import { buildEulerSDK } from "@eulerxyz/euler-v2-sdk";
import { mainnet } from "viem/chains";
const sdk = await buildEulerSDK({
config: {
rpcUrls: {
[mainnet.id]: "https://your-mainnet-rpc",
},
},
});
```
You can also configure RPC URLs with environment variables:
```bash
EULER_SDK_RPC_URL_1=https://your-mainnet-rpc
```
### Common Workflows
#### Read Accounts And Vaults
Use `accountService`, `portfolioService`, and `vaultMetaService` for user and market data.
```typescript
const { result: account } = await sdk.accountService.fetchAccount(
mainnet.id,
"0xOwner...",
{
populateAll: true,
},
);
const { result: portfolio } = await sdk.portfolioService.fetchPortfolio(
mainnet.id,
"0xOwner...",
);
const { result: vault } = await sdk.vaultMetaService.fetchVault(
mainnet.id,
"0xVault...",
);
```
Use `vaultMetaService` when you do not know whether an address is an EVault, EulerEarn vault, or another supported vault type.
Services can enrich (populate) their own entities with data from other services. For example, the account service can fetch vault details, token prices, rewards, and other data for user positions.
#### Plan, Simulate, And Execute Transactions
The `executionService` builds transaction plans for common Euler actions such as deposit, borrow, repay, withdraw, redeem, multiply, liquidation, debt transfer, and swap-driven flows. Plans separate required approvals from executable EVC batch items.
```typescript
import { parseUnits } from "viem";
const { result: account } = await sdk.accountService.fetchAccount(
mainnet.id,
"0xOwner...",
);
const plan = sdk.executionService.planDeposit({
account,
vault: "0xVault...",
asset: "0xAsset...",
receiver: "0xReceiverOrSubAccount...",
amount: parseUnits("100", 6),
enableCollateral: true,
});
const simulation = await sdk.executionService.simulateTransactionPlan(
mainnet.id,
account,
plan,
{ stateOverrides: true },
);
if (simulation.canExecute) {
await sdk.executionService.executeTransactionPlan({
plan,
chainId: mainnet.id,
account,
sendTransaction: walletClient.sendTransaction,
signTypedData: walletClient.signTypedData,
});
}
```
`executeTransactionPlan` processes configured plugins, resolves approvals, requests Permit2 signatures when needed, sends direct contract calls, and submits the final EVC batch.
#### Use Swaps, Rewards, Plugins, And FeeFlow
Use `swapService` for quote-backed operations such as repay-with-swap, deposit-with-swap, wallet-to-wallet swaps, wallet swap-and-borrow, wallet swap-and-repay, withdraw-and-swap, redeem-and-swap, swap collateral, and swap debt.
Use `rewardsService` to fetch campaign data, populate account and vault rewards, and build provider-specific reward claim plans.
Use `feeFlowService` to fetch FeeFlow state, filter eligible vaults, and build FeeFlow buy plans.
Use plugins for flows that need extra read-path or plan-path behavior, such as pull-based oracle updates.
### Examples
The repository ships with runnable examples:
* [TypeScript script examples](https://github.com/euler-xyz/euler-sdks/tree/main/packages/euler-v2-sdk/examples) - deposits, borrows, swaps, swap-and-borrow, swap-and-repay, withdraw-and-swap, redeem-and-swap, liquidations, wallet reads, simulations, FeeFlow, and end-to-end execution flows.
* [React app example](https://github.com/euler-xyz/euler-sdks/tree/main/packages/euler-v2-sdk/examples/react-sdk-example) - full frontend using React Query and Wagmi.
### Further Reading
Detailed documentation lives in [`packages/euler-v2-sdk/docs`](https://github.com/euler-xyz/euler-sdks/tree/main/packages/euler-v2-sdk/docs), covering:
* [Configuration](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/configuration.md)
* [Config Through Env](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/config-through-env.md)
* [Basic Usage](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/basic-usage.md)
* [SDK Architecture Overview](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/sdk-architecture-overview.md)
* [Services](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/services.md)
* [Wallet Service](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/wallet-service.md)
* [Execution Service](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/execution-service.md)
* [Simulations And State Overrides](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/simulations-and-state-overrides.md)
* [Swaps](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/swaps.md)
* [Pricing System](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/pricing-system.md)
* [Rewards Service](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/rewards-service.md)
* [Fee Flow Service](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/fee-flow-service.md)
* [Data Architecture](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/data-architecture.md)
* [Cross-Service Data Population](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/cross-service-data-population.md)
* [Portfolio](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/portfolio.md)
* [Account Computed Properties](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/account-computed-properties.md)
* [Caching External Data Queries](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/caching-external-data-queries.md)
* [Plugins](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/plugins.md)
* [Labels](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/labels.md)
* [Decoding Smart Contract Errors](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/decode-smart-contract-errors.md)
* [Entity Diagnostics](https://github.com/euler-xyz/euler-sdks/blob/main/packages/euler-v2-sdk/docs/entity-diagnostics.md)
import { NetworkTabs } from "../../components/NetworkTabs";
## Contract addresses
The tables load the current production entries from the canonical [`EulerChains.json`](https://github.com/euler-xyz/euler-interfaces/blob/master/EulerChains.json) registry in [`euler-interfaces`](https://github.com/euler-xyz/euler-interfaces), which you can also consult directly.
### Networks
Select a network you would like to view contract addresses for:
### Read next
* [Build](/build)
* [Euler SDK](/build/sdk)
* [Reference](/reference)
## Earn products
### Overview
EulerEarn vaults are ERC-4626 vaults that accept one underlying asset and issue one share token. An allocator can route deposited assets among strategies enabled for that Earn vault, including Euler lending vaults and other factory-accepted ERC-4626 strategies. A single share position simplifies portfolio handling; it does not remove strategy, liquidity, role, or smart-contract risk.
An Earn vault can enable a strategy only when its factory currently allows it: the factory's configured perspective verifies the strategy, or the strategy is another Earn vault created by that factory. ERC-4626 conformance and factory acceptance are compatibility gates, not safety guarantees. Review the implementation, initialization, liquidity, governance, and dependencies of every strategy.
### What you can build
### Build flow
| Step | Read |
| ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| Integrate deposits, withdrawals, and shares | [EulerEarn integrator guide](/build/earn-integrator-guide) |
| Read position and allocation data | [Data API](/build/data-querying/euler-v3-api), [Subgraphs](/build/data-querying/subgraphs) |
| Resolve display metadata and known-vault status | [Vault metadata](/build/data-querying/perspectives) |
| Review withdrawal liquidity | [EulerEarn integrator guide](/build/earn-integrator-guide) |
| Review contract security | [EulerEarn audits](/security/earn-audits) |
| Launch or operate a vault | [Introduction](/curate/vaults/euler-earn/introduction), [Deployment and management](/curate/vaults/euler-earn/deployment-and-management) |
### How underlying markets shape an Earn product
An Earn vault inherits dependencies from every strategy it uses. For an EVK lending strategy:
* **Oracle routes** value collateral and debt and therefore affect solvency, liquidation, and bad-debt risk. They do not directly set the borrowing interest rate.
* **Interest-rate models and utilization** determine borrowing rates and the lending-rate component of supplier APY.
* **Hooks** can permit, reject, or modify configured operation flows.
Rewards, allocation changes, performance fees, liquidity, and losses can further change an Earn vault's realized result. Review each mechanism separately; a quoted APY does not summarize oracle, liquidation, hook, strategy, or withdrawal risk.
Withdrawal capacity also depends on strategy liquidity and withdrawal-queue order. High utilization, losses, or failed strategy calls can reduce the amount available even when shares retain value, so integrations should check current limits and simulate withdrawals against current state.
## Build on Euler
Euler provides a TypeScript SDK, data APIs, lens contracts, and composable smart contracts for integrating lending into apps, wallets, exchanges, bots, and other products.
### Start here
| Goal | Guide |
| ----------------------------------------------- | ----------------------------------------------------- |
| Add supply, borrow, repay, or withdraw flows | [Euler SDK](/build/sdk) |
| Discover markets and display live protocol data | [Data API](/build/data-querying) |
| Interact with accounts and vaults onchain | [EVC integration guide](/build/evc/integration-guide) |
| Integrate an EulerEarn vault | [Earn integrator guide](/build/earn-integrator-guide) |
| Build liquidation infrastructure | [Liquidation bot](/build/liquidation-bot) |
| Run a branded Euler interface | [Euler Lite](/build/euler-lite) |
### Contracts
* [Ethereum Vault Connector](/build/evc) coordinates accounts, sub-accounts, operators, batching, and account checks.
* [Interact with EVK vaults](/build/evk/interacting-with-vaults) covers direct lending-vault integrations.
* [EVK Periphery](/build/periphery) contains factories, governors, lenses, swaps, and supporting contracts.
Use [Contract addresses](/build/contract-addresses) for deployed contracts and [Euler interfaces](https://github.com/euler-xyz/euler-interfaces) for ABIs and Solidity interfaces.
To create and operate a market or vault, continue to [Curate](/curate). Review the relevant [audits](/security/audits) and deployed contract versions before shipping an integration.
## Institutional vaults on Euler
On Euler, an institutional vault is an EVK lending vault or EulerEarn vault tailored to an institution's assets, participants, risk framework, and operating requirements.
### What Euler provides
| Need | Euler component | What it does |
| ------------------------ | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- |
| Lending or credit market | [Euler Vault Kit](/curate/vaults/evk/overview) | Configures the asset, accepted collateral, LTVs, oracle, interest-rate model, caps, liquidations, fees, and governance. |
| Managed yield product | [EulerEarn](/curate/vaults/euler-earn/introduction) | Holds one asset and allocates it across approved ERC-4626 strategies using caps, supply queues, and withdrawal queues. |
| Participant restrictions | [EVK hooks](/curate/vaults/evk/hooks-custom-logic) | Allow or reject selected EVK operations using an onchain allowlist, credential registry, or other policy contract. |
| Administrative controls | [EVK governance](/curate/governance-contracts) and [EulerEarn roles](/curate/vaults/euler-earn/introduction) | Separate responsibilities, add delays, and define emergency permissions. |
| Application integration | [SDK](/build/sdk), [EVC](/build/evc/integration-guide), and ERC-4626 interfaces | Support deposits, withdrawals, borrowing, repayment, batched transactions, and position data. |
### Common structures
* **Permissioned lending market:** approved lenders supply an asset and approved borrowers borrow against configured collateral.
* **Institutional yield vault:** an EulerEarn vault allocates treasury or client assets across a defined set of strategies.
* **RWA-backed market:** tokenized assets are used as the supplied asset or collateral, with oracle, liquidity, redemption, and transfer assumptions reflected in the market configuration.
* **Governed public market:** participation is open, while an institution manages caps, collateral, rates, and emergency controls under a published mandate.
### How to build one
1. Choose EVK for a lending market or EulerEarn for a managed allocation product.
2. Define the underlying asset, permitted participants, liquidity requirements, and operating roles.
3. Configure collateral, LTVs, oracle routes, interest rates, and caps for EVK, or strategies, caps, and queues for EulerEarn.
4. Add hooks only where an operation needs an onchain access or policy check.
5. Assign governance, timelock, allocator, guardian, and emergency permissions as required by the product.
6. Integrate deposits, withdrawals, reporting, and transaction review, then test normal, restricted, and emergency flows.
Euler enforces the configured onchain rules. Identity verification, legal eligibility, custody, asset issuance and redemption, and regulatory reporting remain external processes operated by the institution and its providers.
### Read next
* [EVK overview](/curate/vaults/evk/overview)
* [Create and manage an EVK vault](/curate/vaults/evk/creator-ui)
* [EulerEarn for curators](/curate/vaults/euler-earn/introduction)
* [Hooks and custom logic](/curate/vaults/evk/hooks-custom-logic)
* [RWA vaults](/build/rwa-vaults)
## Tokenized-asset markets
A tokenized asset can be used in an EVK market only with assumptions about valuation, transferability, liquidity, governance, and legal rights. Euler provides lending and collateral infrastructure; it does not issue, sponsor, value, redeem, distribute, or determine eligibility for the underlying asset.
### External dependencies
Assess and document:
* issuer, custodian, administrator, and transfer-agent responsibilities;
* holder and redemption rights and the legal process for enforcing them;
* eligibility, transfer restrictions, freezes, blacklists, and clawbacks;
* default, insolvency, impairment, and dispute scenarios;
* trading calendars, settlement timing, redemption gates, fees, and minimums;
* NAV or reference-price publication, staleness, corrections, and market-price divergence; and
* jurisdiction, disclosure, data, and operational requirements.
A token contract, hook, oracle, or metadata label does not establish those offchain facts.
### Valuation and realizability
Configure the liability vault's oracle route for the intended unit of account and stress both stale and unavailable sources. If an ERC-4626 share is resolved through `convertToAssets`, assess manipulation, decimals, recursion, redemption liquidity, gates, fees, slippage, user restrictions, and whether the quoted assets can actually be realized during liquidation. A stable NAV or conversion quote does not guarantee executable liquidity.
### Transfer and liquidation design
Hooks can cover configured vault operations or vault-share transfers. They do not replace issuer/token-level restrictions or offchain eligibility processes. Document which actors and actions are checked, including deposits, borrows, EVC batches, sub-accounts, transfers, repayments, withdrawals, and liquidations.
Define eligible liquidators and test what happens when collateral is seized but cannot transfer, trade, settle, or redeem. Include provider outages, revocation, freezes, closed trading days, stale valuation, and delayed settlement.
### Exposure boundaries
Isolating a tokenized asset in a separate market can reduce direct exposure, but dependencies can remain through collateral relationships, shared liability or collateral vaults, oracle/router governance, liquidity, hooks, applications, and integrators. Review the complete relationship graph rather than relying on an “isolated” label.
Caps, LTVs, liquidation settings, and IRMs can limit configured exposure; they cannot eliminate issuer, valuation, liquidity, governance, or legal risk.
### Build flow
1. Establish asset rights, restrictions, providers, and failure assumptions.
2. Configure and test [oracle routes](/curate/deploy-oracle-router).
3. Implement only the required [hook checks](/curate/vaults/evk/hooks-custom-logic) and map their exact operation coverage.
4. Set caps, LTVs, liquidation parameters, and [interest-rate behavior](/curate/interest-rate-models) against stressed liquidity and valuation scenarios.
5. Assign and verify [governance controls](/curate/governance-contracts).
6. Test transfer, redemption, liquidation, default, outage, and emergency scenarios.
7. Publish factual [labels and metadata](/curate/vaults/labeling).
### Read next
* [Price oracles](/learn/price-oracles)
* [Liquidations](/learn/liquidations)
* [Attack vectors](/curate/attack-vectors)
* [Vault types](/learn/vault-types)
## Factory contracts in Euler V2
Factory contracts make Euler V2 components repeatable to deploy and easier to inspect. Developers, curators, and auditors can check whether a deployed contract came from a recognized implementation and factory.
Factory origin helps with review, upgrades, and governance. Each deployment still has its own parameters, roles, and connected dependencies.
### Main factory contracts
#### EVault factory (generic factory)
The [EVault `GenericFactory`](https://github.com/euler-xyz/euler-vault-kit/tree/master/src/GenericFactory) deploys EVK vaults. It enables permissionless creation of upgradeable or immutable vaults using a standardized proxy pattern. Vault creators specify parameters such as the underlying asset, oracle, and unit of account. Factory origin helps integrators verify the deployment source, while the live vault configuration remains separate.
#### EulerEarn factory
The [EulerEarn Factory](https://github.com/euler-xyz/euler-earn/blob/master/src/EulerEarnFactory.sol) allows anyone to deploy new Earn vaults. Each Earn vault is an ERC-4626 vault where users deposit one asset into one vault-share position, while configurable roles manage allocation across the vault's selected strategies. Factory origin confirms the deployment source; users and integrators should still evaluate the vault's allocator, roles, strategies, caps, liquidity, and disclosures.
#### IRM factory (kink and adaptive curve)
The IRM (Interest Rate Model) factory is responsible for deploying interest rate models used by vaults. Two main types are supported:
* **[Kink IRM Factory](https://github.com/euler-xyz/evk-periphery/blob/master/src/IRMFactory/EulerKinkIRMFactory.sol):** Deploys linear kink interest rate models, which use a piecewise-linear curve with a "kink" point to set rates based on utilization.
* **[Adaptive Curve IRM Factory](https://github.com/euler-xyz/evk-periphery/blob/master/src/IRMFactory/EulerIRMAdaptiveCurveFactory.sol):** Deploys adaptive curve models, which dynamically adjust rates based on market conditions and utilization.
These factories let vaults use recognized IRM implementations and support parameter changes through the relevant governance process. Curators should still evaluate whether a selected IRM and its parameters fit the market.
#### Euler router factory
The [Euler Router Factory](https://github.com/euler-xyz/evk-periphery/blob/master/src/EulerRouterFactory/EulerRouterFactory.sol) deploys price oracle routers. Routers select configured price routes; the router's live routes and governor remain separate trust boundaries.
#### Governor access control emergency factory
The [`GovernorAccessControlEmergencyFactory`](https://github.com/euler-xyz/evk-periphery/blob/master/src/GovernorFactory/GovernorAccessControlEmergencyFactory.sol) deploys a governance suite for EVK vaults, including a `GovernorAccessControlEmergency` contract and two timelock controllers (admin and wildcard). It standardizes the setup of time-delayed and emergency-enabled governance, but operators remain responsible for assigning roles, configuring delays, monitoring changes, and communicating risks. For more, see the [Governor Access Control Emergency documentation](/build/periphery/governors#governoraccesscontrolemergency).
#### Cap risk steward factory
The [`CapRiskStewardFactory`](https://github.com/euler-xyz/evk-periphery/blob/master/src/GovernorFactory/CapRiskStewardFactory.sol) deploys `CapRiskSteward` contracts. A steward permits authorized, bounded cap adjustments subject to configured adjustment factors and a recharge interval. The role and the resulting cap change do not expire merely because the recharge interval passes. It may also set an IRM only when that IRM is a deployment recognized by the configured IRM factory. A steward is typically used alongside a selector-based governor; its delegated path can bypass an upstream timelock for exactly the selectors and targets granted to it.
### Verify a deployment
Use [Contract addresses](/build/contract-addresses) to locate listed factory deployments, then verify the chain ID, bytecode, factory validity check, implementation, and live role/configuration state. A table entry or factory origin is not an endorsement of contracts deployed from it.
## Factory Governor
The `FactoryGovernor` contract plays a crucial role in the security and management of the EVK factory. Acting as the `upgradeAdmin`, it gives trusted parties the ability to upgrade, pause, or unpause the factory and, by extension, all upgradeable vaults created by it. This centralized control is essential for emergency responses.
### What is Factory Governor?
`FactoryGovernor` is installed as the `upgradeAdmin` of the EVK factory. Unlike vault-level governors such as `GovernorAccessControl`, which focus on individual vaults, `FactoryGovernor` is responsible for the factory itself and all vaults that depend on its implementation. This distinction makes it the first line of defense and intervention for protocol-wide events.
### Key Features and How They Work
One of the most important features of `FactoryGovernor` is the `adminCall` function. This allows users with the `DEFAULT_ADMIN_ROLE` to execute arbitrary function calls on the factory, which is typically used for upgrades or other administrative actions. This level of access should be reserved for highly trusted entities, such as DAO multisig.
In addition to upgrades, `FactoryGovernor` provides robust mechanisms for pausing and unpausing the factory. If a situation arises that requires immediate intervention — such as a discovered vulnerability or a market event — anyone with the `PAUSE_GUARDIAN_ROLE` can pause the factory. This is done by installing a `ReadOnlyProxy` as the factory's implementation. The effect is immediate: all upgradeable vaults created by the factory are paused, as they rely on the factory's implementation. Importantly, non-upgradeable vaults are not affected by this action, preserving their independence.
When the situation is resolved, a user with the `UNPAUSE_ADMIN_ROLE` can unpause the factory. This is accomplished by retrieving the previous implementation from the `ReadOnlyProxy` and restoring it as the factory's implementation.
### Roles and Security Considerations
The `FactoryGovernor` contract relies on three main roles: `DEFAULT_ADMIN_ROLE`, `PAUSE_GUARDIAN_ROLE`, and `UNPAUSE_ADMIN_ROLE`. The admin role is the most powerful and should be held by a highly trusted multisig, as it can perform admin calls and manage roles. The pause and unpause roles are typically delegated to guardians or risk managers who are responsible for monitoring the protocol and responding to emergencies.
Careful assignment of these roles is critical. Only trusted parties should have the ability to pause or unpause the factory, as these actions affect all upgradeable vaults.
Pausing is a powerful circuit breaker and should be used judiciously. While it provides immediate protection in emergencies, it also halts all upgradeable vault activity. For layered security, `FactoryGovernor` is combined with vault-level governors, which can provide more granular control and additional safeguards.
## Governor contracts
Governor contracts can hold the `governorAdmin` authority of Euler Vault Kit (EVK) vaults and compatible oracle routers. They authenticate and forward administrative calls according to their role configuration. A curator, DAO, multisig, or risk steward can hold one or more roles in a governor, depending on the deployment.
The result is a flexible way to separate routine parameter changes, timelocked governance, and emergency actions.
### The role of governor contracts
An EVK vault exposes a `governorAdmin` address with broad vault-configuration authority. The exact callable functions depend on the target contract and governor. This vault-level authority is distinct from the EVault factory's `upgradeAdmin`, which can affect factory-linked upgradeable vault implementations; see [Factory Governor](/build/periphery/factory-governor).
### Roles and configuration
Governor contracts use role-based access control, often selector-based, to manage permissions:
* **DEFAULT\_ADMIN\_ROLE:** The most powerful role, able to grant/revoke other roles and perform admin actions. It should generally be held by a reviewed multisig or DAO-controlled address.
* **WILD\_CARD:** Grants access to all function selectors, typically held by a timelock for day-to-day governance.
* **Function Selector Roles:** Grant access to specific functions, allowing granular permissioning.
* **Guardian and emergency roles:** Their names and powers vary by implementation and can include `LTV_EMERGENCY_ROLE`, `HOOK_EMERGENCY_ROLE`, and `CAPS_EMERGENCY_ROLE`. Inspect role membership and callable selectors rather than inferring authority from a label.
Careful assignment and monitoring of these roles is critical. A misconfigured role can affect vault behavior, oracle routing, caps, LTVs, or emergency response.
### Types of governor contracts
Euler provides several specialized governor contracts, each with different operational tradeoffs:
#### `GovernorGuardian`
`GovernorGuardian` is a simple, proxy-like governor for vaults. Default admins can call any function, while guardians can pause or unpause the vault. It includes a cooldown to prevent repeated pausing and allows selective re-enabling of methods (e.g., only allow withdrawals/repays). Its authority and recovery behavior depend on deployed roles and configuration; review those values rather than treating the contract type as a safety designation.
#### `GovernorAccessControl`
`GovernorAccessControl` provides selector-based access control: permissions are granted per function selector, or globally via the `WILD_CARD` role. Whitelisted callers can invoke specific functions on target contracts, with authentication and forwarding handled by the governor. It can be used standalone or as part of a timelock-enabled governance suite. This is the most flexible and granular governor type.
#### `GovernorAccessControlEmergency`
This contract inherits from `GovernorAccessControl` and adds emergency roles for rapid response. Emergency guardians can instantly lower borrow LTV, pause vault operations, or lower supply/borrow caps. These actions can provide a circuit breaker during risk events. Recovery from emergency states, such as unpausing, goes through the timelock process when a timelock is installed.
#### `CapRiskSteward`
`CapRiskSteward` is a specialized risk management contract that works alongside selector-based governors. It allows authorized users to adjust supply and borrow caps within predefined bounds and cooldowns, and to update interest rate models (IRM) only to those deployed by a recognized factory. This can delegate limited parameter management to reviewed stewards while keeping broader control with the governor and timelock.
### Timelock integration: dual timelock model
The recommended deployment uses the `GovernorAccessControlEmergencyFactory`, which sets up:
* **Admin Timelock:** Holds the `DEFAULT_ADMIN_ROLE`, controls governance of the governor contract itself (break-glass, rarely used).
* **Wildcard Timelock:** Holds the `WILD_CARD` role, used for day-to-day governance (parameter changes, etc.).
The dual timelock model makes queued changes visible before execution, gives users time to respond to pending changes, and separates emergency actions from routine parameter changes.
### How to call the `GovernorAccessControl` contract
To call a function on a vault via `GovernorAccessControl`, you must append the target vault address to the calldata. This allows the governor to authenticate the call and forward it to the correct vault. Here's a simple example in Solidity:
```solidity
// Assume you want to call setCaps(uint16,uint16) on a vault via the governor
address vault = VAULT_ADDRESS;
uint16 supplyCap = 1000;
uint16 borrowCap = 500;
// Fetch the governor address from the vault contract
address governor = IVault(vault).governorAdmin();
// Encode the function selector and arguments
bytes memory encodedCall = abi.encodeWithSelector(
IEVault.setCaps.selector,
supplyCap,
borrowCap
);
// Append the vault address (20 bytes) to the calldata using abi.encodePacked
bytes memory encodedCallWithTarget = abi.encodePacked(encodedCall, vault);
// Call the governor contract
(bool success, bytes memory result) = governor.call(encodedCallWithTarget);
require(success, "Governor call failed");
```
This pattern is also used for `GovernorAccessControlEmergency` and `CapRiskSteward` contracts. The governor contract extracts the trailing address and forwards the call to the vault, authenticating the caller's permissions for the function selector.
### Read next
* [Periphery contracts](/build/periphery)
* [Build](/build)
* [Launch toolkit](/launch)
## Periphery contracts
Euler periphery contracts support deployment, governance, swap execution, read helpers, and order-flow routing around EVK and EVC integrations.
| If you want to... | Start with |
| --------------------------------------------------------------------------------------------------- | ------------------------------------------------------ |
| Review factory deployments for EVK, EulerEarn, IRMs, routers, and governance modules | [Factory contracts](/build/periphery/factories) |
| Understand vault governor contracts, timelocks, emergency controls, and delegated parameter changes | [Governor contracts](/build/periphery/governors) |
| Review factory-wide upgrade and read-only pause authority | [Factory Governor](/build/periphery/factory-governor) |
| Work with swap helpers and related periphery swap contracts | [Periphery swaps](/build/periphery/swaps) |
| Route order flow through Euler supporting contracts | [Order-flow router](/build/periphery/orderflow-router) |
## Order flow router
The [Euler Order Flow Router](https://github.com/euler-xyz/euler-orderflow-router) is an offchain meta-aggregator used by Euler swap and Multiply flows. It queries configured routing strategies, compares eligible responses, and returns route details and calldata that an application can place into an EVC batch.
This allows a user to open, rebalance, or close a position in one transaction while still reviewing the route, slippage bound, and resulting position before signing.
### How it fits into a swap
A router response can provide data for `Swapper` and `SwapVerifier`:
1. `Swapper` executes the encoded external route and, in target-debt mode, performs `repay` or `_repayAndDeposit`.
2. The selected `SwapVerifier` function checks the configured minimum output or maximum remaining debt and deadline.
3. For regular output paths, a verifier function can also skim and deposit or transfer output after the amount check.
4. The EVC completes the required vault and account status checks for the batch.
The router builds a quote and payload; it does not execute the user's transaction. Applications should validate the returned chain, tokens, vaults, accounts, recipients, targets, calldata, amounts, approvals, slippage, and deadline.
See [Periphery swaps](/build/periphery/swaps) for the execution and verification flow.
### Strategies and pipelines
Requests pass through a chain-specific pipeline. A strategy can answer a request, modify it, combine routes, or invoke another stage.
Current source includes:
* **`StrategyAggregators` (`aggregators`):** gathers quotes from configured aggregators and compares eligible responses.
* **`StrategyCombinedUniswap`:** combines an aggregator exact-input leg with a Uniswap exact-output remainder where configured.
* **ERC-4626 and asset wrappers:** compose deposits, redemptions, or direct conversion routes with other quote legs.
* **Connection strategies:** join routes through an intermediary token or another strategy stage.
Provider and pipeline configuration varies by chain and can change over time. Check the current [router repository](https://github.com/euler-xyz/euler-orderflow-router) and API for the intended request.
### Multiply entry and exit
A typical Multiply entry batch can:
1. supply the initial margin;
2. borrow while the required liquidity check is deferred;
3. swap into the collateral asset;
4. route output through the selected verifier path; and
5. finish the verifier and EVC status checks.
A typical unwind withdraws collateral, executes a target-debt swap, lets `Swapper` repay the debt, and uses `verifyDebtMax` to enforce a maximum remaining balance. The exact batch depends on the quote, token behavior, existing account state, and periphery version.
### Debt-target routing
Debt continues to accrue between quote and execution. Depending on configuration, the router can:
* combine an aggregator exact-input route with an exact-output remainder; or
* size an exact-input quote with a buffer, then use target-debt post-processing to repay and handle any surplus.
The caller should set a deadline and remaining-debt maximum that account for interest, fees, slippage, rounding, liquidity, and token behavior.
### Integration checklist
* Decode and validate returned targets and calldata according to the application's policy.
* Confirm input and output amounts and token decimals.
* Verify the output destination expected by the selected verifier flow.
* Keep approvals scoped to the intended spender and amount.
* Simulate the complete EVC batch against current state.
* Show the provider, route, fees, slippage bound, deadline, and resulting position to the signer.
* Handle no-quote, stale-quote, and provider-error responses.
### Resources
* [Order Flow Router repository](https://github.com/euler-xyz/euler-orderflow-router)
* [Deployed API schema](https://swap.euler.finance/)
* [Periphery swaps](/build/periphery/swaps)
* [EVK swap periphery source](https://github.com/euler-xyz/evk-periphery/tree/master/src/Swaps)
## Swaps
Swaps are a core building block in Euler. They let users open leveraged positions, replace collateral, repay debt, and complete liquidations without splitting the workflow across several transactions. The EVC can combine vault operations, an external swap, and explicit result checks in one atomic batch.
### Why swaps matter
Swaps support several common workflows:
* **Open a leveraged position:** borrow an asset, swap it for collateral, and deposit the result.
* **Replace collateral:** withdraw one collateral asset, swap it, and deposit the replacement.
* **Repay debt:** withdraw collateral, swap it for the liability asset, and repay the outstanding debt.
* **Complete a liquidation:** swap received collateral for the liability asset needed to repay debt.
If a required operation or post-swap check fails, the EVC batch reverts as a single transaction.
### How swaps are executed
A typical EVC batch follows this progression:
1. Withdraw or borrow the asset to be swapped.
2. Send it to the `Swapper`.
3. Execute the route through an external venue.
4. Deposit the output, repay debt, or transfer the result as required.
5. Use `SwapVerifier` to check the resulting amount or remaining debt.
6. Complete the EVC account and vault status checks.
### Swapper and SwapVerifier
Euler's reference flow separates execution from verification:
* **`Swapper` executes the route.** It calls handlers for external venues and supports exact-input, exact-output, and target-debt modes. It is permissionless and should not retain funds or standing approvals.
* **`SwapVerifier` checks the result.** The caller supplies a minimum output or maximum remaining debt and a deadline. The selected verifier function checks that condition and reverts if it is not met.
* **The EVC provides atomic sequencing.** Place the verifier after the swap operations in the same batch so a failed postcondition reverts the transaction.
`SwapVerifier` checks caller-selected amount or debt bounds. It does not quote a route or calculate oracle-based price impact.
Use the [`Swapper` source](https://github.com/euler-xyz/evk-periphery/blob/master/src/Swaps/Swapper.sol), [`SwapVerifier` source](https://github.com/euler-xyz/evk-periphery/blob/master/src/Swaps/SwapVerifier.sol), and [periphery swap documentation](https://github.com/euler-xyz/evk-periphery/blob/master/docs/swaps.md) for the version you integrate.
### Swap modes
* **Exact input:** spend a specified input amount and receive the output produced by the route.
* **Exact output:** buy a specified output amount. Supporting handlers return unused input to the configured input vault or account.
* **Target debt:** calculate the amount needed to reach a debt target, execute the swap, and call `repay` or `_repayAndDeposit`. `verifyDebtMax` then checks the remaining debt.
Handler behavior depends on the selected route and mode. Generic handlers can execute calldata built offchain, so applications should review the complete payload rather than assume every `SwapParams` field is enforced onchain.
### Verifier output paths
| Function | Checked condition | Action after the check |
| ---------------------------- | ---------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| `verifyAmountMinAndSkim` | At least `amountMin` assets are available to skim from an EVault before `deadline` | Skims the available assets to `receiver` |
| `verifyAmountMinAndDeposit` | The verifier holds at least `amountMin` underlying assets before `deadline` | Deposits its balance into the selected ERC-4626 vault for `receiver` |
| `verifyAmountMinAndTransfer` | The verifier holds at least `amountMin` of the asset before `deadline` | Transfers its balance to `receiver` |
| `verifyDebtMax` | Account debt is no greater than `amountMax` before `deadline` | Checks the resulting debt without performing repayment |
### Example: swap collateral to repay debt
1. Withdraw collateral to `Swapper`.
2. Execute the swap in target-debt mode. `Swapper` performs the repayment and can deposit surplus output according to the selected mode.
3. Call `SwapVerifier.verifyDebtMax` to check that the remaining debt is within the configured maximum.
4. Complete the EVC account and vault status checks.
### Security and integration checks
* Confirm the chain, contracts, tokens, vaults, account, receiver, handler, target, calldata, approvals, and output destination.
* Set amount or debt bounds and deadlines from the quote reviewed by the user, allowing for fees, slippage, interest accrual, and rounding.
* Simulate the complete ordered batch against current state.
* Keep approvals to `Swapper` scoped to the intended transaction.
* Check the resulting balances, debt, controller, collateral set, and account health after execution.
### Read next
* [Order flow router](/build/periphery/orderflow-router)
* [Periphery contracts](/build/periphery)
* [EVC security considerations](/build/evc/security)
## Interacting with vaults
Euler Vault Kit (EVK) vaults extend ERC-4626 with borrowing and repayment. This guide covers the direct contract calls and EVC batch patterns used by applications, bots, and smart contracts.
Use the ABI and chain-specific addresses from [`euler-interfaces`](https://github.com/euler-xyz/euler-interfaces). Before submitting a transaction, verify the selected vault's asset, factory provenance, EVC, hooks, caps, collateral configuration, oracle route, liquidity, and governance state.
:::note
Direct vault calls work for simple actions. Use the [Ethereum Vault Connector integration guide](/build/evc/integration-guide) when a flow needs atomic batching, sub-accounts, controller or collateral changes, operators, or simulation. For offchain TypeScript integrations, the [Euler SDK](/build/sdk) abstracts both the direct calls and the EVC patterns away.
:::
### Deposit assets
An EVK deposit follows ERC-4626: the authenticated caller supplies underlying assets and `receiver` receives vault shares.
```solidity
IERC20 asset = IERC20(IEVault(vault).asset());
// Approve the vault to pull the underlying asset.
asset.approve(vault, assets);
// Deposit assets and mint shares to receiver.
uint256 shares = IEVault(vault).deposit(assets, receiver);
```
Use `previewDeposit`, `maxDeposit`, and transaction simulation before execution. The actual result remains subject to rounding, caps, hooks, token behavior, and state changes before inclusion.
#### Permit2 allowances
EVK vaults can pull assets through an existing Permit2 allowance before falling back to the underlying token's `transferFrom` allowance. A signed Permit2 message does not authorize the vault merely by being passed to `deposit`: the permit must first be applied to Permit2, either in an earlier call or as part of a reviewed batched flow.
A user normally needs an underlying-token approval to Permit2 once, followed by a scoped Permit2 allowance for the selected vault. Check the Permit2 address configured by the vault, allowance amount, expiration, nonce, chain, token, and spender before signing or submitting anything.
See the [Permit2 repository](https://github.com/Uniswap/permit2) for its interfaces and signature format.
### Withdraw or redeem
Use `withdraw` when specifying an asset amount, or `redeem` when specifying a share amount:
```solidity
// Burn enough owner shares to receive an exact asset amount.
uint256 sharesBurned = IEVault(vault).withdraw(assets, receiver, owner);
// Burn an exact share amount and receive the resulting assets.
uint256 assetsReceived = IEVault(vault).redeem(shares, receiver, owner);
```
The authenticated caller must be `owner` or have sufficient vault-share allowance from `owner`. A withdrawal can still fail because of insufficient vault cash, account-health checks, hooks, or concurrent state changes. For borrowing accounts, simulate the complete EVC flow rather than relying only on `maxWithdraw` or `maxRedeem`.
Do not send underlying assets to an unsigned EVC-derived sub-account. Set `receiver` to an address that can control the received ERC-20 tokens unless the exact receiver flow is EVC-aware and reviewed.
### Borrow assets
Borrowing uses two different vault roles:
* The **collateral vault** holds the account's collateral shares.
* The **borrow vault** is the liability vault, becomes the account's controller, and sends its underlying asset to the borrow receiver.
The borrow vault must accept the collateral vault through a nonzero current LTV configuration.
```solidity
// 1. Deposit the collateral asset.
IERC20 collateralAsset = IERC20(IEVault(collateralVault).asset());
collateralAsset.approve(collateralVault, collateralAmount);
IEVault(collateralVault).deposit(collateralAmount, account);
// 2. Enable collateral and the liability/controller vault.
IEVC(evc).enableCollateral(account, collateralVault);
IEVC(evc).enableController(account, borrowVault);
// 3. Borrow from the liability vault.
uint256 borrowed = IEVault(borrowVault).borrow(borrowAmount, receiver);
```
The debt belongs to the EVC-authenticated `account`; `receiver` only controls where the borrowed tokens are sent. Check both borrow and liquidation LTVs, oracle units and freshness, available cash, the borrow cap, interest rate, and resulting account health.
An account can have only one enabled controller at a time. Use separate [sub-accounts](/learn/sub-accounts) for positions with different liability vaults.
### Repay debt
The caller supplies the borrow asset and the second argument identifies the account whose debt is reduced:
```solidity
uint256 currentDebt = IEVault(borrowVault).debtOf(debtAccount);
IERC20 borrowAsset = IERC20(IEVault(borrowVault).asset());
// The allowance can include a buffer for interest that accrues before repay.
// repay(max, ...) still pulls only the amount actually owed.
uint256 repaymentAllowance = currentDebt + (currentDebt / 100);
borrowAsset.approve(borrowVault, repaymentAllowance);
// type(uint256).max repays the account's full current debt.
uint256 repaid = IEVault(borrowVault).repay(
type(uint256).max,
debtAccount
);
```
For a partial repayment, pass an amount no greater than the current debt. Do not add an asset-amount buffer to a partial `repay`, because repaying more than the debt can revert. For a full repayment, approve enough for accrued debt and use `type(uint256).max`; the vault then pulls the amount actually owed.
Anyone can fund a repayment for `debtAccount`; the payer and debt account do not need to be the same address. The payer must control the asset balance and applicable vault or Permit2 allowance.
If the payer owns shares of the same borrow vault, `repayWithShares` can burn shares to reduce debt:
```solidity
(uint256 sharesBurned, uint256 assetsRepaid) =
IEVault(borrowVault).repayWithShares(
type(uint256).max,
debtAccount
);
```
`repayWithShares` authenticates the share holder through the EVC context. Simulate it when the share value, debt, or exchange rate may change.
### Batch a collateral deposit and borrow
The EVC can enable collateral, deposit, enable the controller, and borrow atomically. Calls targeting the EVC itself use `onBehalfOfAccount: address(0)`; vault calls use the account being authenticated.
```solidity
IEVC.BatchItem[] memory items = new IEVC.BatchItem[](4);
items[0] = IEVC.BatchItem({
targetContract: address(evc),
onBehalfOfAccount: address(0),
value: 0,
data: abi.encodeCall(
IEVC.enableCollateral,
(account, collateralVault)
)
});
items[1] = IEVC.BatchItem({
targetContract: collateralVault,
onBehalfOfAccount: account,
value: 0,
data: abi.encodeCall(
IEVault.deposit,
(collateralAmount, account)
)
});
items[2] = IEVC.BatchItem({
targetContract: address(evc),
onBehalfOfAccount: address(0),
value: 0,
data: abi.encodeCall(
IEVC.enableController,
(account, borrowVault)
)
});
items[3] = IEVC.BatchItem({
targetContract: borrowVault,
onBehalfOfAccount: account,
value: 0,
data: abi.encodeCall(
IEVault.borrow,
(borrowAmount, receiver)
)
});
IEVC(evc).batch(items);
```
This example assumes the collateral asset allowance already exists. If the flow applies a signed permit, include and validate the correct approval call before the deposit. EVC account and vault-status checks can be deferred until the end of a batch, but each item's ordering, authentication, allowance, and receiver semantics still matter.
Simulate the final batch against the intended chain and block, then re-check the decoded calls before signing.
### Flash liquidity
EVault exposes `flashLoan(uint256 amount, bytes data)`. It transfers the requested underlying asset to the EVC-authenticated caller, invokes `onFlashLoan(data)` on that caller, and requires the vault's asset balance to be restored before the callback completes.
```solidity
contract FlashBorrower is IFlashLoan {
using SafeERC20 for IERC20;
IEVault public immutable vault;
IERC20 public immutable asset;
constructor(IEVault vault_) {
vault = vault_;
asset = IERC20(vault_.asset());
}
function execute(uint256 amount, bytes calldata userData) external {
// Production code must add its own caller authorization.
vault.flashLoan(amount, abi.encode(amount, userData));
}
function onFlashLoan(bytes memory data) external {
require(msg.sender == address(vault), "unexpected vault");
(uint256 amount, bytes memory userData) =
abi.decode(data, (uint256, bytes));
// Perform the reviewed atomic operation using amount and userData.
asset.safeTransfer(address(vault), amount);
}
}
```
The standard balance check requires repayment in the same transaction. A configured hook can impose additional policy or fees, and the borrower contract must restrict who can start the flow and what external calls can be made. Verify available vault cash and simulate the complete callback path.
### Assets and shares
Assets are units of the vault's underlying ERC-20; shares represent proportional ownership of the vault. Their exchange rate changes as interest accrues and fees or losses affect the vault.
Use the ERC-4626 conversion and preview functions rather than copying the vault's internal accounting formula:
```solidity
uint256 assetsForShares = IEVault(vault).convertToAssets(shares);
uint256 sharesForAssets = IEVault(vault).convertToShares(assets);
uint256 expectedShares = IEVault(vault).previewDeposit(assets);
uint256 sharesToBurn = IEVault(vault).previewWithdraw(assets);
```
Conversions can round differently depending on the operation. Read the underlying and share decimals independently, preserve integer precision, and treat previews as state-dependent estimates rather than execution guarantees.
### Integration checklist
Before executing a vault interaction:
1. Resolve the chain-specific EVC, vault, asset, ABI, and Permit2 addresses from current sources.
2. Verify factory provenance, proxy or implementation status, asset, decimals, and bytecode.
3. Check caps, cash, hooks, pause state, controller, collateral set, LTVs, oracle path, and governance.
4. Keep the authenticated account, share owner, debt account, token payer, and asset receiver distinct in the integration model.
5. Decode every approval and call, simulate the final payload, and enforce slippage or outcome bounds where the operation supports them.
6. Re-read live state after confirmation; indexed data and simulations can lag or become stale.
### Read next
* [EVC integration guide](/build/evc/integration-guide)
* [Euler SDK](/build/sdk)
* [EVK overview](/curate/vaults/evk/overview)
* [Contract addresses](/build/contract-addresses)
* [Lens contracts](/build/data-querying/using-lens-contracts)
## EVC utils guide
[`EVCUtil.sol`](https://github.com/euler-xyz/ethereum-vault-connector/blob/master/src/utils/EVCUtil.sol) is a utility abstract contract designed to make it easier to build contracts that interact with the [**Ethereum Vault Connector (EVC)**](/build/evc). It provides authentication helpers, context-aware modifiers, and patterns for enforcing that your contract is called through the EVC when required.
### Why use `EVCUtil`?
* **Authentication:** Checks that your contract is called by the EVC in the correct context, reducing unauthorized-access risk when implemented correctly.
* **Context Awareness:** Provides helpers to retrieve the true sender (`onBehalfOfAccount`) and to check if your contract is being called as part of a batch, liquidation, or operator action.
* **Implementation Patterns:** Encourages consistent patterns for vaults, modules, and periphery contracts that need to integrate with the EVC.
### Key features and patterns
#### 1. `callThroughEVC` modifier
The `callThroughEVC` modifier routes a function through the EVC, even if it is called directly. If the call does not originate from the EVC, the modifier will route the call through the EVC's `call()` method, which then calls back into the contract with the correct execution context.
**Why is this needed?**
Vaults and contracts often rely on the EVC to trigger the requested account and vault status checks. These checks typically must be performed at the end of the operation or batch. By using `callThroughEVC`, direct calls are routed through the same context so status checks are deferred to the end of the operation or batch.
**Usage:**
```solidity
function myFunction() external callThroughEVC {
// This will always execute in the correct EVC context
}
```
#### 2. `onlyEVCAccount` and `onlyEVCAccountOwner` modifiers
* `onlyEVCAccount`: Uses the standard authentication rule allowing the account owner or any of its EVC accounts.
* `onlyEVCAccountOwner`: Uses the standard authentication rule allowing only the account owner. This modifier is typically used for governance functions that should only be callable by the account owner.
**Usage:**
```solidity
function restrictedAction() external onlyEVCAccount {
// Only callable by the EVC or a valid EVC account
}
```
#### 3. `_msgSender` and `_msgSenderForBorrow`
* `_msgSender()`: Returns the logical sender, resolving the EVC context if needed.
* `_msgSenderForBorrow()`: Like `_msgSender`, but also checks that the contract is enabled as a controller for the account.
**Usage:**
```solidity
function doSomething() external {
address user = _msgSender();
// Use 'user' as the logical sender
}
```
#### 4. Address prefix and common owner checks
* `_getAddressPrefix(address)`: Returns the 19-byte prefix shared by all sub-accounts of an owner.
* `_haveCommonOwner(address, address)`: Checks if two accounts share the same owner (i.e., same prefix).
**Usage:**
```solidity
bytes19 prefix = _getAddressPrefix(account);
bool sameOwner = _haveCommonOwner(account1, account2);
```
### Example: minimal EVC-aware contract
```solidity
import "ethereum-vault-connector/utils/EVCUtil.sol";
contract Example is EVCUtil {
constructor(address evc) EVCUtil(evc) {}
function onlyEVCOwnerOperation() external onlyEVCAccountOwner {
address user = _msgSender();
// ...
}
}
```
### Read next
* [EVC overview](/build/evc)
* [EVC integration guide](/build/evc/integration-guide)
* [EVC implementation security](/build/evc/security)
## Overview
**The Ethereum Vault Connector (EVC)** is the account and coordination layer for modular lending in Euler V2. Acting as the primary entry point for advanced interactions, the EVC lets integrators build, automate, and orchestrate multi-step workflows across multiple vaults. For offchain TypeScript integrations, the [Euler SDK](/build/sdk) abstracts most of these workflows; the pages in this section cover the contract level.
### What the EVC coordinates
In Euler V2, the EVC mediates cross-vault operations:
* **Batching:** Group multiple actions (deposits, borrows, swaps, repayments, etc.) into a single atomic transaction.
* **Sub-accounts:** Create up to 256 separated positions per wallet, enabling strategy separation and clearer account-level risk tracking.
* **Operators:** Delegate control of sub-accounts to reviewed contracts or automation bots for advanced use cases, such as stop-loss or intent-based trading.
* **Signed delegation:** Authorize delegated execution with signed messages through the EVC `permit` function.
* **Deferred checks:** Defer required account and vault status checks until the end of a call or batch. Only constraints represented by those required checks are deferred.
* **Unified Authentication:** The EVC handles authentication, so vaults can focus on authorization and business logic.
### Core concepts
#### Batching
The EVC's batching system allows integrators to bundle multiple operations, across different vaults and even external contracts, into a single transaction. All operations succeed or fail together, which reduces partial-execution risk within that batch.
#### Sub-accounts
Each user address is granted 256 virtual sub-accounts. These allow for position separation and management of multiple strategies under a single wallet. Risk is still determined by the vaults, controllers, collateral, and operators enabled for each sub-account.
#### Operators
Operators generalize the concept of token approvals. By assigning an operator to a sub-account, users can delegate control to automation contracts, keepers, or other parties. Operator permissions should be granted only after reviewing the delegated contract or account.
The EVC `permit` function lets an account owner sign an authorization offchain so another address can submit it onchain. Integrators can use this for delegated execution flows, while still treating the signed message as a sensitive permission that should be scoped and reviewed before signing.
#### Deferred checks and atomicity
Vaults request account and vault status checks, and the EVC can defer those checks until the end of a call or batch. Intermediate state may violate constraints represented by the deferred checks; the transaction succeeds only if all required final checks pass. A vault that fails to request the correct check is not protected by deferral. Integrators should model the full execution flow and failure cases.
#### Authentication and authorization
The EVC authenticates the originator of every action, while vaults retain control over authorization. This separation of concerns keeps account authentication and vault-level permissioning distinct.
#### Liquidations
Liquidations are orchestrated through the EVC so debt transfer or takeover, collateral seizure, and any liquidation incentive logic are executed atomically according to the controller vault's rules.
A key part of this process is the EVC's `controlCollateral` function. When a borrower's position becomes undercollateralized, the liability (controller) vault can invoke `controlCollateral` to seize collateral from the borrower's enabled collateral vaults. This function lets the controller vault transfer or withdraw collateral on behalf of the account in violation while the liquidator takes over the corresponding debt. From the collateral vault's perspective, this appears as a standard withdrawal or share transfer, but it is executed under the EVC's controller context and the liability vault's liquidation rules.
### What integrators can do with the EVC
* Build custom frontends and bots that leverage batching, sub-accounts, and operators
* Create advanced automation, such as stop-loss, auto-rebalancing, or liquidation-response tooling
* Integrate with other protocols using atomic cross-vault operations
* Simulate complex transactions before execution
* Design new market structures and risk management systems
For a full technical reference, see the [EVC whitepaper](https://github.com/euler-xyz/ethereum-vault-connector/blob/master/docs/whitepaper.md), the [EVC repository](https://github.com/euler-xyz/ethereum-vault-connector) or the EVC dedicated [website](https://evc.wtf).
### Read next
* [EVC implementation security](/build/evc/security)
* [Interact with Euler](/build/evc/integration-guide)
* [EVC utils](/build/evc/evc-utils)
* [Build](/build)
## Interact with Euler
Use the EVC when an integration needs authenticated batching, sub-accounts, collateral and controller management, operators, permits, simulation, or cross-vault actions. The examples below are building blocks; production integrations must resolve deployed interfaces, approvals, account state, and target-chain addresses. For offchain TypeScript integrations, the [Euler SDK](/build/sdk) abstracts these EVC patterns — batching, sub-accounts, permits, and simulation — behind typed helpers; this guide shows the underlying contract-level calls.
:::warning
**Derived-account token safety**
Most ERC-20 tokens are **not EVC-aware**. An EVC sub-account is an ordinary address derived by XOR, but its owner does not hold a separate private key for that derived address. EVC-aware contracts can authenticate its owner through EVC context; an ordinary ERC-20 transfer cannot.
Do not send ordinary ERC-20 tokens directly to a derived sub-account address unless a reviewed EVC-aware recovery flow exists for that exact token and integration. A normal ERC-20 contract cannot authenticate the EVC owner, so the owner generally cannot transfer those tokens back with a wallet signature. This is different from depositing into a vault with the sub-account as share receiver: the vault shares are managed through EVC-aware vault logic.
:::
### 1. Batching operations
Batching lets you group multiple actions into a single atomic transaction. Use the `batch` function and the `BatchItem` struct:
```solidity
IEVC.BatchItem[] memory items = new IEVC.BatchItem[](2);
// Example: Deposit collateral and then borrow in a single batch.
// Assumes the collateral asset is approved and the collateral/controller
// vaults are already enabled for myAccount.
items[0] = IEVC.BatchItem({
targetContract: collateralVault,
onBehalfOfAccount: myAccount,
value: 0,
data: abi.encodeWithSelector(IVault.deposit.selector, depositAmount, myAccount)
});
items[1] = IEVC.BatchItem({
targetContract: borrowVault,
onBehalfOfAccount: myAccount,
value: 0,
data: abi.encodeWithSelector(IVault.borrow.selector, borrowAmount, myAccount)
});
connector.batch(items);
```
All operations succeed or fail together. You can batch across multiple vaults and even external contracts.
### 2. Using sub-accounts
Sub-accounts allow you to separate positions and strategies. Each address prefix has 256 derived account addresses. Token allowances, vault collateral/controller enablement, and operator permissions are separate mechanisms and can still be required for a workflow.
#### Address structure and derivation
All 256 sub-accounts belonging to the same owner share the first 19 bytes of their Ethereum address. The only difference between them is the very last byte. This means that, on-chain, you can easily recognize which sub-accounts belong to the same owner: they will look almost identical, except for the final two characters.
A sub-account address is created by XOR-ing your main address with a number from 0 to 255 (as a `uint8`).
* Your main address is sub-account 0 (no change).
* Sub-account 1 is your address XOR 1, sub-account 2 is your address XOR 2, and so on up to 255.
This structure makes sub-accounts easy to group and identify onchain while preserving unique addresses for each sub-account.
##### Example: deriving a sub-account address in Solidity
```solidity
function getAccount(address owner, uint8 accountId) public pure returns (address) {
return address(uint160(owner) ^ uint160(accountId));
}
// Usage:
address myAddress = /* your main address */;
address account3 = getAccount(myAddress, 3); // This is your 4th sub-account
```
For each operation, distinguish the account authenticated through `onBehalfOfAccount` from the address that receives assets or shares:
* **Deposits:**
* `onBehalfOfAccount` must be an address that actually controls the ERC-20 balance and allowance—commonly the main wallet. A typical XOR-derived EOA sub-account has no separate signer.
* The `receiver` parameter (in the deposit function) can be a sub-account address, so the deposited shares are credited to the sub-account.
* **Borrows:**
* `onBehalfOfAccount` should be the sub-account for which you want to create the debt position.
* The `receiver` should be an address that can control the received ERC-20 tokens—commonly the main wallet—not an unsigned derived address.
##### Example: deposit to a sub-account
```solidity
// Deposit tokens from your main address, but credit the shares to subAccount3
IEVC.BatchItem[] memory items = new IEVC.BatchItem[](1);
items[0] = IEVC.BatchItem({
targetContract: vault,
onBehalfOfAccount: myAddress, // tokens are pulled from here
value: 0,
data: abi.encodeWithSelector(IVault.deposit.selector, depositAmount, subAccount3) // shares go to sub-account
});
connector.batch(items);
```
##### Example: borrow from a sub-account
```solidity
// Borrow on behalf of subAccount3, but send tokens to your main address
IEVC.BatchItem[] memory items = new IEVC.BatchItem[](1);
items[0] = IEVC.BatchItem({
targetContract: vault,
onBehalfOfAccount: subAccount3, // debt is created here
value: 0,
data: abi.encodeWithSelector(IVault.borrow.selector, borrowAmount, myAddress) // tokens sent to main address
});
connector.batch(items);
```
This distinction is about control, not a protocol rule that ERC-20 balances always live at a main address. Most ERC-20 contracts cannot authenticate EVC ownership of a derived sub-account, so tokens sent there are generally not recoverable with the owner's normal wallet signature unless a reviewed EVC-aware flow exists.
### 3. Account ownership and registration
The EVC maintains a mapping of account owners, which is important for resolving the relationship between sub-accounts and their primary (EOA or smart contract) owner. This is especially relevant for integrations, analytics, and off-chain systems.
#### How ownership is registered
An account's owner is registered in the EVC the first time the owner interacts with the EVC (for example, by enabling collateral or a controller, or performing EVC batch or call). Until this happens, the EVC does not know who the owner is.
#### Direct vault interactions and edge cases
Accounts can interact with vaults directly, bypassing the EVC. This means:
* An account may not have an owner registered in the EVC until it finally interacts with the EVC (e.g., to enable collateral or a controller for borrowing).
* If an account receives vault shares (e.g., as a transfer) before its owner has ever interacted with the EVC, the EVC will not have an owner registered for that account.
#### Integration pattern and limitations
A typical integration pattern is:
* Use the EVC's `getAccountOwner(address account)` function to resolve the owner.
* If the owner is not registered (i.e., the function returns `address(0)`), assume that the account is its own owner.
```solidity
address owner = evc.getAccountOwner(account);
if (owner == address(0)) {
// Owner not registered; assume the account is its own owner
owner = account;
}
```
:::note
This pattern is commonly used, but integrators should still handle edge cases where the true owner is not the account itself, especially if ownership is later registered by a different EOA. Consider the security and UX implications for your application.
:::
### 4. Operator delegation
Operators delegate EVC-authenticated authority to another address, such as a reviewed bot or automation contract. `setAccountOperator(account, operator, true)` toggles one account. `setOperator(prefix, operator, bitField)` sets a bitmap across the 256 account IDs sharing that prefix.
```solidity
// Grant operator rights for a specific sub-account
evc.setAccountOperator(subAccount, operatorAddress, true);
// Grant operator rights for ALL sub-accounts of the owner
// The prefix groups the owner's 256 account IDs.
// Each set bit grants the operator authority for that account ID.
// type(uint256).max sets all 256 bits.
evc.setOperator(evc.getAddressPrefix(owner), operatorAddress, type(uint256).max);
```
:::warning
Operator delegation is a safety-critical operation. An operator with access to your sub-accounts can move funds, borrow, repay, and perform any action on your behalf. Only delegate operator rights to trusted contracts or EOAs, and regularly review and revoke permissions you no longer need.
Operators can batch, deposit, withdraw, borrow, and more—enabling advanced automation and intent-based strategies. You can revoke operator rights at any time using the same functions with `false` or by updating the operator bitfield.
:::
:::tip
**What is an Address Prefix?**
In the EVC, an address prefix is the first 19 bytes of an Ethereum address. All 256 sub-accounts of an owner share the same prefix. The EVC uses this prefix to efficiently manage permissions and operator rights across all sub-accounts. The `getAddressPrefix(address)` function returns this value for any given address.
:::
### 5. Liquidations with controlCollateral
To perform a liquidation, the controller vault calls `controlCollateral` to seize collateral from a borrower's sub-account. Typically, this is done by transferring vault shares from the violator's sub-account to the liquidator using the `transfer` function:
```solidity
// Example: Controller vault seizes collateral shares from violator's sub-account
address collateralVault = /* address of the collateral vault */;
address violator = /* sub-account in violation */;
address liquidator = /* address of the liquidator */;
uint256 seizeShares = /* number of shares to seize */;
// Prepare transfer call data
bytes memory transferData = abi.encodeWithSelector(
IVault.transfer.selector,
liquidator, // recipient of the shares
seizeShares // amount of shares to transfer
);
// Call controlCollateral
connector.controlCollateral(
collateralVault,
violator,
0, // value
transferData
);
```
`controlCollateral` is accepted only from the account's enabled controller in the EVC's collateral-control context. Within that context the controller can call the enabled collateral vault on behalf of the account, including a withdrawal or share transfer that would not require the account's ordinary ERC-20 allowance. Collateral-vault implementations must authenticate this exact EVC context; controller implementations determine when and how the authority is used.
### 6. Simulating transactions
You can simulate batches before execution using `batchSimulation`:
```solidity
(
IEVC.BatchItemResult[] memory results,
IEVC.StatusCheckResult[] memory accountChecks,
IEVC.StatusCheckResult[] memory vaultChecks
) = connector.batchSimulation(items);
// Analyze results before sending a real transaction
```
This is useful for diagnostics in frontends, bots, and risk-management systems. Simulation mode is observable by called contracts, so an untrusted target can behave differently in simulation and execution. Do not treat a successful simulation as a security guarantee.
### 7. Relayed transactions with permits
The EVC supports EIP-712 permits. A user can sign an authorization offchain and an allowed relayer can submit it; the relayer pays execution gas, although an application may charge or recover that cost separately.
Permits are useful for relayed transactions and automation on the chain where the permit is valid. The EVC's `permit` function supports both ECDSA (EOA) and ERC-1271 (smart-contract wallet) signatures.
#### How to use EVC permits
1. Construct the permit message, specifying the signer, sender, nonce, deadline, value, and calldata (typically a batch of operations).
2. Sign the message off-chain using EIP-712.
3. Submit the permit to the EVC's `permit` function:
```solidity
evc.permit(
signer, // The user authorizing the action
sender, // The relayer or executor
nonceNamespace, // For replay protection
nonce, // For replay protection
deadline, // Expiry timestamp
value, // ETH value to forward (usually 0)
data, // Encoded calldata (e.g., batch)
signature // EIP-712 signature
);
```
The EVC will verify the signature, check the nonce and deadline, and then execute the requested operations as if they were sent by the signer.
:::info
**Security Note**
Permits are powerful. Verify the sender, nonce namespace, nonce, deadline, value, and calldata before signing. If a harmful permit may have been signed, use Permit Disabled Mode as described below.
:::
#### Understanding nonce namespace
The EVC's permit system uses a `nonceNamespace` and `nonce` for replay protection and sequencing. The `nonceNamespace` allows you to have multiple independent streams of permits for the same account. This is useful if you want to:
* Allow parallel workflows (e.g., one for regular actions, one for high-priority or emergency actions)
* Cancel or replace a specific stream of permits without affecting others
For most simple use cases, you can use a single namespace (e.g., `nonceNamespace = 0`) and increment the `nonce` for each new permit. For more advanced scenarios, you can assign different namespaces to different workflows or applications.
:::tip
If you are unsure, use `nonceNamespace = 0` for all your permits. Only use multiple namespaces if you need parallel, independent streams of permits.
:::
### 8. Emergency modes: lockdown and permit disabled
The EVC provides two emergency modes that can help users limit account activity in case of compromise or suspicious activity:
#### Lockdown mode
* When enabled, Lockdown Mode restricts all operations for the affected address prefix (all 256 sub-accounts), except for managing operators and nonces.
* No external contract calls or value transfers are allowed, but controllers can still control collateral for the accounts.
* Useful if you suspect a malicious operator or permit has been added.
Enable with:
```solidity
evc.setLockdownMode(evc.getAddressPrefix(owner), true);
```
#### Permit disabled mode
* When enabled, this mode prevents execution of any permits signed by the owner for the affected address prefix.
* Useful if you believe a harmful permit message has been signed.
Enable with:
```solidity
evc.setPermitDisabledMode(evc.getAddressPrefix(owner), true);
```
:::tip
Both modes can be disabled by calling the same functions with `false`.
:::
### 9. Best practices
* **Use batching** for related operations to save gas and make the operation atomic
* **Use sub-accounts** for position and strategy separation
* **Delegate with operators** for automation only after reviewing the delegated contract or account
* **Simulate** complex transactions before execution
* **Review EVC security features** such as Lockdown Mode and Permit Disabled Mode as part of your account response plan
### Read next
* [EVC overview](/build/evc)
* [EVC implementation security](/build/evc/security)
* [EVC utils](/build/evc/evc-utils)
* [Interact with vaults](/build/evk/interacting-with-vaults)
* [Euler SDK](/build/sdk)
* [Build](/build)
## Security Considerations
The [**Ethereum Vault Connector (EVC)**](./index) is designed as a foundational layer for secure, modular lending and collateral management. While it provides robust security features, both protocol users and integrators must understand its security model, limitations, and best practices to ensure safe operation.
### Core Security Features
#### Lockdown Mode
EVC introduces a `LOCKDOWN MODE` for emergency response. When activated by the owner, it restricts all accounts under that owner to only managing operators and nonces. All other operations, including calling external contracts, are blocked. This is especially useful if a malicious operator is added or a harmful permit is signed. Controllers can still control collaterals for the accounts under lockdown, allowing for safe unwinding of positions if needed.
#### Permit Disabled Mode
Owners can activate `PERMIT DISABLED MODE` to immediately block execution of any permits signed by them. This is a rapid response to accidental signing of a harmful permit.
#### Authentication and Authorization
* **Authentication** is handled by the EVC, which verifies the true sender and context for every operation (including sub-accounts and operators).
* **Authorization** is the responsibility of the vault. When called via EVC, vaults must use `getCurrentOnBehalfOfAccount` to determine the authenticated account and controller status.
#### Account and Vault Status Checks
* EVC enforces rigorous account and vault status checks, ensuring that accounts remain solvent and vault-level invariants are maintained.
* Vaults must require and implement these checks after any operation that could affect solvency or global constraints.
#### Execution Context and Re-entrancy Protection
* EVC maintains an execution context for each batch or call, deferring checks until the end of the context for atomicity and gas efficiency.
* The `checksInProgress` and `controlCollateralInProgress` mutexes prevent re-entrancy and ensure that status checks and collateral control are performed safely.
### Vault Implementation Security Considerations
Vaults integrating with EVC must:
* Implement the [`IVault`](https://github.com/euler-xyz/ethereum-vault-connector/blob/master/src/interfaces/IVault.sol) interface and follow the EVC vault specification ([vault implementation considerations](https://evc.wtf/docs/contracts/vault-implementation-considerations)).
* Use the `callThroughEVC` modifier (or equivalent pattern) to ensure status checks are always deferred and performed in the correct context.
* Always use `getCurrentOnBehalfOfAccount` for authorization when called via EVC.
* Require account and vault status checks at the end of any operation that could affect solvency or vault invariants.
* Implement `checkAccountStatus` and, if needed, `checkVaultStatus` with the recommended access control and context checks.
* Be careful with re-entrancy guards: when called directly (not via EVC), requiring a status check will immediately call back into the vault, which can trigger a re-entrancy guard. Use the callback pattern or relax the guard for status check calls as needed.
* Only allow calls to trusted contracts; never allow arbitrary contract calls from the vault.
* Restrict allowed collateral vaults to a known-good set of audited addresses or use a registry/factory for validation.
### Known Limitations and Attack Vectors
#### EVC Contract Privileges
EVC can call any contract with arbitrary calldata. It should never be given special privileges or hold tokens/ETH except temporarily mid-batch.
#### Read-only Re-entrancy
EVC's non-transient storage can be read while checks are deferred, but each operation leaves these lists in a consistent state. Vaults should not rely on the controller/collateral sets if checks are deferred.
#### Simulation Limitations
The simulation feature sets a flag that can be observed by external contracts. Malicious contracts could behave differently during simulation, so simulations should not be relied on for security with untrusted contracts.
#### Controller Risk
When a user enables a controller, all their collateral is subject to the controller's rules. Only the controller can disable itself, typically after all debt is repaid. Vaults must implement a standard `disableController` function.
#### Operator Risks
Operators have broad permissions; only trusted, audited contracts should be authorized as operators. Owners should be prepared to revoke operator permissions quickly if needed.
### Best Practices for Developers and Users
#### For Vault Developers
* Always use the EVC utility contracts and recommended modifiers for authentication, authorization, and status checks.
* Restrict collateral vaults to known-good, audited contracts.
* Require account and vault status checks after every operation that could affect solvency or vault invariants.
* Use the callback pattern or relax re-entrancy guards for status check calls as needed.
* Implement and test `disableController` logic carefully.
* Never allow uncontrolled calls to arbitrary contracts.
#### For Protocol Integrators and Users
* Use `LOCKDOWN MODE` and `PERMIT DISABLED MODE` immediately if suspicious activity is detected.
* Only enable trusted, audited controllers and operators.
* Use sub-accounts to isolate risk between positions.
* Be aware of the risks of using vaults as collateral, especially if they themselves accept risky collateral.
## Euler Data API V3
Euler Data API V3 is a hosted HTTP API for querying indexed Euler protocol data. It is intended for dashboards, portfolio views, bots, risk systems, research workflows, and integrations that need protocol data without running their own indexer.
Use the interactive reference and OpenAPI document for the current API contract. Versioned clients should still tolerate documented deprecations, indexing lag, and service errors.
The interactive API reference is available at:
**[https://v3.euler.finance/v3/docs](https://v3.euler.finance/v3/docs)**
The OpenAPI document is the current source of truth for request parameters, response schemas, and endpoint availability:
**[https://v3.euler.finance/v3/openapi.json](https://v3.euler.finance/v3/openapi.json)**
### Base URL
All public endpoints are versioned under `/v3`.
```bash
https://v3.euler.finance/v3
```
For example:
```bash
curl https://v3.euler.finance/v3/chains
curl "https://v3.euler.finance/v3/evk/vaults?chainId=1&limit=20"
```
### When to use it
Use Euler Data API V3 when you need indexed, normalized data across Euler markets and chains. Common use cases include:
* Listing supported chains, tokens, EVK vaults, and EulerEarn vaults
* Reading vault details, totals, positions, holders, debt holders, labels, and visibility
* Querying account positions, sub-accounts, and activity
* Fetching token prices, historical prices, APYs, and rewards
* Monitoring liquidations, oracle state, governance actions, and indexed protocol events
* Building analytics workflows without managing RPC calls, event backfills, or local indexing infrastructure
For transaction construction or protocol reads that must exactly match current onchain state, use direct contract calls or lens contracts and simulate against the intended block. The Data API is optimized for offchain access, aggregation, and historical analysis.
### Authentication and rate limits
The API can be queried without an API key. Unauthenticated requests are rate limited by IP address.
API keys can be sent with either `X-API-Key` or a bearer token and provide higher rate limits.
```bash
curl -H "X-API-Key: your-key" \
"https://v3.euler.finance/v3/tokens"
```
Rate limit information is returned in response headers, including `RateLimit-Limit`, `RateLimit-Remaining`, and `RateLimit-Reset`.
### Endpoint families
The API reference contains the full list of endpoints and schemas. At a high level, the API is organized around these resource families:
| Area | Examples |
| ------------------- | ---------------------------------------------------------------------------------------------------------------- |
| Protocol and docs | `/v3`, `/v3/docs`, `/v3/openapi.json`, `/v3/graphql` |
| Chains | `/v3/chains`, `/v3/chains/{chainId}/stats`, `/v3/chains/{chainId}/borrowable-vaults` |
| EVK vaults | `/v3/evk/vaults`, `/v3/evk/vaults/{chainId}/{address}`, `/v3/evk/vaults/batch` |
| Vault history | LTV, cap, IRM, config, totals, positions, events, holders, and debt-holder endpoints |
| EulerEarn | `/v3/earn/vaults`, `/v3/earn/vaults/batch`, `/v3/earn/vaults/{chainId}/{address}` |
| Accounts | `/v3/accounts/{address}/positions`, `/v3/accounts/{address}/activity`, `/v3/accounts/{address}/sub-accounts` |
| Tokens and prices | `/v3/tokens`, `/v3/prices`, `/v3/prices/history`, `/v3/tokens/{chainId}/{address}/price` |
| APYs and rewards | `/v3/apys/intrinsic`, `/v3/apys/intrinsic/history`, `/v3/apys/rewards`, `/v3/rewards/breakdown` |
| Risk and monitoring | `/v3/liquidations`, `/v3/oracles/*`, vault/account event timelines, public-allocator events, and Fee Flow events |
### Response conventions
Responses use a consistent envelope. Successful list responses generally return `data` with optional pagination metadata:
```json
{
"data": [],
"meta": {
"total": 100,
"limit": 20,
"offset": 0,
"timestamp": "2026-07-15T12:00:00.000Z"
}
}
```
Errors return an `error` object with a stable code, message, and request id:
```json
{
"error": {
"code": "VALIDATION_ERROR",
"message": "Invalid chain ID",
"requestId": "req_abc123"
}
}
```
Common field conventions:
| Field | Convention |
| ---------------- | ---------------------------------------------------------------------------- |
| Addresses | EIP-55 checksummed addresses |
| On-chain amounts | Strings, to preserve bigint precision |
| USD prices | Numbers |
| APY values | Percent values, for example `5.25` means 5.25% |
| Timestamps | ISO-8601 UTC for response timestamps; Unix seconds for many query parameters |
### Querying Off-Chain Prices
When building analytics tools, dashboards, or performing off-chain calculations (such as collateral market value), you often need up-to-date asset prices.
:::warning[Endpoint removed]
The previously documented `https://app.euler.finance/api/v1/price` endpoint no longer exists. Use the endpoints below instead.
:::
### Fetching Prices from the Euler V3 API
Euler Data API V3 serves current and historical USD prices for assets used across Euler deployments:
```bash
# Current prices for one or more assets (comma-separated)
curl "https://v3.euler.finance/v3/prices?chainId=1&addresses=0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0,0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2"
# Current price for a single token
curl "https://v3.euler.finance/v3/tokens/1/0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0/price"
# Historical prices over a time range (Unix seconds)
curl "https://v3.euler.finance/v3/prices/history?chainId=1&addresses=0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0&from=1750000000&to=1752000000"
```
Prices are returned as USD numbers (not fixed-point integers), together with a provider-redacted source category and timestamp. The `source` value is one of `onchain`, `offchain`, or `hardcoded`; the response does not include a confidence field:
```json
{
"data": [
{
"chainId": 1,
"address": "0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0",
"symbol": "wstETH",
"decimals": 18,
"priceUsd": 2323.31,
"source": "offchain",
"timestamp": "2026-07-14T16:11:24.895Z"
}
]
}
```
Use the [interactive API reference](https://v3.euler.finance/v3/docs) for exact parameters and schemas.
### Context: Why Use Off-Chain Prices?
In some cases, protocol risk managers configure oracles that do not directly reflect the current market price. For example, they may use hardcoded values for certain assets, or rely on oracles (such as Chainlink) that are naturally lagging behind the market due to heartbeat intervals or update thresholds. This means the on-chain price used for risk management and liquidations may differ from the real-time market price.
For analytics, risk assessment, or user interfaces, you may want to use a more up-to-date or market-reflective price. Off-chain prices can help you calculate the real-time market value of a collateral position and provide users with more accurate portfolio valuations.
Data API price values are for display and analytics. They are not necessarily the configured oracle values a vault uses for solvency or liquidation. For execution-sensitive checks, read the vault's deployed oracle path or the relevant lens at the intended block. Verify chain, token, quote unit, timestamp, and units before consuming any value.
### Read next
* [Data querying overview](/build/data-querying)
* [Build](/build)
* [Lens contracts](/build/data-querying/lens-contracts)
## Data querying
Euler data integrations usually combine indexed data, metadata, and direct contract reads. Choose the source based on whether you need display data, historical data, or onchain state for execution.
### Choose a data source
* **[Euler Data API V3](/build/data-querying/euler-v3-api):** indexed and enriched data for applications and analytics, including chains, vaults, accounts, prices, APYs, rewards, liquidations, governance actions, and event timelines.
* **[Lens contracts](/build/data-querying/lens-contracts):** current onchain vault, account, oracle, IRM, and Earn state aggregated for offchain reads.
* **[Known vault endpoints](/build/data-querying/perspectives):** public HTTP endpoints for checking which vaults are known (initial configuration reviewed at listing time) and fetching their metadata (name, curator, deprecation status).
* **[Using lens contracts](/build/data-querying/using-lens-contracts):** practical account, vault, health, LTV, and APY queries.
* **[Subgraphs](/build/data-querying/subgraphs):** lightweight GraphQL indexes hosted on Goldsky for discovering active deposit and borrow positions across all sub-accounts.
* **Direct calls, logs, and custom indexers:** query vaults, EVC, and periphery contracts directly or maintain an index when the hosted interfaces do not cover your use case.
Euler state is distributed across vaults, EVC, and periphery contracts. Indexed data can lag chain state. For transaction validity, solvency, liquidation, or other execution-sensitive decisions, read or simulate against current onchain state on the target chain.
## Lens contracts
Lens contracts are specialized, read-only smart contracts designed to make it easy for developers and analysts to access and aggregate protocol data from Euler V2. They provide a convenient way to query on-chain state, combining information from multiple contracts into a single, structured response. Typically, lens contracts are meant for off-chain use only as they are not gas optimized.
### What are lens contracts?
In the context of Euler V2, lens contracts are part of the periphery codebase. They are not involved in protocol state changes or user funds, but instead serve as data aggregators and helpers for off-chain applications, dashboards, bots, and research tools. By using lens contracts, you can:
* Retrieve comprehensive account and vault information in a single call
* Access risk metrics, interest rates, caps, and configuration details
* Query on-chain rewards data
* Aggregate data across multiple vaults or accounts
Euler provides several lens contracts, each focused on a specific aspect of the protocol:
#### [`AccountLens`](https://github.com/euler-xyz/evk-periphery/blob/master/src/Lens/AccountLens.sol)
* **Purpose:** Aggregate all relevant information about a user account and its positions across vaults.
* **What you can query:**
* Account balances and shares in vaults
* Borrowed amounts and debt positions
* Collateral and controller status
* On-chain reward and incentive data
* Liquidity and risk metrics (e.g., time to liquidation)
#### [`VaultLens`](https://github.com/euler-xyz/evk-periphery/blob/master/src/Lens/VaultLens.sol)
* **Purpose:** Provide detailed information about a specific vault.
* **What you can query:**
* Vault configuration and parameters (caps, fees, IRM, etc.)
* Total assets, borrows, and shares
* Collateral and their LTVs
* Oracle and price data
* Interest rate model details
#### [`OracleLens`](https://github.com/euler-xyz/evk-periphery/blob/master/src/Lens/OracleLens.sol)
* **Purpose:** Expose information about price oracles and their configuration.
* **What you can query:**
* Oracle types and parameters
#### [`IRMLens`](https://github.com/euler-xyz/evk-periphery/blob/master/src/Lens/IRMLens.sol)
* **Purpose:** Provide metadata and parameters for interest rate models (IRMs).
* **What you can query:**
* IRM type (e.g., Kink, Adaptive Curve)
* Model parameters (base rate, slopes, kink point, etc.)
#### [`UtilsLens`](https://github.com/euler-xyz/evk-periphery/blob/master/src/Lens/UtilsLens.sol)
* **Purpose:** Offer utility queries and helpers for vaults and tokens.
* **What you can query:**
* ERC-4626 vault info
* APYs
* Token balances and allowances
* Indicative on-chain price lookups
* Time to liquidation
#### [`EulerEarnVaultLens`](https://github.com/euler-xyz/evk-periphery/blob/master/src/Lens/EulerEarnVaultLens.sol)
* **Purpose:** Specialized lens for EulerEarn vaults.
* **What you can query:**
* Strategy allocations and performance
* Fee configuration
* Reward and access control data
### Where to find lens contracts
Lens contracts are part of the [EVK Periphery](https://github.com/euler-xyz/evk-periphery/tree/development/src/Lens) repository. You can find their source code and deployment details there.
For contract addresses, check out the [**Contract Addresses** page](../contract-addresses)
For more technical details, see the Solidity interfaces and structs in the periphery codebase, or explore the guides in this section for practical examples.
## Getting Lists of Known Vaults
Euler vaults are permissionless: anyone can deploy one. Integrators, dashboards, and analytics tools therefore need a way to distinguish **known** vaults from unknown or experimental ones. Euler provides public HTTP endpoints for this — the same vault lists and metadata used by the Euler app.
:::warning[Known does not mean safe]
A vault being "known" means only that its **initial configuration** was reviewed by the Euler Labs team at listing time. It is not an endorsement, a safety guarantee, or a promise of ongoing monitoring. Governed EVK vaults may remain under active governor or curator control; finalized and canonical escrow vaults may have no active governor. Always inspect live roles and configuration before depositing into or integrating a vault.
:::
### Public Endpoints for Known Vaults
The endpoints are hosted at `https://app.euler.finance/api/public` and require no API key. Requests are rate limited per IP, and responses are cacheable for short periods (about 30 seconds). Addresses must be valid EIP-55 checksummed or all-lowercase hex; response keys are always checksummed.
#### Check or List Known Vaults
`GET /api/public/is-known` returns whether addresses are known vaults on a given chain:
```bash
curl "https://app.euler.finance/api/public/is-known?chainId=1&addresses=0x797DD80692c3b2dAdabCe8e30C07fDE5307D48a9"
```
```json
{
"0x797DD80692c3b2dAdabCe8e30C07fDE5307D48a9": true
}
```
* `chainId` (required): the chain to check against
* `addresses` (optional): comma-separated list of up to 100 addresses
Omit `addresses` to get the full known set for the chain, returned as an object with `true` values:
```bash
curl "https://app.euler.finance/api/public/is-known?chainId=1"
```
Responses from these public endpoints can also include the top-level request-context fields `countryCode`, `isProxyOrVpn`, and `is_vpn`. These keys are not vault addresses or vault metadata entries, so integrations that iterate over the response object should handle or remove them separately. The proxy/VPN flags are currently returned as strings such as `"false"`.
#### Fetch Vault Metadata
`GET /api/public/metadata` returns display metadata for known vaults — name, description, vault type, deprecation status, product, underlying asset, and the entities (curators) behind it:
```bash
curl "https://app.euler.finance/api/public/metadata?chainId=1&addresses=0x797DD80692c3b2dAdabCe8e30C07fDE5307D48a9"
```
```json
{
"0x797DD80692c3b2dAdabCe8e30C07fDE5307D48a9": {
"chainId": 1,
"address": "0x797DD80692c3b2dAdabCe8e30C07fDE5307D48a9",
"type": "evk",
"name": "K3 Capital Prime Market",
"description": "A lending and borrowing market for stablecoin-denominated assets and selected collateral, configured by K3 Capital",
"portfolioNotice": null,
"deprecationReason": null,
"deprecated": false,
"governanceLimited": false,
"productId": "k3-prime",
"asset": {
"address": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
"symbol": "USDC",
"name": "USD Coin",
"decimals": 6,
"url": "https://token-images.euler.finance/1/0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"
},
"entities": [
{
"name": "K3 Capital",
"logo": "https://labels.euler.finance/master/logo/k3.svg",
"description": "K3 Capital is a third-party curator using Euler infrastructure...",
"url": "https://k3.capital/"
}
]
}
}
```
* `chainId` (required): the chain to query
* `addresses` (optional): comma-separated list of up to 100 addresses; unknown addresses return `null`
* `productId` (optional): only return vaults belonging to a given product slug (e.g. `k3-prime`)
Omit `addresses` to list metadata for every known vault on the chain. `type` is one of `evk` (borrowable vault), `earn` (EulerEarn vault), or `securitize` (Securitize collateral vault).
#### Typical Integration Flow
1. Discover vault and account addresses from the [subgraph](./subgraphs), [lens contracts](./using-lens-contracts), or the [Euler V3 API](./euler-v3-api).
2. Filter the vault list through `/api/public/is-known` to keep only known vaults.
3. Enrich the results with names, curator entities, and deprecation status from `/api/public/metadata` — in particular, check `deprecated` before presenting a vault as active.
### Underlying Data: euler-labels
The vault lists and metadata served by these endpoints are derived from the [`euler-labels`](https://github.com/euler-xyz/euler-labels) repository, which is maintained by the Euler Labs team and acts as the source of truth for vault labels, products, entities, and known-vault status. You can consume the repository directly if you prefer to build your own view of the data.
### Legacy: On-Chain Perspectives
:::warning[Deprecated as a vault-list source]
The `governedPerspective` — the on-chain curated vault list queried via `verifiedArray()` and `isVerified(vaultAddress)` — has been **retired and replaced by the public endpoints above**. It is no longer maintained and should not be used as a source of known vaults.
:::
Not every perspective contract is retired. The factory perspectives (`evkFactoryPerspective`, `eulerEarnFactoryPerspective`) and the `escrowedCollateralPerspective` remain in use for on-chain **provenance and configuration checks** — verifying that a vault was deployed by the canonical factory, or that it is a correctly configured escrow vault. These perform mechanical checks only; they are not a curated list and do not imply review or endorsement.
## Subgraphs
Subgraphs index on-chain data from Euler V2 smart contracts and expose it through GraphQL. Euler's production subgraphs use a deliberately lightweight schema (`euler-simple`) designed to answer one question efficiently: **which accounts have deposits or borrows in which vaults**. This is the same source the Euler apps and the Euler SDK use for account position discovery.
The simple schema does not expose vault configuration, interest rates, APYs, prices, or health scores. For that data, take the vault and account addresses returned by the subgraph and query [lens contracts](./using-lens-contracts) or the [Euler V3 API](./euler-v3-api).
:::warning[Schema change]
The previous `euler-v2-*` subgraphs and their schema (`eulerVaults`, `trackingActiveAccount` keyed by `mainAddress`, `eulerEarnVaults`, `eulerSwapPools`, etc.) have been decommissioned and their endpoints no longer exist. The `euler-simple-*` subgraphs documented below serve **different entities** and are queried by **address prefix** rather than by account address.
:::
### Source Code
The source code for the Euler simple subgraphs is open source and includes the GraphQL schema, entity definitions, and event handlers:
* [Euler Subgraphs GitHub Repository](https://github.com/euler-xyz/euler-subgraph) (`simple-subgraph` branch)
### Available Networks and Endpoints
Each production network has its own subgraph instance hosted by Goldsky — the same networks listed on the [Contract Addresses](/build/contract-addresses) page:
| Network | Chain ID | GraphQL Endpoint |
| --------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Ethereum | 1 | [https://api.goldsky.com/api/public/project\_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-mainnet/latest/gn](https://api.goldsky.com/api/public/project_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-mainnet/latest/gn) |
| BSC | 56 | [https://api.goldsky.com/api/public/project\_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-bsc/latest/gn](https://api.goldsky.com/api/public/project_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-bsc/latest/gn) |
| Unichain | 130 | [https://api.goldsky.com/api/public/project\_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-unichain/latest/gn](https://api.goldsky.com/api/public/project_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-unichain/latest/gn) |
| Polygon | 137 | [https://api.goldsky.com/api/public/project\_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-polygon/latest/gn](https://api.goldsky.com/api/public/project_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-polygon/latest/gn) |
| Monad | 143 | [https://api.goldsky.com/api/public/project\_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-monad/latest/gn](https://api.goldsky.com/api/public/project_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-monad/latest/gn) |
| Sonic | 146 | [https://api.goldsky.com/api/public/project\_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-sonic/latest/gn](https://api.goldsky.com/api/public/project_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-sonic/latest/gn) |
| TAC | 239 | [https://api.goldsky.com/api/public/project\_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-tac/latest/gn](https://api.goldsky.com/api/public/project_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-tac/latest/gn) |
| HyperEVM | 999 | [https://api.goldsky.com/api/public/project\_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-hyperevm/latest/gn](https://api.goldsky.com/api/public/project_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-hyperevm/latest/gn) |
| Base | 8453 | [https://api.goldsky.com/api/public/project\_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-base/latest/gn](https://api.goldsky.com/api/public/project_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-base/latest/gn) |
| Plasma | 9745 | [https://api.goldsky.com/api/public/project\_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-plasma/latest/gn](https://api.goldsky.com/api/public/project_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-plasma/latest/gn) |
| Arbitrum | 42161 | [https://api.goldsky.com/api/public/project\_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-arbitrum/latest/gn](https://api.goldsky.com/api/public/project_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-arbitrum/latest/gn) |
| Avalanche | 43114 | [https://api.goldsky.com/api/public/project\_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-avalanche/latest/gn](https://api.goldsky.com/api/public/project_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-avalanche/latest/gn) |
| Linea | 59144 | [https://api.goldsky.com/api/public/project\_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-linea/latest/gn](https://api.goldsky.com/api/public/project_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-linea/latest/gn) |
| BOB | 60808 | [https://api.goldsky.com/api/public/project\_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-bob/latest/gn](https://api.goldsky.com/api/public/project_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-bob/latest/gn) |
| Berachain | 80094 | [https://api.goldsky.com/api/public/project\_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-berachain/latest/gn](https://api.goldsky.com/api/public/project_cm4iagnemt1wp01xn4gh1agft/subgraphs/euler-simple-berachain/latest/gn) |
### Schema
The simple subgraph indexes vaults deployed by the EVK vault factory, the EulerEarn factory, and the Securitize collateral vault factory, and tracks account activity from vault `Transfer`, `Borrow`, and `Repay` events. It exposes three entities:
| Entity | Keyed by | Purpose |
| ----------------------- | ------------------------------- | -------------------------------------------------------------------------------------- |
| `Vault` | vault address | All indexed vaults and the factory that deployed them |
| `TrackingActiveAccount` | address prefix (first 19 bytes) | Lists of active deposit and borrow positions for all sub-accounts sharing a prefix |
| `TrackingVaultBalance` | account + vault (concatenated) | Internal data structure used to maintain the active position lists — do not rely on it |
The subgraph tells you **where** positions are, not their current size. `TrackingVaultBalance` holds raw values captured at the time of the last event and is immediately outdated — debt in particular accrues interest every second, but the subgraph only re-captures it when a new event touches the position. Read current balances, debt, and health through [lens contracts](./using-lens-contracts) or the [Euler V3 API](./euler-v3-api) instead.
### Address Prefixes
The key difference from the previous subgraphs: account activity is **grouped by address prefix, not by account address**. On Euler, every owner address controls 256 virtual sub-accounts via the [EVC](../evc/index). All of them share the first 19 bytes of the address and differ only in the last byte. The subgraph keys `TrackingActiveAccount` by this shared prefix, so a single query returns positions across all of a user's sub-accounts.
To compute the prefix, lowercase the address and drop the last byte (the last two hex characters):
```js
// 0x + 38 hex characters = first 19 bytes
const getAddressPrefix = (address) => address.toLowerCase().slice(0, 40);
getAddressPrefix("0x2B5A103a91B78E1352fDe6d3b7526bd932d1a2C4");
// => "0x2b5a103a91b78e1352fde6d3b7526bd932d1a2"
```
### How to Get Active Positions of an Account
This is the primary use case for the simple subgraph, and the exact flow used by the Euler apps and the [Euler SDK](../sdk).
#### Step 1: Query the Subgraph by Address Prefix
Use the `trackingActiveAccount` query with the address prefix as the `id`:
```graphql
query AccountPositions($prefix: ID!) {
trackingActiveAccount(id: $prefix) {
deposits
borrows
}
}
```
`deposits` and `borrows` are lists of active positions, each entry a concatenation of the sub-account address (20 bytes) and the vault address (20 bytes), e.g. `0x000000000000000000000000000000000000deade1ce9af672f8854845e5474400b6ddc7ae458a10`.
To parse the entries in JavaScript:
```js
import { getAddress } from "viem";
function parseEntry(entry) {
return {
subAccount: getAddress(entry.substring(0, 42)),
vault: getAddress(`0x${entry.substring(42)}`),
};
}
```
* `subAccount` is the sub-account holding the position
* `vault` is the vault the position is in
To look up several users in one request, batch the prefixes with `trackingActiveAccounts`:
```graphql
query AccountVaults($ids: [String!]!) {
trackingActiveAccounts(where: { id_in: $ids }) {
id
deposits
borrows
}
}
```
#### Step 2: Fetch Detailed Data Using Lens Contracts
Once you have the list of sub-accounts and vaults, use the [lens contracts](./using-lens-contracts) for detailed information:
* Use **`AccountLens`** for account-level data (balances, health, rewards, etc.)
* Use **`VaultLens`** for vault-specific details (configuration, caps, rates, etc.)
#### Step 3: Filter for Known Vaults
Use the [known-vault endpoints](./perspectives) to check whether a vault is known and to fetch its metadata (name, curator, deprecation status). This helps filter out unknown or experimental vaults — note that a vault being known is not a safety guarantee; only its initial configuration was reviewed.
### Other Queries
#### List Indexed Vaults
```graphql
query Vaults {
vaults(first: 1000, orderBy: id, orderDirection: asc) {
id
factory
}
}
```
#### Check Indexing Status
Use `_meta` to check how far the subgraph has indexed — useful for waiting until a recent transaction is reflected in query results:
```graphql
{
_meta {
block {
number
}
}
}
```
## Using Lens Contracts
This guide is for developers, analysts, and integrators who want to query protocol data efficiently and make sense of the results. We'll walk through practical examples and explain the key data types you'll encounter. If you would rather not call the contracts directly, the [Euler SDK](/build/sdk) wraps these lens queries behind typed helpers; the examples below show the underlying calls.
The contract ABIs and deployment addresses for lens contracts are available in the [euler-interfaces](https://github.com/euler-xyz/euler-interfaces) repository. Be sure to use the correct address for your target network.
### Connecting to a Lens Contract
To interact with a lens contract, you'll typically use a web3 library like ethers.js. All lens contracts are read-only, so you can call them from any off-chain context (scripts, dashboards, bots, etc.).
**Example: Connecting to `AccountLens`**
```js
const { ethers } = require("ethers");
const provider = new ethers.JsonRpcProvider(RPC_URL);
const accountLens = new ethers.Contract(ACCOUNT_LENS_ADDRESS, AccountLensABI, provider);
```
### Querying Account Data: `getAccountInfo`
The `getAccountInfo(account, vault)` function returns a comprehensive snapshot of a user's position in a vault. The result is an `AccountInfo` struct, which contains several nested types:
* **`EVCAccountInfo`:** General info about the EVC sub-account (owner, enabled controllers/collaterals, status flags)
* **`VaultAccountInfo`:** Position data for the vault (balances, shares, borrowings, collateral/controller status, liquidity info)
* **`AccountRewardInfo`:** On-chain reward and incentive data (balances and earned rewards)
If you want to query the same data for all enabled collaterals and controllers of an account in one call, use `getAccountEnabledVaultsInfo(evc, account)`. This function returns arrays of the same types for every enabled vault, making it efficient to fetch a user's full protocol exposure. Note that this function only returns data for vaults that are explicitly enabled as collateral or controller in the EVC - it won't return information about deposits in vaults that aren't enabled as collateral.
**Example:**
```js
const account = "0x...";
const vault = "0x...";
const info = await accountLens.getAccountInfo(account, vault);
// Accessing nested data:
console.log("Owner:", info.evcAccountInfo.owner);
console.log("Vault shares:", info.vaultAccountInfo.shares);
console.log("Borrowed:", info.vaultAccountInfo.borrowed);
console.log("Is Controller:", info.vaultAccountInfo.isController);
console.log("Earned rewards:", info.accountRewardInfo.enabledRewardsInfo);
```
#### Understanding the Types
* **`AccountInfo`**: The top-level struct, grouping all relevant data for a user/vault pair.
* **`EVCAccountInfo`**: Includes the EVC address, owner, enabled controllers/collaterals, and status flags (e.g., lockdown mode).
* **`VaultAccountInfo`**: Contains balances, shares, borrowings, allowances, collateral/controller status, and liquidity info (including time to liquidation and collateral values).
* **`AccountRewardInfo`**: Shows reward balances and details for any enabled onchain rewards.
> **Tip:** Many fields are nested structs or arrays. Use dot notation to access them (e.g., `info.vaultAccountInfo.liquidityInfo.timeToLiquidation`).
#### Position Health, Collateral Value, and Health Score
When analyzing your account's risk and health, it's important to understand how the protocol evaluates your positions. Here are some key concepts and how to extract them using the lens contracts:
* **Health Score (Health Rate):**
* The health score is a measure of how safe your borrow position is. It is calculated as:
`healthScore = collateralValueLiquidation / liabilityValueLiquidation`
where both values are found in `VaultAccountInfo.liquidityInfo`.
* To get the health score for a borrow position, you must query the vault from which you borrowed (the controller vault). In the context of `getAccountEnabledVaultsInfo`, this will be the vault where `isController` is true.
* **Risk-Adjusted Collateral Value:**
* The protocol uses different collateral values for borrowing and for liquidation:
* `collateralValueBorrowing`: The value of your enabled collaterals as seen for borrowing purposes.
* `collateralValueLiquidation`: The value of your enabled collaterals as seen for liquidation purposes (usually more conservative).
* Both are available in `VaultAccountInfo.liquidityInfo`.
* These values are aggregated across all enabled collaterals for the position, but you can also see the breakdown per collateral in the `collateralValuesBorrowing` and `collateralValuesLiquidation` arrays.
* **Collateral Market Value (Raw):**
* The raw market value of your collaterals, as seen by the controller vault, is given by `collateralValueRaw` in `VaultAccountInfo.liquidityInfo`.
* The breakdown per collateral is available in the `collateralValuesRaw` array.
* **Off-Chain Collateral Market Value:**
* If you want to compute the market value of your collateral using off-chain prices, multiply your collateral **asset balance** (not shares) by the current market price of the asset. For example:
`offChainCollateralValue = assetsAccount * assetPrice`
where `assetsAccount` is the asset balance from `VaultAccountInfo.assetsAccount` and `assetPrice` is the off-chain price per unit of the asset.
* Note: For some assets, you may need to use your own price source if the [Data API price endpoints](/build/data-querying/euler-v3-api#fetching-prices-from-the-euler-v3-api) do not return a value.
> **Tip:** The `getAccountEnabledVaultsInfo` function returns an `AccountMultipleVaultsInfo` struct, which contains an array of `VaultAccountInfo` for each enabled collateral and controller. For borrow positions, focus on the vault where `isController` is true to get the health and risk data for your position.
### Querying Vault Data: `getVaultInfoFull`
The `getVaultInfoFull(vault)` function (from `VaultLens`) returns a `VaultInfoFull` struct, which is a detailed snapshot of a vault's configuration and state.
**Example:**
```js
const vaultLens = new ethers.Contract(VAULT_LENS_ADDRESS, VaultLensABI, provider);
const vaultInfo = await vaultLens.getVaultInfoFull(vault);
console.log("Vault name:", vaultInfo.vaultName);
console.log("Total assets:", vaultInfo.totalAssets);
console.log("Interest rate model:", vaultInfo.interestRateModel);
console.log("Supply cap:", vaultInfo.supplyCap);
console.log("Recognized collaterals:", vaultInfo.collateralLTVInfo);
```
#### Key Types in `VaultInfoFull`
* **`VaultInfoFull`**: The main struct, with fields for vault configuration, totals, caps, fees, IRM, oracles, hooks, and more.
* **`LTVInfo[]`**: An array of collateral types and their LTV (Loan-to-Value) parameters. Each `LTVInfo` includes the collateral address, borrow and liquidation LTVs, and ramping info.
* **`VaultInterestRateModelInfo`**: Details about the vault's interest rate model, including type and parameters.
* **`AssetPriceInfo`**: Price and oracle data for assets and collaterals.
> **Tip:** Arrays like `collateralLTVInfo` are append-only, so not all entries may be active collaterals. Always check the LTV values - a collateral with zero `borrowLTV` is no longer accepted as collateral. Only iterate through entries with non-zero LTVs to display currently supported collaterals and their risk parameters.
> **Tip:**
> If a vault is ramping down its liquidation LTV, you can calculate the current liquidation LTV for a collateral using the following formula, based on the fields in the `LTVInfo` struct returned by the lens:
>
> ```js
> // LTVInfo fields:
> // - liquidationLTV: target value (uint256)
> // - initialLiquidationLTV: starting value at ramp start (uint256)
> // - targetTimestamp: when ramping ends (uint256, unix time)
> // - rampDuration: total ramp duration (uint256, seconds)
>
> function getCurrentLiquidationLTV(ltvInfo) {
> const now = Math.floor(Date.now() / 1000); // current unix timestamp
> if (
> now >= ltvInfo.targetTimestamp ||
> ltvInfo.liquidationLTV >= ltvInfo.initialLiquidationLTV
> ) {
> return ltvInfo.liquidationLTV;
> }
> const timeRemaining = ltvInfo.targetTimestamp - now;
> return (
> ltvInfo.liquidationLTV +
> ((ltvInfo.initialLiquidationLTV - ltvInfo.liquidationLTV) * timeRemaining) /
> ltvInfo.rampDuration
> );
> }
> ```
>
> This matches the on-chain logic: the liquidation LTV linearly ramps from `initialLiquidationLTV` to `liquidationLTV` over the period ending at `targetTimestamp`. If ramping is not active, just use `liquidationLTV`.
### Querying APYs for a Vault
To quickly fetch the current borrow and supply APYs for a vault, use the `getAPYs(vault)` function from the `UtilsLens` contract. This function returns the annualized borrow and supply rates, computed based on the vault's current interest rate model and utilization.
**Example:**
```js
const utilsLens = new ethers.Contract(UTILS_LENS_ADDRESS, UtilsLensABI, provider);
const [borrowAPY, supplyAPY] = await utilsLens.getAPYs(vault);
console.log("Borrow APY:", borrowAPY);
console.log("Supply APY:", supplyAPY);
```
The returned values are typically expressed in ray units (`1e27`), so you may need to convert them to a human-readable percentage (e.g., `Number(borrowAPY) / 1e25` gives the APY as a percent with two decimals).
> **Note:** The APYs returned here only include the Euler rates from lending and borrowing activity within the protocol. They do **not** include any intrinsic APY from the underlying asset (for example, the staking yield of wstETH) or any additional rewards. To account for those, you must supplement with external data sources.
### Where to Find Type Definitions and More Resources
The full definitions of all structs and types used by lens contracts can be found in the [LensTypes.sol](https://github.com/euler-xyz/evk-periphery/blob/master/src/Lens/LensTypes.sol) file in the EVK Periphery repository.
## Fee Flow
Euler does not currently charge protocol fees. In April 2026, Fee Flow was turned off and Euler protocol fees were set to 0% across live and future deployments. The DAO can reintroduce protocol fees through future governance. See [Reduce Euler Protocol Fees to Zero](https://forum.euler.finance/t/proposal-reduce-euler-protocol-fees-to-zero/1835/1).
Curators and vault operators may still configure separate vault-level fees, such as EVK interest fees or EulerEarn performance fees, where supported by the relevant vault.
Fee Flow is a continuous sequence of Dutch auctions. A `FeeFlowController` can hold multiple fee assets and has one immutable payment token and payment receiver. For Euler's EUL-denominated deployment, a buyer pays EUL and receives the controller's **entire balances of the asset addresses supplied to `buy`**. This is an asset sale for EUL, not an auction in which bidders offer progressively larger amounts.
### Mechanics
1. The current payment amount starts at the epoch's `initPrice` and decreases linearly to zero over `epochPeriod`.
2. A caller chooses the asset-address list and receiver, and supplies the current epoch ID, a deadline, and a maximum payment amount.
3. `buy` transfers the current payment amount from the caller to the immutable `paymentReceiver`, then transfers the controller's full balance of every supplied asset to `assetsReceiver`.
4. Settlement immediately starts the next epoch. Its initial price is the settlement payment multiplied by `priceMultiplier`, bounded below by `minInitPrice` and above by the contract maximum.
The contract does **not** value its inventory, determine when inventory is worth the price, or require a bid contest. Buyers make that assessment offchain. If an asset is omitted from the supplied list, it remains in the controller. After an epoch has elapsed the computed payment can be zero, subject to transaction ordering and the caller's safeguards.
```solidity
feeFlow.buy(
assets, // assets to sweep from the controller
assetsReceiver,
currentEpochId,
deadline,
maxPaymentTokenAmount
);
```
Use `getSlot0()` and `getPrice()` immediately before constructing a purchase. Protect execution with the epoch ID, deadline, maximum payment, private transaction strategy where appropriate, and an independently verified inventory list. A malicious token in the list can revert or behave unexpectedly.
### Accounting taxonomy
Keep these quantities separate:
* **Fee inventory:** non-payment assets held by the controller and available to a buyer.
* **Auction receipts:** payment tokens transferred directly to `paymentReceiver` at settlement.
* **Treasury-held EUL:** EUL controlled by a DAO treasury address or another DAO-controlled position.
* **Reward inventory/distributions:** EUL committed to or distributed by reward programs, including rEUL backing where applicable.
* **Burned EUL:** EUL actually sent to a burn address or otherwise destroyed according to the relevant token contract.
Paying EUL into Fee Flow does not itself burn EUL. Nor does the contract itself prove that its payment receiver is DAO-controlled; verify constructor parameters and receiver control for the deployment.
### Current status
Fee Flow has been turned off and Euler protocol fees are currently set to zero. Before integrating against a historical or future deployment, verify the relevant chain's `ProtocolConfig`, vault fee configuration, Fee Flow address, and governance state. Vault-level curator or governor fees are separate from protocol fees.
### Sources
* [`FeeFlowController.sol`](https://github.com/euler-xyz/fee-flow/blob/master/src/FeeFlowController.sol)
* [Fee Flow whitepaper](https://github.com/euler-xyz/fee-flow/blob/master/docs/whitepaper.md)
* [DAO treasury taxonomy](/euler-dao/treasury)
## Multichain EUL
Some EUL deployments use LayerZero OFT adapters. The set of networks, trusted peers, routes, limits, fees, and any preferred hubs are configuration facts that can change. Do not assume every EUL deployment can transfer directly to every other deployment, or that a historical hub-and-spoke proposal still describes current peers.
Ethereum's address files identify the original EUL token and an `eulOFTAdapter`; other chains may identify a bridged token or adapter. A label such as `MintBurnOFTAdapter` describes contract behavior, not current connectivity or governance.
### Before bridging
1. Obtain token and bridge addresses from [EUL addresses](/EUL/addresses) and the linked source files.
2. Verify the source and destination chain IDs and deployed bytecode.
3. Inspect the adapter's configured LayerZero peers and enforced options for that exact route.
4. Use the adapter/bridge quote for fees and limits; do not rely on a copied route diagram.
5. Confirm the recipient and expected destination token address before signing.
6. For accounting, reconcile locked canonical EUL with minted/burned remote representations; do not add all chain supplies as independent EUL.
The [LayerZero bridge governance proposal](https://forum.euler.finance/t/eip-63-select-layerzero-oft-as-eul-cross-chain-bridge-solution/1258) is historical rationale, not a live route registry.
## Overview
### Introduction
**EUL** is an ERC20 token that acts as the native governance token of the Euler protocol. EUL tokens serve as rewards on the platform, represent voting power in Euler DAO governance, and act as the payment token in [Fee Flow](./fee-flow) auctions (currently inactive, with protocol fees set to 0%). Governance voting and execution from a treasury or operational Safe are separate steps. EUL can be transferred between supported networks. Find the official addresses [here](./addresses).
### Token Utility
* **Governance**: EUL tokens grant holders the ability to participate in votes on protocol changes and treasury management.
* **Fee Flow Auctions**: When Fee Flow is active, buyers pay EUL to the configured payment receiver in exchange for fee assets held by the Fee Flow controller. The fee assets—not the EUL payment—are the auction inventory, and payment does not itself burn EUL. Fee Flow is currently turned off, with protocol fees set to 0%.
* **Rewards**: EUL is distributed as rewards to users for participating in the protocol.
### Token Distribution
The total supply of EUL is 27,182,818 (in homage to [Euler's number](https://www.investopedia.com/terms/e/eulers-constant.asp), e). Below is the allocation breakdown as of 31/01/25, with links to governance proposals reflecting historical changes.
#### Euler DAO
Around 34% of EUL tokens have been allocated to the Euler DAO, protocol users, or used to fund various ecosystem growth initiatives. This figure includes the roughly 3.7% subsequently granted from the DAO treasury to the Euler Foundation, described in the next section. Holders of EUL tokens can vote on how treasury tokens are used. Among this group:
* \~1% (271,828 EUL) was distributed to users on Euler during its soft launch in 2021.
* \~0.18% (48,100 EUL) was deployed to Uniswap v3 as protocol-owned liquidity following a governance [proposal](https://forum.euler.finance/t/eip-58-eul-liquidity/1062) on 22/02/24.
* As of 31/01/25, \~22.9% (6,236,107 EUL) was held, unlocked, in the then-current Euler DAO [Treasury multisig](https://etherscan.io/address/0xcAD001c30E96765aC90307669d578219D4fb1DCe). In November 2025, the Euler Foundation [recategorised this address](https://forum.euler.finance/t/euler-foundation-multisig-update/1703) as the Operational multisig and [transferred treasury assets](https://etherscan.io/tx/0xae69ec1b51a553ca138c17158a7160b200040b3616bac161dd9014f87ad691fa), excluding protocol revenue retained during the transition, to [0xC7C5aFDB61e08BE3e2FB09098412b5706EB5c550](https://etherscan.io/address/0xC7C5aFDB61e08BE3e2FB09098412b5706EB5c550).
* \~6.3% (1,712,517 EUL) was distributed to protocol users as rewards during the period 2021 to 2025.
:::note
Token numbers for the treasury and protocol users change continuously as EUL is distributed as rEUL rewards to users following a governance [proposal](https://forum.euler.finance/t/euler-rewards-update/1145/1) on 04/11/24. Numbers shown are only accurate as of 31/01/25.
:::
#### Euler Foundation
Around 3.7% of EUL tokens have been allocated to the Euler Foundation, a legal entity representing the interests of the Euler DAO. These tokens have largely been used to facilitate ecosystem growth via provision of protocol-owned liquidity:
* \~0.018% (5,000) EUL was allocated to the Euler Foundation as an operating budget, following a governance [proposal](https://forum.euler.finance/t/eip-57-euler-foundation-operational-funding/1023) on 15/12/23.
* \~3.7% (1,000,000 EUL) was allocated to the Euler Foundation to enable them to facilitate ecosystem initiatives, following a governance [proposal](https://forum.euler.finance/t/eip-60-ecosystem-initiatives-proposal/1084) on 18/05/24. Note that:
* A total of 906,200 EUL was deployed by the Euler Foundation as additional protocol-owned liquidity to Balancer v2, Aera, and Arrakis.
* As of 31/01/25, a remaining 80,598 EUL was held by the Euler Foundation multisig [wallet](https://etherscan.io/address/0x967b10c27454cc5b1b1eeb163034acde13fe55e2).
#### Strategic Partners
Around 39.5% of EUL tokens have been allocated to various cohorts of strategic growth partners, who helped provide support for the development of the Euler protocol in various ways. All of these tokens are fully unlocked. Among these:
* \~4% (1,087,313 EUL) were given to Encode, an early project [incubator](https://medium.com/eulerfinance/introducing-euler-8f4422f13848).
* \~10% (2,718,282 EUL) were given to [Cohort A](https://www.prweb.com/releases/oxford-researcher-led-euler-xyz-announces-800k-seed-round-to-build-decentralised-finance-defi-start-up-854179288.html) growth partners, including Lemniscap, CMT Digital, Launchub, and others.
* \~15.85% (4,308,477 EUL) were given to [Cohort B](https://www.theblock.co/post/115502/paradigm-leads-8-million-series-a-into-defi-lending-company-euler) growth partners, including Paradigm, a variety of industry angel investors, and others.
* \~9.67% (2,628,170 EUL) were given to [Cohort C](https://www.theblock.co/linked/150447/haun-ventures-leads-32-million-round-in-ethereum-protocol-euler) growth partners, including Haun Ventures, Coinbase Ventures, Uniswap Labs Ventures, Jane Street, and others.
#### Euler Labs
Around 26.5% of EUL tokens have been allocated to project founders and other contributors to the development of the protocol via their association with Euler Labs:
* \~26.5% (7,203,446 EUL) to employees, advisors and consultants of Euler Labs. Note that:
* Founder vesting linear unlock schedule starting on 01/01/2022.
* Non-founder vesting is specific to individuals, but typically follows a non-linear 48 month schedule.
* Figure shown here includes an additional 1.6m tokens allocated in a governance [proposal](https://forum.euler.finance/t/eip-59-contract-for-services-with-euler-labs/1071) on 07/03/24.
### Links
More information about EUL can be found on:
* [Etherscan](https://etherscan.io/address/0xd9fcd98c322942075a5c3860693e9f4f03aae07b)
* [CoinMarketCap](https://coinmarketcap.com/currencies/euler-finance/)
* [CoinGecko](https://www.coingecko.com/en/coins/euler)
## Reward EUL
### Introduction
Reward EUL (rEUL) is a locked form of EUL designed to incentivize early adopters of the v2 version of the protocol. Users of Euler receive rEUL rewards by participating in supported markets, with both supply and borrow activities eligible for rewards. The rEUL token converts 1:1 into EUL over six months, following a non-linear unlock schedule:
* **20% unlocks immediately**: For each lock, 20% of its underlying EUL is vested and redeemable right away.
* **80% unlocks linearly over six months**: The remaining portion vests gradually.
* **Forfeiture**: Users can redeem a selected lock at any time, but doing so closes that lock. Any unvested EUL is forfeited and sent to the contract's configured `remainderReceiver`.
### Example
Suppose Alice deposits $10,000 USDC into Euler and earns 100 rEUL per month as rewards. After three months, she transfers 300 rEUL to her wallet. At this point, the unlock period for 300 EUL begins.
She has the following options:
* **Immediate redemption**: She can redeem 60 EUL right away (20% of her expected 300 EUL at maturity). Doing so closes the selected lock and sends the unvested 240 EUL to the contract's configured `remainderReceiver`.
* **Full vesting**: If she waits the full six-month period, she can redeem the full 300 EUL.
* **Redemption before maturity**: She can redeem a selected lock before full maturity and receive the amount vested at that time. The selected lock still closes in full, and its unvested remainder is forfeited.
Additionally, Alice can continue withdrawing rEUL to her wallet at any time. Each transfer starts a separate unlock schedule, making rEUL a non-fungible asset despite its ERC-20-like interface.
### How to earn
Deposits or borrows eligible for rEUL incentives display a green sparkle icon next to the Supply or Borrow APY. Once deployed, a user begins accruing rEUL immediately. Any earned rEUL is displayed on both the portfolio page and navigation bar for [Euler Finance](https://app.euler.finance/).
:::info
**Important note**. Reward calculations and distribution are handled by Merkl, and their systems can take up to 12 hours to update.
:::
### How to Convert rEUL to EUL
To convert rEUL to EUL, a user first needs to claim the rEUL to their wallet. This can be done on the portfolio page of [Euler Finance](https://app.euler.finance/) or on the [Merkl webpage](https://app.merkl.xyz/).
Once rEUL has been claimed to a user's wallet, a clock is started on vesting, enforcing the terms outlined above. A user can redeem a selected lock at any time. Redemption burns the rEUL wrapper amount for that lock, sends the vested underlying EUL to the user, sends the unvested remainder to the configured `remainderReceiver`, and closes the selected lock. The wrapper burn reduces rEUL supply; it does not burn EUL or reduce EUL `totalSupply`. The amount that is currently vested / unvested is displayed on the portfolio page of [Euler Finance](https://app.euler.finance/).
### FAQ
#### Can I swap rEUL?
No, rEUL tokens cannot be swapped. While they appear in your wallet like standard ERC-20 tokens, they are actually non-fungible. Each time you claim rEUL, a new vesting period begins, meaning no two claims are identical. As a result, rEUL tokens cannot be exchanged like regular ERC-20 tokens.
#### Can I transfer rEUL?
It depends. Most rEUL tokens in a user's wallet are locked and cannot be transferred to general-purpose wallet addresses. However, transfers are allowed to certain whitelisted addresses, primarily smart contracts linked to third-party Euler integrations. In most cases, users will not need to transfer their tokens to these addresses.
#### Has rEUL been audited?
Yes. The audit was performed by two yAudit lead security researchers, HHK and Panda, and can be viewed [here](https://github.com/euler-xyz/evk-periphery/tree/master/audits).
### Further Reading
See the [rEUL Rewards Governance Proposal](https://forum.euler.finance/t/reward-eul-reul/1133) for more details.
import { NetworkTabs } from "../../components/NetworkTabs";
## EUL addresses
:::warning
Verify the network, chain ID, contract bytecode, and token symbol/decimals before a transfer. A copied address table can become stale.
:::
### Canonical source
The table above is populated from the [`euler-interfaces/addresses`](https://github.com/euler-xyz/euler-interfaces/tree/master/addresses) repository, the canonical record of published deployments. To verify an address directly, open the folder for the numeric chain ID and check `TokenAddresses.json` (or `BridgeAddresses.json` for bridge contracts) on the `master` branch, which reflects the latest published deployments.
A zero address means nothing is published for that key. A published token address does not by itself mean a bridge route is configured on that network.
### A note on burns
Fee Flow payments, treasury transfers, and unvested reward balances do not burn EUL. For rEUL early redemptions, the forfeited amount only reduces supply if the deployed reward contract actually burns it — check the contract's behavior and transaction events before counting it as burned.
### Read next
* [EUL overview](/EUL/overview)
* [Multichain EUL](/EUL/multichain)
* [Reward EUL](/EUL/reward-eul)