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 TSLAX-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 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. The bound is required in both acceptance modes, because it sizes the funds locked at submission.
On a spot instrument baseQty must land on a step: a multiple of the baseQtyIncrement the instruments endpoint publishes for the pair. A size off the step is refused with BASE_QTY_OFF_INCREMENT, and details.increment names the step to round to.
Locked funds
Submission locks the taker's worst-case pay side, in either acceptance mode: quoteLimit on a BUY, baseQty on a SELL. A request the balance cannot cover is rejected rather than queued. A perp request locks nothing, because the margin sits at the venue.
Minimum order value
A market can set a smallest order value it takes, in the quote token. Read it as
minQuoteNotional on the instrument from GET /v1/rfq/instruments. A market
that sets no minimum omits the field and takes any size its tokens can
represent, which is how every market ships until an operator tightens it.
On a BUY the minimum is measured against quoteLimit net of the taker fee:
the limit has to cover minQuoteNotional plus the fee charged on it. A SELL
is not measured, because what it is worth is only known once a maker prices it.
A request under the minimum is rejected at submission with
BELOW_MIN_NOTIONAL, and details.minQuoteNotional in that response carries
the figure, so the next request is sized from the rejection rather than from a
guess. The same code can arrive later as a failureCode, if the floor rises
while a request sits PENDING.
Read the field rather than hard-coding a number: it is set per market and can change.
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. Selection acts on the taker's behalf and works to the quoteLimit the request carries.
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.
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 request, which it may do while the request is PENDING and before its auctionEndsAt, 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 request, while it is PENDING and before its auctionEndsAt. Once the auction closes the outcome is fixed and a cancel is refused 409. Locked funds are released. | Yes |
Balances and reconciliation
The RFQ surface exposes balances and a ledger so integrators can reconcile account state.
Balances are reported per token and per custody rail: a token held on both HYPEREVM and HYPERCORE has two lines. Each line carries available, locked, and pending, which together make up the account's claim on that rail, plus withdrawable, the ceiling on a single withdrawal from it. 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. A withdrawal may name the rail to pay from, and is then paid from that rail or refused; omit it and a rail that can cover the amount is chosen. Funds never move between rails. See the funding endpoints in the API Reference.
A withdrawal reports a txHash identifying the payout on whichever rail paid, and what the hash proves differs by rail. A HYPEREVM payout reports its ERC-20 transaction hash, set once the transaction is broadcast, so it records the attempt rather than proving the funds arrived; status is what confirms that. A HYPERCORE payout reports the ledger entry that moved the funds, set only on completion, so its presence is the proof. The two are separate chains with separate explorers, so read rail before building a link.
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.