ERC-7540 Asynchronous Vaults vs ERC-4626 for Tokenized Credit: Request Queues, Epoch NAV & Liquidity Gates

The question for an allocator is not which standard is newer. It is whether the vault's settlement model matches the asset inside it. Loans are valued periodically and repaid on a schedule. A vault that prices and pays every block is pricing something it cannot see and paying with cash it may not have.

This guide assumes you know the two interfaces. For the function signatures, share math and the request states from the investor's side, read MetaMorpho V2, ERC-4626 and ERC-7540 vaults. Here the subject is the operation of one settlement cycle and what it protects.

Synchronous vs asynchronous in one paragraph

The ERC-4626 specification defines deposit as a call that "mints shares Vault shares to receiver by depositing exactly assets of underlying tokens", and redeem as a call that "burns exactly shares from owner and sends assets of underlying tokens to receiver". Request and settlement are one transaction, at the rate the contract reads at that moment. The ERC-7540 specification splits the same operation in two: a request, which enters a Pending state, and a later claim, which the standard allows only once the request is Claimable. The investor submits now, the vault settles later at a valuation it records for that settlement, and the investor claims afterwards. ERC-7540 also requires the vault to implement ERC-7575, which separates the share token from the vault contract.

Morpho's Vault V2, the successor of MetaMorpho, is the reference design for the synchronous flow; the Wave 1 guide calls it MetaMorpho V2. Its documentation states that it "is ERC-4626 and ERC-2612 compliant" and that "the allocator is responsible for ensuring that users can withdraw their assets at any time": curated vaults over on-chain lending markets, where the allocator's duty is same-transaction liquidity. Rekord Capital Markets (RCM) operates its vaults on Lagoon, "an ERC-7540 based on-chain vault protocol", because the positions behind its shares are loans, and loans give neither a per-block price nor per-block liquidity.

The request queue lifecycle, seen from the operator

The ERC-7540 specification names three request states: Pending, "the state where a Request has been made but is not yet Claimable"; Claimable, "the state where a Request is processed by the Vault", so that the user can claim the shares or the assets; and Claimed, "the state where a Request is finalized by the user and the user receives the output token". A request "MUST NOT skip the Claimable state". The investor view of the states is in the Wave 1 guide. The operator view is a set of obligations at each state, and a set of facts that anyone can read on-chain while the request sits there.

Pending: the request holds the assets or the shares

Per the specification, requestDeposit "transfers assets from owner into the Vault and submits a Request for asynchronous deposit", and requestRedeem "assumes control of shares from owner". Nothing is priced. In Lagoon's implementation the pending assets and shares are escrowed in a pending silo, "a utility contract deployed at vault creation to hold assets awaiting settlement", and the vault valuation "excludes pending deposits, which sit in silos until they are settled". The operator's job at this state is to leave the request alone: the assets wait outside the credit strategy, and the shares wait outside the market.

The pending totals are public. The specification defines pendingDepositRequest and pendingRedeemRequest per controller and requestId, and requires that they "MUST NOT show any variations depending on the caller". Lagoon's integration notes add that request ids are epoch-based and that 0 works as a wildcard in these views. An operator who reads the redemption queue against the next repayment dates already knows whether the next settlement can be paid in full. That is the input to the liquidity section below.

Claimable: one settlement fixes the price

The standard does not say how a request moves from Pending to Claimable: the transition "happens at the Vault implementation level and is not specified in the standard", and "the exchange rate of any Request may be fixed or variable depending on the implementation". Lagoon fixes it. Its documentation states that "requests are grouped and settled at a single valuation point, ensuring consistent pricing within each settlement cycle", in a two-step procedure: "first, the Valuation Provider will store a valuation proposal in the vault", then "the curator can accept this valuation by calling either settleDeposit/settleRedeem". Every pending deposit in the batch converts to shares at that valuation, and every pending redemption converts to assets at the same valuation.

The settlement is the artefact an auditor cares about. In Lagoon's epoch data model, each proposed valuation creates an epoch record, and the settle record "is finalized at the last proposed valuation": the valuation used, the shares minted for the deposit queue and the assets released for the redemption queue are all tied to one transaction. The operator's second obligation is to fund it. Lagoon's how-to is explicit: "the settlement of redemptions will only happen if there are enough assets in the curator's address", and "it is the curator's job to make sure it is the case". Note the two senses of the word: in Lagoon's documentation the Curator is the vault role that allocates and settles, while on this site 9Summits is named as the strategy curator of the 9SicUSDC vault.

Claimed: the investor, or its operator, takes delivery

The claim is a separate transaction. The controller calls deposit or mint to receive the shares, or redeem or withdraw to receive the assets, at the rate fixed at settlement. The specification allows the caller to be the controller or an operator the controller approved. For custodied investors, that operator makes the call. The standard sets no expiry on a claimable request; Lagoon states that settled shares "can be claimed at any time". From the operator's seat, unclaimed amounts are a liability already priced and reserved, and they are visible through claimableDepositRequest and claimableRedeemRequest.

Epoch NAV accounting

ERC-7540 leaves the settlement schedule to the implementation. Lagoon's pattern is an epoch: "every time a new valuation is proposed for the vault, a new Epoch Data is created", and each epoch "holds details about all users' deposits and redemption requests" (Lagoon, Key Data Structures and Epoch mechanism). The 9SicUSDC vault runs periodic nav settlement; the length of its periods is not published and is not stated here.

Inside an epoch the operator keeps two books. The on-chain book is the last settled valuation and the share supply, which together give the share price any integrator reads. The credit book is the loan tape: principal outstanding, interest accrued, repayments received, and any impairment. The two agree only at the moment of settlement. Between settlements the on-chain price is, by design, the last agreed valuation and nothing more.

What goes into a NAV update

Lagoon's valuation page sets the perimeter: "a valuation must exclusively reflect the positions held by the curating address", and "it is the responsibility of the Valuation Provider to value the positions in the underlying asset of the vault". For a loan book that valuation is built from four entries.

• Accrual. Interest earned on the loans over the period, at the contracted rates. For a fixed-rate book this is arithmetic; for a revolving facility it follows the drawn balance.
• Cash movements. Repayments and new draws change the mix between cash and loans, not the NAV itself, but they decide whether the curator's address holds enough assets for the redemption queue to settle.
• Impairments and markdowns. A loan that is late, restructured or written down reduces NAV at the update in which the valuation provider recognizes it. This is the entry that makes settlement timing matter, and the worked example below is built on it.
• Fees. The 9SicUSDC vault charges a 0% management fee and a 20% performance fee. In Lagoon, "fees are collected at each settlement and distributed as shares to the designated feeReceiver address", and the performance fee is "applied exclusively to new profits, calculated against the high-water mark" (Lagoon, Fees).

The order of operations matters. A clean epoch settlement first recognizes everything that happened to the loan book, then prices the queue at the resulting NAV. A vault that prices the queue first and recognizes the markdown later has reintroduced the stale-price problem through the back door, with a longer delay instead of a shorter one.

The records behind each NAV are where Rekord Kloud enters the picture. As described on Rekord Vaults, Rekord Kloud anchors collateral, cashflow and strategy records, readable in the Proof Console, so a later change to the inputs of a settled NAV is detectable.

Liquidity gates and redemption windows vs the loan maturity profile

The problem a gate solves is older than tokenization. The Financial Stability Board's 2023 recommendations on liquidity mismatch in open-ended funds state that "redemption terms that open-ended funds offer to investors should be based on the liquidity of their asset holdings" (Recommendation 3), and that anti-dilution tools should "impose on redeeming investors the explicit and implicit costs of redemptions", "including any significant market impact of asset sales to meet those redemptions", to "mitigate potential first-mover advantage arising from structural liquidity mismatch" (Recommendation 5). A liquidity gate is the on-chain form of that rule: it limits how much the vault pays out at one settlement to the cash the book returns, so the vault does not sell loans early at a discount to meet an exit.

The operator sizes the window from the maturity profile. A book of short-duration receivables returns cash every few weeks and can support frequent settlements. A book of term loans returns cash at a handful of dates and needs settlements aligned with them, or a cash reserve to bridge the gap. Either way the operator reads the redemption queue against the repayment calendar before it settles.

What Lagoon enforces

The Lagoon pages cited here describe a funding condition and a curator decision, not a numeric gate. Per the settlement how-to, redemptions settle "only if there are enough assets in the curator's address", and settleDeposit also settles pending redemptions because "the best moment to honor redemption requests is when there is a maximum of underlying in the curator address". Per the roles page, the curator "decides when to process deposit and withdrawal batches", and the integration notes add that "settlement is a curator action with no time guarantee". A request that is not settled stays pending; it is not priced until it is.

For the RCM vault, the published terms are what Rekord Vaults states: ERC-7540 asynchronous requests, settled at valuation updates, on Ethereum Mainnet. Institutions that need bespoke redemption terms rather than a pooled queue are covered on Rekord for Institutions.

Operator and controller roles for custodians

The ERC-7540 specification separates three parties around a request. The owner is the account whose assets or shares fund it. The controller is the "owner of the Request, who can manage any actions related to the Request"; a request "is discriminated by both the requestId and the controller". An operator is "an account that can manage Requests on behalf of another account". setOperator "grants or revokes permissions for operator to manage Requests on behalf of the msg.sender", and for any request "owner MUST equal msg.sender unless the owner has approved the msg.sender as an operator".

This maps onto institutional custody directly. The beneficial owner's custodian, or a fund administrator, is the operator. The institution's own account, often a cold address that never signs routine transactions, is the controller. The custodian submits the redemption request on the institution's behalf, watches the request move to claimable after settlement and calls redeem with the institution's address as controller and receiver. The assets land with the institution, and the custodian never holds them. Lagoon's integration notes confirm the claim path: assets are released to "the user, or an operator they approved with setOperator".

Two points for the custodian's operating procedures. First, operator approval is set on each vault contract and is revocable with setOperator(operator, false); the specification requires the vault to emit OperatorSet on every change. Second, the request state functions are read per controller, so the reconciliation a custodian runs against its own ledger uses the institution's address, not the custodian's.

The roles of the vault itself are different from the ERC-7540 operator of a request. In Lagoon the Valuation Provider "proposes the valuation inputs used to set the settlement price per share" and the Curator "validates the valuation proposal and decides when to process deposit and withdrawal batches". In the 9SicUSDC vault the vault roles are held by a 3/6 Safe multisig with a Zodiac Roles policy, described in the vault section below.

Failure modes of ERC-4626 for tokenized credit

Nothing in ERC-4626 is wrong. It is the correct interface for an asset that can be valued and exchanged every block. Put a loan book behind it and three failure modes follow, all from the same cause: the price the contract quotes is not the price the assets are worth.

Stale price

totalAssets for a loan vault is whatever the last valuation set it to. Between valuations, accrued interest is not in it and impairments are not in it. The ERC-4626 security considerations already warn that convertToShares, convertToAssets and totalAssets "are estimates useful for display purposes", and that the preview functions "are manipulable by altering the on-chain conditions and are not always safe to be used as price oracles". For a loan vault, every deposit and redemption still settles at that estimate. The question is only who the error favors.

Instant-exit runs

A synchronous vault pays redemptions from its liquid balance until it has none. The standard then requires redeem to "revert if all of shares cannot be redeemed", and maxRedeem to return 0 when redemptions are disabled "even temporarily". The SEC's 2016 liquidity risk management rule describes the dynamic in open-ended funds: there are "incentives in times of liquidity stress in the markets for shareholders to redeem quickly to avoid further losses", and "as the level of outflows from a fund increases, the incentive for remaining shareholders to redeem may also increase". The vault either sells loans at a discount to refill, which marks down the holders who stayed, or it stops paying, which is a gate imposed by accident instead of by rule.

NAV arbitrage

The combination of the two. An investor who learns that a markdown is coming before the next valuation can redeem at the stale, higher price and leave the loss with the holders who stay. The SEC release quotes a 1969 release's description of this transfer: "a preference in favor of the redeeming shareholders and a diminution of the NAV per share". The same investor can deposit just before a known positive revaluation and capture yield it did not earn. In a batch-settled ERC-7540 vault the request sits in the queue and settles at the post-markdown NAV alongside everyone else. The worked example below puts numbers on the difference.

ERC-4626, ERC-7540 and the 9SicUSDC vault compared

The table reads the two interface standards and the live RCM vault against the questions an operations or audit team asks. Morpho Vault V2 belongs in the ERC-4626 column as the reference synchronous implementation; it is not a venue RCM operates on.

Worked example: NAV arbitrage at a stale price

One loan is written down by 3% of the vault's NAV, and the markdown is known before the next NAV update. One investor holding 2,000,000 shares acts on it. The example runs the same exit through an ERC-4626 vault at the stale price and through one batch-settled ERC-7540 vault. The gross APR is the 9SicUSDC figure; the NAV, supply, period, markdown and exit size are illustrative round inputs. Fees are left out so the markdown is the only moving part.

The post-markdown NAV

1. Accrual over the period. 10,000,000.00 × 15% × 30 ÷ 365 = 123,287.67 USDC.
2. Markdown. 10,000,000.00 × 3% = 300,000.00 USDC.
3. NAV the next update will record. 10,000,000.00 + 123,287.67 − 300,000.00 = 9,823,287.67 USDC, or 0.982329 per share across all 10,000,000 shares.

ERC-4626: the exit settles at the stale price

1. The early redeemer calls redeem before the update. 2,000,000 × 1.000000 = 2,000,000.00 USDC leave the vault.
2. The update lands on what is left. 9,823,287.67 − 2,000,000.00 = 7,823,287.67 USDC over 8,000,000 shares = 0.977911 per share.
3. Transfer of value. The redeemer received 35,342.47 USDC more than its shares were worth at the post-markdown NAV. The holders who stayed lost exactly the same amount, 35,342.47 USDC, which is 45 basis points of their position on top of the markdown itself.

ERC-7540: the same exit waits for the batch

1. The request is pending. 2,000,000 shares leave the investor's custody and wait. No price is quoted.
2. Settlement at the post-markdown NAV. 2,000,000 × 0.982329 = 1,964,657.53 USDC become claimable.
3. The holders who stay. 9,823,287.67 − 1,964,657.53 = 7,858,630.14 USDC over 8,000,000 shares = 0.982329 per share, the same price the redeemer got.

The markdown is the same in both cases. What differs is who bears it. In the synchronous vault the redeemer bears none of it and the remaining holders bear all of it plus the redeemer's share. This is the "significant dilution of remaining investors' interests" that the SEC's liquidity rule is written to prevent. In the asynchronous vault every share in the batch bears its pro rata part, and the redeemer's information advantage is worth nothing because it cannot be converted into a different price. To run the arithmetic on your own inputs, including fees, use the RWA vault yield calculator.

The 9SicUSDC vault in brief

The live example is the 9Summits Short Duration Institutional Credit vault, Powered by Rekord. Rekord Capital Markets (RCM) operates it on Lagoon, and 9Summits is the curator. The share token is 9SicUSDC, the underlying asset is USDC, and the standard is ERC-7540 (Lagoon) on Ethereum Mainnet. The figures below are those published on Rekord Vaults.

The vault roles sit with a 3/6 Safe whose outgoing transfers are scoped by a public Zodiac Roles policy to one settlement wallet. Pending requests, claimable amounts, supply and the settlement history are readable on Etherscan. The product view, with the other RCM strategies, is on Rekord Vaults. RCM's BTC- and ETH-backed credit line for institutions is described on Digital Asset Credit.

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. As published on Rekord for Institutions, deposits and redemptions run asynchronously through the ERC-7540 vault on Lagoon and settle at valuation updates; the vault roles are held by the 3/6 Safe with its Zodiac Roles policy, and settlement runs through a whitelisted Fordefi wallet separate from the signer Safe.

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

Sources

1. ERC-7540: Asynchronous ERC-4626 Tokenized Vaults, Ethereum Improvement Proposals. Supports: request states, requestDeposit / requestRedeem, controller and operator definitions, setOperator, requestId, the unspecified Pending → Claimable transition, the fixed-or-variable exchange rate, the mandatory revert of the preview functions, the ERC-7575 requirement.
2. ERC-4626: Tokenized Vaults, Ethereum Improvement Proposals. Supports: deposit / redeem definitions, totalAssets, the revert of redeem when shares cannot be redeemed, maxRedeem returning 0, the security considerations on estimates and price oracles.
3. ERC-7575: Multi-Asset ERC-4626 Vaults, Ethereum Improvement Proposals. Supports: the separation of the share token from the vault contract.
4. What is Lagoon?, Lagoon docs. Supports: Lagoon as an ERC-7540 based vault protocol.
5. Deposit and Redemption flows, Lagoon docs. Supports: the pending silo, settlement of each batch at a single valuation point, claims at any time.
6. Update the vault valuation & settle requests, Lagoon docs. Supports: the two-step valuation proposal and settleDeposit / settleRedeem, the funding condition on the curator's address.
7. Vault valuation, Lagoon docs. Supports: the valuation perimeter, the exclusion of pending deposits, the Valuation Provider's responsibility.
8. Fees, Lagoon docs. Supports: fees collected at each settlement as shares to the feeReceiver, the high-water mark.
9. Roles and capacities, Lagoon docs. Supports: the Valuation Provider and Curator roles.
10. Key Data Structures and Epoch mechanism, Lagoon docs. Supports: one epoch record per proposed valuation, the settle record finalized at the last proposed valuation.
11. Async flow, Lagoon developer hub. Supports: epoch-based request ids, the wildcard request views, the operator claim path, settlement as a curator action with no time guarantee.
12. Vault V2, Morpho (GitHub README). Supports: ERC-4626 compliance of Morpho Vault V2 and the allocator's duty to keep withdrawals available.
13. Morpho Vault V1 (MetaMorpho), Morpho (GitHub README). Supports: MetaMorpho as an ERC-4626 vault and Vault V2 as its successor.
14. Revised Policy Recommendations to Address Structural Vulnerabilities from Liquidity Mismatch in Open-Ended Funds, Financial Stability Board, 20 December 2023. Supports: redemption terms based on asset liquidity (Recommendation 3), anti-dilution tools and first-mover advantage (Recommendation 5).
15. Investment Company Liquidity Risk Management Programs, U.S. Securities and Exchange Commission, Release Nos. 33-10233 and IC-32315, 81 FR 82142 (18 November 2016). Supports: the incentive to redeem first under liquidity stress, dilution of non-redeeming shareholders, the 1969 release it quotes on the transfer to redeeming shareholders.
16. Rekord Vaults, Rekord. Supports: the 9SicUSDC vault figures, the redemption mechanism, the Safe and Fordefi settlement set-up, the records Rekord Kloud anchors.
17. Rekord for Institutions, Rekord. Supports: asynchronous settlement at valuation updates, the separation of the signer Safe from the settlement wallet, the entity split.