ERC7540 Asynchronous ERC4626 Tokenized Vaults

ERC7540 extends the ERC4626 Tokenized Vault Standard by introducing asynchronous deposit and redemption flows, referred to as Requests. These flows allow vaults to handle delays that occur in real-world processes without blocking on-chain transactions. This is essential for RWA protocols where underlying assets often have non-instant settlement cycles, such as custody transfers, legal validation, NAV attestation, or bank wire processing.

Where ERC4626 assumes synchronous and atomic mint-and-burn operations, ERC7540 provides a framework for deferred execution while preserving ERC4626’s composability. A Request moves through distinct lifecycle stages:

1. Pending - The user submits a deposit or redemption request.
2. Claimable - Off-chain processing completes, and proof arrives (for example, an SPV confirms asset receipt).
3. Claimed - The request finalizes on-chain through a standard ERC4626 mint or burn operation executed by the user.

This pull-based design avoids untrusted or gas-expensive “push” mechanisms and ensures users always finalize outputs themselves, maintaining both safety and composability.

ERC7540 is implemented alongside ERC20, ERC165, and ERC7575 to enable modular extensions. It is already used in production by RWA platforms such as Centrifuge and UltraYield, where redemptions may involve T plus settlement, off-chain wire confirmations, or SPV-signed proofs. The standard also integrates cleanly with ERC3643 for compliant investor onboarding and transfer restrictions.

ERC7540 enables vaults to reflect the reality of RWAs, the world settles slowly, but blockchains expect atomicity. The standard bridges this gap by letting contracts remain composable on-chain while safely interfacing with asynchronous off-chain workflows.
 

Use of ERC7540 in RWA Contexts

ERC7540 is essential for RWA vaults that manage illiquid, regulated, or slow-settling assets. Traditional ERC4626 flows assume synchronous minting and burning, which breaks down when underlying assets settle on T plus cycles, require off-chain legal checks, or depend on custodial attestations. ERC7540 resolves this by decoupling request submission from fulfillment, enabling vaults to process deposits and redemptions asynchronously while preserving a transparent on-chain record of each request state.

For RWA developers, this model supports pull-based claim finalization, minimizes oracle dependencies, and makes hybrid on-chain and off-chain architectures feasible at scale.
 

Key Applications in RWA Development

Asynchronous Onboarding and Fractionalization

High-value or custody-gated RWAs (such as tokenized real estate, art, or credit portfolios) often cannot finalize deposits immediately.

• Users submit requestDeposit, placing funds into a Pending bucket.
• Custodians or SPVs verify the inflow off-chain (KYC, AML, subscription docs).
• Once approved, the request becomes Claimable, and the user calls deposit to mint shares.

This enables batch onboarding, protects against instant-liquidity assumptions, and avoids mismatched NAV accounting.
 

Delayed Redemptions and Liquidity Management

Assets like private credit or real estate cannot support T+0 redemptions.

• requestRedeem locks shares in a Pending state.
• The vault waits for appraisals or settlement proofs (for example, Chainlink NAV attestations).
• Claimable requests can be processed in order, with pro-rata fulfillment when liquidity is constrained.

This structure defends against bank-run dynamics and ensures fair treatment among simultaneous redeemers.
 

Cross-Jurisdictional Compliance

RWA flows often span multiple regulatory regimes.

• Integrate with ERC3643 to enforce whitelisting and accredited-investor rules.
• Requests can remain Pending until AML or KYC oracles validate the participant.
• Ideal for global funds operating across time zones and regulatory windows.
   

Integration with Yield and Oracles

Requests respond differently to yield accrual depending on their state:

• Claimable requests may grow in value as NAV increases.
• Pending requests usually do not accrue yield until custody confirmation.

Developers can override ERC4626 preview functions to enforce state-aware quoting and prevent misleading UI values. This is critical for investor disclosures and compliance reporting.
 

Developer Advantages in RWA Builds

• State Transparency: Public view functions such as pendingDepositRequest() or pendingRedeemRequest() enable real-time dashboards, essential for compliance under frameworks like SEC Rule 15c3-3 and MiCA.
   
• Extensibility Structured RequestIds allow batching by investor class, jurisdiction, or tranche. Institutional operators can manage requests on behalf of clients without sacrificing auditability.
   
• Risk Mitigation By splitting Request and Claim into separate calls, ERC7540 avoids atomic failure scenarios and provides cancellation paths for stuck requests. This is crucial when off-chain processes introduce uncertainty.
   
• Composability Finalization still calls standard ERC4626 functions, making asynchronous vaults compatible with Aave, Yearn, Uniswap LPs, and other DeFi primitives without wrapper contracts.

Centrifuge’s Tinlake architecture uses ERC7540-style request queues for invoice financing and credit-backed RWA pools. Redemptions remain in Pending state until borrower payments clear, enabling the system to scale beyond 500 million dollars in AUM without liquidity mismatches.

Developers should start from reference implementations published by the ERC4626 Alliance to ensure security, correct rounding, and alignment with best practices for async settlement.

The following sequence diagram illustrates an asynchronous redemption flow in an RWA vault, showing how shares are locked, off-chain settlement is performed, and the final claim is executed. This highlights ERC7540’s role in coordinating vault logic, custodians, and oracle attestations when dealing with illiquid or slow-settling assets.

Core Specification

ERC7540 vaults must implement the full ERC4626 interface, while overriding synchronous flows to support asynchronous behavior. The standard introduces Request-based operations for deposits and redemptions, enabling vaults to defer fulfillment until off-chain settlement, oracle attestations, or regulatory checks are completed.

In an asynchronous vault, synchronous previews such as previewDeposit or previewRedeem are expected to revert when a request-based flow is required. This enforces correct state transitions and prevents frontends from treating async vaults like synchronous ones. Assets or shares associated with Pending requests may remain locked until the claim window opens, at which point users finalize outputs through standard ERC4626 methods (deposit, redeem, withdraw).
 

Key Definitions

• Request the primary asynchronous entry or exit call, initiated through requestDeposit or requestRedeem.
• Pending The state representing a submitted request that is still awaiting off-chain actions (custody checks, wire confirmations, NAV attestations).
• Claimable The request has been processed and validated (often via an oracle or custodian signature) and is ready to be finalized through a synchronous ERC4626 method.
• Claimed The user completes the process by calling deposit, redeem, or another ERC4626 entry point appropriate to the request type.
• RequestId Unique identifier for a batch of requests. A RequestId of 0 denotes an aggregated “global” queue. Requests sharing the same RequestId are fungible, enabling batched settlement and pro-rata distribution.
• Controller The account that owns the request and is authorized to claim the output.
• Operator A delegated account permitted to manage requests on behalf of the controller, intended for institutional flows, custodial managers, or multi-signature operators.

ERC7540 vaults may implement asynchronous behavior for deposits, redemptions, or both, enabling flexible designs tailored to RWA settlement cycles, liquidity constraints, and regulatory workflows.

The ERC7540 standard introduces 10 additional functions (including required overrides) and 3 new events on top of ERC4626. These extensions define the full lifecycle of asynchronous deposit and redemption Requests. Below is the ABI-compliant interface, accompanied by RWA developer notes highlighting settlement, compliance, and NAV-integration considerations.

1// SPDX-License-Identifier: MIT
2pragma solidity ^0.8.0;
3
4import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
5import "./IERC4626.sol";  // Assumes ERC4626 base
6
7interface IERC7540 is IERC4626 {
8    // Overridden ERC4626 Functions (with controller param)
9    function deposit(uint256 assets, address receiver, address controller) external returns (uint256 shares);
10    function mint(uint256 shares, address receiver, address controller) external returns (uint256 assets);
11    function redeem(uint256 shares, address receiver, address owner) external returns (uint256 assets);
12    function withdraw(uint256 assets, address receiver, address owner) external returns (uint256 shares);
13
14    // Async Deposit Requests
15    function requestDeposit(uint256 assets, address controller, address owner) external returns (uint256 requestId);
16    function pendingDepositRequest(uint256 requestId, address controller) external view returns (uint256 assets);
17    function claimableDepositRequest(uint256 requestId, address controller) external view returns (uint256 assets);
18
19    // Async Redemption Requests
20    function requestRedeem(uint256 shares, address controller, address owner) external returns (uint256 requestId);
21    function pendingRedeemRequest(uint256 requestId, address controller) external view returns (uint256 shares);
22    function claimableRedeemRequest(uint256 requestId, address controller) external view returns (uint256 shares);
23
24    // Operator Management
25    function isOperator(address controller, address operator) external view returns (bool status);
26    function setOperator(address operator, bool approved) external returns (bool success);
27
28    event DepositRequest(address indexed controller, address indexed owner, uint256 indexed requestId, address sender, uint256 assets);
29    event RedeemRequest(address indexed controller, address indexed owner, uint256 indexed requestId, address sender, uint256 shares);
30    event OperatorSet(address indexed controller, address indexed operator, bool approved);
31}

Detailed Function Breakdown (with RWA Developer Notes)

requestDeposit(uint256 assets, address controller, address owner) Transfers the specified asset amount from the owner (via ERC20 approval) and places it into a Pending deposit queue. Emits DepositRequest.

• RWA relevance: Useful for tokenized T-bill or invoice vaults where off-chain verifications must occur before shares are minted.
• Batching: A requestId of 0 can aggregate deposits for group KYC or subscription cycles.
• Edge case: Assets typically do not accrue yield until they become Claimable.

pendingDepositRequest(uint256 requestId, address controller) Returns the amount of assets that are still Pending for the given controller.

• RWA relevance: Ideal for UI dashboards that track custodial settlement, bank wires, or NAV verification cycles. claimableDepositRequest(uint256 requestId, address controller) Returns the processed asset amount that is ready to be claimed via deposit or mint.
   
• RWA relevance: Used after oracle-fed NAV confirmations. Often increases maxDeposit because assets are now fully validated. 
  requestRedeem(uint256 shares, address controller, address owner) Locks or burns the specified shares and places the redemption into a Pending queue. Emits RedeemRequest.
• Operator support: Can be triggered by authorized managers without consuming allowances.
• RWA relevance: Core mechanism for redemption queues; prevents instant exits for illiquid credit or real estate.
• Edge case: Shares are removed from the owner immediately, which avoids double-use exploits. pendingRedeemRequest(uint256 requestId, address controller) Returns the number of shares still awaiting processing.
   
• RWA relevance: Commonly displayed on investor dashboards to monitor redemption backlogs. claimableRedeemRequest(uint256 requestId, address controller) Returns the shares that have been processed and are ready to be redeemed or withdrawn.
   
• RWA relevance: Enables pro-rata distribution when multiple users share a RequestId (for example, quarterly redemption windows). deposit(uint256 assets, address receiver, address controller) Finalizes a Claimable deposit request and mints shares. No asset transfer occurs here, since assets were already delivered during requestDeposit.
   
• Access control: Callable only by the controller or an approved operator.
• RWA relevance: The mint step typically occurs after KYC, AML, or subscription agreement checks. mint(uint256 shares, address receiver, address controller) Finalizes a Claimable deposit request for a fixed number of shares.
   
• RWA relevance: Useful for funds with predetermined share issuance schedules or tranche-based offerings. redeem(uint256 shares, address receiver, address owner) Finalizes a Claimable redemption and delivers the output assets. Burns shares if they were not pre-locked.
   
• RWA relevance: Often triggers or aligns with off-chain settlement flows, such as SPV-signed confirmations or investor wire transfers. withdraw(uint256 assets, address receiver, address owner) Mirror of redeem, but expressed in terms of assets rather than shares.
   
• RWA relevance: Allows variable-amount redemptions when NAV changes between request and claim. isOperator(address controller, address operator) Returns whether the operator is authorized to act on behalf of the controller.
   
• RWA relevance: Essential for institutional vaults where custodians, fund managers, or brokers act on the investor's behalf. setOperator(address operator, bool approved) Sets or revokes operator permissions for the caller. Emits OperatorSet.
   
• RWA relevance: Aligns with patterns from ERC6909 and enables multi-sig treasuries, fund administrators, or compliance officers to manage investor requests.
   

Reference Implementation

The ERC4626 Alliance maintains audited, production-grade reference implementations of ERC7540 in Solidity, These contracts extend solmate ERC4626 base and introduce state-tracking structures required for asynchronous flows, such as:

1mapping(uint256 => mapping(address => uint256)) public pendingDepositRequest;

The design is fully modular, allowing developers to enable asynchronous deposits, asynchronous redemptions, or both. The repository also includes invariant tests, fuzzing harnesses, and customizable fulfillment hooks for integrating oracle callbacks, settlement proofs, or SPV attestations. This makes it a robust starting point for RWA vaults that need to bridge on-chain logic with delayed off-chain settlement cycles.
 

Constructor and Setup

1import "@openzeppelin/contracts/token/ERC20/extensions/ERC4626.sol";
2import "./IERC7540.sol";
3
4contract AsyncRWAVault is ERC4626, IERC7540 {
5    mapping(uint256 => mapping(address => uint256)) public override pendingDepositRequest;
6    mapping(uint256 => mapping(address => uint256)) public override claimableDepositRequest;
7    // Similar for redeem...
8    mapping(address => mapping(address => bool)) public override isOperator;
9
10    constructor(IERC20 asset_) ERC4626(asset_) ERC20("Async RWA Vault", "aRWA") {
11        // Enable async flags if needed
12    }
13
14    // ERC165 support for detection
15    function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) {
16        return super.supportsInterface(interfaceId) || interfaceId == type(IERC7540).interfaceId;
17    }
18}

• Async behavior is opt-in, enabling flexible deployment architectures for mixed liquidity environments.
• supportsInterface ensures downstream protocols can detect asynchronous capability for safe integration.
• For RWAs, constructors typically initialize compliance registries, NAV sources, or settlement modules.
   

requestDeposit

1function requestDeposit(uint256 assets, address controller, address owner) public virtual override returns (uint256 requestId) {
2    if (msg.sender != owner) {
3        // Operator check
4        require(isOperator[owner][msg.sender], "Not operator");
5    }
6    SafeERC20.safeTransferFrom(asset(), owner, address(this), assets);
7    uint256 id = _generateRequestId(DEPOSIT_TYPE, controller);  // Custom gen (e.g., hash or counter)
8    pendingDepositRequest[id][controller] += assets;
9    emit DepositRequest(controller, owner, id, msg.sender, assets);
10    return id;
11}

• Uses the operator model for delegated flow, common for institutional RWA vaults where fund managers act on behalf of investors.
• RWA extension points: Insert compliance checks, reject unverified assets, and validate subscription agreements.
• RequestIds support batching for daily NAV windows or grouped investor onboarding.
   

claimableDepositRequest

1function claimableDepositRequest(uint256 requestId, address controller) public view virtual override returns (uint256) {
2    return claimableDepositRequest[requestId][controller];  // Pulled from internal fulfillment
3}

• Typically updated by internal or admin fulfillment functions after receiving settlement or NAV proofs.
• RWA oracles move amounts from Pending to Claimable once custodians attest that funds are settled.
   

Overrides for Async

1function deposit(uint256 assets, address receiver, address controller) public virtual override returns (uint256 shares) {
2    require(msg.sender == controller || isOperator[controller][msg.sender], "Not controller or operator");
3    uint256 id = _getActiveRequestId(DEPOSIT_TYPE, controller);  // Infer from state
4    uint256 claimable = claimableDepositRequest[id][controller];
5    require(assets <= claimable, "Exceeds claimable");
6    claimableDepositRequest[id][controller] -= assets;
7    shares = _convertToShares(assets);  // Post-fee/yield
8    _mint(receiver, shares);
9    emit Deposit(msg.sender, receiver, assets, shares);
10    return shares;
11}

• This is the claim step: funds are already held by the vault from the request.
• For RWA vaults, _fulfillRequest often checks a Chainlink or RedStone NAV update before marking the request claimable.
• _convertToShares should incorporate fee logic or NAV adjustments to avoid mispricing.
   

setOperator

1function setOperator(address operator, bool approved) public virtual override returns (bool success) {
2    isOperator[msg.sender][operator] = approved;
3    emit OperatorSet(msg.sender, operator, approved);
4    return true;
5}

• Enables institutional workflows: custodians, fund administrators, or delegated managers operate on behalf of investors.
• Mirrors design patterns from ERC6909 to support non-custodial delegation.
• For RWAs, often combined with compliance registries to limit who can be an operator.
   

Security Considerations

ERC7540 introduces asynchronous state transitions on top of ERC4626, significantly expanding the attack surface. Because async flows depend on delayed settlement, oracle callbacks, and administrative fulfillment, misalignment between on-chain and off-chain processes can lock capital, break invariants, or enable administrative abuse.

Below are the most critical security vectors to address.
 

State Transition Vulnerabilities

Asynchronous flows risk leaving requests stranded in the Pending state, especially when oracle updates fail, settlement data never arrives, or admins misconfigure fulfillment. In RWA vaults, this can trap millions in limbo.

Mitigations:

• Introduce timelocked fulfillment windows so requests cannot stall indefinitely.
• Support user-triggered cancellations, emitting events for off-chain claims or manual settlement.
• Maintain the invariant: pending + claimable == total requested, validated through Foundry invariants (included in the reference implementation).
• Avoid admin-only pathways that allow manual tampering without event logs.
   

Exchange Rate and View Manipulation

View functions such as pendingDepositRequest or claimableRedeemRequest represent informational estimates rather than binding oracle values. While flashloans cannot directly exploit them, stale or misleading views cause inaccurate UI quotes, poor redemption planning, and mispriced RWAs.

Mitigations:

• Treat view values as non-Oracle data in all frontends.
• Use time-weighted averages (TWAP) or oracle-backed NAVs during claim operations.
• Encourage dApps to rely on simulated calls instead of view-returned amounts for execution planning.
   

Reentrancy in Fulfillment Hooks

Callbacks triggered during state transitions, such as pending to claimable, are dangerous if they execute external calls (for example, oracle callbacks, admin fulfillments, or custodian attestations). Poor design allows malicious actors to exploit reentrancy to drain vault balances or corrupt the state.

Mitigations:

• Apply ReentrancyGuard to all fulfillment paths.
• Follow Checks-Effects-Interactions (CEI) strictly.
• Batch fulfillment operations to minimize repeated external calls.
• Include a fulfillment pause switch for emergency response, as recommended by multiple audits.
   

Fungibility and Pro-Rata Accounting Errors

In batched systems where multiple users share a RequestId, claimable outputs must be distributed pro rata. Incorrect arithmetic or rounding can dilute shares, over-allocate assets, or cause discrepancies in fund accounting, serious failures in regulated RWA settings.

Mitigations:

• Use OpenZeppelin’s Math utilities (mulDiv, tryAdd, etc.) for precise proportional calculations.
• Fuzz-test partial claims and multi-user scenarios to detect imbalance.
• Confirm that RequestIds behave as fungible buckets, not separate ledgers—a common source of spec misunderstandings.