Tx Relay FAQ
What chains will Tx Relay be on?
Through 2023, Ethereum Mainnet and Polygon….more chains to come
What pairs are supported?
Tx Relay aggregates liquidity from 29 sources on Mainnet, and 24 sources on Polygon. A comprehensive set of liquidity sources is available here. Users will have access to any pair supported by those liquidity sources.
The only trades Tx Relay CANNOT support on those wherein the end-user is trying to sell a native token from their wallet (eg: selling ETH for USDC, on Mainnet). This is because native tokens are typically not ERC-20s, so they do not support the
transferFrom function, which the metatransaction relay system underlying Tx Relay utilizes.
Who pays for the gas fees to allow those swaps to happen?
Gas fees are paid by 0x, but a fee to cover the gas costs are included by default to the end user. In other words, while the gas is technically paid by 0x, users will cover the costs in terms of fees. An application may choose to sponsor transactions, in which case they will pay 0x directly, and users will not be billed on chain
Why is the support limited to some tokens?
For gasless swaps, we support all tokens that Swap API supports on Polygon, while we currently only support tokens on the Uniswap Token List on Ethereum. Gasless approvals, however, depend on the token's support (generally, for EIP-2612). You can find the list of tokens supported for gasless approvals here.
What if my user wants to sell a native token, eg: swap ETH for USDC, on Mainnet?
In this case, we’d recommend using the Swap API, wherein the user will pay for the gas of the transaction, with the chain’s native token. Otherwise, you can recommend your users to wrap their ETH into WETH (or equivalent, in other chains).
What tokens work with gasless approvals?
See the list of tokens in the gasless approvals token list.
You can also examine a token’s eligibility at trade time, by observing the response from requests to
/tx-relay/v1/swap/quote. If the variable
true, the token the user is selling supports gasless approvals.
What if my user is selling a token that doesn’t support gasless approvals?
In this case, your user would need to do a standard approval transaction with the 0x Protocol. If you user doesn’t have sufficient native token to pay for the approval transaction, she can use Tx Relay to swap a popular token (eg: USDC) for ETH (or the equivalent native token) on Mainnet, Matic on Polygon, etc. Please note that the approval transaction is a one-time transaction for each new token the user sells. Once the approval transaction is mined, the user can still do gasless swaps with that token.
To perform a standard approval, your user would need to (or your frontend should prompt the user to) submit an approval transaction for the token the user wants to trade (
approve(address spender, uint256 amount) → bool method defined by ERC20, with
spender set to the address of 0x Exchange Proxy and
amount being at least the amount the user wants to trade. Do note that the smaller the
amount is, the more frequent the user has to perform the standard approval step)
Some UIs may choose not to support tokens that do not support EIP-2612 to be able to guarantee a 100% gasless experience. However, Tx Relay does not limit anyone in this manner and is strictly a choice of the developer.
How do I know if an approval is required?
Tx Relay can check whether an approval transaction is necessary, although the check worsens latency.
To perform the check, please ensure that the parameter
checkApproval is set to
true, in requests to
/tx-relay/v1/swap/quote. Tx Relay will check to see if your user has previously set the allowance for you. If the allowance is non-existent, or too low, we require an approval transaction, and
true will be returned in the response.
true only when necessary.
My user is doing a swap and needs an approval - are these separate transactions? Do I need 2 signatures?
Although gasless approvals and gasless swap are bundled in the same transaction, they each require a signature for the corresponding EIP-712 object. However, you may elect to create a front-end experience wherein it appears to the user that they are signing only 1 transaction.