Morpho Vault V2's liquidity adapter is the configured route for new deposits and for withdrawals that exceed idle cash. Other allocations can contribute to the vault's asset value without being reached by a plain withdraw or redeem call. With MorphoMarketV1AdapterV2, liquidityData selects one market inside the adapter; it does not create a withdrawal queue.
Identify the adapter and the selected position
An adapter contains the logic for entering, valuing and exiting a supported position. Enabling an adapter gives the vault an allocation option, subject to its risk controls. Selecting it as the liquidity adapter gives it an additional routing role. Morpho's adapter configuration guide treats adapter enablement and cap configuration as explicit setup steps.
This walkthrough follows Vault V2 with MorphoMarketV1AdapterV2, plus a separate MorphoVaultV1Adapter position. The implementation reference is official repository commit 07698890ec96, checked on 29 October 2026. Match a deployed vault's chain, addresses and bytecode before applying these mechanics to it.
Read the pair together:
| Item | What it identifies | What it does not establish |
|---|---|---|
| Enabled adapters | Contracts the vault may use | Which one serves an ordinary exit |
liquidityAdapter | The selected adapter address | Every position inside that adapter |
liquidityData | The position passed to that adapter | A queue of alternative positions |
| Vault idle balance | Underlying tokens held by the parent vault | Cash held inside an underlying market or nested vault |
For the named market adapter, liquidityData encodes the full MarketParams structure. Its pinned allocation and deallocation functions decode those parameters and act on that market. Each market's loan token must match the vault asset, and its IRM must equal the adapter's configured adaptive-curve IRM. The same adapter address can hold positions in several eligible markets. Selecting market L leaves market B outside the plain exit route, even if both belong to that address.
Morpho's liquidity curation tutorial explicitly describes idle-first withdrawals and the absence of automatic fallthrough to another market. A Vault V1 withdrawal queue cannot be assumed at the Vault V2 parent layer.
The liquidity adapter is optional. Without one configured, deposits stay idle and a plain exit has only the parent's idle assets available. Enabling another adapter does not automatically select it as that route.
Separate the asset claim from reachable cash
Three quantities answer different questions. A depositor's share conversion estimates their asset claim. The parent vault's idle balance tells you how many underlying tokens it already holds. The configured position's available liquidity tells you what that route can return now, also bounded by the vault's own position.
The adapter interface reports investment value in underlying units through realAssets. Reporting value does not itself return tokens to the parent vault. The vault's conversion code also applies its rate bound and fee accounting, so a raw sum of adapter values is not a universal share-price formula.
At a fixed state, a useful cash check is:
Plain exit capacity = parent idle + cash recoverable through the configured pair.
The requested amount must also fit the owner's shares, permissions and applicable gates. This capacity is a state-dependent planning quantity, not a guaranteed amount at a future block.
The direct Morpho Blue supply-share example explains a market position's asset conversion and rounding. A Vault V2 depositor owns a separate vault share token; the market adapter holds the underlying Blue supply position. Keep those ownership layers separate when estimating what can be withdrawn.
Follow a deposit and a failed withdrawal
Consider this hypothetical ledger, denominated in fictional underlying token U with six decimals. The parent has 10,000 U of accounted assets and 10,000 whole vault shares, using 18 share decimals. Alice owns 5,000 shares. There is no interest, loss, donation, fee or intervening activity during the sequence. Adapter reports and transfers reproduce the amounts shown exactly; gates allow the actors and receivers.
One market adapter holds L and B. L is selected in liquidityData. A second adapter holds a position in nested Vault V1 C. Each cash amount below is what the parent position can recover at this state, after considering its holding and the underlying source's liquidity. It is not the whole market's or nested vault's total assets.
| Opening location | Accounted position in U | Cash recoverable now in U | Plain withdrawal source? |
|---|---|---|---|
| Parent idle | 1,000 | 1,000 | Yes, first |
| Selected market L | 2,000 | 600 | Yes, after idle |
| Other market B, same adapter | 4,000 | 2,000 | Requires a separate operation |
| Nested Vault V1 C, second adapter | 3,000 | 1,500 | Requires a separate operation |
| Total | 10,000 | 5,100 | Only 1,600 follows the plain route |
Another depositor now supplies 800 U. Because L is configured, the full new deposit goes into L. Parent idle stays at 1,000 U. L's position rises to 2,800 U and, under the example's unchanged borrowing, its available cash rises to 1,400 U. Total accounted assets and total whole shares become 10,800.
Alice's 5,000 shares still convert to 5,000 U under these assumptions. Nevertheless, her plain 2,600 U withdrawal fails. After using 1,000 U idle, the exit needs 1,600 U from L, which can return only 1,400 U. The transaction reverts; it pays no U and burns no Alice shares.
The immediately reachable amount is 2,400 U. Adding B's 2,000 U and C's 1,500 U would describe cash accessible through additional operations, not what this plain request executes. The nested adapter's implementation calls its underlying Vault V1 to withdraw when asked to deallocate; merely owning that position does not trigger the call.
A deposit can fail while idle stays available
Suppose L's market-specific absolute allocation cap is 3,500 U. All its other applicable caps permit the illustrated entries, with relative caps set to 100%. The first 800 U deposit fits: L rises from 2,000 to 2,800 U.
A second 800 U deposit would take L to 3,600 U, above that absolute cap. The allocation checks revert the whole deposit; they do not leave 700 U allocated and 100 U idle. The earlier 1,000 U idle balance does not create an entry fallback. Only 700 U of headroom remains under this particular cap.
That is an entry constraint. Raising or lowering a cap does not itself return allocated cash. The Vault V2 cap increase versus decrease guide explains the separate approval and timing boundaries.
Return assets to idle, then reconcile the exit
Continue from the first successful deposit. The failed attempts have left the state unchanged. An authorized allocator asks market B to return 900 U to the parent vault. This is an ordinary deallocation, with no user forced-deallocation penalty.
| Completed state | Idle U | L position U | B position U | C position U | Accounted assets U |
|---|---|---|---|---|---|
| After the 800 deposit | 1,000 | 2,800 | 4,000 | 3,000 | 10,800 |
| Allocator returns 900 from B | 1,900 | 2,800 | 3,100 | 3,000 | 10,800 |
| Alice withdraws 2,600 | 0 | 2,100 | 3,100 | 3,000 | 8,200 |
Returning 900 U changes its location. It creates neither income nor an extra claim. The next exit takes 1,900 U idle and asks L for the remaining 700 U. L can satisfy that request, leaving 700 U of its previously available 1,400 U.
Alice receives 2,600 U, burns 2,600 whole vault shares and retains 2,400 shares. Remaining total shares are 8,200. The asset ledger closes at 2,100 + 3,100 + 3,000 = 8,200 U, also equal to 10,000 + 800 − 2,600.
These whole-share amounts are exact in this constructed state. Vault V2's one virtual raw asset and 10^12 virtual raw shares preserve the stipulated conversion for this six-decimal asset. Real positions require the actual rounded previews and accrued fee shares.
The Yearn idle-versus-debt reconciliation uses a similar location-versus-value distinction. Its queue mechanics belong to that named Yearn implementation; the cash return here was explicitly requested before Alice's Vault V2 exit.
Changing the selected market is another distinct action
Return instead to the 10,800 U state before the allocator's 900 U deallocation. If the allocator changes liquidityData from L to B, the setter moves no assets. It changes which market the next entry or exit uses. With B now selected, the illustrated plain capacity becomes 1,000 + 2,000 = 3,000 U.
A 2,600 U withdrawal could then use 1,000 U idle and 1,600 U from B. L would stay at 2,800 U, B would fall to 2,400 U and C would remain 3,000 U. This is an alternative branch, not another step after the previous table. Any subsequent deposit would also route toward B and face B's applicable caps.
Check what an interface adds before quoting a limit
An interface can construct a transaction that first uses forceDeallocate to return available assets from another position, then withdraws from idle. That broader transaction can reach more than a plain call. It also needs a plan for the selected position and any penalty charged in vault shares. The forced-deallocation penalty example follows the difference between assets returned to idle and a user's net exit.
Morpho's withdrawal integration guide makes this distinction explicit. Forced deallocation does not manufacture underlying liquidity when all available assets in a market are borrowed. An in-kind exit changes the position the user holds; it is a different outcome from receiving U in a wallet.
The Morpho help page says its app can attempt forced deallocation when the vault configuration permits it. Therefore, a displayed app limit may include more than idle and the configured pair. Read its breakdown and transaction plan before comparing it with a plain-call simulation.
Validate one route at one block
Record the vault, underlying asset, owner and observation block. Then read the actual liquidity adapter and raw data together. Decode the selected market using that adapter's implementation. An adapter address alone is an incomplete routing description.
For each position, keep valuation and recoverable cash in separate columns. Distinguish the parent token balance from cash inside B or C. Check current share previews, fees, gates and allowance alongside the proposed amount. The Vault V2 contract reference also documents that its four ERC-4626 max functions return zero. A zero maxWithdraw is therefore not a measurement proving this example's idle balance has disappeared.
Simulate the exact transaction, including any preliminary deallocation, against a consistent state. Check who may perform each operation: the allocator can set the route, while an allocator or Sentinel can perform ordinary deallocation. A user planning a permissionless forced deallocation must account for its own gates, share authorization and penalty.
After confirmation, reconcile the receiver's actual token increase, shares burned, idle balance and remaining positions. For the main branch here, those facts are 2,600 U paid, 2,600 shares burned, zero idle and 8,200 U remaining across L, B and C. Under unchanged conditions, the remaining plain-route cash is 700 U from L. Alice's remaining 2,400-share claim needs a fresh exit plan.