Audit a 0x v1 integration before switching to v2

A 0x v1-to-v2 migration changes the adapter contract, not merely its hostname. Old assumptions can survive a successful HTTP request and still produce a wrong wallet action.

The official migration guide documents the unified API host with a chain parameter, the version header, renamed request fields, nested transaction fields and separate allowance models. Treat those changes as a review map.

Audit four boundaries

1. Request serialization: confirm the chain, taker and token fields are sent under the current names. Convert slippage with an explicit unit conversion.
2. Response parsing: read execution fields from the v2 transaction object and branch on liquidity availability before requiring them.
3. Authorization: distinguish the allowance spender from the execution destination. Retire assumptions about the old Exchange Proxy.
4. Signing: implement the chosen AllowanceHolder or Permit2 flow completely, including any required typed-data signature assembly.

Keep the migration behind a provider-version boundary. A mixed parser that accepts either top-level or nested calldata can mask incomplete migrations and makes incident diagnosis harder.

Compare meaning, not just JSON shape

Build fixtures describing the same hypothetical user intent under each adapter version. Compare chain, sell quantity, recipient, minimum received and authorized spender after normalization. The returned market price need not be identical for the migration to be correct.

Remove obsolete request options and defaults explicitly. An ignored field is particularly dangerous when the application still assumes it enforces a constraint.

Handle pending history separately

Existing transaction hashes remain historical records even after new quote traffic moves to v2. Preserve the adapter version that created each attempt. Stop creating old-version payloads without deleting receipts or confusing old approvals with permissions required by the new execution path.