Morpho
Morpho vaults: Deposit allocation and withdrawal liquidity
Morpho vaults pool a deposit asset and allocate capital to lending positions within curator-defined caps. Depositors hold shares in the combined portfolio. Vault V1 uses ordered market queues, while Vault V2 uses adapters and shared risk caps. Actual allocations, configured fees, and accessible liquidity shape the exposure behind those shares.
The asset behind each allocation
Each vault accepts a specified ERC-20 asset, which denominates deposits, accounting, and ordinary withdrawals. In a Morpho Blue allocation, borrowers receive that loan asset and post the market's specified collateral. The vault's asset determines what depositors supply; the underlying collateral affects the borrowing risk behind its yield. An adapter connects a Vault V2 to an enabled lending destination and holds positions for the vault. Several markets can share collateral or oracle dependencies, leaving concentration despite a spread of allocations. An oracle supplies collateral prices for loan health checks.
If liquidation fails to cover a borrower's debt, the lending position can incur bad debt. Losses can reach the vault through that exposure, while adapter bugs and underlying contract failures add risks along the same allocation chain.
Shares and the value behind them
Vault shares represent a proportional claim on pooled assets. Both versions use ERC-4626, the tokenized vault standard, to distinguish underlying assets from receipt shares. Deposits mint shares, and ordinary withdrawals burn them. Borrower interest can increase the asset value represented by each share. Conversion and preview functions calculate the asset-share relationship without reserving liquidity for a later exit. Loss accounting differs by implementation: Vault V1.0 reflects realized market bad debt in its share value. Vault V1.1 tracks the shortfall without that immediate decrease, leaving later withdrawers exposed unless someone covers it.
Vault V2 adjusts its accounting downward when idle assets plus adapter-reported values fall below its recorded total. Adapters supply those values through
realAssets(). Its allocator-set
maxRate
also limits recognized asset growth, without imposing a floor on returns. Vault V2 supports a performance fee on distributed interest and an annualized management fee on total assets. Collection mints shares to configured fee recipients, diluting existing holders. Management fees can reduce share value during loss periods. Vault V1 has a vault-level performance fee without this management-fee mechanism.
Who controls where vault deposits are allocated?
The curator sets permitted allocations and risk limits, while allocators move capital within those limits and manage the vault's deposit and withdrawal routing. In Vault V2, the owner appoints the curator and sentinels. Sentinels can revoke pending changes, lower caps, and deallocate assets. An optional adapter registry can restrict which adapters the vault may add. One party can hold multiple roles, so the actual role assignments determine who controls each permission.
Risk identifiers and caps
A Vault V2 adapter can attach several risk identifiers to one allocation. Shared collateral identifiers can aggregate exposure across markets. The identifiers that the adapter returns determine which caps apply.
Absolute caps
An absolute cap limits the total recorded asset allocation for a risk identifier after an allocation operation. Lowering a Vault V2 allocation cap does not withdraw existing assets. Reducing the held position requires deallocation, with liquidity available in its underlying destination.
Relative caps
A relative cap constrains new allocations as a proportion of vault assets; withdrawals from elsewhere can subsequently increase that position's portfolio weight. Interest or donations can also push exposure above configured limits. Caps therefore need to be read alongside the positions actually held; they are not continuously enforced portfolio ceilings.
Queue routing and the liquidity adapter
Vault V1 directs deposits through its supply queue in order, filling markets up to available cap headroom. Its withdraw queue determines the order for sourcing exit liquidity. Allocators can change these queues and rebalance positions. A configured idle market holds loan assets that cannot be borrowed, providing liquidity without lending interest on that portion.
Vault V2 pairs a liquidity adapter with protocol-specific data identifying the normal allocation destination. When configured, this pair can select one position inside an adapter, which receives the entire deposit. If an applicable cap rejects that allocation, the deposit reverts; the excess does not automatically fall back to idle.
Without a liquidity adapter, Vault V2 deposits remain idle in the vault contract. Those assets earn no underlying lending interest.
Timelocks and access permissions
Vault V2 supports a separate timelock for each protected configuration function. The applicable delay determines when a submitted change becomes executable, with a zero delay providing no advance notice period. An executable proposal takes effect only when its execution call succeeds. Routine allocator reallocations do not require this waiting period, so pending configuration changes do not describe every portfolio movement.
Optional Vault V2 gates can restrict deposit senders, share recipients, share transfers, and withdrawal recipients. An unset gate imposes no restriction of its own. Permanently disabling changes to a gate's address leaves any administration inside that external gate untouched. Its own administrator may retain control over access rules. A frozen address therefore requires a separate assessment of the gate's behavior.
Why can a withdrawal fail while a vault still holds assets?
A withdrawal can fail because assets are borrowed or held in positions outside the vault's ordinary exit route. Vault V2 pays from idle assets first, then retrieves the shortfall through its liquidity adapter. Liquid assets elsewhere in the portfolio are not automatically part of that route.
Permissionless
forceDeallocate
can move available assets from positions in any enabled adapter into the idle balance, subject to its configured penalty. A nonzero penalty burns shares from the designated account, with share allowance required when another account acts on its behalf. The corresponding assets remain in the vault for remaining holders. Deallocation itself does not pay the requested exit amount to the depositor;
withdraw
or
redeem
performs that transfer. Compatible tooling can combine these operations within one transaction.
In-kind redemption can exchange vault exposure for an underlying lending position when borrowed liquidity prevents an asset withdrawal. The Morpho SDK's Vault V2 in-kind route requires exactly one
MorphoMarketV1AdapterV2, sufficient flash-loan liquidity, share authorization, and permitted gate access. The received lending position retains its market risk and liquidity dependence.
Withdrawal gates can block ordinary and in-kind exits. Restoring market liquidity resolves a liquidity shortage, but it does not remove an access restriction.
Allocation checks before a Vault V2 deposit
Before a Vault V2 deposit, its configured routing determines whether the asset can enter and which liquidity an ordinary exit could use. Inspect these conditions before authorizing spending or submitting the deposit.
-
Match the deposit token to the vault's
asset; an approval authorizes spending without creating a vault position. - Read the liquidity destination's allocation and all applicable caps; insufficient headroom can reject the entire deposit.
- Identify idle liquidity and assets retrievable through the liquidity adapter, separately from other portfolio positions.
- Check gates for the deposit sender, share recipient, share owner, and intended withdrawal recipient.
- Read configured fees, relevant timelocks, and pending changes before committing to the allocation policy.
If a required condition fails, leave the deposit unsubmitted. A simulation evaluates the state it reads; liquidity and configuration can change before execution. After a confirmed successful deposit, reconcile the transferred asset amount and minted shares with the transaction receipt and the recipient's share balance. Then revisit the actual allocations and exit liquidity before deciding whether to keep the position.
Things people ask about Morpho vaults
Why does Vault V2's maxWithdraw function return zero when liquidity is available?
Vault V2's maxWithdraw function always returns zero as a conservative bound because gate checks can revert, so that result does not measure available liquidity. Applications need a version-aware calculation incorporating idle assets, usable liquidity-adapter capacity, the holder's shares, and access restrictions. The same zero-return behavior applies to maxDeposit, maxMint, and maxRedeem.
Can a Vault V2 allocate into a Vault V1.1?
A Vault V2 can allocate into a Vault V1.1 through an enabled MorphoVaultV1Adapter. Vault V1.1 does not recognize bad debt by reducing its share price, so the parent vault will not reflect that allocation's corresponding losses through the adapter's valuation. The additional layer retains the inner vault's liquidity and loss-accounting constraints; the wrapper does not remove them.
Does a Vault V2 need seed shares before accepting deposits?
A Vault V2 should have an adequate initial deposit whose shares are permanently locked before normal deposits. Those shares help reduce donation-based inflation attacks on later deposit conversions. The required seed share amount depends on the underlying asset's decimals, so an arbitrary token amount does not establish sufficient protection. A successful deposit transaction alone does not prove that this protection is present.
What does an empty Vault V1 supply queue mean for existing deposits?
An empty Vault V1 supply queue blocks new deposits without itself disabling withdrawals. Existing shares retain exposure to the vault's positions, and withdrawals use the withdraw queue subject to market liquidity. Closing the deposit route does not establish that the portfolio has been unwound. Authorized reallocations remain possible where underlying liquidity and cap headroom allow them.
Why can a Vault V2 deposit hit a relative cap even though it adds assets?
Vault V2 uses a nonzero initial asset total as the relative-cap basis for the transaction. A deposit routed through the liquidity adapter can therefore fail the cap check even if its post-deposit portfolio percentage would fit. Raising token allowance does not fix this rejection. The applicable cap headroom or configured routing must permit the allocation.