Tokenized Vault Foundation and OpenZeppelin Bring ERC-7540 Asynchronous Vaults to Onchain Funds

OpenZeppelin, a security partner of the Tokenized Vault Foundation, has contributed a standardized implementation for onchain vaults that settle at the pace real-world assets move. Built on ERC-7540, the industry standard for asynchronous vaults, it was developed with support from Foundation members Centrifuge and Superform.

Institutional funds rarely move in a single transaction. A deposit can wait on a compliance check or a wire; a redemption, or withdrawal, can queue when demand outstrips liquidity. Tokenized treasuries, private credit, and regulated funds all run on their own timelines, which same-block synchronous vaults weren't designed to hold. Asynchronous vaults separate the request from settlement and control how redemptions are ordered, the way these funds already work offchain.

Where asynchronous vaults fit institutional finance

A tokenized vault works much like a fund: investors deposit assets and receive shares that represent their stake. OpenZeppelin's implementation provides a base vault plus a set of ready-made options, so a team can choose how each side of the vault behaves without building a custom vault for each case.

Each option maps to a specific fund operation:

• Request-then-claim flow: A deposit or redemption is submitted as a request and claimed once it has been fulfilled. This creates a defined window between an investor's instruction and settlement, the window in which an offchain step such as an eligibility check or an incoming wire is completed.
• Admin-fulfilled settlement: A fund administrator or other authorized account fulfills each request, which mirrors the subscription and redemption approval a managed or regulated fund already runs.
• Delegated operation: An investor can authorize an operator, such as a custodian, to submit and claim requests on their behalf.
• Time-delayed settlement: Requests become claimable after a configurable waiting period, which enforces a fixed redemption notice period or a staking unbonding period with no manual step.
• Ordered redemptions: When a fund cannot meet every withdrawal at once, redemptions are fulfilled in an order the vault controls rather than by transaction timing, the way a fund runs a redemption queue.
• One synchronous side: A vault can keep deposits instant while redemptions settle over time, or the reverse, when only one direction needs a wait.
• ERC-4626 compatibility: Claims use the functions the existing vault standard already defines, so vault shares stay usable as collateral across the lending markets and integrations built around ERC-4626.

Where each Vault standard fits

ERC-7540 adoption and the case for standardization

For institutions moving onchain, building vault logic from scratch would mean more integration work and a larger surface to audit and secure. A shared implementation of a recognized standard reduces both.

The synchronous version of this standard, ERC-4626, is already the default across DeFi, used by protocols from Yearn to Morpho to Aave. ERC-7540 extends that proven base to assets that settle over time, and it is already in production: Centrifuge runs ERC-7540 vaults across more than $1.6 billion in real-world asset pools, and institutional-facing protocols USDai, Nashpoint, Cove, Nest by Plume, and Lagoon have shipped ERC-7540-compliant vaults.

Altogether, the standards the Tokenized Vault Foundation maintains sit behind more than $13 billion in total value locked. Working alongside the Foundation and its members, OpenZeppelin has contributed a standardized starting point for that same pattern, backed by its record of protecting more than $250 billion in onchain value and working with institutions like DTCC, WisdomTree, and Fidelity.

How the ERC-7540 implementation works

Under the hood the implementation centers on a base contract, ERC-7540, that manages the request lifecycle, with strategy modules a vault composes for each direction. The two new entry points, requestDeposit and requestRedeem, register a request, and the existing ERC-4626 functions (deposit, mint, withdraw, redeem) become the claim step once a request is fulfilled. A request moves through pending, claimable, and claimed states, each readable through view functions such as pendingDepositRequest and claimableDepositRequest.

A vault selects one deposit strategy and one redeem strategy from three fulfillment models:

• Admin (ERC7540AdminDeposit, ERC7540AdminRedeem): an authorized account fulfills requests.
• Delay (ERC7540DelayDeposit, ERC7540DelayRedeem): requests become claimable after a configurable waiting period.
• Synchronous pass-through (ERC7540SyncDeposit, ERC7540SyncRedeem): keeps one side instant, deposits or redemptions, while the other settles asynchronously. A vault cannot be sync on both sides
• Sync (ERC7540SyncDeposit, ERC7540SyncRedeem): one side keeps the standard ERC-4626 synchronous flow.
• Epoch, in development: batches the requests in each window and fulfills them together at one net asset value, distributing shares or assets pro rata, the way funds that price at set intervals operate.

Asynchronous flows add state transitions that synchronous vaults do not have, so the implementation carries the safeguards OpenZeppelin applies to ERC-4626, including a configurable decimal offset that hardens the vault against the inflation attack, also known as the first-depositor attack.

The ERC-7540 implementation is available now in OpenZeppelin Community Contracts and is a candidate for a future audited release of the main OpenZeppelin Contracts library. Read the developer guide for the full module and interface reference.

FAQs

How can institutions benefit from using asynchronous vaults?

They suit any onchain product that cannot settle in a single transaction. Common cases include tokenized treasuries and money market funds with T+1 or T+2 settlement, private credit and other funds that run on subscription and redemption cycles, regulated products that require a compliance or eligibility check before a deposit clears, and staking strategies with an unbonding period. In each case the vault records the request, the real-world or time-based step runs, and the investor claims once it is complete.

What is ERC-7540?

ERC-7540 is an extension of the ERC-4626 tokenized vault standard that adds asynchronous deposit and redemption flows. It lets a vault record a request, wait for an off-chain or time-based step to complete, and settle afterward, rather than requiring settlement in a single transaction.

How is ERC-7540 different from ERC-4626?

ERC-4626 settles deposits and redemptions atomically, which suits liquid, same-block strategies. ERC-7540 introduces a request-then-claim flow for vaults that cannot settle instantly, such as real-world asset funds, private credit, and staking with unbonding periods. It reuses the existing ERC-4626 functions for the claim step, so the interface stays compatible.

Is the OpenZeppelin implementation audited?

The implementation is currently available in OpenZeppelin Community Contracts and is a candidate for a future audited release of the main OpenZeppelin Contracts library.