Should Tokenized Funds Use ERC-7540 Async Vaults?
ERC-7540 is a Final Ethereum standard extending ERC-4626 with a mandatory asynchronous request and claim lifecycle — Pending, Claimable, Claimed — that cannot be short-circuited, so a deposit can wait on a compliance check or a wire and a redemption can queue when demand outstrips liquidity. Created on 18 October 2023, it received a standardized OpenZeppelin implementation on 23 July 2026 in collaboration with the Tokenized Vault Foundation, whose standards underpin over $13 billion in TVL. It is the first standard to encode dealing-cutoff reality rather than assume it away, and it relocates the resulting risk rather than removing it: the specification concedes that shares received may not equal convertToShares at request time, and mandates no cancellation path.
TL;DR — Key Takeaways
- ✓The Standard: ERC-7540 (created 18 October 2023, status Final) adds a mandatory Pending to Claimable to Claimed lifecycle to ERC-4626 that cannot be short-circuited.
- ✓Why It Exists: A deposit can wait on a compliance check or a wire; a redemption can queue when demand outstrips liquidity. ERC-4626 assumes single-block pricing and settlement, which no regulated fund satisfies.
- ✓The Conceded Exposure: The spec states shares received may not equal convertToShares(assets) at request time, because price can change between request and claim.
- ✓The Two Gaps: Security Considerations flag that positions can stay pending indefinitely absent cancellation functionality, and that operators gain control over both assets and shares.
- ✓Adoption: OpenZeppelin shipped a standardized implementation on 23 July 2026 with the Tokenized Vault Foundation ($13B+ TVL behind its standards). Centrifuge ($1.6B+ RWA pools), USDai, Nashpoint, Cove, Nest by Plume, Lagoon.
A Standard That Admits Funds Do Not Settle in One Block
ERC-4626 made tokenized vaults interoperable by fixing a common interface for deposits and redemptions. It also embedded an assumption that quietly disqualifies most regulated products: that the vault can determine an exchange rate and settle the transaction within a single call.
No regulated fund works that way. Subscriptions and redemptions price at a dealing point defined in the fund documents. Cash moves on banking hours. Investor eligibility may need to be confirmed before a subscription completes. A synchronous vault wrapping such a fund has to paper over one of those, usually by pricing against whatever NAV was last published.
ERC-7540 stops papering over it. Created on 18 October 2023 and now Final, it adds a mandatory request/claim lifecycle with three states — Pending, Claimable, Claimed — that cannot be short-circuited.
“A deposit can wait on a compliance check or a wire; a redemption, or withdrawal, can queue when demand outstrips liquidity.”
— OpenZeppelin and the Tokenized Vault Foundation, on the rationale for ERC-7540, 23 July 2026
That sentence describes ordinary fund operations. The notable thing is that it took until 2026 for a vault standard to say so. For where this sits among permissioned standards, see our guide to RWA token standards.
What the Three-State Lifecycle Actually Encodes
The lifecycle maps directly onto how a fund order already works: an instruction is submitted, it is executed at a valuation point, and the resulting units or cash are then delivered. ERC-7540's contribution is making that sequence explicit on-chain rather than hiding it behind a call that pretends to settle immediately.
| State | What has happened | What the investor holds |
|---|---|---|
| Pending | Request submitted; awaiting compliance, cash, or the next valuation point | A claim on a future execution at an unknown price |
| Claimable | Executed and priced; the output is allocated but not yet taken | A determined entitlement, not yet in their wallet |
| Claimed | Investor has taken delivery | The shares or assets themselves |
The middle state is the one that has no analogue in a synchronous vault, and it is doing real work. It separates “the fund has decided what you get” from “you have it”, which is exactly the distinction that lets an operator batch executions at a dealing point while investors claim on their own schedule.
This is a deliberate departure from atomic settlement, the model examined in atomic settlement and DvP for tokenized securities. Both legs moving together is the right goal for a securities trade and the wrong one for a fund subscription, because the fund cannot price the second leg until its valuation point.
The Specification Concedes the Price Exposure Outright
An investor submitting a request does not know what they will receive. The standard says so in its own Rationale, which is unusually candid for an EIP and worth quoting rather than paraphrasing.
“The shares that will be received on deposit or mint may not be equivalent to the value of convertToShares(assets) at request time, as price can change between Request and Claim.”
— EIP-7540, Rationale
This is forward pricing, and in conventional fund terms it is entirely normal. An order placed before a dealing cutoff is priced at the next valuation point, not at the price displayed when it was submitted, and every fund prospectus says so. ERC-7540 has reproduced a standard fund mechanic rather than inventing a new risk.
What differs is the surrounding disclosure. A fund investor receives a prospectus stating the dealing cutoff, the valuation point and the pricing basis. A vault user receives a contract interface. The exposure is identical; the documentation that makes it comprehensible is not automatically present, and supplying it is the issuer's job rather than the standard's.
The practical consequence is that an ERC-7540 vault fronting a regulated fund needs its dealing terms published somewhere an investor will actually read, and needs them to match the fund documents exactly. A mismatch between the contract's behaviour and the prospectus is a disclosure problem before it is a technical one — see RWA reporting and investor disclosure requirements.
Two Gaps the Standard Names and Does Not Close
ERC-7540's Security Considerations flag two exposures that conformance alone does not address: positions can remain pending indefinitely where no cancellation functionality is provided, and operators gain control over both assets and shares during the pending window.
Cancellation is the more surprising omission. Because it is not mandated, an investor's ability to withdraw a request before it becomes claimable is an implementation choice. A vault can be fully ERC-7540 conformant while offering no way out of a pending redemption, which under stress is precisely when an investor wants one. This has to be checked per vault; the standard's name on a product says nothing about it.
Operator control is the more consequential. An investor with a pending deposit has parted with assets and holds no shares; one with a pending redemption has parted with shares and holds no assets. In both windows the operator holds the position, which makes operator selection a credit decision. The length of the pending window is therefore not just a service-quality question — it is the duration of an unsecured exposure.
What to establish per vault, not per standard
- Is cancellation implemented? If not, a pending request is irrevocable regardless of what changes while it waits.
- What bounds the pending window? A queue with no maximum duration is a redemption gate without the disclosure a gate normally carries.
- Who is the operator, and what happens if they fail mid-window? This is the exposure the standard explicitly declines to solve.
- How are queued redemptions ordered? First-in-first-out and pro-rata allocate stress losses very differently between investors.
- Do the on-chain terms match the fund documents? Cutoffs, valuation points and settlement periods should be identical, not merely similar.
For the fund type where these mechanics bind hardest, see tokenized money market fund compliance.
When ERC-7540 Is the Right Choice, and When It Is Not
Use it when the underlying genuinely cannot settle synchronously — a fund with a dealing cutoff, an asset requiring a compliance check before transfer, or a strategy whose liquidity is not continuous. In those cases ERC-7540 lets the contract describe what actually happens instead of forcing a misleading approximation.
Do not reach for it when the underlying can settle synchronously. If a vault holds continuously priced, continuously liquid assets, ERC-4626 remains simpler, has broader integration support, and does not introduce a pending window in which an operator holds investor positions. Asynchrony is a cost that a genuine constraint justifies.
Adoption gives some confidence in the implementation path. OpenZeppelin released a standardized implementation in Community Contracts on 23 July 2026 with the Tokenized Vault Foundation, whose standards underpin over $13 billion in TVL, with contributions from Centrifuge and Superform. Named production users include Centrifuge, running over $1.6 billion in RWA pools, alongside USDai, Nashpoint, Cove, Nest by Plume and Lagoon.
One caveat worth stating plainly. A standardized implementation from a reputable source reduces implementation risk; it does not touch the two exposures the specification itself flags, because those are design choices left to the deployer. A vault built on the OpenZeppelin contracts can still lack cancellation and still concentrate operator control, and reviewing the deployment is not optional because the library is well regarded.
For how permissioned standards have developed alongside this one, see the evolution of RWA token standards, and for the structural overview our institutional guide to RWA tokenization.
Frequently Asked Questions
What does ERC-7540 add to ERC-4626?
A mandatory two-step lifecycle. ERC-4626 assumes a vault can price and settle a deposit or redemption within a single transaction. ERC-7540, created 18 October 2023 and now Final, adds a request/claim flow with three states — Pending, Claimable, Claimed — that cannot be short-circuited. That lets a deposit wait on a compliance check or an incoming wire, and lets a redemption queue when demand exceeds available liquidity.
Why can a regulated fund not use ERC-4626 directly?
Because ERC-4626 requires the vault to know the exchange rate and settle at the moment of the call, and no regulated fund satisfies that. Subscriptions and redemptions are priced at a dealing point set by the fund's documentation, cash movement runs on banking hours, and investor eligibility may need checking before the transaction completes. A synchronous vault has to fake one of those, usually by pricing against a stale NAV.
What price does an investor actually get?
One that is not known when they commit. The specification states directly that shares received on deposit or mint may not be equivalent to the value of convertToShares(assets) at request time, because the price can change between request and claim. This mirrors forward pricing in conventional funds, where an order placed before a dealing cutoff is priced at the next valuation point rather than at the price displayed when it was submitted.
Can a pending request be cancelled?
Not necessarily. The specification's Security Considerations note that assets or shares can remain in a pending state indefinitely where no cancellation functionality is provided, because cancellation is not mandated by the standard. Whether an investor can withdraw a request before it becomes claimable is therefore an implementation choice, and it must be checked per vault rather than assumed from ERC-7540 conformance.
How much trust does the operator require?
Full trust over both legs. The Security Considerations state that operators gain control over both assets and shares during the pending period. An investor whose deposit is pending has parted with assets and not yet received shares, and one whose redemption is pending has parted with shares and not yet received assets. In both windows the operator holds the position, which makes operator selection a credit decision rather than a technical one.
Who is using ERC-7540 in production?
OpenZeppelin released a standardized implementation in Community Contracts on 23 July 2026 with the Tokenized Vault Foundation, whose standards underpin over $13 billion in TVL, with contributions from Centrifuge and Superform. Named production users include Centrifuge, which runs over $1.6 billion in RWA pools, alongside USDai, Nashpoint, Cove, Nest by Plume and Lagoon.
Related Articles
RWA Token Standards: A Complete Institutional Guide
The pillar covering token standards for regulated assets.
The Evolution of RWA Token Standards
How permissioned standards have developed since ERC-3643.
Atomic Settlement and DvP for Tokenized Securities
The settlement model async vaults deliberately depart from.
Tokenized Money Market Fund Compliance
The fund type most affected by dealing-cutoff mechanics.