One API for Kalshi and Polymarket: 4 Gaps

One API for Kalshi and Polymarket is a tidy idea with a messy middle. Both venues sell something that looks identical from a distance: a contract that pays one dollar if a stated event happens and nothing if it does not. The pricing increments, the collateral, the body that decides the event occurred and the fee arithmetic all differ, and a single schema has to flatten each of those differences into one field. Below are the four flattenings, and what information each one throws away.

Can one API cover Kalshi and Polymarket?

It can cover the plumbing. Fetch a book, place an order, read a position, list open markets: those verbs map cleanly onto both venues, and an open-source wrapper that gives you one function for each is genuinely useful. What it cannot do is make the two instruments the same instrument.

Kalshi is a CFTC-designated contract market. Orders rest in a central limit order book operated by the exchange, contracts are quoted in cents, and a filled position sits as a dollar balance at a US clearing organization. The rulebook for each market names the source that decides the outcome, and the exchange performs the determination.

Polymarket positions are outcome tokens on a public blockchain, collateralized by USDC. Orders are matched off-chain by an operator and settled on-chain, and a completed market resolves through an optimistic oracle: a proposer posts the outcome with a bond at stake, a challenge window runs, and an unchallenged proposal becomes final. A disputed one goes to a token-holder vote.

Same economic payoff, two different legal and technical regimes. Everything below follows from that gap. For how the payoff itself compares with a listed derivative, start with event contracts versus stock options.

Field one: price and tick

A unified price field is the first thing every wrapper ships and the first thing that loses detail. As of October 2026, Kalshi quotes in whole cents from 1 to 99, so a market has 99 distinguishable prices and the smallest possible improvement on a resting order is one cent. Polymarket books commonly quote in tenths of a cent on liquid markets, roughly ten times as many price points across the same range.

SELECT
    venue,
    min_tick_cents,
    toUInt16(round((99.0 - 1.0) / min_tick_cents) + 1) AS distinct_price_points
FROM
(
    SELECT 'Kalshi cent grid' AS venue, 1.0 AS min_tick_cents
    UNION ALL
    SELECT 'Polymarket tenth cent grid' AS venue, 0.1 AS min_tick_cents
)
ORDER BY min_tick_cents DESC

The two rows are computed from each venue's published price conventions as of October 2026 rather than read from a live book. A grid change on either venue changes every number in the panel.

Flatten both into a float between 0 and 1 and the number survives. The grid does not. A quoting routine that rounds its target to the nearest cent will sit behind the book on the finer venue, and one that posts three decimals will have its order snapped or rejected on the coarser one. The spacing also changes what a one-tick move means: a single increment is a one point jump in implied probability on one venue and a tenth of a point on the other, which matters the moment your logic says improve the best bid by one tick. Carry the venue's tick on the market object and compute improvements from it, never from a constant.

There is a second quiet loss. A quoted price becomes a probability only after the venue's conventions come off, and the two books present the opposite side differently. On Kalshi, selling YES and buying NO are distinct actions against one book. On Polymarket the complementary token is its own asset with its own book, and the two sides can drift apart. Before comparing venues, strip the implied vig out of each book on its own terms, then compare. The mechanics of reading either book are in how to read an event contract ladder.

Field two: collateral and maximum loss

A long binary contract is fully funded on both venues. Pay 40 cents, risk 40 cents, collect a dollar if it resolves YES. The identical arithmetic hides two different accounts, and a unified max_loss field reports the right number while dropping the unit.

On Kalshi the collateral is a dollar balance held at the exchange under its published margin rules, and the thing you own is an integer number of contracts. On Polymarket the collateral is USDC, a dollar-pegged token sitting in a wallet, and the position size is a fractional token amount. There is no credit and no liquidation: a short is created by funding the complementary token rather than by borrowing.

That difference breaks sizing functions in a way that is easy to miss. A sizer written against integer contracts with a per-contract fee returns a number that is not expressible on a venue with fractional sizes and no per-contract charge, and the same risk budget fills a different real exposure on each side. A balance of 1.00 in a flattened field also says nothing about how quickly that dollar can move: an exchange withdrawal and an on-chain redemption are different operations with different availability. Store the collateral asset next to the amount, and keep the venue's size granularity on the market object.

Field three: settlement source and timing

This is the flattening that produces wrong marks rather than wrong orders. A schema that reduces resolution to a YES/NO plus a resolved_at timestamp assumes one authority and one moment of finality. Neither assumption survives contact with both venues.

Kalshi settles from the source named in the market's rulebook, with the exchange making the determination and publishing it, and with a dispute process that runs under CFTC oversight. Polymarket's finality arrives in stages: proposed, inside the challenge window, challenged, then either unchallenged-and-final or voted. The window is short on routine markets and the vote path runs for days. A feed that marks positions the instant a proposal appears will carry a confident value for exactly the markets where the outcome is still contested.

There is also an outcome with no counterpart on the regulated venue. An oracle can return a split resolution, paying both sides fifty cents, which a boolean resolution field cannot represent at all. And payout timing separates from resolution timing: an exchange credits the balance, while a token holder redeems on-chain whenever they get around to it. Model resolution as a small state machine with an authority field, two timestamps and a numeric payout, rather than as a flag. The underlying mechanics are covered in how event contracts settle.

Field four: fees

Fee schedules move, so treat the shape as the durable fact and the numbers as something to re-read. Kalshi publishes a trading fee computed from price and contract count, largest for trades near 50 cents and shrinking toward the tails, which makes the cost of a trade a function of where in the probability range it sits. Polymarket's headline trading fee has been zero on most markets, with cost arriving through the spread and through chain operations, and the venue has introduced charges on some products. Check each venue's current schedule as of the day you write the mapping.

Flattening this into a single fee_bps number loses the price dependence entirely. A two-cent gross edge near the middle of the range survives one schedule and disappears under the other, and a screen built on flattened prices and a flat fee constant will keep showing cross-venue edges that do not exist. Keep fees as a callable function of price, size and side.

What the flattening costs you downstream

• A size computed from one venue's collateral rules and size granularity is wrong on the other.
• A resolution feed that assumes a single authority will mis-mark the other venue's disputed and split markets.
• Cross-venue screens built on unified prices plus a constant fee will surface edges the real fee functions erase.
• A stored history of only the flattened fields cannot be re-run against venue rules that changed afterwards.

The design response is the same in each case. Persist the raw venue payload, make the unified layer a view over it, and put the venue discriminator on every record. If you adopt an open-source wrapper, read its schema before its feature list, and pin to a tagged release: a mapping written against last season's fee schedule or tick grid goes stale without any visible error.

Where the differences bite hardest

A buy-and-hold position tolerates a sloppy wrapper. A quoting strategy does not, since it touches tick spacing, collateral turnover and fee curvature on every order. That is the full weight of all four flattenings landing at once, and it is worked through in market making in prediction markets.

FAQ

Is a Kalshi contract the same as a Polymarket share?

The payoff is the same shape: one dollar if the event occurs, zero if it does not. The wrapper around it differs. One is an exchange-cleared contract held as a dollar balance in integer quantities, the other a fractional blockchain token collateralized by USDC.

Why do the same event's prices differ between the two venues?

The two books have separate participants, separate tick grids and separate fee schedules, and the quoted mid on each already contains that venue's own costs. Price gaps between them coincide with those structural differences as often as with any disagreement about the event itself.

What does a fifty-fifty resolution mean on Polymarket?

It is an oracle outcome where neither side is determined the winner and both sides receive fifty cents per share. A unified schema with a YES/NO resolution field has nowhere to put it, which is why a numeric payout field is safer than a boolean.

Do I need separate position sizing for each venue?

Yes, if the sizing depends on collateral units or order granularity. Integer contracts with a price-dependent per-trade fee and fractional tokens with a different cost structure produce different real exposure from the same nominal risk budget.

To see how an event's pricing lines up against the stock and options data behind the same story, ask the question in plain English on the Strasmore terminal.