No ERC20 input support is implemented in V1. Its tested contract cannot be upgraded.
Current research
Primary sources reviewed: Universal Router command documentation, official V4Router source, Universal Router v4 adapter, Permit2 overview.
Universal Router exposes v3 exact-output operations and v4 swap actions, plus wrap/unwrap and settlement helpers. V4Router supports single/multi-hop exact-output and bounded debt settlement. This establishes building blocks; it does not establish that an arbitrary mixed v3/v4 route is atomic exact-output end to end, or that a particular USDC route is cheapest today. Current source has evolved beyond old deployed versions: select and verify a concrete deployment/commit before encoding anything.
WETH candidate
For a future router, transfer a bounded quantity of canonical WETH under a bounded allowance/Permit2 permit, unwrap only funding for the native-ETH POOL4 leg, buy exact IMD, and return all unused input in a documented currency. Verify canonical WETH code, approve/transfer semantics, callbacks, exact refund currency and forced/pre-existing balance isolation. No route comparison is needed to understand 1:1 wrapping, but implementation and fork validation are still required.
USDC candidates
- An all-v4 USDC/native-ETH/IMD exact-output path, if a verified sufficiently liquid first pool exists. Resolve every PoolKey and hook. Backward exact-output routing can derive the preceding hop's output from the final required debt.
- Mixed v3 USDC/WETH and v4 native-ETH/IMD. Two independently capped exact-output commands require an intermediate funding plan, unwrap/refund handling and proof of atomic failure. Buying a fixed guessed amount of WETH is not proof that exact IMD will be affordable. A custom callback-driven reverse dependency is more complex and expands security exposure.
- A production routing service may quote candidates but must not supply arbitrary executable calldata to a funds-holding contract. Restrict to audited typed routes and exact token/recipient/input bounds.
UNRESOLVED: live USDC candidate pool keys/fees/liquidity, verified deployed mixed-router semantics, current optimal route by size/gas, approval UX and ERC20-input fork tests. No safest or optimal USDC route is claimed. Benchmark candidates at fixed and latest blocks before implementing. Treat USDC issuer freeze/upgrade powers separately.
Permit2 signatures can be bounded by token, amount, spender, nonce and expiry. Permit2 still needs a token allowance where applicable; it is not inherently approval-free. Do not blindly reuse the SDK helper that grants unlimited approval. Avoid allow-revert command flags: any leg failure must unwind the whole acquisition and refund input without sweeping other users' balances.
One-click IdentityMD cooperation
True atomic admission is not achieved by forwarding tokens to payTo. A coordinated V2 would require IdentityMD to define an authenticated settlement/admission adapter, bind action/quote hash, payer, exact IMD, max input, expiry and replay protection to one reviewed authorization, and have its facilitator recognize verifiable router settlement.
An alternative smart-account batch can combine compatible on-chain steps, but current EOA-based x402 signatures and off-chain API admission still require support and failure/retry semantics. It cannot make off-chain admission magically atomic. IdentityMD must specify what happens if acquisition succeeds but admission fails, who sponsors gas, and how idempotency/refunds work. That is a proposed protocol change, not a V1 capability.