NEVER set an allowance on the Settler contract. Doing so may result in unintended consequences, including potential loss of tokens or exposure to security risks. The Settler contract does not support or require token allowances for its operation. Setting an allowance on the Settler contract will lead to misuse by other parties.
ONLY set allowances on AllowanceHolder or Permit2 contracts, as indicated by the API responses.
The correct allowance target is returned in issues.allowance.spender or allowanceTarget.
In API v2, allowance management and swap execution are handled by different contracts.
/swap/allowance-holder) or Permit2 (/swap/permit2), depending on the approval method.issues.allowance.spender or allowanceTarget.data payload here./swap/permit2) or AllowanceHolder (/swap/allowance-holder), depending on the approval method.transaction.to.This separation enhances security by isolating allowance management from swap execution.
0x v2 is built on 0x Settler, a new set of smart contracts designed to enable the secure and continuous deployment of new features. 0x Settler uses Permit2 and the AllowanceHolder contracts to perform swaps without any passive allowances to the contract.
Learn more about 0x Settler. These contracts have been fully audited with four audits from three separate firms, including Ourovoros, Trail of Bits, OpenZeppelin, and Trail of Bits a second time.
For v2, we strongly advise against hardcoding any entry point contract addresses. These addresses are dynamic and depend on the current Settler deployment. Below are the recommended and alternative ways to obtain the latest Settler address.
transaction.toThis is the recommended and most reliable method.
The entry point contracts returned in the APIs as transaction.to (see the API reference) will always reflect the current Settler deployment automatically. No manual updates are needed.
You can query the on-chain Settler address registry directly to find the latest deployment by running this this code.
This is the same trustless data source used by the dashboard above.
This is an advanced and error-prone method. Avoid hardcoding any Settler address in your integration, as addresses can change with new deployments. For accuracy and maintainability, we strongly recommend using Option 1 to always get the latest Settler address automatically.
For a comprehensive list of all Settler addresses (past, current, and predicted next hundred), download the settler_predictions.tar.xz file here.
In the list, each chain includes the following address types:
AllowanceHolder is the default and recommended allowance contract for most integrators. It provides a better UX, lower gas costs, and is designed to minimize common integration pitfalls that can occur with using Permit2.
AllowanceHolder is recommended for most integrators, and it is especially well-suited for:
The AllowanceHolder contract sits in front of 0x Settler and maintains a one-way trust relationship.
When using the Swap API with AllowanceHolder, the AllowanceHolder contract is the allowance target (spender). It manages approvals while also serving as the entry point contract for executing swaps.
If the taker doesn’t have an allowance set to the contract, the AllowanceHolder contract address will be returned in the issues object. For example,
The AllowanceHolder contract has chain-specific addresses that can be safely hardcoded. Always verify with the official documentation before doing so:
0x0000000000001fF3684f28c67538d4D072C22734 — Cancun hardfork chains (Ethereum Mainnet, Arbitrum, Avalanche, Base, Berachain, Blast, BSC, Ink, Linea, Mode, Monad, Optimism, Plasma, Polygon, Scroll, Sonic, Unichain, World Chain)0x0000000000005E88410CcDFaDe4a5EfaE4b49562 — Shanghai hardfork chains (Mantle)Learn more in our AllowanceHolder integration guide and the AllowanceHolder example code.
Permit2 was developed by Uniswap, based on work from 0x alumnus Lawrence Forman. It provides a secure and efficient way to manage token approvals across multiple smart contracts. Permit2 is immutable, thoroughly audited, trusted by protocols like Uniswap, and backed by a $3M bug bounty.
Permit2 offers flexible approvals with features like time-limited and granular allowances. It can be powerful, but it introduces risks that new integrators must be careful with.
⚠️ Permit2 is for advanced integrators only.
Consider Permit2 if:
Note: Each trade requires two user signatures — one for limited approval and one for the trade itself. This is more complex to integrate but allows for features like time-limited approvals.
Permit2 is made up of two modules:
When using Swap API with Permit2:
If the taker hasn’t granted an allowance, the Permit2 contract address will be returned in issues.allowance.spender. For example:
For more details, see this Permit2 explanation.
Permit2 is deployed to 0x000000000022D473030F116dDEE9F6B43aC78BA3 across all chains. You can hardcode this address in your integration.
Learn more in our Permit2 integration guide and the Permit2 example code.