The new fees aren’t live yet. This guide helps you prepare for them. The current API still charges 0%, and you can’t enable the new tiers through a request parameter.
1. Separate the three amounts
Your interface should distinguish:
- Gross output: final output before Route’s fee.
- User output: final output after Route’s fee, before gas.
- Modeled net value: user output minus estimated gas converted to the output token.
The signed minimum must protect user output. Do not use the gas-adjusted value as the onchain token minimum. Do not subtract a provider fee twice when its returned output already includes that fee.
Current quote and preparation responses expose grossAmountOut, amountOut, protocolFeeBps and feeAmount, but their schema enforces zero Route fees. execution.amountOut is a separately assessed result; it may differ from the earlier estimate. A fee-bearing release must document how its fee breakdown relates to that assessed result before integrators combine these fields.
2. Calculate the fee
Use this helper to preview the output fee. It only calculates amounts; it doesn’t build a transaction or charge a fee.
At 10 bps, 1,000,000 output base units gives a fee of 1,000 and leaves 999,000 for the user. Keep amounts as integers until you format them for display. This example covers fee rounding only; routing and gas can also change the final result.
3. Let the server choose the tier
The server follows these rules:
- Validate chain and token addresses against reviewed metadata.
- Apply approved same-peg, ETH/stablecoin and LST/stablecoin rules.
- For other pairs, apply 50 bps only when trusted creation evidence establishes an age strictly below 24 hours; otherwise use 10 bps.
- Produce a single decision for the complete swap and preserve it through review and preparation.
The policy and API integration have been built locally. Before the new-token tier can work automatically, we need verified creation records on the server. More asset categories also need review. Clients can’t choose their own fee category through the API.
The approved fee destination is Safe 0x3b9C7bC09FF64F554480f30Ad40286cFc09d2F80. The upcoming collector pays it directly in the final output asset. Do not send these fees to the creator-fee flywheel or assume they are automatically used for buybacks.
4. Check what the transaction will do
Before asking the user to sign, verify the exact input, recipient, minimum after fees, deadline, fee rate, fee recipient and policy. Use the published contract ABI and schema when the release goes live. The contract must enforce those terms, along with its existing approval and callback checks. Only use documented fields and verified contract addresses.
Apply the fee once when rebuilding provider transactions. Compare what the user gets after Route fees and gas, then simulate the full transaction from their wallet after approval.
5. Migrate clients with the release
Once the new schema and verified deployment are available:
- Regenerate typed clients from the released OpenAPI and check the updated fee rules.
- Resolve output-specific executors from configuration and require a new spender review when needed.
- Replace zero-fee assertions with validation of the documented fee schedule, arithmetic and signed terms. Do not just remove the assertions in the current recipe.
- Display expected user output, Route fee and minimum before confirmation. Rebuild and request a new review if the fee or spender changes while the user is approving.
- Validate the released receipt events and actual recipient/fee payments. Do not assume a
FeePaid event exists before the ABI defines it.
Do not relabel historical 15 bps contracts as the new tiered release or reuse a prior approval for a different executor. Follow the fee rollout status and changelog for the reviewed deployment and API release.