Kalshi Queue Position: How Limit Order Priority Works

Educational guide. Trading can lose money, including the full amount you pay for a contract. DeskBot does not guarantee profits, returns, win rates or income. DeskBot is not affiliated with, endorsed by or a partner of Kalshi.

Short answer

When you rest a limit order on Kalshi, it waits in line behind every order already sitting at the same price. Kalshi matches orders by price-time priority: a better price goes first, and at the same price the earlier order goes first. Your queue position is the number of contracts that must be matched (or cancelled) ahead of you before your order gets its first fill, and Kalshi's API reports it directly. Knowing that number is what turns "should I rest a bid or just pay the ask?" from a guess into arithmetic. This guide explains how the line works, which actions keep or lose your place, how to read queue position from the API, and a worked example on a live Bitcoin 15-minute book where waiting saves about 1.7 points of break-even but may never fill.

How price-time priority works on Kalshi

Every order sent to Kalshi is a limit order with a price. If your price reaches the best opposite order, you trade immediately as a taker for as many contracts as are available there. Whatever does not fill (and whatever you deliberately priced below the market) rests in the book as a maker order.

Resting orders are ranked in two steps:

1. Price. A Yes bid at 82¢ is ahead of every Yes bid at 81¢. If you are the only order at a new best price, you are first in line.
2. Time. At the same price, orders fill in the order they arrived. If 4,000 contracts were already bidding 82¢ when you joined, all 4,000 come before you.

Kalshi's book only lists bids (Yes bids and No bids), because a No bid at 17¢ is the same thing as an offer to sell Yes at 83¢. So "the line" at a price includes every bid for that outcome at that price. If you are new to reading the book, start with Kalshi order book explained.

Two things move you up the line: trades at your price (someone sells into the bids ahead of you) and cancellations by people ahead of you. Nothing behind you can move you back, unless you change your own order in a way that resets your timestamp.

What keeps your place and what loses it

Kalshi's Amend Order (V2) documentation is explicit about this, and it matters for any bot that adjusts orders:

The practical rule: if you want more contracts at the same price, send a second order rather than enlarging the first one. The first keeps its place and only the added size goes to the back. If you need fewer contracts, use Decrease Order (with reduce_by or reduce_to) or amend down, which keeps your spot. Cancel only when you really want out.

A note on amend's count field: Kalshi defines it as the new total fillable count, meaning already-filled plus what you want left resting. If 30 of 100 contracts have filled and you want 50 more resting, you send 80, not 50. Getting this wrong by sending a larger number counts as a size increase and costs you your place. For an expiry-only change, the docs say to send the current price and total quantity.

Reading queue position from the API

Kalshi exposes two authenticated endpoints (both require a signed request with your API key; see Kalshi API keys and authentication):

• GET /portfolio/orders/{order_id}/queue_position returns one order's position as queue_position_fp.
• GET /portfolio/orders/queue_positions returns positions for all your resting orders, filterable with market_tickers (comma-separated) or event_ticker. Each item has order_id, market_ticker and queue_position_fp.

queue_position_fp is a fixed-point string with two decimals, such as "4252.13", because Kalshi now supports fractional contract counts down to 0.01. The docs describe it as the number of preceding contracts ahead of your order. Treat it as a string in your code and convert with a decimal type, not a float, if you compare it to sizes.

A minimal Python loop looks like this. signed_get stands for whatever helper you already use to sign requests; the signing itself is covered in our Kalshi API Python tutorial.

Use the batch endpoint when you have several orders in one market; it is one request instead of many, which matters because order-related reads count against your rate limit (see Kalshi API rate limits and WebSocket). Practice in Kalshi's demo environment first.

Worked example: rest at the bid or pay the ask?

Here is the top of the book for Kalshi's Bitcoin 15-minute market KXBTC15M-26OCT311515-15 (window closing 3:15 PM ET on October 31, 2026, target price $77,490.23), pulled from the public API at 3:08 PM ET with depth=5:

Best Yes bid: 82¢. Best price to buy Yes now: $1.00 − 17¢ = 83¢, with about 1,957 contracts available. The spread is 1¢, so there is no room to bid inside it without crossing.

Say you want 100 Yes contracts. Two choices:

Take at 83¢. Kalshi's taker fee on these markets is 0.07 × contracts × price × (1 − price), before Kalshi's fee rounding. That is 0.07 × 100 × 0.83 × 0.17 = $0.9877, about $0.99. Total cost about $83.99, so each contract needs to win about 83.99% of the time to break even. You get filled now, for certain.

Rest a bid at 82¢. Using the 0.0175 maker rate from our maker vs taker fees guide (check the series fee schedule; rates can differ), the fee is 0.0175 × 100 × 0.82 × 0.18 = $0.2583, about $0.26. Total cost about $82.26, break-even about 82.26%. That is roughly $1.73 cheaper per 100 contracts, or 1.73 points of break-even win rate, which is large on a market priced in the 80s (the full method is in Kalshi fees and break-even win rate).

The catch is the queue. Joining at 82¢ puts you behind about 4,252 contracts. Your API call would report queue_position_fp near "4252.13", and that many contracts must trade at 82¢ or be cancelled before your first contract fills. With about seven minutes left in the window, that may never happen.

The two hidden costs of waiting

1. Non-fill. If the price moves up and away from your bid, you never trade. If you only ever take when the market is calm and miss when it runs, your filled trades are not a random sample of your ideas. Count the trades you would have made and compare them with the ones that actually filled.

2. Adverse selection. The most common way a resting Yes bid gets filled is that sellers hit the bids because Yes is getting less likely. The fill you get after waiting through 4,000 contracts often arrives right as the price drops through your level. A 1.7-point fee saving can disappear if your fills land on the worse side of the move. This is why maker fills on paper often look better than maker fills with real money; see Kalshi paper trading vs live.

A reasonable way to decide, using queue position as an input:

• Compare the contracts ahead of you with recent trading volume at that price. If thousands are ahead and the window closes in minutes, you are effectively not in the market.
• If the decision only makes sense at the taker price, don't rest a bid and hope. Either take or skip (see when to skip a Kalshi trade).
• If you rest, set an expiration_time (with time_in_force set to good_till_canceled) so the order can't sit into the final seconds of a 15-minute window by accident. Extending that expiry later keeps your place.
• Kalshi's create-order request also has a post_only flag for orders meant only to rest, and a cancel_order_on_pause flag that cancels the open order if trading is paused. Test exactly how both behave in demo before relying on them.

Why 15-minute markets make the queue matter more

On a market that settles in months, a resting order has time to work through the line. On a 15-minute crypto market the whole life of the trade is a few minutes, the book is rebuilt every window, and the deepest levels are often market makers who can cancel and re-quote faster than any home connection. Joining the back of a 4,000-contract level near the close is usually a non-trade, not a cheap trade. Earlier in the window, with a fresh book and thinner levels, resting can be realistic. Tracking queue position over time tells you which of those situations you are in. (For how these windows open, close and settle, see Kalshi 15-minute markets explained and how Kalshi markets settle.)

Where DeskBot fits

DeskBot uses proprietary trading logic with customer-selected settings. Its dashboard shows supported market views and app activity. See the current product and support pages for the features and requirements of your release.

Related reading: Kalshi order book explained, Kalshi order types, amending and cancelling orders with the API, maker vs taker fees, the Bitcoin 15-minute market explained.

What is queue position on Kalshi?

The number of contracts ahead of your resting limit order at the same price. Those contracts must be matched or cancelled before your order receives its first fill.

How does Kalshi decide which order fills first?

Price-time priority. Better-priced orders fill first; at the same price, earlier orders fill first.

How do I check my queue position?

With a signed request to GET /portfolio/orders/{order_id}/queue_position for one order, or GET /portfolio/orders/queue_positions for all resting orders, optionally filtered by market_tickers or event_ticker. The value comes back as queue_position_fp, a two-decimal string.

Do I lose my place if I amend an order?

Not if you only change the expiration time or decrease the size. Increasing the size or changing the price moves the order to the back of the line.

Why is my queue position a decimal?

Kalshi reports contract counts as fixed-point strings with two decimals and supports fractional contracts down to 0.01, so the number of contracts ahead of you can include a fraction.

Is resting a limit order always cheaper than taking?

The fee is usually lower for the maker, but you may not get filled, and the fills you do get tend to arrive when the price is moving against you. Compare fee savings with your fill rate and how your filled trades actually performed.

Can I jump the queue?

Only by offering a better price. If the spread is 1¢ wide, a better price means crossing the spread and trading as a taker.

Is DeskBot affiliated with Kalshi?

No. DeskBot is independent software and is not affiliated with, endorsed by or sponsored by Kalshi.

Risk disclaimer: Trading involves risk of loss. Only trade money you can afford to lose. DeskBot does not guarantee profits, returns, win rates or income. The order book shown is a single snapshot from Kalshi's public API at 3:08 PM ET on 2026-10-31 and changes constantly; fee figures are illustrative and before Kalshi's fee rounding. Kalshi facts in this guide were checked against docs.kalshi.com (Get Order Queue Position, Get Queue Positions for Orders, Amend Order V2, Decrease Order V2, Create Order V2, Fee Rounding) on 2026-10-31; Kalshi can change its rules, fees and limits. DeskBot is not affiliated with Kalshi.

Current product information: Kalshi · Robinhood · Setup and support. Check the relevant product page for current downloads, pricing, renewal and cancellation terms. Desktop and mobile products have separate availability and offers.

Educational content, not financial advice. Trading can lose money. DeskBot does not guarantee profits, returns, win rates or income and is not affiliated with or endorsed by the named exchanges or brokers.