Curve LlamaLend: the market with no liquidation price

Every lending integration you have ever written contains the same two assumptions, buried so deep they never get written down: that a market has one LTV, and that a position has one price at which it dies. Aave has them. Compound has them. Morpho Blue has them. The order book we wrote about moved where the rate comes from but kept both. Even CDPs, which threw out depositors and utilization entirely, kept both.

Curve's LlamaLend breaks both, and it does so on purpose. There is no liquidation price - the protocol will not tell you one, because none exists. And the collateral factor is not a market parameter at all: it is a number the borrower picks when opening, anywhere from 0.90 to 0.98 on the same market, fixed for the life of the loan.

This is the most mechanically unusual lender in our index, and the one whose data model breaks the most consumer code. Here is how it actually works, what it changes, and how the 1delta API flattens it into the same shape as everything else.

Liquidation, but continuous

Start with what normal liquidation is: a step function. Your health factor crosses 1, a bot repays part of your debt, seizes collateral plus a penalty, and you are worse off by that penalty in a single block. It is discrete, adversarial, irreversible, and it is why "liquidation price" is a number every lending UI shows.

LlamaLend replaces the step with a ramp. Each market owns an AMM - Curve calls it a LLAMMA - and your collateral does not sit in a vault, it sits inside that AMM, spread evenly across a contiguous range of price bands that you choose at open.

As the oracle price falls into your range, the AMM does what an AMM does: it sells your collateral for the borrowed token, band by band, at market. Nobody liquidates you. No penalty is charged. And if the price recovers back up through the range, the AMM buys your collateral back. The process is gradual, market-driven and reversible.

Three consequences follow immediately, and each one breaks something a normal integration assumes:

• There is no liquidation price to display. The protocol's own user_prices returns a range, not a number. Any UI with a "Liquidation at $X" field has to answer a question the protocol refuses to answer.
• A position holds two assets at once. Mid-conversion, your collateral is partly the original token and partly the borrowed one. user_state returns both legs. Code that models a position as one collateral balance plus one debt balance is structurally wrong here.
• Health factor stops meaning "distance to liquidation". Soft liquidation begins while the position is perfectly healthy. Crossing into your band range is a normal operating state, not a failure.

Hard liquidation still exists as a backstop - if the price falls below your entire range and the loan is underwater, a liquidator can close it with a discount. But that is the tail, not the mechanism.

The honest caveat: soft liquidation is not free

"No penalty" is true and it is not the same as "no cost". Every conversion happens at market inside the AMM, so a price that oscillates in and out of your range sells low and buys back high, repeatedly. That bleed is real, it has a name in Curve's own docs - soft-liquidation loss - and a choppy market extracts more of it than a single clean move down would. What you are buying is not immunity; it is the replacement of one violent, penalised event with a continuous, market-priced one you can reverse.

The LTV is a number you choose

Here is the part that surprises people who have integrated twenty lenders: ask LlamaLend for a market's collateral factor and there is no such field.

Your borrowing power is a function of N, the number of bands your collateral is spread over. You pick it at open, anywhere in [4, 50]. Fewer bands concentrate your collateral into a narrow price window - higher LTV, but the soft-liquidation range is tight and you convert fast once you enter it. More bands spread the conversion over a wider, gentler range and cost you borrowing power.

On a live market (sfrxUSD/crvUSD, with the market's own geometry) the curve looks like this:

That is an eight-point LTV spread on one market, at one moment, chosen entirely by the borrower. And note the marketing trap: Curve's own front-end advertises the N = 4 figure (around 50x max leverage) while defaulting users to N = 10 (around 33x). Both numbers are true about different loans.

N is immutable once the loan opens. Adding collateral or borrowing more reuses the existing band width, so there is no path to change it - only closing and reopening. It is the rare DeFi parameter that is a genuine, irreversible decision at open, which is exactly why it deserves to be a visible choice rather than a silent default.

How it differs from everything else

A word on crvUSD, since it is the borrowed asset in most of these markets. It is Curve's own stablecoin, and it is CDP-minted — but by a separate product: nine "mint markets" on Ethereum where you lock blue-chip collateral (ETH and BTC LSTs) and mint crvUSD into existence, ~$38M of debt today. Those mint markets run the same LLAMMA soft-liquidation engine described above, so Curve operates both halves of this article on one piece of machinery: a CDP where crvUSD is minted, and LlamaLend where the same crvUSD is lent by depositors. In a LlamaLend market nothing is minted — the crvUSD you borrow was supplied by someone else.

The rate row matters for anyone reading the table too fast: unlike a CDP, LlamaLend does have real depositors and a real utilization curve. Its supply side is an ordinary ERC-4626 vault per market, and the borrow rate comes from a policy contract, not from the borrower. Two families of rate model are in use across the book, and both expose a pure future_rate function - so we can quote the exact rate a given borrow size would produce, with no modelling and no approximation.

What LlamaLend genuinely shares with the CDP family is position identity: loans are address-keyed, one per address per market. There is no sub-account concept, no NFT to discover, and one wallet cannot hold two loans on the same market at once.

Who is allowed to create a market

The listing row deserves unpacking, because LlamaLend sits at an end of this axis that is easy to miss.

Aave and Compound list assets by governance vote: a proposal sets the collateral factor, the caps and the oracle, and nothing exists until it passes.

Morpho Blue made market creation permissionless, and that is rightly the headline - anyone can deploy a (loan, collateral, oracle, IRM, LLTV) market without asking. But the freedom is bounded on the two parameters that decide risk: the LLTV and the IRM must both be enabled by governance first. Simulated against mainnet Blue right now, a random address creating a market at the enabled 86% LLTV succeeds; the same address asking for 77.7% reverts with LLTV not enabled. Permissionless creation, curated risk.

LlamaLend removes the second half too. Its factory's create takes the band-geometry parameter A, the loan_discount, the liquidation_discount, the fee, the price oracle and the rate bounds - all chosen by the caller, none drawn from an allowlist. A random address simulating that call today succeeds exactly as the factory admin does. There is no governance-enabled set to pick from, because there is no set.

That is the deeper version of this article's thesis. On Aave the LTV is chosen by governance; on Morpho Blue it is chosen by the market creator from a governance-approved menu; on LlamaLend nobody chooses it once. The creator picks the geometry, and then every borrower picks their own point on the curve it produces. It is why "what is this market's LTV" has no answer here, and it is also why curation matters more: a permissionless market with a hand-rolled oracle and a 50% loan_discount is a market someone can deploy this afternoon.

Which is exactly what the book shows. Four Ethereum markets carry a 50% loan_discount and therefore an LTV near 0.49 - not a data bug, but Curve soft-deprecating older markets while a newer one runs the same pair at 1.3%. Indexing this protocol means reading each market's own geometry rather than trusting the brand.

Two generations wearing one brand

LlamaLend ships in two live generations that share a name, an API and a front-end: oneway (v1) and oneway-v2. They are not variants. They share nothing but the concept - even create_loan has a different function selector on each.

Worse, they are mixed together on the same chains, so "which chain am I on" tells you nothing about which contract you are talking to. And because the contracts are written in Vyper, which compiles every default-argument arity to its own selector, even within v1 the available function signatures differ between older and newer markets. Assuming one ABI across the book is the single most reliable way to write LlamaLend code that reverts on half of it.

That is invisible in our data. Every market carries its generation, and every encoder branches on it.

How we integrate it

The protocol runs 99 markets across five chains, with roughly $68M supplied and $52M borrowed. We index 42 of them - 27 on Ethereum, 10 on Arbitrum, 5 on Optimism - which is where essentially all of that liquidity sits.

Making it comparable to the rest of the unified surface came down to four decisions:

• One market per controller, both generations in one key space. To a user they are one protocol and Curve returns them in one list, so they share a key. The generation rides along as a field the encoders branch on, never something a consumer has to know.
• The band count is modelled as an open parameter, not an e-mode. The market publishes the domain (4–50, the default, and the fact that it is immutable after open); each position carries the value it actually chose. This distinction is load-bearing: roughly one loan in five sits at a non-default N, so treating the market's headline collateral factor as the position's LTV is simply wrong for those loans. We also publish the whole LTV curve - every value from 4 to 50, derived analytically from the market's geometry - so a UI can show what a choice costs before it is made.
• We never invent a liquidation price. The market is tagged as gradual, reversible, penalty-free conversion, and the term sheet says so in words. A consumer that renders a single threshold is rendering the wrong event, so we do not hand them one to render.
• The oracle is read the protocol's own way. LlamaLend's price feed lives on the market's AMM and is denominated in the borrowed token, not USD. Eight markets borrow something other than crvUSD, so that distinction is not academic - we normalize through the borrowed token's own price rather than treating the ratio as dollars.

What the API supports

Everything below is live through the 1delta API, and none of it requires the caller to know a single thing above.

• Market and position data - rates, liquidity, debt, the full band-LTV curve, and per-position state including both collateral legs during soft liquidation.
• All four direct actions - deposit, withdraw, borrow, repay. Supplying the borrowed asset routes to the ERC-4626 vault; supplying collateral routes to the controller. The API picks the right target and the right approval.
• Both one-shots, natively - deposit-and-borrow (which is how a loan is opened, since collateral and N must arrive in the same transaction) and withdraw-and-repay, each a single transaction rather than a sequence.
• Leverage and deleverage, with no contracts of ours in the path. Curve deploys its own leverage zaps, and we route through them. 28 of the 42 markets support it. You get a levered open or a full unwind as one EOA transaction.
• Exact rate-at-depth. Because both rate policies expose a pure projection function, we quote what the rate will be after a borrow of a given size - not what it is now.
• Term sheets that state the mechanics in words: gradual conversion, no penalty, no single liquidation price, N fixed at open.

Two honest limits. Collateral swap and debt swap are not available - a LlamaLend market is one collateral against one borrowed asset, and its own tooling implements only open and close; changing either side means closing and reopening. And the band count of an existing loan cannot be changed through the API today, because the protocol offers no such operation.

Why this matters for builders

LlamaLend is the clearest case in our index of a protocol whose risk product is genuinely different rather than differently parameterised. A borrower gets a position that degrades gracefully instead of dying at a threshold, that can recover on its own when the market does, and whose aggressiveness they set themselves at open - up to 98% LTV if they accept a narrow conversion window. That is a real alternative to offer next to a pooled market, not a reskin of one.

It is also the clearest case of a protocol that punishes assumptions. One LTV per market, one liquidation price per position, one ABI per protocol, one collateral balance per loan - all four are false here, and all four fail quietly rather than loudly. Getting them right once, behind a stable response shape, is the entire point of integrating through an aggregator instead of against the contracts.

One-sentence takeaway

LlamaLend deletes the liquidation event - collateral converts gradually and reversibly through the market's own AMM across a band range the borrower chooses - so it has no liquidation price and no single LTV, and the 1delta API surfaces all 42 markets, both generations, and native leverage through the same shape as every other lender.

Where to go next

• API reference - endpoints, response shapes, and x-api-key setup.
• Docs site - supported protocols and network coverage.
• Cross-protocol lending aggregation - the general model this plugs into.
• CDP lending - the other family that abandoned pooled assumptions, for different reasons.
• When lending leaves the pool - Morpho Midnight's order book.
• How we unify fixed-term lending - the same unification story for fixed-rate markets.