Treat transfer-tax tokens as a separate integration capability

A transfer-tax token can change the amount delivered between route steps. A quote engine and router must account for that behavior; increasing slippage alone does not establish support.

Model the capability

Mark whether the selected provider and execution path support the token's transfer behavior. Do not infer support because an API recognizes its address or returns a price. The 0x tax-support documentation describes provider-specific detection and metadata. Read those fields under that provider's schema rather than treating them as a universal tax oracle.

Distinguish input transfer tax, output transfer tax and fees charged by the swap service. They can affect different amounts and different recipients. An adapter that subtracts every reported percentage from the final output may double-count a charge already incorporated in the quote.

Validate the actual path

Simulate the executable transaction with the real sender and current state where possible. If the token changes its transfer rules by address or state, a previous successful simulation or a historical tax value may not describe the new transaction.

After execution, reconcile what the intended recipient received. The nominal route output and an intermediate Transfer event may differ from its usable balance change.

Unsupported is a valid result

If the engine cannot produce a supported route, stop with a clear unsupported-token or unavailable-route state. Do not remove protections until a transaction happens to pass.

Useful fixtures include a tax on the first transfer, a tax on the final transfer and a tax already reflected in a provider's output. Keep these separate from nonstandard boolean-return fixtures: the two issues can coexist, but they require different handling.