Implement the 0x AllowanceHolder swap path

The AllowanceHolder path provides a conventional transaction-based 0x integration. Use its own endpoints and response fields throughout instead of combining v1 examples or Permit2-specific steps.

The official quickstart sequences indicative price, allowance setup, firm quote and transaction submission. The v2 response nests executable fields inside transaction.

Build a narrow adapter

Normalize chainId, sellToken, buyToken, sellAmount and taker from the reviewed request. Keep integer amounts as strings and send the documented API authentication and version headers from the appropriate server boundary.

Parse liquidity and issue state before reading transaction fields. If the account lacks the input balance, keep browsing available but block execution. If allowance is insufficient, resolve the intended spender under 0x's contract rules, request permission and wait for confirmation.

Refresh at the execution boundary

After approval, obtain a fresh quote for the same current request. Match token identities, account and chain. Preserve transaction.to, transaction.data and transaction.value as a coherent payload, then simulate and estimate fees.

The wallet owns the final authorization. A rejection returns to review; a hash moves the attempt to pending. Reconcile a receipt and actual output before marking completion.

Test provider-specific failure states

Use fixtures for unavailable liquidity, insufficient allowance, insufficient balance, incomplete simulation and a transaction carrying native value. Include an unexpected response version so the adapter fails closed rather than reading top-level fields from an old schema.

This outline follows the retrieved v2 documentation and describes an implementation approach. It does not claim that a live swap was executed or that every wallet, token and chain combination has been tested.