-
Notifications
You must be signed in to change notification settings - Fork 11.9k
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
base: master
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: f3a616a The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
5dd9d86
to
9c8b97d
Compare
…ingDepositRequest/claimableDepositRequest
There was a problem hiding this 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 { |
There was a problem hiding this comment.
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
…ding a description
…ding a description
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
ERC4626
to support asynchronous deposits and redemptions.requestDeposit()
andrequestRedeem()
, ensuring separation between pending, claimable, and claimed states.deposit()
andredeem()
methods.2️⃣ Compliance with ERC-7540 Specification
✅ Request Lifecycle
pendingDepositRequest()
,pendingRedeemRequest()
,claimableDepositRequest()
, andclaimableRedeemRequest()
.✅ ERC-4626 Overrides
deposit()
andmint()
do not transfer assets (they userequestDeposit()
instead).redeem()
andwithdraw()
do not burn shares (handled byrequestRedeem()
).previewDeposit()
,previewMint()
,previewRedeem()
, andpreviewWithdraw()
revert as required.✅ ERC-165 Compliance
supportsInterface()
to declare support for ERC-7540, ERC-7575, and ERC-165.true
for0xe3bc4e65
(ERC-7540 operators) and0x2f0a18c5
(ERC-7575 interface).✅ Max Deposit / Redeem Logic
maxDeposit()
andmaxRedeem()
now return the claimable amount, ensuring correct behavior.✅ Operator Management
setOperator()
andisOperator()
, allowing controllers to manage requests on behalf of others.📜 References
ERC-7540 Proposal
ERC-4626 Standard
OpenZeppelin Vaults Documentation
PR Checklist
npx changeset add
)