EIP-7540: Asynchronous ERC-4626 Tokenized Vaults

21

Then it would be great to explicitly specify it in the section ERC-7540: Asynchronous ERC-4626 Tokenized Vaults that redeem flow is not backward compatible .

23

Update log

  • 2024-12-03: Event names were fixed, PR #670
24

requestRedeem and redeem both expect the argument shares.

Assume the following situation that Alice calls requestRedeem 3 times with shares 30, 50, 20 respectively which makes total shares requested to redeem = 100.
Also assume that requestRedeem returns 0 as request id.

ERC7540 says:

When requestId==0 , the Vault MUST use purely the controller to discriminate the request state. The Pending and Claimable state of multiple requests from the same controller would be aggregated.

This means that in redeem, we must redeem all claimable shares. The confusing thing now is that what if alice passes 80 as shares. This would mean that she only wants to redeem assets of 80 shares, which kind of goes against the ERC7540 specification statement about request id = 0.

What should the decision be here so the code still obeys the ERC7540 specification ?

25

This EIP is one of the biggest mistakes ever. Forcing 4626 backwards compatibility is same as if the car manufacturers decided to put actual horses into cars. There is no point and I did not see a single implementation that retains this backwards compatibility without being hacky and breaking 4626.
We need a new standard for async vaults, otherwise we will have to endure tons of problematic code in the future.

26

The aggregation rule under requestId == 0 reads naturally if you treat the controller’s pending balance as a single pool. Under that reading, redeem(80) is a partial redemption of the 100 claimable shares, leaving 20 still claimable. The spec doesn’t say partial redemption is forbidden, only that pending and claimable states are aggregated, and the existing redeem(shares, receiver, controller) signature already accommodates the partial case because the caller specifies the share amount.

The case where this gets uncomfortable is if implementations have any per-request state that survives aggregation. For example, if request 1 (30 shares) and request 2 (50 shares) settled at different exchange rates, the assets owed for redeem(80) depend on which shares you treat as redeemed. Aggregation papers over this by treating the controller’s claimable balance as a single pool with a single effective rate, which I think is the only consistent interpretation, but it’s worth saying explicitly in the spec because implementers will otherwise have to invent FIFO or LIFO conventions on their own.

This thread is part of why I’ve been working on an alternative async-vault representation that uses per-request NFTs instead of aggregated controller balances. The aggregation ambiguity @giorgilagidze is pointing at is one of the things that disappears when each request is a distinct on-chain object: there is no “which 80 of the 100 shares” question because each receipt has its own amount, mint timestamp, and (if applicable) settlement rate.

I’m not posting to suggest 7540 should change. The receipt model is suited to retail flows where the pending position should be wallet-visible and composable as a primitive; 7540 fits programmatic and institutional flows where the aggregation is a feature rather than a problem. The two are complementary.

For anyone interested, the proposal is here:
https://ethereum-magicians.org/t/erc-receipt-nfts-for-asynchronous-erc-4626-vaults/28529

Feedback from the 7540 contributors would be especially valuable since you’ve already lived through the design questions a successor standard would have to answer :folded_hands: