Deveab Blog

ERC-7540: Asynchronous ERC-4626 Tokenized Vaults

Written by

deveab

in

👉 Explore advanced DeFi strategies with asynchronous vaults

Abstract

ERC-7540 extends the ERC-4626 tokenized vault standard by introducing asynchronous deposit and redemption flows, called Requests. This enables non-atomic interactions for protocols requiring delays (e.g., cross-chain lending, liquid staking, or real-world asset vaults).

Key features:
– Asynchronous Requests: Submit deposits/redemptions without immediate execution.
– Backward compatibility: Fully integrates with existing ERC-4626 methods.
– Flexible implementation: Vaults can support async deposits, redemptions, or both.

Motivation

While ERC-4626 optimized synchronous yield-bearing tokens, its atomic limits hinder protocols with delayed settlement (e.g., insurance modules or undercollateralized lending). ERC-7540 addresses this by:
1. Allowing non-blocking deposit/redemption queues.
2. Preserving ERC-4626’s composability for claims.

👉 Learn how async vaults enhance DeFi scalability

Specification

Core Definitions

Term Description
Request Async intent to deposit (requestDeposit) or redeem (requestRedeem).
Claimable State where requests are executable via ERC-4626 methods.
Controller Address managing a request (may differ from asset owner).

Request Lifecycle

  1. Pending: Assets/shares locked post-request.
  2. Claimable: Vault processes the request.
  3. Claimed: User finalizes via deposit/redeem.

Mandatory Overrides

  • Async Deposit Vaults:
  • previewDeposit/previewMint must revert.
  • Assets transfer during requestDeposit, not claim.
  • Async Redemption Vaults:
  • previewRedeem/previewWithdraw must revert.
  • Shares burn during requestRedeem.

Key Methods

requestDeposit

  • Inputs: assets, controller, owner.
  • Behavior: Transfers assets to vault; emits DepositRequest.
  • Reverts if limits are exceeded or approvals fail.

requestRedeem

  • Inputs: shares, controller, owner.
  • Behavior: Locks/burns shares; emits RedeemRequest.

Operator Controls

  • setOperator: Grants third-party request management rights.
  • isOperator: Checks operator status.

Rationale

Design Choices

  1. No Short-Circuiting Claims: Ensures consistent integration patterns.
  2. Optional Flows: Vaults implement only needed async features.
  3. ERC-165 Support: Simplifies interoperability checks.

Security Considerations

  • Operators: Have full control over requests—approve trusted addresses only.
  • Pending Requests: May remain unfulfilled; implementations should mitigate stuck states.

FAQ

1. How does ERC-7540 differ from ERC-4626?

ERC-7540 adds non-atomic request queues while retaining ERC-4626’s claim mechanics, enabling delayed settlements.

2. Can a vault support both sync and async flows?

Yes. Vaults may implement async for deposits only, redemptions only, or both, falling back to ERC-4626 for unsupported flows.

3. Are pending requests yield-bearing?

Implementation-dependent. Async redemption requests may or may not accrue yield.

4. How are request IDs used?

They discriminate between request batches. ID 0 aggregates all requests per controller.

Backward Compatibility

Fully compatible with ERC-4626. Existing deposit/redeem methods now serve as claim functions for async requests.

Conclusion

ERC-7540 unlocks new DeFi use cases by decoupling request submission from execution. Its flexible design ensures seamless integration with existing infrastructure while addressing latency-sensitive protocols.

👉 Discover ERC-7540 vault implementations

Copyright and related rights waived via CC0.

More posts