ERC-7540: Asynchronous ERC-4626 Vaults
ERC-4626 assumes deposits and withdrawals settle synchronously in the same call. But many real-world vaults — RWA tokenization, off-chain CeDeFi strategies, restaking protocols with unbond periods — require asynchronous flow: user requests deposit, operator processes it after some delay, user later claims their shares.
Mechanics
| Phase | Methods |
|---|---|
| Request | requestDeposit(assets, controller, owner) |
| Process | (off-chain or admin call that fulfills pending requests) |
| Claim | deposit(assets, receiver, controller) (different overload from 4626 sync) |
The controller address can be different from the owner — useful when a custodian manages requests on behalf of the depositor.
Neo Equivalent
The Neo port stores pending requests in a per-user mapping and exposes the same request-then-claim flow as the Solidity demo. Production vaults can add operator batching on top of this request ledger.
Live on Neo TestNet
Both implementations are deployed on Neo N3 TestNet (network magic 894710606).
| Implementation | Contract Hash | Deploy Tx |
|---|---|---|
Solidity (neo-solc) | 0xd8838ba126e5a77727c673215782aec59f465b41 | (reused — see 0xd8838ba126e5a77727c673215782aec59f465b41) |
Neo C# (nccs) | 0xc2137b33423fdda8ce5a240e7feec8db2c4b626e | (reused — see 0xc2137b33423fdda8ce5a240e7feec8db2c4b626e) |
Checked-in snapshot matches on initial counts; the manifest now also exercises request recording, pending deposit amount, and claim count. Source pairs under docs/standards-mirror/deployments/erc-7540/.
