ERC-8161 Transferable tokenized vault requests
Final · Vaults & DeFi · created 2025-02-12
An optional extension that allows deposit and redemption requests pending processing in an asynchronous vault (ERC-7540) to be transferred in whole to another address.
Why it is needed
In ERC-7540, the asynchronous tokenized vault standard, a deposit or redemption request remains in a Pending state once submitted until the vault processes it. This pending period can be long, and during it the request's owner (controller) has no way to move their pending position to another address. This is an obstacle for users who want to move their wallet to a new address, users who want to reallocate positions across multiple accounts, and protocols that want to build functionality on top of pending request positions. Previously, the only option was to cancel the request and resubmit it from the new address. This standard allows the pending request itself to be transferred, opening up secondary market liquidity for pending positions and simplifying account management.
In depth
Mandatory rules for transferDepositRequest
A vault supporting deposit request transfer MUST implement the IERC7540DepositTransferable interface. transferDepositRequest moves the entire pending deposit request balance for that requestId from oldController to newController. Only the Pending balance must be moved, and the Claimable balance MUST NOT be touched. On a successful transfer, pendingDepositRequest(requestId, oldController) must decrease by the transferred amount and pendingDepositRequest(requestId, newController) must increase by the same amount (minus any fee, if applicable). msg.sender must be either oldController themselves or an operator approved by oldController, and a TransferDepositRequest event must be emitted.
Mandatory rules for transferRedeemRequest
Vaults that support transferable redeem requests MUST implement the IERC7540RedeemTransferable interface. The rules are symmetric with the deposit side. The entire pending redeem request balance is moved from oldController to newController, affecting only the Pending balance while the Claimable balance remains unaffected. On success, pendingRedeemRequest(requestId, oldController) must decrease and pendingRedeemRequest(requestId, newController) must increase by the same amount (minus fees). The msg.sender restriction and the obligation to emit a TransferRedeemRequest event also apply.
ERC-165 Interface Identification
Contracts implementing this standard MUST implement ERC-165's supportsInterface function. A vault implementing IERC7540DepositTransferable MUST return true when interfaceID 0x53b3bb0a is passed in, and a vault implementing IERC7540RedeemTransferable MUST return true for 0x7846f5bd. Integrators can use these values to check in advance which transfer type a vault supports.
Why only Pending balances are moved
This standard deliberately limits the transfer target to the Pending state. The Claimable balance already has a fixed exchange rate and the controller can claim it at any time, so allowing it to be transferred too would add complexity without much benefit. Narrowing the scope to Pending simplifies the interface and avoids edge cases like partially claimable balances.
Why deposit and redeem are split into separate interfaces
Following the design philosophy of ERC-7540, which made the deposit flow and redeem flow each optional, this standard also keeps deposit transfers and redeem transfers as separate interfaces. A given vault may have good reason to allow only one side. For example, a vault might allow transfers of pending deposit requests whose assets are locked, while blocking transfers of pending redeem requests whose shares have already been burned or are tied to specific accounting treatment.
Only full balances transfer, no partial transfers
transferDepositRequest and transferRedeemRequest transfer the entire pending balance rather than letting a specific amount be specified. This keeps the interface simple and matches the ERC-7540 model in which requests sharing the same requestId are treated as fungible.
Compatibility with existing ERC-7540 vaults
This standard is fully backward compatible with ERC-7540. Vaults that do not implement this extension behave exactly as before, and integrators can detect support for the transfer functionality via ERC-165's supportsInterface. The source status is Final.
Things to watch out for
- Scope of operator authority: As with ERC-7540, an operator approved by the controller can transfer pending requests on the controller's behalf. Users should understand that granting operator authority also hands over the ability to move locked assets or shares to an arbitrary address, outside the controller's control.
- Pending requests have no reference price: Vault shares have an on-chain price reference via convertToShares and convertToAssets, but pending requests have no built-in pricing mechanism. The exchange rate is unknown until the request is processed. Anyone building a secondary market around transferable requests must account for the lack of an official price source in their pricing and settlement design.