Euler (EUL)

Euler: Modular Lending Markets Built Around Vaults

Euler is a permissionless lending system that replaces the single shared pool model with configurable vaults, connected accounts, and market-specific risk controls. EUL mainly coordinates governance and selected reward or fee mechanisms rather than serving as collateral for ordinary lending activity.

What Euler is designed to do

Euler V2 is infrastructure for creating, curating, and using onchain credit markets. Suppliers deposit assets into lending vaults, borrowers provide eligible collateral and draw debt, and market operators configure the relationships between those assets. EulerEarn adds single-asset vaults that can allocate deposits across configured strategies. The system is therefore aimed at several groups: individuals seeking lending or borrowing markets, developers integrating credit into applications, and curators responsible for setting market parameters.

The system is permissionless at the vault-creation layer. Anyone can deploy an Euler Vault Kit vault for an ERC-20 asset, but permissionless deployment does not mean every vault is equally suitable for use. A market's practical profile depends on its collateral links, oracle route, interest-rate model, caps, hooks, liquidity, and governance configuration. Users must evaluate the specific vault or market rather than treating the Euler protocol as one uniform pool.

The vault-based architecture

The Euler Vault Kit extends the ERC-4626 vault standard with borrowing functionality. Each credit vault holds one underlying asset, records deposits and debt, accrues interest, checks account health, and can support liquidations. Borrower interest is the principal source of lending yield in a basic credit vault: as debt grows, the vault's accounting reflects the interest owed to suppliers, less configured fees and other adjustments.

A liability vault determines which other vaults may be used as collateral. Price-oracle components value collateral and debt, while interest-rate models determine the borrow-rate input. The protocol supports isolated vault and market configurations, so risk can be separated by asset or connected through explicitly chosen collateral relationships. Compared with Euler's earlier shared-pool design, this makes the configuration of each market more consequential: an oracle, loan-to-value factor, cap, or governor can materially change the behavior of a position.

The Ethereum Vault Connector

The Ethereum Vault Connector, or EVC, is the coordination layer for Euler V2 accounts and vaults. It can bundle deposits, borrows, repayments, swaps, and other actions into one atomic transaction. It also supports sub-accounts, delegated operators, signed permissions, and deferred account checks. These functions allow integrators to build more complex workflows without writing a separate coordination system for every vault combination.

The EVC also changes how collateral and borrowing authority are organized. When a user borrows through an EVC account, a liability controller can enforce the borrowing vault's collateral rules, including restrictions on withdrawals and liquidation actions. The design is useful for composable lending strategies, but it adds another dependency: users and integrators need to understand the controller, sub-account, operator, and account-check settings attached to a position.

What EUL does

EUL is Euler's ERC-20 governance token. The project's documentation assigns it three principal roles: voting in Euler DAO governance, distribution as rewards to protocol participants, and use as the payment token in Fee Flow auctions. The documented maximum supply is 27,182,818 EUL. Fee Flow is currently described by the project as inactive, with protocol fees set to zero, so that mechanism should not be treated as an active source of demand without a later change in configuration.

EUL is not presented as the asset that powers ordinary borrower collateral or supplier accounting. Those functions are handled by the assets deposited into individual vaults and by the vault shares issued to suppliers. EUL's direct connection to the protocol is instead governance, rewards, and the conditional Fee Flow design. The official address documentation also warns that a published token address does not by itself establish a bridge route on a given network, making chain and contract verification necessary before transfers.

Governance and control

Euler governance combines offchain discussion and voting with onchain execution for proposals that change smart contracts. The stated process moves from discussion and a request-for-comment to an Euler Improvement Proposal, followed by Snapshot voting. Proposals involving smart-contract changes may proceed to Tally for onchain voting, after which successful proposals target protocol contracts. The published parameters list different thresholds, quorums, and voting periods for Snapshot and Tally.

Governance can influence risk parameters such as collateral factors, borrow factors, asset tiers, and the wider risk methodology. However, not every important decision is controlled by the EUL DAO in the same way. Individual vaults may have their own governors, upgrade settings, or finalised configurations, and offchain votes can require execution by the Euler Foundation rather than automatically changing code. This creates a layered control model in which token governance, vault-level governance, factory administration, and operational roles can all matter.

Security record and practical limits

Euler publishes a security program covering formal verification, independent reviews, deployment verification, fuzzing, and monitoring. Its documentation states that the public review record covers more than 60 engagements and that Certora has formally verified properties of Euler V2 core and EulerEarn. The code repository also describes the Vault Kit as experimental software supplied without warranties, which is a reminder that audits and formal methods reduce some risks but do not eliminate implementation, configuration, or economic failures.

The main unresolved risk is configuration complexity. A position depends not only on shared protocol components but also on the selected vault's oracle, collateral relationships, LTVs, caps, liquidity, hooks, governor, and upgrade state. Permissionless vault creation expands the range of possible markets, including markets with weak pricing or governance choices. Cross-vault composition can also create dependency chains in which a problem in an underlying asset, oracle, integration, or nested vault affects a wider position.

Key takeaways

• Euler V2 is a modular lending framework built from independent ERC-4626-style credit vaults.
• The Euler Vault Kit lets creators configure assets, collateral relationships, oracles, interest-rate models, caps, hooks, and governance.
• The Ethereum Vault Connector coordinates batching, sub-accounts, operators, delegated execution, and account health checks.
• EUL is primarily a governance and reward token; Fee Flow use is documented but currently inactive according to Euler's documentation.
• A vault's risk depends heavily on its live configuration, curator or governor, oracle design, liquidity, and upgrade permissions.
• Audits and formal verification provide evidence of review, not a guarantee against smart-contract, market, oracle, or governance losses.

Risks and open questions

• Permissionless vault creation means users may encounter markets with materially different risk controls and governance arrangements.
• Oracle failure, stale pricing, collateral volatility, or an unsuitable loan-to-value setting can trigger liquidations or losses.
• Upgradeable vaults, factory administration, governors, operational Safes, and Foundation execution roles create control dependencies that vary by deployment.
• Nested vaults and integrations can introduce additional dependency chains and make risk harder to assess from the EUL token alone.
• EUL's Fee Flow role is conditional because the project's documentation says Fee Flow is currently inactive and protocol fees are set to zero.
• Published token addresses and supported network labels do not by themselves prove that every bridge route, deployment, or market is active or suitable for use.