This standard extends ERC-7540 by adding optional transferability of pending deposit and redeem Requests. It introduces two separate interfaces that allow a controller to transfer their pending Request balance to a new controller. Implementations may support either or both interfaces independently.
ERC-7540 asynchronous Requests can remain in the Pending state for an extended period of time. During this period, controllers have no way to transfer their position to another address. This creates friction for users who need to migrate wallets, restructure positions across accounts, or integrate with protocols that compose on top of pending Request positions.
By enabling transferability of pending Requests, this standard unlocks secondary market liquidity for pending positions and simplifies account management without requiring cancelation and re-submission of Requests.
Transferability is kept optional and split into two separate interfaces so that implementations can choose to support transferable deposit Requests, transferable redeem Requests, both, or neither, depending on their security model and use case.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Vaults that support transferable deposit Requests MUST implement the IERC7540DepositTransferable interface.
transferDepositRequestTransfers the entire pending deposit Request balance from oldController to newController for the given requestId.
MUST only transfer the Pending balance. Claimable balances MUST NOT be affected.
After a successful transfer, pendingDepositRequest(requestId, oldController) MUST decrease by the transferred amount and pendingDepositRequest(requestId, newController) MUST increase by the same amount.
msg.sender MUST be oldController or an operator approved by oldController.
MUST emit the TransferDepositRequest event.
TransferDepositRequestfrom has transferred their pending deposit Request of assets to to for the given requestId.
MUST be emitted when a pending deposit Request is transferred using the transferDepositRequest method.
Vaults that support transferable redeem Requests MUST implement the IERC7540RedeemTransferable interface.
transferRedeemRequestTransfers the entire pending redeem Request balance from oldController to newController for the given requestId.
MUST only transfer the Pending balance. Claimable balances MUST NOT be affected.
After a successful transfer, pendingRedeemRequest(requestId, oldController) MUST decrease by the transferred amount and pendingRedeemRequest(requestId, newController) MUST increase by the same amount.
msg.sender MUST be oldController or an operator approved by oldController.
MUST emit the TransferRedeemRequest event.
TransferRedeemRequestfrom has transferred their pending redeem Request of shares to to for the given requestId.
MUST be emitted when a pending redeem Request is transferred using the transferRedeemRequest method.
Smart contracts implementing this standard MUST implement the ERC-165 supportsInterface function.
Vaults implementing IERC7540DepositTransferable MUST return the constant value true when 0x53b3bb0a is passed through the interfaceID argument.
Vaults implementing IERC7540RedeemTransferable MUST return the constant value true when 0x7846f5bd is passed through the interfaceID argument.
This standard deliberately restricts transfers to the Pending state. Claimable balances already have a deterministic exchange rate and can be claimed by the controller at any time; transferring them would add complexity without significant benefit. Limiting scope to Pending balances keeps the interface simple and avoids edge cases around partial claimability.
Following the design philosophy of ERC-7540 where deposit and redemption flows are independently optional, this standard keeps deposit and redeem transferability as separate interfaces. A Vault may have valid reasons to allow transferability of one request type but not the other. For example, a Vault might allow transfer of pending deposit Requests (where assets are locked) but disallow transfer of pending redeem Requests (where shares have already been burned or locked with specific accounting implications).
The transferDepositRequest and transferRedeemRequest methods transfer the entire pending balance rather than accepting a partial amount. This simplifies the interface and aligns with the ERC-7540 model where Requests of the same requestId are fungible.
This standard is fully backward compatible with ERC-7540. Vaults that do not implement this extension continue to function as before. Integrators can detect support for transferability via ERC-165 supportsInterface.
As with ERC-7540, operators approved by a controller can transfer pending Requests on their behalf. Users must be aware that granting operator permissions extends to the ability to transfer pending Requests to arbitrary addresses, effectively moving locked assets or shares out of the controller's control.
Unlike Vault shares, which have convertToShares and convertToAssets as onchain price references, pending Requests have no built-in pricing mechanism. The exchange rate is unknown until fulfillment. Builders of secondary markets around transferable Requests should account for this lack of a canonical price source when designing pricing and settlement mechanisms.
Copyright and related rights waived via CC0.