0x Documentation
Searchโ€ฆ
Introduction
This section is for Professional Market Making with Limit Orders

RFQ System

An Exclusive Source of Liquidity

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:

RFQ-T

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!

RFQ-M

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.

Trusted Takers

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 takerAddress query parameter. When an order containing this parameter gets hashed and signed by two counterparties, it is exclusive to those two counterparties.

Dedicated Makers

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.
If you represent a trading firm that would like to add liquidity to the 0x ecosystem via the RFQ system, please get in touch here: 0x RFQ Interest Formโ€‹

Maintaining Trust

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.

Indicative Pricing & Firm Quotes

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.

RFQ-T

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.

Indicative Pricing

The indicative pricing resource is hosted at /swap/v1/price and 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.

Firm Quotes

The firm quote resource is hosted at /swap/v1/quote and 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 /price resource is new and specific to RFQ-T, the /quote resource 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-key and non-null takerAddress).

When to Request Firm Quotes

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.

RFQ-M

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 /rfqm/v1/submit.

Quote Validation

Whenever a 0x API client specifies a takerAddress in their /quote request, 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 takerAddress help with catching issues?".) However, given that a takerAddress is 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 /quote resource: 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.

Note for Smart Contract Integrations

One particular circumstance in which it may be necessary to skip quote validation is that in which the takerAddress refers 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=true in the query string of your /quote request.

Excluding Liquidity Sources

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 0x/Native liquidity 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 0x liquidity source.

Code Examples

Checkout our Guides for RFQT and RFQM Market Makers on how to create, hash, sign, fill, get state, and cancel 0x V4 RFQ orders