This section is for Professional Market Making with RFQ Orders
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.
RFQ liquidity may be accessed in one of two ways:
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 show 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!
We also have another RFQ system, RFQ-M or “Request for Quote-Maker”. In RFQ-M, 100% of a user’s order is filled by a professional market-maker, and the user pays no gas or network fees. For trades above a certain threshold, RFQ-M typically provides better pricing than (AMMs + RFQ-T) because market makers are given last-look on the trade; when market makers do not have to worry about being arbitraged on stale outstanding quotes, they can quote more tightly. However, it is imperative that end-users take quotes quickly, or they risk being rejected on last-look because of underlying market movement. RFQ-M is an ideal route for end users who are looking to do substantial size, in a short timeframe.
RFQ-M is currently accessible by using “Gasless Trading” on Matcha. It will be available on other integrations, soon.
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.
In addition to the 0x API configuration identifying trusted takers, it also contains a list of specific market makers that participate in the RFQ system. Each maker is identified by an HTTP endpoint URL, and each endpoint has an associated list of asset pairs for which that endpoint will provide quotes. For the instance at
api.0x.org, the 0x team is maintaining a list of trusted market makers.
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. Finally, with the RFQ-M system, market makers have last-look on any quotes they issue, so it is impossible for an arbitrageur to pick them off on stale quotes. 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. For market-makers using RFQ-M, it means building a track record of honoring quotes that have been outstanding a short amount of time.
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.
In RFQ-M, Makers get last-look on quotes - if they approve last look, they can be 100% certain the trade will settle, so they don’t need to reserve capital until that juncture. Takers who wish to consume liquidity using RFQ-M should know that if they see an quote they like, they should act quickly to fill it - a volatile market move between the time the quote is issued and the time the taker looks to fill it, could result in the issuing market maker rejecting the quote on last-look. RFQ-M quotes can be accessed at with an http GET request to
/rfqm/v1/quote. To fill the quote, it should be quickly signed and sent as a POST to
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