How RFQs Work
This page explains the concepts. For endpoints, request fields, responses, and schemas, see the RFQ API overview and the interactive API Reference.
An RFQ, or request for quote, is a trading workflow where a taker asks makers for executable prices on a specific instrument. The system is designed to work across HyperEVM and HyperCore, giving traders one universal flow to execute against all the available instruments on Hyperliquid.
The flow is built to span instruments such as:
- Tokenized instruments issued on EVM
- Larger perp positions on HyperCore or through HIP-3 deployers
- Spot instruments on HyperCore or HyperEVM
Main actors
Takers
The taker is the account requesting liquidity. A taker creates the RFQ, reviews quotes when using manual acceptance, accepts a quote or waits for auto-selection, and tracks the final trade state. A taker can hold funds on either HyperCore or HyperEVM. Settlement abstracts away which chain the funds are on and returns funds to the same chain the taker initiated from.
Makers
The maker is the market maker that prices an instrument and fills the trade. A maker watches for open RFQs on supported instruments and submits quotes. As with takers, maker funds are abstracted away from the chain: the maker responds to an RFQ and settlement handles the chain abstraction.
Makers gain capital efficiency from how settlement is authorized. A maker declares how each quote settles through its settlement mode: from its own inventory, through an external venue with the adapter's payload attached to the quote, or as a promised delivery owed within a bounded window (see createMakerQuote). Each quote carries an expiry, and the engine binds that expiry to an on-chain Permit2 deadline, so a maker commits to deliver the tokens only within a bounded window. The objective is to let makers quote more competitively without parking idle inventory.
Silhouette
Silhouette is the coordinator that sits between takers and makers and runs the RFQ lifecycle. It coordinates the taker's request, collects maker quotes, selects or records an accepted quote, locks and releases balances as needed, exposes the final trade status, and uses the CoreWriter contracts to manage cross-chain transfers. Takers and makers never interact directly; every step passes through Silhouette.
Instruments
Each RFQ is for one instrument, such as XTSLA-USDC-SPOT. The canonical instrument ID has the form BASE-QUOTE-TYPE and identifies the base token, the quote token, and the product type (for example SPOT). See the InstrumentId schema in the API Reference for the exact format.
The TYPE segment is what lets the same flow generalise: the contract defines SPOT and PERP instrument types, and settlement spans tokenized instruments on EVM as well as HyperCore spot and perp venues. Expect the supported instrument set to grow rather than the workflow to change.
The taker sends a side:
BUYmeans the taker wants to buy the base token and is setting the maximum quote amount they will pay.SELLmeans the taker wants to sell the base token and is setting the minimum quote amount they will accept.
The taker also sends baseQty, the amount of the base token to trade, and optionally quoteLimit, the taker's price bound in the quote token. A quote outside the bound cannot win, and the bound is never shown to makers. With auto-acceptance the bound is required, because selection accepts on the taker's behalf; a manually accepted RFQ may omit it.
Quote window
Every RFQ has a quote window. During this window, makers can submit competing quotes. A short window favors faster execution. A longer window gives more makers time to respond and can improve price discovery.
If the taker omits windowMs, Silhouette uses the operator's default window. A supplied value is clamped server-side to the operator's minimum and maximum, so an out-of-range request is honoured at the nearer bound rather than rejected, and the submission response returns the deadline the clamp settled on.
Auto-acceptance (two-round flow)
In the two-round flow the taker submits and makers quote, with no acceptance step required. The taker submits an RFQ with autoAccept: true, Silhouette waits until the quote window closes, then automatically selects the best conforming quote. Funds lock at RFQ submission rather than at acceptance. Auto-acceptance requires a quoteLimit, since selection acts on the taker's behalf and has no other bound to work to; omitting it is rejected with QUOTE_LIMIT_REQUIRED.
The taker keeps the option to accept early. Calling acceptRfqQuote on an auto-accept RFQ takes the quote immediately rather than waiting for the window to close, so the auction end is a backstop rather than the only moment a quote can win.
Perp instruments cannot auto-accept. Matched execution needs the taker's signed order at acceptance, so autoAccept: true on a perp instrument is rejected.
If there is no conforming quote by the deadline, the RFQ ends FAILED and locked funds are released. Auto-acceptance is useful when the taker wants the best available quote at the end of the window without a second decision step.
Manual acceptance (three-round flow)
The three-round flow adds a third round, where the taker reads the quotes and accepts one, in exchange for control over which quote wins.
The taker submits an RFQ with autoAccept: false (or omits autoAccept, the default). The RFQ enters PENDING while makers submit quotes. The taker reads the competing quotes with listRfqRequestQuotes and explicitly accepts one with acceptRfqQuote before the auction ends. Here acceptance is the only way the request fills: nothing is selected on the taker's behalf when the window closes.
Funds lock when the taker accepts a quote. After acceptance, the RFQ moves toward settlement. If settlement succeeds, the RFQ becomes SETTLED. If the selected maker does not deliver or settlement cannot complete, the RFQ becomes FAILED and locked funds are released.
Manual acceptance is useful when the taker wants to inspect quotes before committing. Rate limits apply to this flow to discourage spam.
Maker quoting
Makers discover open RFQs through listMakerRequests, which returns the open RFQs on the instruments the maker is approved to quote, or by subscribing to the openRfqs topic. Either route needs an active maker record, approval for the instrument's pair, and at least one operated settlement adapter. A maker submits a quote with createMakerQuote.
A quote describes what the maker pays and what the maker receives. Quotes start as SUBMITTED. Before selection, a maker can cancel a still-submitted quote with cancelMakerQuote, taking it to CANCELLED; to re-price, the maker submits a fresh quote for the same RFQ. Selection marks one quote SELECTED and the rest NOT_SELECTED (or EXPIRED if the window closes with no conforming quote). It runs when the auction ends, or earlier if the taker accepts a quote before then, which it may do in either selection mode.
After selection, the winning quote follows its settlement mode: one that settles atomically goes straight to SETTLED; one whose settlement does not complete ends FAILED. A winning promised quote moves to PENDING_DELIVERY while the maker owes the on-chain delivery, then to SETTLED on delivery or DEFAULTED when the maker misses its window. DEFAULTED is distinct from FAILED because it is attributable to the maker and carries consequences.
When a quote is selected, the maker reads it back through listMakerQuotes. A SELECTED quote carries the engine-signed Permit2 authorization the maker relays on-chain to settle.
Trade lifecycle
Each branch resolves to one of the lifecycle states below. The two unsettled terminals divide on whether the trade was called off deliberately: a taker cancelling its own still-PENDING request ends CANCELLED, and every other ending without a settlement ends FAILED, with failureReason carrying which one it was. Status values are returned in SCREAMING_SNAKE_CASE; the set is open, so treat an unrecognised value as non-terminal. See the RfqStatus schema in the API Reference for the authoritative list.
| Status | Meaning | Terminal |
|---|---|---|
PENDING | Auction open; quotes may be arriving. | No |
QUOTED | A winning quote was selected or accepted and carries a settlement artefact to observe (a signed Permit2 permit or an on-chain escrow); settlement is in progress. A quote whose settlement mode settles atomically skips this state and goes straight to SETTLED. | No |
PENDING_DELIVERY | The winning quote is a promised delivery: the maker owes the on-chain delivery within its window. | No |
SETTLED | Settled on-chain; a completed trade carrying a settlement transaction hash. | Yes |
FAILED | Every ending without a settlement that nobody called off: no quotes arrived, none conformed, none was accepted before the auction ended, the settlement deadline passed with no fill, or a delivery window was exhausted. Locked funds are released. | Yes |
CANCELLED | A party ended the request deliberately before settlement. In this version that means the taker cancelling its own still-PENDING request. Locked funds are released. | Yes |
Balances and reconciliation
The RFQ surface exposes balances and a ledger so integrators can reconcile account state.
Balances show available, locked, and total amounts by token. The ledger is an append-only audit trail for balance changes such as deposits, settlements, withdrawals, and adjustments. See the balance endpoints in the API Reference.
Deposits and withdrawals are separate funding operations. Withdrawals are asynchronous and use the account's registered address; the caller cannot specify a destination. See the funding endpoints in the API Reference.
Developer reference
For exact endpoints, request fields, responses, and schema definitions, start at the RFQ API overview and explore the interactive API Reference. Authentication is covered in the RFQ API authentication section.