Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ERC-7540: Asynchronous ERC-4626 Tokenized Vaults #5457

Open
wants to merge 32 commits into
base: master
Choose a base branch
from

Conversation

DeeJayElly
Copy link

@DeeJayElly DeeJayElly commented Jan 24, 2025

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)

Copy link

changeset-bot bot commented Jan 24, 2025

🦋 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

Copy link
Collaborator

@Amxx Amxx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

* https://eips.ethereum.org/EIPS/eip-7540[ERC-7540]
*/
interface IERC7540 is IERC4626 {
struct Request {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not part of the ERC

@DeeJayElly DeeJayElly marked this pull request as ready for review January 30, 2025 09:46
@DeeJayElly DeeJayElly requested a review from Amxx January 30, 2025 09:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants