Event date: Oct 19, 2026. This is an independent summary of a platform announcement; the original source is linked below.
Kalshi's October 19 changelog says a post-only RFQ (request for quote) cancellation can contribute to quoting penalties when the maker's order would cross the book at execution. Repeated failures can temporarily limit the maker's ability to submit new quotes. The flag itself remains supported.
For a builder, the useful distinction is between answering a quote on time and reaching execution successfully. A confirmation can be recorded before the later post-only check cancels the resulting order. Monitoring only missed confirmation deadlines would miss that second failure path.
This is a source review of Kalshi's Predictions RFQ workflow. We did not create a quote, connect an account or test funded execution.
What the October 19 notice changes
The dated changelog entry connects these execution-time cancellations to the penalty treatment for an accepted quote that a maker fails to confirm. It says repeated failures can lead to temporary restrictions on new quotes.
That is the stated scope. The notice does not supply a fixed cancellation count, a guaranteed restriction duration or a universal retry interval. A client should not invent those values or assume that an ordinary public-data request and a new RFQ quote share the same limit.
The current RFQ guide documents the same behavior. Read that current workflow when maintaining an integration, rather than relying only on a saved rollout note.
Acceptance, confirmation and execution are separate observations
An RFQ lets a requester ask market makers for prices on a market and size. Selecting a quote is one step; the maker's confirmation is another. Confirmation starts the execution timer, after which the orders enter the public book.
The guide defines separate confirmation and execution windows, with shorter windows for High Volatility Markets, including combos. The relevant book can change while those steps occur. A successful confirmation response therefore needs to remain a distinct log entry from the later order and fill records.
For the ordinary book mechanics behind crossing a price, see our order-book walkthrough. RFQ communication has its own lifecycle; do not substitute a generic order label for a quote state.
What post-only controls here
Kalshi's Create Quote reference describes post_only as canceling the quote creator's resting order instead of allowing it to take liquidity when it would cross. The October 19 notice explains the quoting-penalty consequence of that cancellation.
Changing the flag changes execution behavior. Treat disabling it as an intentional trading-policy decision, rather than a harmless way to silence an error. Keep that decision separate from fixing late messages or an incorrectly parsed response.
The resulting cancellation also does not tell you the state of every other order or position in the account. Our order-status checklist explains how to reconcile an order, its fills and any remaining quantity.
A paper log that exposes the missing step
Imagine one fictional RFQ, RFQ-A, and one quote, QUOTE-A. These labels are illustrative, not exchange identifiers or a captured trade:
- Quote created: retain the RFQ ID, quote ID, market, size context and post-only setting.
- Quote accepted: record the observed acceptance time and the applicable confirmation deadline.
- Maker confirmed: retain the confirmation result and when it was received. Do not overwrite this with a later cancellation label.
- Execution-time result: inspect whether the resulting order executed, remained open or was canceled by the post-only check. Preserve the actual reason when available; an unknown reason stays unknown.
- Account reconciliation: match any real fills to the documented identifiers and account/subaccount. A missing message is a gap to investigate, rather than proof of zero activity.
This record lets you ask a precise question: did the maker miss confirmation, or did a confirmed quote fail the later book check? It does not estimate whether a strategy will profit or predict when a quoting restriction will end.
What to review in an existing integration
Check that quote notifications are read from the documented communications channel. The RFQ guide describes it as authenticated and distinguishes it from the order-book feed. Public market snapshots alone do not reveal a private quote conversation.
Review how your client links acceptance, confirmation, order and fill records. Preserve RFQ and quote IDs across reconnects, avoid counting the same event twice, and surface a quoting restriction instead of repeatedly submitting new quotes without understanding the response.
Use a paper-trading test plan to exercise a timely confirmation followed by a cancellation, a missed confirmation, a delayed notification and an uncertain outcome after a disconnect. Record simulated outcomes as simulated. Documentation review and a clean paper log do not establish that funded execution has been tested.