MetaMorpho V2, ERC-4626 & ERC-7540 Asynchronous Vaults: Institutional Architecture & Risk Curation

An allocator who reviews an on-chain vault needs three answers: how shares are priced, who can move the capital, and what stops them from moving it somewhere else. The standards in this guide answer the first question. The vault configuration answers the other two.

For a shorter introduction, read the Education Hub entries on MetaMorpho V2 and on ERC-4626 and ERC-7540. For the full Rekord stack, from borrower documents to anchored NAV, see How Rekord works.

What MetaMorpho V2 is

MetaMorpho is the curated vault layer built on top of Morpho. Depositors supply one asset to an ERC-4626 vault, and a curator decides which lending venues that capital can reach and under which limits. The depositor holds vault shares, and the vault holds positions in the venues the curator has approved.

The design separates powers across named roles. Each role can do a narrow set of things, and the riskiest actions wait in public before they take effect.

Roles

• Owner. Appoints the other roles and holds the top-level control of the vault.
• Curator. Sets the risk framework: which markets or adapters the vault may use and how much exposure each one can carry.
• Allocators. Move liquidity between the approved markets, inside the caps the curator has set. An allocator cannot raise a cap or add a new market.
• Safety role. In MetaMorpho V1 this is the guardian, which can revoke pending changes. V2 uses sentinels for the same protective function.

Timelocks on curator actions

Risk-increasing changes pass through a timelock. A curator who wants to add a market or raise a cap submits the change, and it becomes executable only after the delay has elapsed.

In V2 the timelock is configurable per function, so the delay on a cap increase can differ from the delay on a fee change. During the delay, depositors can read the pending change on-chain and exit if they disagree with it. The delay values are set per vault, so read them from the contract of the vault you are reviewing.

Caps and adapters

V1 limits risk with a supply cap per Morpho Blue market. V2 generalizes this into absolute and relative caps on shared risk exposures. An absolute cap limits the amount of capital exposed to a risk factor, such as a collateral asset or an oracle. A relative cap limits that exposure as a share of the vault's total assets.

V2 also reaches beyond Morpho Blue through adapters. An adapter connects the vault to a Morpho market or to another venue, and the caps apply across adapters. Two markets that share the same collateral therefore count against the same exposure limit.

MetaMorpho settles deposits and withdrawals synchronously, so it fits assets with on-chain liquidity. A vault that lends to real-world borrowers needs a different settlement model, which is where ERC-7540 comes in.

ERC-4626: the synchronous vault flow

ERC-4626 is the tokenized vault standard. It defines one interface for depositing an asset, receiving shares, and turning those shares back into the asset. Every major vault framework, MetaMorpho included, implements it.

function totalAssets() view returns (uint256)
function convertToShares(uint256 assets) view returns (uint256 shares)
function convertToAssets(uint256 shares) view returns (uint256 assets)

function previewDeposit(uint256 assets) view returns (uint256 shares)
function previewMint(uint256 shares) view returns (uint256 assets)
function previewWithdraw(uint256 assets) view returns (uint256 shares)
function previewRedeem(uint256 shares) view returns (uint256 assets)

function deposit(uint256 assets, address receiver) returns (uint256 shares)
function mint(uint256 shares, address receiver) returns (uint256 assets)
function withdraw(uint256 assets, address receiver, address owner) returns (uint256 shares)
function redeem(uint256 shares, address receiver, address owner) returns (uint256 assets)

Share accounting

The vault is an ERC-20 share token over a pool of one underlying asset. totalAssets returns the value the vault manages, in units of the asset, and the share supply is the ordinary ERC-20 totalSupply.

sharesOut  = assetsIn  × totalSupply ÷ totalAssets   (rounded down)
assetsOut  = sharesIn  × totalAssets ÷ totalSupply   (rounded down)
sharePrice = totalAssets ÷ totalSupply

convertToShares and convertToAssets express that ratio without fees or limits. They are the reference figures an integrator uses for display and reporting.

The standard requires rounding in favor of the vault. A depositor receives slightly fewer shares, and a redeemer slightly fewer assets, so no caller can extract value from the rounding at the expense of the other holders.

The four entry points

• deposit: the caller fixes the assets in, and the vault returns the shares minted.
• mint: the caller fixes the shares out, and the vault pulls the assets needed.
• withdraw: the caller fixes the assets out, and the vault burns the shares needed.
• redeem: the caller fixes the shares in, and the vault returns the assets.

The four preview functions simulate each entry point at the current state, including fees. A preview must return no more shares or assets than the real call would deliver in the same block, which lets a front end quote the result before the user signs.

Everything happens in one transaction. The price is the current totalAssets divided by the current supply. That works when the vault can value its holdings every block and pay out from liquid positions. It breaks when the holdings are loans that are valued periodically and repaid on a schedule.

ERC-7540: the asynchronous vault flow

ERC-7540 extends ERC-4626 with asynchronous requests. A deposit or a redemption is first recorded as a request. The vault fixes the price later, and the investor claims the result once the request is settled.

// 1. Request: assets or shares leave the investor now, the price is set later
function requestDeposit(uint256 assets, address controller, address owner) returns (uint256 requestId)
function requestRedeem(uint256 shares, address controller, address owner) returns (uint256 requestId)

// 2. Read the request state
function pendingDepositRequest(uint256 requestId, address controller) view returns (uint256 assets)
function claimableDepositRequest(uint256 requestId, address controller) view returns (uint256 assets)
function pendingRedeemRequest(uint256 requestId, address controller) view returns (uint256 shares)
function claimableRedeemRequest(uint256 requestId, address controller) view returns (uint256 shares)

// 3. Claim: the ERC-4626 entry points, with the controller as an extra argument
function deposit(uint256 assets, address receiver, address controller) returns (uint256 shares)
function mint(uint256 shares, address receiver, address controller) returns (uint256 assets)
function redeem(uint256 shares, address receiver, address controller) returns (uint256 assets)
function withdraw(uint256 assets, address receiver, address controller) returns (uint256 shares)

// Operators act for a controller on requests and claims
function setOperator(address operator, bool approved) returns (bool)

Request states

1. Pending. The investor calls requestDeposit with assets, or requestRedeem with shares. The vault takes custody of the assets or the shares and returns a requestId. Nothing is priced yet.
2. Claimable. The vault processes the request at a valuation. The pending amount moves to the claimable state, now with a fixed exchange rate.
3. Claimed. The investor calls deposit or mint to receive the shares, or redeem or withdraw to receive the assets. The claim uses the rate fixed at settlement, whatever the share price has done since.

A vault can be asynchronous on one side only. For example, deposits can stay synchronous while redemptions go through requests. For whichever side is asynchronous, the standard requires the matching preview functions to revert, because no honest quote exists before settlement.

Epochs and NAV settlement

ERC-7540 defines the request and claim interface. It leaves the settlement schedule to the vault. An implementation typically batches requests over a period and settles them together.

At settlement, the vault records a new net asset value (NAV), which becomes the new totalAssets. Every pending deposit in the batch converts to shares at that one price, and every pending redemption converts to assets at the same price. No investor in the batch enters or exits at a valuation that others did not share.

Controllers and operators

Each request has an owner, whose assets or shares fund it, and a controller, who manages it and claims it. An investor can approve an operator through setOperator. The operator can then submit requests and claims on the controller's behalf, which suits custodians and treasury platforms that act for many beneficial owners.

Why private credit needs the asynchronous model

• Valuation. Loans do not trade on an order book. Their value comes from a periodic NAV, so any per-block price would be stale between valuations.
• Liquidity. Capital is lent out for a term. Redemptions are paid from repayments and reserves, and they need a settlement window rather than an instant pool.
• Fairness. Settling a whole batch at one NAV removes the advantage of anyone who could time an entry or exit against a known stale price.

ERC-4626, ERC-7540, MetaMorpho V2 and 9SicUSDC compared

The two standards define interfaces. MetaMorpho V2 and the 9SicUSDC vault are implementations with governance on top. The table reads each one against the questions an allocator asks.

Worked example: one ERC-7540 settlement with a performance fee

The example follows one settlement period of an asynchronous vault. The fee rates come from the 9SicUSDC vault: 0% management fee and 20% performance fee, with a 15% fixed gross APR. The NAV, supply, period and request sizes are illustrative round inputs, chosen to make the arithmetic easy to follow.

Step by step

1. Gross yield for the period. NAV × gross APR × days ÷ 365 = 1,000,000.00 × 15% × 30 ÷ 365 = 12,328.77 USDC.
2. Management fee. NAV × 0% × 30 ÷ 365 = 0.00 USDC.
3. Performance fee. 20% × gross yield = 2,465.75 USDC.
4. NAV at settlement. 1,000,000.00 + 12,328.77 − 0.00 − 2,465.75 = 1,009,863.01 USDC.
5. New share price. 1,009,863.01 ÷ 1,000,000 = 1.009863 USDC per share.
6. Pending deposit becomes claimable. 100,000.00 ÷ 1.009863 = 99,023.33 shares, claimed later with deposit or mint.
7. Pending redemption becomes claimable. 50,000 × 1.009863 = 50,493.15 USDC, claimed later with redeem or withdraw.
8. After settlement. NAV of 1,059,369.86 USDC over 1,049,023.33 shares. The price stays at 1.009863, because both requests were converted at that price.

The last step is the point of the asynchronous model. The new depositor and the departing holder both transacted at the NAV that included the period's yield and fees. Neither diluted the holders who stayed.

The example deducts the fees from NAV. A vault can also collect a performance fee by minting new shares of equal value to the fee recipient, which gives the same price per share. Read the fee mechanism of a specific vault from its contract and its documentation.

Simple fee math and the reported net APR

On simple fee math, a 15% gross rate less a 20% performance fee on the yield and a 0% management fee gives 12% a year.

The 9SicUSDC page reports a 12.58% net APR. That figure is Lagoon's measured inception net APR on the snapshot date (Snapshot Oct 23, 2026), measured from the vault's performance since inception. The two numbers are measured in different ways, so expect them to differ: one is arithmetic on a fixed rate, the other is observed performance since launch. On this snapshot they differ by 0.58 percentage points. For qualified counterparties only.

The 9SicUSDC vault in detail

The live example of these standards at Rekord is the 9Summits Short Duration Institutional Credit vault, Powered by Rekord. RCM operates it on Lagoon, and 9Summits is the curator. The share token is 9SicUSDC, and the underlying asset is USDC.

Custody and transfer controls

The vault roles are held by a 3/6 Safe multisig at 0x2EC0F23B52f60ce3C6406cf3Fd72fB9E28016Eff. A transaction needs 3/6 signer approvals before it executes.

A signer quorum still leaves open where the funds can go. The Safe therefore carries a public Zodiac Roles Modifier that scopes outgoing transfers to one whitelisted destination: the Fordefi settlement wallet at 0xC5a8b7C688aeb508cD19894c12d2f9Ef3ae753D3.

The role configuration is on-chain. Anyone can read the Zodiac Roles policy and confirm the permitted destination without asking the operator.

Status and settlement

The vault is Fully Allocated · View Only: its current capacity is deployed, and new deposits wait for the next tranche. It runs periodic nav settlement under ERC-7540, so redemption requests settle at valuation updates.

The share supply, pending requests and NAV history are public. Read them on Etherscan or on the Lagoon vault page. The product view is on Rekord Vaults.

A risk curation checklist for institutions

The standards make a vault readable, and the review of its risk stays with the allocator. Before an allocation, an institution can work through these 10 questions against the contract and the documents.

1. Who holds the roles? Identify the owner, curator, allocators and safety role, or their equivalents. Check whether each one is a multisig, its threshold, and who the signers are.
2. Which changes are timelocked? Read the delay on cap increases, new markets, fee changes and role changes, and check who can cancel a pending change.
3. What are the caps? List the exposure limits per market, per collateral and per counterparty, and check whether they are enforced on-chain or by policy.
4. Where does the valuation come from, and how often? Name the NAV source, the party that records it on-chain and the settlement cadence.
5. Where can funds go? Trace the settlement path and the whitelists that restrict outgoing transfers, such as a Zodiac Roles policy on the Safe.
6. How liquid are redemptions? Compare the redemption window with the maturity profile of the assets and the reserves held against requests.
7. What can you verify on-chain? Confirm that totalAssets, supply, pending requests and settlement history can be read from the contract without the operator.
8. Are the legal entities separated? Identify which entity operates the capital, which entity provides the software, and which entity holds depositor funds.
9. Does the fee math reconcile? Recompute the share price over one period from the stated fees, as in the worked example, and compare it with the on-chain price.
10. Is there proof of the records? Check whether the collateral, cashflow and NAV records behind the price are hashed and anchored, so a later change is tamper-detectable.

Entity separation

Two entities share the work behind the 9SicUSDC vault, and the split is deliberate.

Rekord Capital Markets (RCM) operates the vault and the credit strategies. It deploys capital, signs settlement transactions within the limits the Safe and the Roles Modifier enforce, and publishes NAV.

Rekord AG, Zug, is a separate software provider. Its Trust Layer, Rekord AI and Rekord Kloud, read through the Proof Console, provides the underwriting and the proof of the records behind each NAV. Rekord AG does not hold depositor funds.

Treasuries and allocators that hold stablecoins can see how a deposit fits their mandate on For Stablecoin Holders.