ERC-7540 is the 2024 standard for tokenised vaults whose deposits or redemptions cannot settle instantly. It is the youngest standard in this chapter and the one most likely to matter as tokenisation extends beyond money-market funds into less liquid asset classes. The reason it exists is structural: ERC-4626 (the predecessor vault standard) assumed shares and assets exchanged synchronously inside one transaction, which is fine for a stablecoin or a daily-liquid MMF but actively wrong for private credit, hedge funds with monthly windows, or anything where a custodian or transfer agent has to physically settle off-chain before shares can be issued.
What ERC-4626 does and where it stops working
Synchronous shares-for-assets, in one transaction. ERC-4626 standardised the tokenised-vault interface in 2022. The user calls deposit(assets, receiver), the vault accepts the assets, mints shares back, and the receiver gets shares in the same block. redeem(shares, receiver, owner) works the same way in reverse: shares burn, assets transfer out, atomically. This works because the standard quietly assumed that the vault could always price and settle inside one transaction.
For a tokenised MMF with daily NAV and an issuer who runs constant-NAV mechanics, that assumption holds. MONY does not need ERC-7540: the underlying is liquid, the NAV is daily, the cash leg settles same-day through the bank's existing rails. ERC-4626 (or an ERC-4626-shaped extension) is enough.
For a tokenised private-credit fund with monthly subscription windows and 30-to-90-day redemption notice, the assumption breaks. A user calling deposit cannot get shares back in the same block because no one knows what the NAV is, the underlying loan portfolio cannot be priced atomically, and the issuer has to run an off-chain process before shares can be minted. The contract has no clean way to express "I have your assets, you do not get shares yet, come back later."
The two-step pattern
requestDeposit, then deposit. ERC-7540 introduces an explicit asynchronous flow. A user wanting to subscribe calls requestDeposit(assets, controller, owner). The vault accepts the assets, records the request, and returns nothing yet. Off-chain (or on-chain via a scheduled job) the issuer processes the request: prices the underlying, runs compliance checks, adjusts the share register. When the request is ready, the issuer marks it claimable. The user (or anyone authorised) then calls deposit(assets, receiver) to claim the shares.
Redemption mirrors the pattern: requestRedeem(shares, controller, owner) followed later by redeem(shares, receiver, owner) once the issuer has processed the unwind. Between request and claim there is a defined state where the user's request is pending; the standard exposes view functions (pendingDepositRequest, claimableDepositRequest) so that wallets and front ends can show the user where they are in the queue.
The standard is deliberately quiet on how the issuer processes requests. That is operational logic, not standard logic. The standard fixes only the request-and-claim state machine and the view functions a front end needs to render it.
Why MMFs do not need it
Daily-liquid is synchronous-enough. A tokenised MMF runs a constant-NAV-style mechanic where shares price at a known peg and the cash leg settles same-day through the bank rails the issuer already operates. The user calling deposit is, from the contract's perspective, asking for the same shares-for-assets exchange that ERC-4626 was designed for. The fact that the cash leg sweeps through a bank account rather than a smart contract does not break the synchronous interface, it just means the on-chain mint happens after the off-chain cash arrives, on the same operational day.
BUIDL, MONY, FOBXX, OUSG all run this pattern. The compliance plumbing is ERC-3643-shaped (Part 3); the vault plumbing, where it exists, is ERC-4626-shaped or a custom variant that looks ERC-4626-shaped to the front end. ERC-7540 is overkill.
Where it matters
Private credit, hedge funds, real estate. The asset classes that need ERC-7540 are the ones where the underlying cannot be priced or unwound on demand. A tokenised private-credit fund subscribing in monthly windows uses the request-and-claim pattern because the loan portfolio has to be priced and the new investor allocated against the existing pool, which is a multi-day operation. A tokenised hedge fund with monthly liquidity has the same shape: the user requests redemption, the manager unwinds positions through the redemption window, and the user claims when the cash leg has actually arrived.
Tokenised real estate is the most extreme case. Property does not sell in days. Redemption from a tokenised real-estate vehicle either runs against a separate liquidity pool (which is a different design problem) or runs on multi-quarter notice with explicit asynchronous mechanics.
What this means for collateral and credit rails
Asynchrony breaks atomic DvP. The interesting downstream consequence is for collateral systems that want to accept tokenised vault shares as posted collateral. A liquid MMF token (BUIDL, MONY) can be posted and unwound atomically; a private-credit vault share cannot. If JPMorgan's Kinexys extends TCN-style collateral mechanics into private-credit collateralisation (the Apollo ACRED extension is the obvious example), the collateral system has to handle assets where redemption is asynchronous by construction. The clean answer is to value the asset as collateral on a different basis (a haircut for liquidity, or a forced-sale or repo path) rather than to pretend the vault can settle on demand.
That is the load-bearing consequence of ERC-7540 for the institutional stack. The standard itself is a small piece of plumbing. The architectural implication, that some tokenised assets are intrinsically asynchronous and the systems consuming them have to know that, is what changes how downstream rails get designed.
Part 5 zooms back out and looks at why the architectural pattern (separating token from compliance, then separating sync from async) is the load-bearing innovation of this chapter, and how the standard choice cascades into everything downstream.