Accessing RFQ liquidity on 0x API
This guide discusses what RFQ liquidity is, how it works, and how your project can apply to access it
In its role as a DEX aggregator, the 0x API integrates both on- and off-chain liquidity. On-chain liquidity is sourced by sampling smart contract liquidity pools, such as Uniswap and Curve. Off-chain liquidity is sourced from professional market makers via the 0x Request-for-Quote (“RFQ”) System.
If integrators request a standard quote from the 0x API, part or all of their quote may be sourced via the RFQ-T system. RFQ-T stands for “Request for Quote - Taker”. In this system, the 0x API aggregates quotes from professional market makers, alongside quotes from AMMs. If the market-maker quotes are more competitive than AMM quotes, they may be included in the final price shown to the end-user. The end-user’s liquidity is ultimately provided by a combination of AMMs and professional market makers. Everything happens under the hood!
Currently, the RFQ system is available only on Ethereum, but we anticipate releasing it to the other chains where the 0x API is already available, including Polygon, BSC, Avalanche, Celo, Fantom and Optimism.
The 0x API is configured with a list of API keys, issued to Trusted Takers, who are permitted access to RFQ liquidity. For the instance at
api.0x.org, the 0x team is maintaining a list of trusted integrators, which at this time includes such projects as DeFi Saver and Zerion, and of course 0x's own Matcha. This practice helps protect market makers from arb bots, and reduces 0x system load. There is also protection at the protocol level - RFQ orders contain a
takerAddressquery parameter. When an order containing this parameter gets hashed and signed by two counterparties, it is exclusive to those two counterparties.
RFQ market makers are never obligated to provide a quote. If they cannot provide a competitive price at a given moment, for example, they may decline to make an offer. Moreover, they may decline to respond for any reason at all. Because the taker address is always known to the market maker, the maker can easily monitor taker behavior over time. Makers can potentially identify arbitrageurs, by identifying specific taker addresses that seem to repeatedly take advantage of the maker's mispriced orders. And because the maker has the option to choose whether or not to respond to the quote request, they can easily blacklist taker addresses that they deem to be arbitrageurs. Furthermore, the request sent from the 0x API to an RFQ market maker also includes the API key associated with the trusted integration client. In the same way that makers can blacklist taker addresses, they also have the option to blacklist specific applications that integrate with the 0x API. In order to retain access to RFQ liquidity, it's important for clients of the 0x API to be good citizens of the marketplace. For end users of trusted integrations, being a good citizen means actually filling the orders they claim to intend to fill. And for trusted integrations, it means properly managing their users' intentions; more specifically, it means adhering to the flow of using indicative quotes by default, and firm quotes only when appropriate.
When a market maker provides a fillable quote, which can be settled by the 0x API or taker's submitting it to the 0x protocol, the taker has an expectation that the swap will actually settle, that it won't revert due to a lack of available maker assets. To uphold this expectation, makers will refrain from using those same assets as the basis for any other quotes, until the quote's expiry. However, if every price inquiry required the maker to reserve capital, they would quickly end up with all of their capital in reserve. They would then be unable to provide any other quotes until those outstanding quotes were either filled or expired. In order to improve capital efficiency, the RFQ system offers end-users both indicative pricing, and firm quotes; the latter are fillable.
The RFQ-T model introduces the distinction between "indicative pricing" and "firm quotes." In service of this distinction, the 0x API offers two different resources for the use of RFQ-T.
The indicative pricing resource is hosted at
/swap/v1/priceand responds with pricing information, but that response does not contain a full 0x order, so it does not constitute a legitimate transaction that can be submitted to the Ethereum network. Therefore, when a market maker services an indicative request they do not need to reserve any capital for it, leaving their capital available for other quotes to other clients.
The firm quote resource is hosted at
/swap/v1/quoteand responds with a full 0x order, which can be submitted to an Ethereum node by the client. Therefore it is expected that the maker has reserved the maker assets required to settle the trade, leaving the order unlikely to revert. Note that while the
/priceresource is new and specific to RFQ-T, the
/quoteresource is the same one already used to access non-RFQ-T liquidity through the API. In order to qualify for RFQ-T liquidity, the request must include the query parameter
intentOnFilling=true(in addition to the aforementioned
0x API clients should strictly adhere to a rule of using indicative pricing by default, and of only requesting firm quotes when the user is actually intent on filling. For example, a continuously updating price display on a web page should be fed by indicative pricing, and a trade confirmation display should be fed by firm quotes. Breaking this rule could lead to a maker noticing a specific integration consistently locking up their capital but never following through on trades, and thereby could lead to the maker blacklisting that integration. Again, in order to retain access to RFQ-T liquidity, it's important for integrated applications to be good citizens of the marketplace.
Whenever a 0x API client specifies a
/quoterequest, the API will validate the quote before returning it to the client, avoiding a number of possible causes for transaction reverts. (For more details, see "How does
takerAddresshelp with catching issues?".) However, given that a
takerAddressis required in order to obtain RFQ liquidity, and given that this requirement subverts the optionality of the quote validation feature, the implementation of RFQ-T introduced a new query parameter to the
skipValidation. When this parameter is set to
true, quote validation will be skipped. While validating even RFQ-T quotes is a best-practice recommended default, skipping validation can be useful in certain circumstances, such as when experimenting with a new maker integration deployment.
One particular circumstance in which it may be necessary to skip quote validation is that in which the
takerAddressrefers to a smart contract. In this case, the validation of the quote by the 0x API could fail due to a lack of asset balances in the contract's account. In order to avoid such a validation failure, simply avoid validation, by specifying
skipValidation=truein the query string of your
When requesting a quote from the 0x API, clients can choose to have the API exclude specific liquidity sources. (For more details, see the API specification.) At this time, RFQ liquidity is considered by the 0x API to be included within the
Nativeliquidity group. (In the API's interface, it's referred to as
0x, but in the underlying routing logic it's referred to as
Native.) Therefore, if a 0x API client intends to access RFQ liquidity, it's important that they not exclude the