Skip to main content
Kalshi implements an RFQ (Request for Quote) system for pre-execution communication between members. RFQs allow a requester to solicit quotes from market makers on a specific market and size. Execution follows a two-step lock: accept, then confirm. RFQs are available on any market, including combo (multivariate event) markets. Combo markets are classified as High Volatility Markets (HVM), which have shorter timing windows (see Timing).

​
Interfaces

RFQs are accessible over REST, FIX, and WebSocket. Quote notifications arrive on the communications WebSocket channel, not the orderbook channel.

​
Flow

  1. Requester creates an RFQ specifying a market ticker, size, and whether to rest any remainder.
  2. The RFQ is broadcast to all makers.
  3. Makers respond with quotes containing a yes_bid and no_bid. Quotes are for the full RFQ size. Each quote is private between the requester and the individual maker. Makers cannot see each other’s quotes.
  4. Requester accepts one side of the best-priced quote.
  5. Maker confirms within the confirmation window. Once confirmed, neither party can withdraw.
  6. After the execution timeout, orders are placed on the public book.

​
Creator identity and privacy

Public communications IDs are pseudonymous identifiers derived from a user ID with a salted hash. By default, makers see the requester’s public communications ID and can recognize it across RFQs. Set obscure_creator_id: true when creating an RFQ over REST, or ObscureCreatorId (21034) to Y in the FIX NoRelatedSym group, to hide that identifier from other users. Obscured creator fields display the shared placeholder e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. The placeholder appears in these fields for other users: Creators still see their own normal ID. After successful quote execution, the hashed RFQ creator identity will become visible. Subsequent REST RFQ responses show the normal public communications ID to all viewers. The executed quote’s REST response and WebSocket quote_executed event also show that ID to its participants.

​
Sizing

When creating an RFQ, the requester specifies size in exactly one of:
  • contracts_fp: number of contracts, including partial contracts in 0.01-contract increments.
  • target_cost_dollars: dollar amount to spend. The exchange derives a contract count from the quote price, returned as yes_contracts_fp / no_contracts_fp on the quote.
By default the target cost caps principal plus Kalshi fees: the derived contract count is the maximum whose total cost including your taker fee fits inside target_cost_dollars, so your debit can never exceed it. Set target_cost_excludes_fees: true to size as principal only — the count becomes target_cost / price and your taker fee is charged on top of the target cost. contracts_fp-sized RFQs are never reduced for fees under either mode.

​
Quotes

Each quote has two prices: yes_bid (price per YES contract) and no_bid (price per NO contract). These are typically different. Either can be "0" to decline that side, but not both. If yes_bid + no_bid > $1 the quote is rejected. Quoters do not specify a size. Each quote is implicitly for the full RFQ amount (contracts_fp, or whatever count target_cost_dollars resolves to at the quoted prices). Prices must land on the market’s price grid. Check price_ranges on GET /markets/{ticker} for the valid step size. A new quote on the same RFQ replaces the maker’s previous quote.

​
Post-only quotes

If a confirmed quote is cancelled because the maker’s post-only order would cross the book at execution, that cancellation counts toward the same quoting penalties as failing to confirm an accepted quote. Repeated failures can temporarily rate limit the maker’s ability to create new quotes.

​
Timing

The exchange designates certain markets as High Volatility Markets (HVM). All combo markets are HVMs. HVMs use shorter confirmation and execution windows. After acceptance, the maker has the confirmation window to confirm. Upon confirmation, the platform begins the execution timer. At the end of the timer, orders are entered into the book. Fills appear in GET /portfolio/fills. Match on creator_order_id (maker) or rfq_creator_order_id (requester).

​
WebSocket

Subscribe to the communications channel (requires auth). rfq_created and rfq_deleted go to all subscribers. quote_created, quote_accepted, and quote_executed go only to the involved requester and maker.

​
Combos (MVE)

Combo RFQs include mve_collection_ticker and mve_selected_legs. Use Multivariate Event Collections to discover eligible combinations.

​
Subaccounts

Requesters can create an RFQ under a numbered subaccount by passing subaccount on POST /communications/rfqs. Makers can likewise pass subaccount on POST /communications/quotes. Execution, fills, and settlement follow the subaccount the RFQ or quote was created under. The full REST RFQ lifecycle — including combo-market creation — is also available to subaccount-restricted API keys, scoped to the key’s locked subaccount. On FIX, restricted keys support the maker quote lifecycle only.

​
Common errors