Implement ERC-7540

[Amxx]

ERC-7540 is in the review phase, and looks like a good candidate for inclusion.

[mw2000]

@Amxx I'd love to help with this

[mw2000]

Added a Draft PR
#4776

I'm still unsure about how to approach overriding deposit, redeem, withdraw, and mint functions.

[Amxx]

I'm still unsure about how to approach overriding deposit, redeem, withdraw, and mint functions.

This is exactly why this issue needs to be discussed and researched BEFORE we make any PR. As the tag shows, this is this only an idea. We may not even do that at all.

One thing we need to figure out is the process for going from pendingDepositRequest to maxDeposit. Because the deposit function should consume the maxDeposit, NOT the pendingDepositRequest.

Please do not rush to propose implementations. The ERC is still in draft, and we need to hear from (multiple) potential users before we start designing an actual solution.

[0xTimepunk]

Any updates on this? Superform.xyz is a cross-chain yield marketplace building on top of ERC4626 standards and now ERC7540 for asynchronous vaults. We could use a reference implementation from OpenZeppelin

[mw2000]

@Amxx @0xTimepunk more than happy to pickup where we left off on this PR, once we have designs mapped out.

[alphastorm]

The ERC was finalized two days ago 🎉

cc @Joeysantoro

[yorhodes]

@alphastorm @Joeysantoro @mw2000
I am very interested in a reference implementation for this which composes with the rest of the OpenZeppelin ERC20/4626 lifecycle hooks

[kevin-pv01]

We'd be interested in using 7540 if there was an OZ reference implementation.
Do we know if any work on this is planned?

[TalCrypto]

Any update on this implementation?
I represent logarithm.fi and we are building an asynchronous redeem vault now.
Would be happy if there were some OZ references.

[zjesko]

same, would love to have a OZ reference (or any other) for buildling trading vaults

[mw2000]

@zjesko @yorhodes @kevin-pv01

There's a reference implementation in this repo (thanks to @TalCrypto for mentioning) -> https://github.com/ERC4626-Alliance/ERC-7540-Reference

Alternatively, I plan to sharpen up my old implementation in the #4776 PR, if there's demand for it. I would love to get input on what you guys want to see in a reference implementation, especially if the other implementation is not a good fit.

[hieronx]

Just wanted to share my thoughts here after developing the above mentioned reference implementation + our implementation at Centrifuge (https://github.com/centrifuge/liquidity-pools/blob/main/src/ERC7540Vault.sol).

I think there is a few points of discussion that should be decided upon first, before implementing the full OpenZeppelin version. I'll list what I think those are here:

Vault classes support

You can categorize vaults in 4 classes:
A. Fully synchronous (IERC4626)
B. Asynchronous on deposit (IERC7540Deposit)
C. Asynchronous on redeem (IERC7540Redeem)
D. Fully asynchronous (IERC7540Deposit + IERC7540Redeem)

A is already supported by https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC4626.sol

The main use case I see for C is Liquid Staking Tokens (LSTs).

Most RWA vaults (like Centrifuge) are likely D.

I would propose, similar to https://github.com/ERC4626-Alliance/ERC-7540-Reference/tree/main/src, to support all 4 classes through contract inheritance.

Request fulfillment methods

I can roughly think of 3 groups of methods for fulfilling requests:

1. Manual per user: an admin controlled function needs to be called to fulfill a request for a specific user. This is the case for most RWAs.
2. Batched: there is some grouping of requests (e.g. based on a time window) and each batch of requests is fulfilled manually by an admin controlled function
3. Time-based: LSTs are a good example, where the redemptions are fulfilled with e.g. a 7 day delay

In my opinion, batched fulfillments will likely be highly custom per implementation, and hard to generalize through an OpenZeppelin reference implementation (beyond the basic building blocks of ERC4626)

I would propose implementing the base OZ implementation as 1, and allowing the fulfillment method to be virtual to support custom implementations.

This can also support 3, by overriding the fulfillment method to be permissionless if the time delay has passed.

ERC-7575 support

ERC-7540 enforces that each implementation also supports ERC-7575. This can be simply done by adding

function share() external view returns (address) { return address(this); }

to the contract.

I would propose adding this to the standard ERC-4626 contract. It is a helpful addition to any ERC-4626 implementation, that can support the multi-asset vault use cases in the future (potentially through a future OZ reference implementation building on ERC-4626). And ERC-7540 will inherit from ERC-4626 contracts thus then automatically inheriting the ERC-7575 support.

Implementation

I actually had started porting over the reference implementation linked above to the OZ repository, see this branch: https://github.com/hieronx/openzeppelin-contracts/blob/erc7540/contracts/token/ERC20/extensions/ERC7540.sol I haven't yet had time to take this further yet. @mw2000 if you want to do this, happy to support you!

I would say the above questions should be agreed here in the thread first, before continuing with the implementation.

@zjesko @yorhodes @kevin-pv01 @TalCrypto @Amxx curious on your thoughts!

[TalCrypto]

I totally agree on your thoughts @hieronx.
Your classifications cover everything that is needed to implement ERC7540.
The fulfillment methods are really dynamic based on protocols' needs.
For example, we are building AsyncRedeemVault and the fulfillment method is batched one.
Due to this specific requirement, I can't find any reference on this.
We've already built it by adhering ERC4626, but it requires additional funcions beyond the standard to withdraw.
Anyways, I will try to adhere ERC7540, and then will share my implementation here.
Thank you for bringing up this topic here @mw2000

[mw2000]

@hieronx happy to take it over if it's still in flight :)

[0xCSMNT]

Excellent proposal @hieronx

We are currently building a fully asynchronous vault per model D you described above:
https://www.nashpoint.fi/

On your suggestions:

• Having 4 separate classes that can be combined via inheritance is the correct approach IMO.
• We are also implementing manual fulfilment per user, as that is the most straightforward approach and I recommend using it for the reference implementation.

Our project invests in RWA protocols and will launch early next year. Having a reference implementation by OZ will be an enormous help to us as we work with teams to build out integrations, and will be a massive benefit to the RWA ecosystem.

Well done for leading the charge for standardization!

[hieronx]

Thanks all for the feedback!

I've pushed the setup for the proposal above here: #5294 It is based on the existing reference implementation, supports vault classes B, C and D separately through inheritance, and implements manual fulfilment per user.

@mw2000 if you want to take over the implementation, that would be great.

It would be ideal to get some feedback on the design of the ERC7540 implementation from the maintainers (cc @Amxx and anyone else) before too much time is invested in implementing one approach.

[hieronx]

@Amxx was wondering if you have any feedback on this design proposal? Would love to move forward on this as there is a lot of requests for a reference implementation for this standard.

[Amxx]

We didn't really got time to review that latelly. Our focus has been on very different stuff for DevCon and 5.2.

I'm adding that as a candidate for the next release.

[hieronx]

Sounds good! Happy to contribute in any way I can to this.