Designing vaults for lending collateral

Yield vaults are built for depositors. Lending protocols need something different: they need to liquidate. What an ideal collateral vault looks like.

Designing vaults for lending collateral

DeFi yield vaults and lending protocols have a misalignment problem. Vaults are designed for depositors who want yield. Lending protocols that accept vault shares as collateral need something different: they need to liquidate. When a borrower goes underwater, the lending protocol must redeem vault shares and recover the underlying asset quickly enough that liquidity provider (LP) capital is protected. The speed and reliability of that redemption path determines everything downstream: the LTV ratio, the liquidation bonus, whether the vault is accepted at all. We call this the Margin Period of Risk (MPOR) - the time between detecting that a position is underwater and completing the liquidation. It is the single most important variable in assessing whether a vault is suitable as collateral.

Most yield vaults were not designed with this use case in mind. The result is a set of recurring pain points that appear in every vault risk assessment. This article describes what an ideal collateral vault would look like, starting from first principles and informed by real assessments of Morpho, Superform and Yo Protocol vaults.

The fundamental tension

Yield requires capital deployment. Capital deployment creates redemption risk. Collateral use requires deterministic redemption.

A vault earning 5% on USDC has deployed that USDC into lending markets, PT strategies, or cross-chain positions. When the lending protocol needs to liquidate, it calls redeem() and the vault has to unwind those positions fast enough that the collateral doesn't depreciate beyond the safety margin during the wait. If it can't, the lending protocol's LPs absorb the loss.

The design question is: what is the minimum viable vault complexity that delivers meaningful yield while keeping the liquidation path fast and deterministic?

Sync is ideal but the yield ceiling is low

The simplest answer is synchronous ERC-4626 redemption. redeem() either succeeds atomically in the same transaction or reverts. No queue, no fulfillment service, no claim mechanism. This is the Morpho model - the vault holds supply positions in lending markets, and withdrawal pulls from available liquidity.

With sync redemption, the MPOR is bounded by on-chain execution time (seconds) when liquidity is available, or by interest rate pressure on utilization (minutes to hours) when it's not. There is no fulfillment dependency, no circuit breaker deadlock, no bridge latency.

The tradeoff: sync only works when the vault's assets can be recalled atomically. That limits the strategy to on-chain lending (Morpho, Aave), idle holdings, and liquid AMM positions. No Pendle PTs before maturity, no cross-chain deployments, no locked staking. At current rates, the yield ceiling for a sync USDC vault is roughly 3-5% - the going rate for on-chain USDC lending.

For same-denomination collateral (USDC vault backing USDC loans), this works. The LTV adjustment for same-denomination is large enough (90%+ adjusted) that the yield-vs-LTV tradeoff is generally positive: a borrower gives up roughly 5 percentage points of borrowing capacity relative to raw USDC but earns yield on the collateral. Whether this tradeoff is net positive depends on how fully the borrower utilizes their borrowing capacity and at what cost. But for most borrowers at current rates, the vault yield exceeds the capital efficiency cost within a reasonable timeframe.

For volatile collateral (ETH, BTC), the economics are harder. A sync ETH vault earns maybe 1-2% at current rates, and the LTV penalty versus raw ETH is the same 5 points. The yield often doesn't cover the cost. If you want meaningful yield on volatile collateral, you need PT strategies, cross-chain deployments, or leveraged positions, all of which require async.

The async design space

Async redemption (ERC-7540 or custom) adds a fulfillment step between the request and the payout. The user calls requestRedeem(), the vault operator unwinds the position, and the user claims the proceeds. The time between request and claim - T_fulfillment - is the core of MPOR.

Every vault we assessed with async redemption had the same structural problem: the fulfillment step depends on something that fails during stress. Superform's circuit breaker blocks fulfillment exactly when the lending protocol needs to liquidate. YO's cross-chain rebalancing adds bridge latency at the worst possible time. The fulfillment service itself is an off-chain dependency. If it goes down, redemptions stall.

But async is not inherently broken. The problems are design choices, not architectural necessities. A well-designed async vault can keep MPOR bounded while accessing higher-yield strategies. The key is to separate what the vault invests in from what the vault redeems from.

The liquidity ladder

The core design pattern for an async collateral vault is a liquidity ladder: stratify assets by redemption speed and serve redemptions from the fastest layer down.

The idle buffer guarantees that small-to-medium liquidations complete atomically without touching any strategy position. The liquid lending layer handles larger redemptions via utilization-driven withdrawal. The lower layers provide yield uplift. They only get touched for very large redemptions (>30% of AUM) which are rare in a collateral context.

This is not a novel pattern. Superform already does something similar, maintaining 80%+ of AUM in liquid Morpho positions. The design is right. What goes wrong is what happens to the fulfillment path during stress.

Five design rules for async collateral vaults

1. Fulfillment is never blocked by the circuit breaker

This is the single highest-impact rule. A circuit breaker that pauses redemption fulfillment during stress creates a deadlock: the event that triggers the lending protocol's need to liquidate is the same event that blocks the vault's ability to fulfill the redemption.

The fix: decouple fulfillment from strategy pause. The circuit breaker should pause deposits (stop new capital entering a potentially compromised vault) and strategy execution (stop the strategy from deploying capital into new positions). But fulfillment of pending redemption requests from existing liquidity should always proceed.

For a lending protocol with realistic LTV buffers, getting 95% of value back in one hour is almost always better than getting 100% back in seven days. The price movement during a seven-day wait typically exceeds the 5% imprecision. The vault may fulfill at an imprecise share price during a circuit breaker event. But the lending protocol already applies conservative LTV buffers to absorb that imprecision. The cost of a slightly incorrect redemption price is marginal compared to the cost of being unable to liquidate at all.

2. Protection mechanisms should be user-class-aware

Not all redemption requests are equal. A circuit breaker that pauses all redemptions treats two very different situations identically.

A retail depositor choosing to exit during a share price anomaly is making a voluntary decision that the circuit breaker rightly second-guesses. They might be locking in a loss at a manipulated or incorrect price. The protection is valuable because it prevents a bad voluntary choice.

A lending protocol redeeming vault shares during a liquidation is a different situation entirely. The borrower who deposited those shares as collateral occupies a double role: they are a depositor in the vault and a borrower in the lending protocol. When the borrower defaults, the depositor role vanishes. The lending protocol now holds vault shares it needs to convert to cash to protect its LPs. The circuit breaker is protecting a "depositor" who is no longer making voluntary decisions about their position. They are in default. The shares are being seized, not withdrawn.

The cost of not redeeming (bad debt to the lending protocol's LPs, potentially the full position) almost always exceeds the cost of redeeming at a slightly imprecise price. The lending protocol already applies LTV buffers sized to absorb exactly this imprecision.

The design should not be a blanket priority lane that skips all protections. It should be a circuit breaker that applies different rules based on the context of the redemption:

  • Deposits: paused for everyone during an anomaly. No new capital into a potentially compromised vault.
  • Voluntary redemptions: paused. Protect depositors from panic-selling at an incorrect price.
  • Liquidation redemptions: proceed. The original depositor is in default. The lending protocol accepts pricing imprecision within its buffer, and the cost of blocked liquidation exceeds the cost of imprecise redemption.

This is not a privilege, it is a recognition that the circuit breaker's purpose (protecting depositors from bad voluntary exits) does not apply when the exit is forced by a default. Applying it to a liquidation protects nobody. The defaulting borrower has already lost their position, and the circuit breaker just converts a recoverable situation into bad debt for the lending protocol's LPs.

The whitelist itself must be tightly controlled. A compromised whitelisted address could drain vault liquidity during an exploit by bypassing the circuit breaker. This reinforces that user-class-aware protection is a design-time decision, built into the vault from day one with appropriate access controls.

3. Auto-fulfill with a contract-enforced SLA

Instead of best-effort fulfillment, the contract should enforce a maximum fulfillment time. If a request is not fulfilled within N hours, the contract auto-fulfills from whatever liquidity is available. Even if that means accepting slippage on strategy unwind. The vault absorbs the cost rather than letting the request hang indefinitely.

This converts T_fulfillment from "operationally unbounded" (depends on when the operator acts) to "architecturally bounded" (the contract enforces a hard deadline). The lending protocol can underwrite a bounded MPOR without relying on operational assumptions about operator availability.

4. Cross-chain positions only in the lower layers

Cross-chain deployments (via bridges like Across, LayerZero, etc.) add bridge latency, bridge failure risk, and cross-chain oracle staleness to the redemption path. These are acceptable for yield but unacceptable in the critical path for liquidation.

The design rule: the idle buffer and liquid lending layer (layers 1-2, 70-80% of AUM) must be same-chain. Cross-chain positions live in layers 3-4 only. Most redemptions never touch the bridge.

5. Liquid layer floor enforced on-chain

The 80%+ liquid allocation should be an on-chain invariant, not a soft target. If strategy rebalancing would push the liquid layer below the floor, the transaction reverts. This gives the lending protocol an architectural guarantee that the redemption path has liquidity, not just an operational promise.

Ring-fencing: the allocation control model

A collateral vault's risk profile is only as good as its risk boundary. The lending protocol underwrites a specific set of risks when it accepts vault shares. If the vault's capital can flow to positions the curator didn't choose - via public allocators, permissionless rebalancers, or broad operator permissions - the underwriting is meaningless.

The Resolv exploit (March 2026) demonstrated this concretely. An attacker minted 80M unbacked USR stablecoins, crashing the price to near zero. Morpho's public allocator - a permissionless function that anyone can call to reallocate vault liquidity between markets - was used to redirect vault liquidity toward markets backed by USR collateral during the depeg. Vaults that appeared to have no Resolv exposure were exposed via the reachable market set. The curated allocation was a normal-conditions description, not a risk boundary.

The right allocation model for a collateral vault: curator-controlled whitelist with timelocked additions. The curator can reallocate between whitelisted destinations instantly (operational flexibility), but adding a new destination requires a timelock (the lending protocol has time to assess the new exposure). No permissionless reallocation mechanism, no public allocator, no arbitrary-call operator.

The share price question

The vault's share price (totalAssets / totalSupply) determines the collateral value. Three approaches exist:

Real-time computation (Morpho): totalAssets() iterates supply positions and computes value including accrued interest. No staleness, no oracle dependency. Gas-intensive but trustworthy.

Validator-signed share price (Superform): off-chain validators compute the price and sign it. Updated hourly with deviation bounds. Faster to read, but introduces validator trust and staleness window.

Discrete updates (YO V1): an updater pushes the price once per day. Cheap but creates a 24-hour staleness window during which the collateral value may be incorrect.

For collateral use, real-time is ideal. The lending protocol reads the truth and applies its own skepticism - rate-limiting upward movements (prevents borrow-more attacks against inflated prices) while allowing rapid downward recognition (detects genuine losses quickly). The vault reports what is; the lending protocol decides what to do about it.

If real-time is too expensive (gas cost for iterating many positions), the next-best is validator-signed with tight deviation bounds and short update intervals. Discrete daily updates are unacceptable for collateral - 24 hours of staleness in either direction creates material mispricing risk.

What this vault looks like

Putting it together:

A vault optimised for lending collateral is a sync ERC-4626 vault allocating to on-chain lending markets with a 5-10% idle buffer, real-time share price, curator-controlled whitelist with no permissionless reallocation, and no circuit breaker on redemptions. It yields 3-5% on stablecoins and is worth the complexity for same-denomination collateral where the LTV adjustment makes the yield-vs-capital-efficiency tradeoff positive.

If you need higher yield (volatile assets, or yield above 5% on stablecoins), the vault moves to async with a liquidity ladder: the idle buffer plus liquid lending layer (70-80% of AUM) stays same-chain and instantly redeemable, while the remaining 20-30% accesses higher-yield strategies. The critical design rules are: fulfillment never blocked by circuit breaker, user-class-aware circuit breaker that allows liquidation redemptions, contract-enforced fulfillment SLA, cross-chain only in the lower layers, and on-chain liquid layer floor. This achieves a bounded MPOR measured in hours rather than days.

Rethinking the liquidation path itself

The above sections describe what can be built today with current vault primitives. What follows is more speculative. Paths that could reduce or eliminate the MPOR problem at the protocol layer rather than the vault layer. These require new primitives that don't exist yet, but they suggest a direction worth exploring.

Everything above assumes the liquidation path runs through vault redemption: seize shares, redeem for the underlying asset, repay the loan. All of the MPOR complexity (utilization delays, circuit breaker deadlocks, fulfillment queues) lives in that redemption step. But what if the liquidation path didn't require redemption at all?

Two alternative paths are worth exploring.

In-kind share transfer. The liquidator seizes the vault shares (an ERC-20 token) and the lending protocol marks the debt as repaid at the current share price. Nobody redeems anything during the liquidation. The shares just change hands. MPOR drops to detection time only - seconds. The liquidator holds the shares and redeems at their leisure, with no time pressure.

This works because vault shares are standard ERC-20 tokens. Transferring them requires no vault interaction, no fulfillment service, no bridge, no circuit breaker check. It works when the vault is paused. It works when utilization is 100%. It works when the bridge is down. The entire async/sync distinction becomes irrelevant for the liquidation itself. It only matters when the liquidator eventually chooses to redeem.

The cost is that the liquidation bonus must compensate the liquidator for taking on redemption risk. For high-quality vaults where redemption works 99% of the time, this premium might be small (1-2% above the base bonus). For riskier vaults, it could be significant. But the lending protocol's LPs are no longer exposed to redemption delay. That risk is transferred to the liquidator via the bonus.

In-kind collateral delivery. More speculative, but potentially more powerful. Instead of the vault returning its loan asset (USDC) - which requires borrowers to have repaid - the vault returns whatever it can deliver fastest. For a Morpho USDC vault during high utilization, the USDC has been lent out to borrowers. But the collateral those borrowers posted (ETH, cbBTC) is sitting in the market contract, available.

A function like redeemInKind(shares) that returns whichever asset the vault can deliver immediately would invert the utilization problem. High utilization means no USDC available but collateral assets are abundant. The lending protocol (or liquidator) receives ETH instead of USDC and can sell it on a DEX. The swap slippage for liquid assets during normal conditions is likely small relative to a multi-hour redemption delay. But the actual cost under stress would need to be measured, not assumed.

This is the most speculative path in this article. The collateral sitting in a Morpho market is the borrower's asset, held by the market contract. The vault's position is a supply-side claim on the lending pool, not a direct claim on borrower collateral. Implementing redeemInKind() would require a new primitive at the lending market layer (Morpho Blue, Aave), not just at the vault layer. It is a fundamental change to how lending markets account for supply positions.

These paths can be composed into a liquidation priority ladder:

Path 1 is the current model. Path 2 requires vault-level support that doesn't exist today. Path 3 is always available because it's just a token transfer.

If this ladder is implemented, the lending protocol's direct MPOR exposure drops dramatically because path 3 always works mechanically (it's just a token transfer). But MPOR does not disappear from the system - it transfers to the liquidator, who now holds shares they may not be able to redeem immediately. The liquidation bonus is the price of that transfer. The risk model shifts from pricing redemption delay (how fast can we get USDC back?) to pricing valuation uncertainty (how confident are we in the share price at seizure?) and exit risk transfer (how much bonus does the liquidator need to accept vault shares instead of cash?). That is a fundamentally different risk model, and potentially a simpler one for the lending protocol. Though it requires a liquid and willing liquidator market.

These paths are speculative and don't match any current vault design. But they suggest that the MPOR problem might be solvable at the liquidation layer rather than the vault layer and that the sync/async distinction may matter less than we think if the lending protocol is willing to accept non-standard assets during liquidation.

The gap in existing vaults

No vault we assessed fully meets this specification. The closest is Morpho's MetaMorpho, sync, real-time pricing, immutable, no pause on redemptions. But it lacks a priority redemption path, the public allocator breaks ring-fencing, and there is no idle buffer guarantee. Superform has the right liquidity ladder structure but the wrong circuit breaker design (blocks fulfillment during pause). YO sits on the opposite end of the spectrum, cross-chain meta-vault with daily updates and broad operator permissions.

The gap is not surprising. These vaults were designed for depositors, not for lending protocols. The collateral use case is a different customer with different requirements. Bridging that gap requires either:

  • vault builders adding collateral-specific features (priority redemption, deposit-only circuit breakers, on-chain liquidity floors) to new deployments, or
  • lending protocols building a wrapper layer that provides the guarantees they need on top of existing vaults.

Neither path is free. But the alternative - accepting existing vaults as collateral and hoping the risk framework catches the gaps - produces the assessments we've seen: conservative LTV assignments (55-65% instead of 75-90%), failed onboarding reviews on rebalancing controls, and outright rejection of every async vault with a circuit breaker that blocks liquidation. A better design at the vault level solves the problem at the source.


Stay updated on all things Sprinter, and onchain credit, by following us on X, joining our Telegram, and reading more on our blog.