ERC-7540: Asynchronous ERC-4626 Tokenized Vaults

[DeeJayElly]

Fixes #????

📌 Summary

This PR introduces an implementation of ERC-7540, which extends ERC-4626 with asynchronous deposit and redemption flows. The contract provides the ability to request deposits and redemptions asynchronously, ensuring compliance with the EIP-7540 specification.

---

🔍 Changes Introduced

1️⃣ ERC-7540 Implementation

• Extends ERC4626 to support asynchronous deposits and redemptions.
• Introduces request-based flows via requestDeposit() and requestRedeem(), ensuring separation between pending, claimable, and claimed states.
• Implements claiming of assets/shares through the deposit() and redeem() methods.

2️⃣ Compliance with ERC-7540 Specification

✅ Request Lifecycle

• Introduces pendingDepositRequest(), pendingRedeemRequest(), claimableDepositRequest(), and claimableRedeemRequest().
• Ensures requests must transition from Pending → Claimable → Claimed, per EIP-7540.
• Implements cumulative requests (requests in the same block are merged).

✅ ERC-4626 Overrides

• deposit() and mint() do not transfer assets (they use requestDeposit() instead).
• redeem() and withdraw() do not burn shares (handled by requestRedeem()).
• previewDeposit(), previewMint(), previewRedeem(), and previewWithdraw() revert as required.

✅ ERC-165 Compliance

• Implements supportsInterface() to declare support for ERC-7540, ERC-7575, and ERC-165.
• Returns true for 0xe3bc4e65 (ERC-7540 operators) and 0x2f0a18c5 (ERC-7575 interface).

✅ Max Deposit / Redeem Logic

• maxDeposit() and maxRedeem() now return the claimable amount, ensuring correct behavior.

✅ Operator Management

• Implements setOperator() and isOperator(), allowing controllers to manage requests on behalf of others.

---

📜 References
ERC-7540 Proposal
ERC-4626 Standard
OpenZeppelin Vaults Documentation

PR Checklist

• Tests
• Documentation
• Changeset entry (run npx changeset add)

[changeset-bot]

🦋 Changeset detected

Latest commit: f3a616a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
openzeppelin-solidity	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Amxx]

I don't see any "coupling" between the 7540 function and the 4626 logic. I was expecting deposit/reddem logic to hook into 4626. When there is a "delayed option" (7540), should the "instantaneous option" (4626) be disabled ?

Right now, the requestDeposit/requestReedem operate on assets (transferFrom/_burn) without using any of the 4626 logic. That means:

• the exchange rate defined in 4626 is not considered
• the assets that are transfered/burn change the overall state of the vault, making 4626 operation use a bad rate.
• its possible/easy to miss doing the secound part (_mint/transfer)

Also, It would be interresting to have mock that show features of 7540 that go beyound what 4626 already support. For example, it would be nice to have a system where the exit (reedem) is hapenning like a vesting (automatic based on clock).

[Amxx]

This is not part of the ERC

[hieronx]

You can copy the interfaces that match the standard from here: https://github.com/foundry-rs/forge-std/pull/644/files#diff-39b5d73aa19abd1df539c3f24017dd6db331f8ef698e36a3495aa7cbe1ffc89f

[hieronx]

@DeeJayElly @Amxx nice to see work happening on the ERC7540 implementation.

I wonder though why you decided to not go with the approach proposed in #5294, and discussed in #4761 (comment)?

Specifically, having the flexibility of all 4 options:
A. Fully synchronous (IERC4626)
B. Asynchronous on deposit (IERC7540Deposit)
C. Asynchronous on redeem (IERC7540Redeem)
D. Fully asynchronous (IERC7540Deposit + IERC7540Redeem)

A lot of projects I've been speaking to require partial asynchronicity rather than full asynchronicity.

This is implemented in #5294 already through inheritance.

Also, this current implementation is generating request IDs which is not supported in standard ERC7540. This requires a future extension.