A crypto RFQ firm quote offers executable terms for a specified trade while that quote remains live and its conditions are met. An indicative quote is a pricing estimate that still needs executable confirmation. Before submitting an acceptance, verify the quote identity, instrument, side, size, fees, expiry rule and any last-look policy. A displayed price or an acknowledgement of an acceptance request alone does not establish a completed trade.
An RFQ, or request for quote, asks a liquidity provider to price a particular transaction. The response may be a preliminary indication, an executable offer or a package containing several legs. The useful question is whether the response matches the exact transaction you intend to authorize and what evidence will prove execution.
Indicative and firm quotes answer different questions
An indicative price can help establish whether a transaction is worth preparing. It might reflect a model, recent market conditions or an estimate for a proposed size. It does not itself reserve that price for an acceptance attempt.
A firm quote moves the process toward execution: it supplies terms that can be accepted through the provider's supported mechanism. Its executable status still depends on its scope and current validity. Calling something firm does not explain the venue's cancellation rights, balance checks or settlement requirements.
The distinction appears explicitly in 0x's Swap API quickstart. Its indicative /price response supplies pricing information without creating a full order or transaction. Its /quote response supplies an order ready to submit to the network. These endpoint meanings belong to 0x; other providers can use different names and protocols.
| Question | Indicative response | Firm response to verify |
|---|---|---|
| Can this price be accepted? | A fresh executable quote is still needed. | A supported acceptance mechanism exists. |
| What size does it cover? | The estimate may depend on a proposed amount. | Exact quantity or permitted fill range is specified. |
| How long does it last? | Its observation time describes freshness. | An expiry and any cancellation rules govern validity. |
| What proves a trade? | The indication proves no execution. | A trade confirmation or authoritative execution record is needed. |
Order-book estimates answer another question: what quantity might be available across price levels. The market-order slippage-cap guide explains price bounds for that execution path. An RFQ comparison starts with the terms attached to each particular offer.
Identify the ticket behind the price
Keep the RFQ identifier separate from the maker's quote identifier and the resulting trade identifier. One request can receive several quotes, and a refreshed response may replace earlier terms. A price of 60,040 without its identity and scope is insufficient evidence for an acceptance instruction.
Record the venue, account or wallet, provider, environment and quote version. Then resolve the economic terms:
- Instrument and asset identifiers, including settlement asset and network where relevant.
- Your side, expressed explicitly as buying or selling the base asset.
- Exact amount and unit: base quantity, quote notional or contracts.
- Whether the quote is for the full ticket, allows partial execution or has a minimum fill.
- Included fees, separately charged fees and any later settlement charges.
A two-way response requires care. From the customer's perspective, buying the base asset normally uses the provider's ask and selling uses its bid. Confirm the protocol's side convention rather than inferring it from a field named side.
For a package, preserve each leg's instrument, direction and ratio. If the RFQ replaces an expiring future with a later contract, the futures expiry and roll-cost guide explains why the combined economics depend on both legs. A single attractive leg price cannot validate the whole package.
Changing a 2 BTC ticket to 3 BTC changes what the provider is being asked to execute. Request new terms unless the original quote explicitly permits that change. Do not multiply a displayed unit price by a larger quantity and assume the commitment scales with it.
Separate quote expiry from request expiry
An RFQ may remain open after a particular maker's response expires. Conversely, a quote countdown on a screen does not establish that a request arriving later will be accepted.
OKX describes separate displays for these clocks: its RFQ board shows the request's remaining lifetime, while each bid or ask has its own quote-expiry indicator. OKX: managing RFQs and quote lifetimes. Its maker guide also says a live quote can be edited or canceled before its time limit. A future expiry timestamp therefore does not, by itself, prove that an earlier response remains available. OKX: quoting and canceling RFQ responses.
Check what event must occur before expiry: provider receipt, acceptance processing or on-chain execution. Do not assume these boundaries are interchangeable. 0x says RFQ commitments generally have a short window, roughly 60 seconds on mainnet, and an expired RFQ order can revert. That is a description of its flow, not a universal crypto RFQ timeout. 0x: RFQ quote expiry.
A client can stop new acceptance attempts before the official boundary to leave a processing buffer. The buffer must reflect the actual path and clock uncertainty; an arbitrary countdown cannot guarantee timely arrival. The good-till-date order guide addresses the separate lifetime of an order already submitted to a venue.
A cheaper headline can be a more expensive ticket
Consider an illustrative spot RFQ to buy exactly 2 BTC with USD. The account has sufficient USD, all quotes cover the same settlement arrangement and there are no other charges. Prices, fees, identities and times below are invented. Fees charged separately are rounded to the nearest cent, with half cents rounded up.
| Response | Terms for the 2 BTC request | Total USD payable |
|---|---|---|
| A | Indicative 60,000 USD/BTC; no executable confirmation | 120,000.00 estimated |
B, quote Q-B | Firm 60,040 USD/BTC, fees included | 120,080.00 |
C, quote Q-C | Firm 60,020 USD/BTC plus a separate 0.04% fee on notional | 120,088.02 |
For C, the notional is 2 × 60,020 = 120,040 USD. The fee is 120,040 × 0.0004 = 48.016 USD, rounded to 48.02. Total payable becomes 120,088.02 USD, which exceeds B by 8.02 USD. The lower unit price did not produce the lower comparable cost. A remains an estimate and cannot substitute for either executable offer.
Now suppose Q-B expires at 12:00:05.000 UTC. In this constructed protocol, provider receipt before expiry is required, and the quote remains active throughout the attempt:
| UTC time | Event | State to retain |
|---|---|---|
| 12:00:01.000 | Client receives Q-B for 2 BTC. | Live quote; nothing has traded. |
| 12:00:04.200 | Client sends acceptance of that exact quote. | Acceptance outcome pending. |
| 12:00:04.400 | Provider receives the acceptance and executes; its response is lost. | Actual exposure is 2 BTC, but the client has not confirmed it. |
| 12:00:05.000 | Local quote countdown reaches zero. | The earlier acceptance remains unresolved from the client's perspective. |
| 12:00:06.200 | Authoritative history confirms the trade identity and 2 BTC execution. | Reconcile 120,080 USD payable and the acquired quantity. |
Expiry prevents a new acceptance under these assumed rules; it does not undo an execution already completed. Requesting and accepting another full ticket before resolving the first could buy 4 BTC in total. Use order-timeout reconciliation as the related recovery principle, while following the RFQ provider's actual lookup and retry rules.
Last look makes the acceptance boundary important
Last look describes an additional provider decision after a customer requests execution against a quote. The Global Foreign Exchange Committee's last-look guidance announcement defines it as a final opportunity to accept or reject a trade request at the quoted price. That source concerns FX market practice; it supplies useful terminology rather than rules governing every crypto provider.
Ask a crypto provider whether hitting the quote completes the trade or submits a request subject to further approval. If a further decision exists, establish its maximum duration, permitted rejection reasons and the status returned while waiting. Clarify whether checks concern identity, available credit and message validity, or whether market-price changes can also cause rejection.
If a provider calls a quote firm while reserving price-based rejection, resolve that condition explicitly before treating the displayed price as a commitment.
This distinction prevents two opposite mistakes. A customer may treat a pending request as a fill and hedge an exposure that never appears. Or they may treat a slow response as a rejection, accept a replacement and later discover both traded.
A rejection alone does not identify last look. Expired terms, insufficient balance, invalid signatures and communication failures can produce unsuccessful attempts without discretionary price review. Preserve the reason and the stage at which the attempt failed. A firm label is useful only alongside a clear statement of when commitment becomes final.
Validate the quote contract before relying on it
Use a documented walkthrough or supported test environment to answer five concrete questions:
- Does changing size, side or a package leg require a fresh quote identity?
- Which timestamp and processing event determine expiry, and can quotes be withdrawn early?
- Are partial fills possible, and what quantity becomes committed on acceptance?
- What evidence separates pending, rejected and executed acceptance attempts?
- How can the original attempt be queried after its response disappears?
Retain the original request, quote terms, acceptance identity, timestamps, terminal outcome and settlement record. Review execution price and total cost separately from later holding expenses. For a perpetual position, the quote does not determine every future funding charge; funding-rate caps and floors covers that distinct contract rule.
Before the next acceptance, write one sentence that identifies exactly what can trade, for how much and until which boundary. If the response cannot support that sentence, obtain executable terms or resolve the missing condition first. After acceptance, close the record only when the trade and settlement outcome are known.