What Is Euler?

Introduction

Euler is a decentralized lending and borrowing protocol, but the important part is how it approaches that job. Most lending protocols begin by tightly controlling which assets and markets exist. Euler pushes in the other direction: it is built to let developers create custom lending vaults and, in its earlier design, to support permissionless market listing, while still trying to contain the extra risk that openness creates.

That is the puzzle at the center of Euler. In lending, openness is attractive because DeFi moves quickly and new assets appear constantly. But lending is not like spot trading. If a protocol lets users borrow against collateral, then a bad listing decision, a weak oracle, or a flawed liquidation design can spread losses through the system. Euler matters because it tries to make credit markets more programmable without pretending that risk disappears.

In practice, Euler is for two overlapping groups. For users, it is a place to lend assets to earn yield or to borrow against posted collateral. For builders, it is infrastructure: a modular system for launching custom lending markets and connecting vaults into larger DeFi products. The same design choice that makes Euler attractive to builders (flexibility) is also what makes its risk controls and security history essential to understand.

What problem is Euler trying to solve in DeFi lending?

A lending market has to answer two questions at once. First, how do idle assets become available for borrowers? Second, how does the protocol decide whether a borrower is still safe or needs to be liquidated? Many protocols solve those questions with a fairly curated model: governance chooses supported assets, sets parameters, and limits what can happen.

Euler’s bet is that this curation creates a bottleneck. If every new market depends on slow approval and one standard market design, then DeFi credit remains narrower than the assets and strategies people actually want to use. Euler therefore presents itself as a credit layer for programmable finance: not just an app for lending and borrowing, but a base layer that other apps and vaults can build on top of.

That framing explains why Euler emphasizes modular tools such as the Euler Vault Kit (EVK) and the Ethereum Vault Connector (EVC). EVK is the toolkit for creating custom lending vaults. EVC is the mechanism that lets vault positions interact so that vaults can be used as collateral for other vaults. The core idea is composability: instead of one monolithic market structure, Euler offers building blocks that can be assembled into different credit products.

How do lending and borrowing work for users on Euler?

At the user-facing level, Euler still looks familiar if you have used DeFi lending before. A lender deposits an asset into a pool or vault. In return, the protocol mints a tokenized claim on that position. In Euler’s earlier architecture, those supplier claims were called eTokens, which are interest-bearing ERC-20 tokens representing a share of the pool’s assets. As interest accrues from borrowers, the value represented by those claims rises.

Borrowing is the mirror image. A user posts collateral, then draws another asset against it. Euler’s earlier design represented debt with dTokens, ERC-20 debt tokens. That tokenization matters because it makes positions easier to integrate into other smart contracts. The protocol is not only tracking balances in an internal database; it is exposing supply claims and debt claims as programmable on-chain objects.

The mechanism becomes clearer in a simple example. Imagine a user deposits a volatile asset as collateral and borrows a stablecoin. If the collateral keeps enough value relative to the debt, the position remains healthy. If the collateral falls too much, the protocol needs a way to close part of the position before lenders are exposed to a shortfall. Euler therefore treats solvency as a live condition, not a one-time check at the moment of borrowing.

This is where Euler departs from simpler lending designs. Instead of only discounting collateral values, Euler’s white paper describes a two-sided risk adjustment. The protocol uses both collateral factors and borrow factors. Intuitively, it does not just ask, “How much should we haircut the collateral?” It also asks, “How much extra risk should we assign to the liability?” That matters because some borrowed assets are themselves more dangerous to owe than others are dangerous to hold.

Why are permissionless markets on Euler powerful and risky?

The feature that made Euler stand out historically was permissionless listing. In the v1 white paper, Euler states that any asset with a WETH pair on Uniswap v3 could be added as a lending market. That is a very different philosophy from governance-curated lending menus.

The appeal is obvious. Long-tail assets can get credit markets faster. Builders do not have to wait for a central committee to decide that their token is important enough. DeFi can experiment with more market structures and move closer to the way permissionless exchanges expanded beyond handpicked pairs.

But here is the mechanism that creates the risk: a lending market is fragile in ways a spot market is not. If an illiquid or manipulable asset is accepted too freely, the protocol may overestimate collateral value or underestimate liquidation difficulty. When users can borrow against that mistaken value, losses can propagate to lenders.

Euler’s answer was not to deny the risk, but to classify it. Its white paper describes asset tiers designed to limit contagion. Some assets could only be borrowed in isolation. Some could be borrowed alongside others but not used as collateral. The safest tier could be used for ordinary lending and collateralized borrowing. This is a containment system. Rather than saying every listed asset is equally trustworthy, Euler tries to separate experimental assets from the parts of the system where they could do the most damage.

That design also reveals who Euler is really for. If you are a casual user who only wants the deepest, most conservative blue-chip lending markets, a more tightly curated protocol may feel simpler. Euler is more compelling for users and builders who value access, customization, and composability enough to spend more attention on market-specific risk.

How does Euler price assets, set interest rates, and handle liquidations?

A lending protocol lives or dies by three moving parts: how it prices assets, how it prices borrowing, and how it unwinds bad debt. Euler’s architecture put unusual emphasis on all three.

For pricing, the v1 design relied heavily on Uniswap v3 TWAP Oracle. TWAP means time-weighted average price. The reason to use a time-averaged price rather than the latest spot trade is straightforward: a spot price can be manipulated for a moment, while an average over time is harder to distort. The trade-off is equally straightforward: smoothing protects against manipulation, but it also introduces lag. In a fast market, a smoothed oracle can be slower to reflect reality.

For interest rates, Euler’s white paper describes a reactive model based on a PID controller from control theory. The intuition is simpler than the term sounds. Every pool has a utilization level; the share of supplied assets that are already borrowed. If utilization gets too high, borrowing should become more expensive to attract more supply and discourage additional borrowing. If utilization is too low, rates can fall. Instead of relying only on a static rate curve set in advance, Euler aimed to make rates adjust dynamically toward a target utilization.

For liquidations, Euler described a softer, more dynamic approach than fixed-discount liquidations. The white paper presents a mechanism closer to a Dutch auction, where the liquidation discount increases as a position becomes more underwater. The idea is to reduce the all-or-nothing race for a single fixed bonus and to let liquidators restore a position toward health rather than necessarily wiping out as much as possible at once. The intended consequence is less blunt borrower damage and less wasteful competition among liquidators, though in practice any liquidation system still depends heavily on market conditions and implementation quality.

Why do developers build on Euler, and what responsibilities does that create?

Euler is not only a destination app. It is also infrastructure. The product pages and docs emphasize that developers can create and deploy lending protocols and markets quickly, and that vaults can be connected to each other through EVC. That means Euler can sit underneath other products rather than only serving end users directly.

This matters because credit is more useful when it can be embedded. A protocol might want isolated risk vaults for a particular strategy, collateral routing between vaults, or application-specific borrowing logic. A monolithic lending market can be too rigid for that. Euler’s modularity is what makes it attractive to builders who want to define the market structure itself, not just use a predefined pool.

The trade-off is that flexibility shifts responsibility outward. The more freedom builders have to create custom vaults and connect positions, the more important it becomes for them to understand oracle assumptions, liquidation paths, collateral behavior, and the exact smart-contract semantics they inherit.

What happened in Euler’s March 2023 exploit and what does it mean for users and builders?

You cannot explain Euler honestly without mentioning the March 2023 exploit. Euler Labs’ own account says the attack stemmed from a missing health check in the [donateToReserves](https://www.euler.finance/blog/war-peace-behind-the-scenes-of-eulers-240m-exploit-recovery) code path, a function added during a patch related to an earlier issue. That missing check let an attacker move collateral into reserves, push a position into insolvency, and then profit through liquidation mechanics. Euler reports that the exploit was about $197 million, and later described a recovery process that resulted in the return of most funds.

The key lesson is not merely that Euler was exploited. Many DeFi systems have suffered exploits. The deeper lesson is that Euler’s design seeks power through composability and flexibility, and that power increases the importance of invariants. In a lending system, one invariant matters above all: actions that change collateral and debt must not allow an account to become unsafe without the protocol immediately recognizing and handling it. A single missing health check broke that invariant in an obscure path.

This does not erase Euler’s design strengths, but it should shape how users and builders think about the protocol. Permissionless or modular credit systems can unlock markets and use cases that curated systems cannot reach as quickly. They also create more surface area where subtle logic errors matter. Euler’s own materials still emphasize security, audits, and bug bounties, but the protocol’s history is a reminder that lending risk is not only market risk. It is also implementation risk.

Conclusion

Euler is best understood as a programmable credit layer rather than just another lending app. It tries to make lending markets more flexible, more modular, and easier to build on, using tools like EVK and EVC, tokenized lending and debt positions, dynamic risk controls, and composable vault design.

That makes Euler attractive to users who want more versatile DeFi credit markets and to builders who want to launch their own. But the same openness that gives Euler its edge also makes risk management central to the product. The simplest way to remember Euler is this: **it expands what a lending protocol can be, by turning credit markets into infrastructure; and by making the quality of that infrastructure matter enormously. **

How do you evaluate a DeFi lending or collateral market before using it or buying related tokens?

Evaluate a DeFi lending or collateral market by checking its oracle design, liquidation rules, asset‑tiering, and security history before trading or holding related tokens. Use this checklist to run concrete on‑chain and off‑chain checks, then fund your Cube Exchange account to execute trades or hedge exposure.

1. Open the protocol’s docs or whitepaper and note asset tiers, who can list markets, governance‑updatable parameters, and the stated liquidation model (discounts, Dutch‑auction behavior, or fixed bonuses).
2. Inspect the protocol’s price feeds on chain: find the oracle contract(s), verify whether they use TWAP windows or Chainlink feeds, and record the TWAP window length or feed aggregation method.
3. Check market liquidity for the token pair you care about on major DEX pools and CEX order books. Simulate a trade equal to your intended size to estimate slippage and whether liquidations could be executed without severe price impact.
4. Search for security evidence: audits, bug‑bounty programs, post‑mortems (exploit TX hashes), and whether fixes were merged and verified. Confirm any past exploit’s recovery status and open issues.
5. Fund your Cube Exchange account, place a limit order sized well within on‑chain depth, and use position sizing and stop orders that reflect the token’s liquidation and oracle risks.