EIP-7540: Asynchronous ERC-4626 Tokenized Vaults

[0xfarhaan]

@joeysantoro

An operator param is better than an approval because the operator param is stored internally in the vault implementation as part of the same call. Requiring users and the vault to maintain a separate approval status for async pending deposits, async pending redeems, and internal shares (which are all not fungible with each other). Some vaults could require operator=msg.sender to remove this implementation complexity.

My main concern is with approvals an owner can revoke and give another operator the approval in order to process the redemption request. In the context of RWA assets redemption lead times could be hours to weeks if not longer and having the owner locked into a specific operator is problematic.

I see two potential ways forward, one is with approvals as already discussed or alternatively a nested mapping where the owner stores the operator e.g

function pendingRequestRedeem(address owner, address operator) returns (uint256 shares)

this way an owner can go back and change the operator that would service their redemption once it becomes claimable.

@joeysantoro

sure the LPs prefer this but is it economical or wise to allow the standard to acommodate the use case?

Too much optionality makes it impossible for integrating smart contracts to intelligently handle all use cases. Is it a two step deposit? what about withdrawals? can the vault push tokens to me at some random time?

Push per LP is generally expensive and intractable, and pull use cases scale much better. Higher abstraction layers such as EIP-712 signatures and smart wallets can handle the second step, but the standard should explicitly not allow this in my opinion.

That being said I am open to having it be allowed if there are better arguments that outweigh the negatives.

That is fine in our case we see using both but as long as the EIP requirement is fulfilled I don’t see any harm in protocols extending the standard further (lol) to support differing use cases.

If you folks need any help with writing the reference implementation let me know, Maple are heavy users of the 4626 vaults already (with async flows) and would be happy to contribute to getting this across the line.