ERC-7540: Asynchronous ERC-4626 Tokenized Vaults

Extension of ERC-4626 with Asynchronous Deposit and Redemption Support

Abstract

ERC-7540 extends ERC-4626 by introducing asynchronous deposit and redemption flows, termed Requests. This standard enables non-atomic interactions with tokenized vaults, accommodating use cases like cross-chain protocols, liquid staking, and real-world asset integrations.

Key Features

Asynchronous Requests: Supports requestDeposit and requestRedeem for deferred transactions.
Backward Compatibility: Fully interoperable with ERC-4626 synchronous methods (deposit, mint, redeem, withdraw).
Flexible Implementation: Vaults may opt for async deposit, redemption, or both.
ERC-165 & ERC-7575 Compliance: Mandates interface detection and share accounting standards.

Specification

Core Definitions

Request: A deferred action (deposit/redemption) initiated via requestDeposit or requestRedeem.
Pending State: Request submitted but not yet claimable.
Claimable State: Request fulfilled; user may execute deposit/redeem to claim assets/shares.

Method Overrides

Async Deposit Vaults:
- deposit/mint skip asset transfers (previously handled in requestDeposit).
- previewDeposit and previewMint always revert.
Async Redemption Vaults:
- redeem/withdraw skip share transfers (handled in requestRedeem).
- previewRedeem and previewWithdraw always revert.

Workflow Example (Deposit)

Pending: User calls requestDeposit(assets, controller, owner).
Claimable: Vault internally fulfills the request.
Claimed: Controller calls deposit(assets, receiver, controller) to receive shares.

👉 Explore advanced vault strategies for optimizing async flows.

Rationale

Design Choices

No Short-Circuiting: Claims require explicit user action to avoid integration ambiguity.
Optional Flows: Flexibility to support sync/async hybrid models.
ERC-165 Integration: Simplifies vault type detection during integrations.

Security Considerations

Operator Risks: Operators control both assets and shares—approvals require trust.
Pending State Risks: Implementations should mitigate stuck requests via fungibility or cancellations.

FAQs

Q: Can a vault support both async deposit and redemption?

A: Yes. ERC-7540 allows implementations to choose one or both async flows.

Q: How are exchange rates determined for async claims?

A: Rates are vault-specific and may differ from the initial request time.

Q: Is ERC-4626 compatibility preserved?

A: Absolutely. Sync methods remain unchanged, with async flows as opt-in extensions.

👉 Learn more about vault interoperability in DeFi ecosystems.

Reference Implementation

// Simplified pseudocode  
function requestDeposit(uint256 assets, address controller, address owner) external {
    asset.transferFrom(owner, address(this), assets);  
    pendingDepositRequest[controller] += assets;  
    emit DepositRequest(controller, owner, 0, msg.sender, assets);  
}  

function deposit(uint256 assets, address receiver, address controller) external {
    claimableDepositRequest[controller] -= assets;  
    uint256 shares = convertToShares(assets);  
    _mint(receiver, shares);  
}

For full implementation details, refer to the ERC-7540 EIP.