Fluid: one liquidity layer, a thousand markets on top

Lending design has been moving one way for three years: break the pool apart. Morpho Blue made every market its own island. Silo gave each asset pair its own silo. Euler let anyone assemble a vault. Isolation contains risk, and the cost is that liquidity gets chopped into a hundred pieces that cannot help each other.

Fluid went the other way. Every borrow vault, every earn token and the protocol's own DEX draw from one shared Liquidity Layer, with a single rate curve per token for the entire protocol. About $812M of net TVL and $756M borrowed against it sit on that layer today across Ethereum, Arbitrum, Base, Polygon, Plasma and BNB — and the same design lets a vault's collateral earn yield instead of sitting dead.

That single structural choice changes the data model, the permission model and the integration surface. Here is what it actually looks like from the inside.

One balance sheet, not fifty

In Aave you supply into a reserve and borrow from the same reserve. In Morpho Blue you supply into a market — USDC-against-wstETH is a different pool of USDC than USDC-against-WBTC, and neither can lend the other a dollar. Fluid has a third arrangement: the Liquidity Layer holds one balance per token for the whole protocol, and everything else is a permissioned front-end onto it.

If you have read Aave's V4 papers this will look familiar: the Liquidity Layer is a hub, and vaults and fTokens are spokes. Aave is building toward that architecture. Fluid has been running it in production for two years, with the DEX bolted on as another spoke.

The practical consequence is that a new vault does not need bootstrapped liquidity. List an ETH/USDC vault and it borrows against the protocol's entire USDC balance from block one — the same USDC that backs fUSDC depositors and every other vault. Depth is shared; only risk is isolated.

The number that trips integrations up

Every variable-rate lender prices its loans off one number: utilization, the share of deposited money that is currently lent out. When little is borrowed, capital sits idle and the loan is cheap. As the pool empties, the rate climbs steeply — that is how the protocol attracts fresh deposits and discourages further borrowing, and how it makes sure lenders can still get their money out.

Everywhere else, that number belongs to the market: take what the market has lent out, divide by what it holds. Ask a Fluid vault the same question and the answer is meaningless, because its deposits and its debts are different tokens — it holds wstETH and owes USDC. Dividing one by the other compares apples to dollars, and doing it literally is how an early pass at this integration came to report a utilization of 121,140%.

The architecture answers the question by itself. One token has one pool and one rate curve, so utilization belongs to the token at the layer and never to a vault above it. Every wstETH/USDC borrower, every USDC/WBTC borrower and every fUSDC depositor sees the same USDC utilization, because they are all drawing on the same USDC.

Two smaller consequences follow from the same picture. A vault can carry a multiplier on the rate its own users see — a lever the protocol uses to steer demand toward or away from a market — so two vaults on the same token may quote different rates while sharing one curve and one pool. And "available liquidity" is not the cash left in a pool: the layer hands each market an allowance to withdraw and to borrow that refills over time, which caps how fast shared liquidity can drain. A market can hold plenty of deposits and still decline a large exit right now.

Curation: closer to Aave than to Morpho

Morpho Blue's defining property is that market creation is permissionless: anyone can deploy a market with any oracle and any LTV, and curation is pushed up to the vault layer, where a MetaMorpho allocator decides which markets deserve deposits. Silo is similar in spirit — pairs are cheap to create and the risk decision is per silo.

Fluid does not work that way. Vaults are listed by the protocol, with the LTV, liquidation threshold, penalty and oracle set as part of that listing. There is no permissionless market factory to index, no long tail of empty markets with hostile oracles, and no curator layer to model — every fUSDC depositor is exposed to the same book because there is only one book.

The shape of a market is also fixed and narrow. A Fluid vault has exactly one collateral asset and exactly one debt asset. There is no basket, no e-mode, no per-position mode selection: each vault ships a single LTV tier, where collateralFactor is the LTV you may open at and liquidationThreshold is where liquidators may act. Liquidation carries a penalty in basis points and a close factor of 1 — an unhealthy position can be repaid in full in one go, rather than the half-close-then-repeat dance most Aave forks require.

For an aggregator, that combination is unusually pleasant. Morpho needs pagination and a curation model, Euler needs a governance graph. Fluid's entire protocol comes back in two calls — VaultResolver.getVaultsEntireData() and LiquidityResolver.getAllOverallTokensData() — against resolver contracts deployed at the same address on every chain.

Collateral that earns

Post collateral to Morpho Blue and it earns nothing. That is deliberate: idle collateral cannot be lent, so it cannot be part of a bad-debt cascade. It is also the single biggest hidden cost of borrowing there, and it is invisible in every headline APR comparison.

On Fluid, vault collateral goes into the Liquidity Layer like everything else, which means it is lent out and it accrues the layer's supply rate for that token. A wstETH/USDC borrower earns wstETH's supply yield on the collateral leg while paying USDC's borrow rate on the debt leg — on top of wstETH's own staking yield. The net cost of the loan is the difference, and on stable-versus-stable vaults that difference can be a fraction of the quoted borrow APR.

Which is why the two legs belong on screen separately — supplyRateVault (layer yield plus the vault's magnifier and any rewards) for the collateral, borrowRateVault for the debt. Comparing Fluid's borrow rate against Morpho's borrow rate without netting the collateral leg systematically overstates what Fluid costs.

Earn is an fToken, and every holder gets the same rate

The supply side is not a vault in the MetaMorpho sense. fTokens — fUSDC, fETH, and friends — are plain ERC-4626 wrappers that deposit straight into the Liquidity Layer. There is no allocator, no withdraw queue to reorder, no performance fee, no timelock on reallocation, because there is nothing to allocate: one token, one pool, one rate.

That makes the earn side trivially comparable — two people holding fUSDC earn identically, always — and it removes the question every Morpho or Euler vault has to answer: which markets is my money actually in? On Fluid the answer is "all of them, in proportion to what has been borrowed".

It also forces a rethink of what exposure means. Everywhere else, exposure is an allocation list: this vault put 40% into market X. Fluid makes no allocation, so the breakdown has to be built from the other direction — take every borrow vault whose debt asset is the fToken's underlying, and report each as a slice of that token's borrows, weighted by USD. An fUSDC holder then sees what their USDC is actually financing (ETH-collateralized loans, wstETH loans, cbBTC loans) even though the protocol never chose where to send it.

Positions are NFTs

A Fluid borrow position is an ERC-721 token minted by the vault factory — the same factory address on every chain, 0x324c…Bf2d, thanks to deterministic deployment. Your position is not a balance keyed to your address. It is a token you hold.

That is genuinely useful. One address can run many independent positions in the same vault, each with its own collateral, debt and health factor, so a hedged position and a leveraged one never share a liquidation. The natural way to model it is as a sub-account per NFT — the same shape a Liquity trove or an Init Capital position takes — with health computed per NFT rather than per user.

It also means ownership is the authorization model. Fluid has no credit delegation, no operator mapping, no permit for acting on someone's behalf — modifying a position requires holding its NFT. What makes that workable is that ownership is itself a token, and a token can change hands inside a transaction. ERC-721 supplies the delegation the lending protocol left out, in two forms:

• The user pushes it. safeTransferFrom carries an arbitrary payload alongside the transfer, so the user hands the position over with the intended operations attached. The receiving contract's onERC721Received hook runs them while it owns the position and then transfers it back — all one transaction, and the user never stops being the beneficiary.
• The contract pulls it. With a standard approve (one position) or setApprovalForAll (all of them), a router can take the NFT when it needs to, edit the position and send it back in the same call. That is the familiar grant-once pattern after all, provided by the token standard rather than by the lender.

Custody, however brief, is real control, so the receiving side has to be strict about who may hand it a position. The push route needs two gates: the transfer must come from the Fluid vault factory, and the transfer's initiator must be the owner — otherwise anyone holding a blanket approval could push someone else's NFT in with a payload of their own choosing. The NFT should also be returned unconditionally at the end of the call, checked rather than assumed, so a payload that forgets to send it back cannot strand the position.

Opening a new position has the mirror-image problem — the NFT does not exist yet, so it cannot be pre-approved or predicted. Passing nftId = 0 mints one, and the id that operate returns can be read inside the same transaction and the fresh NFT swept to the user. No address prediction, no front-run window, and deposit-plus-borrow-plus-delivery collapses into one transaction that previously took two.

The DEX underneath

Fluid also runs its own DEX on the same liquidity, and it is not a side project: roughly $96M traded in the last 24 hours and $2.4B over the last 30 days. Fluid is one of the larger DEXs on Ethereum by volume, and it happens to be the same contract system as the lending protocol.

The interesting part is where the two meet. Fluid vaults can take a DEX LP position as collateral, as debt, or both — "smart collateral" and "smart debt" — which produces four vault shapes, identified by the scaled constant IFluidVault.TYPE() returns:

A T2 position earns lending yield and swap fees on its collateral. A T3 position's debt shrinks or grows with the pool's composition. These are real products with real TVL, and they are also where a uniform lending data model stops fitting: the "asset" on a smart side is a pool, not a token, so LTV, oracle price and health need a pool-aware treatment rather than a token-aware one.

What 1delta supports

For non-DEX (T1) vaults, everything: supply, withdraw, borrow, repay, the one-shot deposit-and-borrow and withdraw-and-repay flows, leveraged loops, and cross-lender migration in both directions — Fluid can be the source of a migrate (via NFT custody) or the target (into an existing position, or as a fresh open that mints the NFT straight to the user).

A few Fluid-specific things fall out of the design:

• One operation instead of four. Because operate is dual-axis, there are no separate deposit/borrow/repay/withdraw primitives to encode. Collateral and debt are signed amounts in a single call: positive deposits or borrows, negative withdraws or repays, and type(int256).min means all of it, resolved on-chain against the live debt so a full close cannot leave a wei of dust behind.
• Native ETH is native. Fluid vaults hold real ETH rather than WETH, using the 0xEee… sentinel on-chain. We never let that sentinel cross the calldata boundary — the zero address is the canonical native form in every 1delta payload, and the Fluid legs translate. The flip side: Fluid has no gateway that wraps or unwraps for you, so a request that asks a native-ETH vault to accept WETH is rejected rather than silently rerouted.
• The native-debt migrate exception. Most lenders cannot receive a migrated position whose debt is the native asset, because on-behalf borrowing is delegated and native debt cannot be delegated. Fluid borrows through its own operate under NFT custody, not through a delegation — so a migration into a Fluid native-ETH debt vault works, and Aave WETH → Fluid ETH is a supported move.

Smart vaults are further along in the contracts than in the data layer. The composer ships fork-tested operations for T2, T3 and T4 including the share-precise operatePerfect form — and one lesson from those tests worth recording: closing a T4 position in a single call, burning all collateral shares and all debt shares at once, trips an invariant inside the Fluid DEX. It has to be two calls, repay-all first, then burn the collateral side. Our public data currently emits T1 vaults only; extending the market model to pool-backed sides is the next piece.

Everything above is reachable through the 1delta API in the same shape as Aave, Morpho, CDPs and order books — one market schema, one health factor, one call to open a position. The NFT custody, the sentinels, the layer-level utilization and the ETH-versus-WETH translation stay on our side of the line.