Skip to main content

​
Overview

In order to scale capacity, Kalshi will be splitting trading across multiple matching engines. Exchange instances will correspond to a specific category (e.g. “crypto” exchange, a “combos” exchange). Kalshi plans to add shards incrementally to maintain a healthy balance of traffic.

​
Timeline

Kalshi will migrate combos from the “default” exchange instance to shard 1, followed by crypto, commodities, and selected sports series.
  • August 6, 2026: intra-exchange instance transfers enabled to exchange index 1.
  • August 10, 2026: KXMVECROSSCATEGORY-SHARD1-R multivariate event collection created with support for all combos.
  • August 17, 2026: combos created over legacy collections KXMVESPORTSMULTIGAMEEXTENDED-R, KXMVECROSSCATEGORY-R will be created on shard 1.
  • August 24, 2026 at 12:00 PM ET: new crypto events will be created on shard 2, and new tennis and baseball events will be created on shard 3.
  • September 10, 2026 at 12:00 PM ET: new commodities markets will be created on shard 2, and new basketball markets will be created on shard 3.

​
Balance Management

Kalshi’s collateralization checks will continue to run within the matching engine. Programmatic traders must preallocate collateral on a given exchange shard before order placement. Funding Overview Subaccounts Overview
  • To fund a subaccount on a new exchange instance, first transfer user-level funds to the desired exchange instance.
  • Next, use Create Subaccount with the exchange_index parameter to provision the subaccount on the new instance.
  • Then, use Transfer Between Subaccounts with the exchange_index parameter to transfer funds from the primary account to the subaccount on that instance.
  • Get All Subaccount Balances provides a breakdown of subaccount balances for each (exchange_index, subaccount) pair.
Auto-Rebalancing
  • Users may opt in to automatic rebalancing between exchange shards.
  • The customer supplies a target balance allocation as a percentage of their balance across exchange shards. For example, {Default: 80, Combos: 20}.
  • Every 10 seconds, Kalshi computes the customer’s balance on each exchange shard as its account balance minus the value of its resting orders.
  • If the balance has drifted from the target allocation, Kalshi executes an intra-exchange account transfer on the customer’s behalf to restore the target allocation.
  • Target balance allocations can be configured through the REST API and the clearing portal.

​
Order routing

​
Market Data

Auto-routing requires the market ticker: provide market_ticker for API2 or Symbol<55> for FIX. An order ID alone cannot identify the exchange shard.

​
API2

The exchange_index query parameter is available on a per-endpoint basis.
  • If exchange_index >= 0, routes directly to the target exchange.
  • If exchange_index is -1, auto-routes using the required market_ticker.
  • If exchange_index is omitted and market_ticker is provided, auto-routes using market_ticker.
  • Otherwise, defaults to exchange index 0.

​
FIX

ExDestination<100> is available on a per-message basis for event-contract sessions.
  • If ExDestination<100> >= 0, routes directly to the target exchange.
  • If ExDestination<100> is -1, auto-routes using the required market ticker in Symbol<55>.
  • If ExDestination<100> is omitted and Symbol<55> is provided, auto-routes using Symbol<55>.
Margined FIX sessions always route to exchange index 0.

​
Upcoming Series Shard Assignments

The following assignments determine the shard where new events will be created. Shard 0 is the catch-all for all categories and tags not listed below.

​
FAQ

  • All child markets of an event will live on the same exchange instance.
  • There is currently no plan to migrate any live market to a new exchange instance.
  • Single REST order writes that explicitly target a nonzero shard are rate-limited against that shard’s Write budget. Auto-routed single REST order writes are billed to the unscoped Write bucket and every nonzero shard’s Write bucket. REST batch writes and explicit shard 0 writes use only the unscoped Write budget. See Rate Limits and Tiers.
  • Providing ExDestination / exchange_index is unnecessary for all RFQ operations, including FIX QuoteRequest (35=R), Quote (35=S), and AcceptQuote (35=UA), which are routed internally by Kalshi.
  • When trading via FIX, both MassCancelRequest and CancelOrdersOnDisconnect will target all exchange shards for the FIX session.
  • Automatic routing will incur an additional latency cost.
  • Subaccount balances are local to a specific exchange instance.
  • Order groups do not function across exchange instances.
  • KXMVECROSSCATEGORY-SHARD1-R is live in demo for testing.