This ERC proposal extends ERC-7540 by allowing pending deposit and redeem requests to be transferred between controllers.
Problem: ERC-7540 async requests can sit in a pending state for extended periods. During that time, controllers are stuck, they can’t move their position to another address without canceling and resubmitting. This creates friction for wallet migrations, account restructuring, and any protocol that wants to compose on top of pending request positions.
This unlocks secondary market liquidity for pending positions and simplifies account management across the ERC-7540 ecosystem.
We’d love feedback from the community, particularly any security considerations we may have missed around operator trust and pricing of pending requests in secondary markets.
Hi.
To discuss, let me check this EIP’s purpose again.
In summary, is this draft EIP for “To remove the limitation of the liquidity which is based on the same demand“?
Yes, I understand.
So in usecase example, there are two vault dapps, and there is two pending requests, but cause of a certain accident, the one vault doesn’t work, but if ur proposed EIP applied, another one also can handle the request.
So from the liquidity perspective, it’s more flexible and workable.
Let me know my understanding is accurate or not, please.
A simpler example would be that say you have an stETH position and you wanted to exit that back into ETH.
At the moment you have two options,
a) Unstake in Lido and wait a few days to be redeemed at face value, or
b) Swap on an AMM and pay the slippage and AMM fees.
If you decide to unstake on Lido and its taking too long and you want the redemption sooner, this would open the door to allow you to find a buyer of that unstaking position and sell it to them in exchange for the instant liqudity.
This aligns well with cross-chain vault architectures where redemption requests originate on one chain but settle on another. In those systems, the pending request token effectively becomes a bearer claim that may need to travel across bridges before settlement
A few observations from that angle:
1.Stress-exit liquidity
The strongest case for transferability isn’t account restructuring — it’s letting users exit during degraded infrastructure states (bridge outages, oracle staleness, strategy locks) by selling their pending claim at a market-determined discount rather than waiting for the system to recover. This materially reduces trust assumptions on the operational layer.
2.Partial transfers
The spec restricts to full-balance transfers. For cross-chain redemptions where the pending amount may be large relative to available counterparty liquidity, partial transfers would enable better price discovery on secondary markets (sell 20% at 2% discount rather than the full position at 5%).
3.ERC-20 compatibility
Has the working group considered how request tokens could compose with existing token standards (ERC-20, ERC-6909) on top of the transfer interface?
Pricing hooks
The spec explicitly punts on pricing (“no built-in pricing mechanism”). For vaults with variable NAV or fee structures, an optional previewRedeemRequest(requestId) that returns the current expected settlement value would help secondary market makers price claims without relying on off-chain data.
Great observations — the cross-chain vault angle is exactly the kind of use case we had in mind when designing the transfer interface.
On stress-exit liquidity: Agreed, this is the strongest argument for transferability. Letting users sell pending claims at a market-determined discount materially reduces risk and increases composability.
On partial transfers: We intentionally left this out because it adds significant complexity for implementations. Transferring requests partially often means splitting up request IDs, which is non-trivial for many vault architectures. That said, this is straightforward to implement in a higher layer: transfer the request to an operator contract that issues a fungible token on top. Keeps the base spec clean while enabling the use case.
On ERC-20 compatibility: We envision a standardized ERC-20 and/or ERC-6909 token that supports any ERC-8161 vault, similar to how the ERC-4626 Router works. Ideally this becomes a community/public good project.
On pricing hooks: Most implementations won’t be able to price pending requests. For RWA use cases in particular, this pricing information simply isn’t available on-chain. Rather than adding an optional interface that only a subset of vaults can support, we think the better path (via ERC-165 detection) is a separate ERC dedicated to pricing pending requests. This lets that standard evolve independently.
The general design philosophy is to keep the base spec as minimal as possible so it works across the widest range of use cases.
Fully agree with the decisions to keep the spec minimal and behavior all-or-nothing.
A few small comments:
After a successful transfer, pendingDepositRequest(requestId, oldController) MUST decrease by the transferred amount and pendingDepositRequest(requestId, newController) MUST increase by the same amount.
^ this restricts the use case where the vault takes a fee, can maybe just add a simple “[newController] MUST increase by the same amount (less any fees).”
Additionally, the assets and shares parameters of the events may not be necessary. It can be inferred by the prior request event. It may be the case that more complex vault implementations with multiple requests sharing the same requestId could have a hard time calculating these values.
I don’t feel particularly strongly about either comment above but one or both may be helpful to include!