The prediction market
that settles on chain.

Why prediction markets need a new venue.

Prediction markets are the most useful financial instrument almost no one uses. They aggregate information better than polls, faster than journalists, and more honestly than pundits. Polymarket proved the demand. Kalshi proved the regulatory path. But both run on top of payment rails that require trust — trust in a custodian, trust in a centralized matching engine, trust that the platform won't change the rules after you've placed your bet.

The crypto-native version of this product has been attempted many times — on Ethereum, on Polygon, on every L2 chasing the next narrative. Most of them fail for the same reason: the chain underneath was never designed for sub-minute markets settling in real time. Block times are too slow. Gas costs eat small bets alive. MEV bots front-run resolutions. Bridges introduce trust assumptions that defeat the whole point.

KOM exists because Kaspa changes the underlying math. One-second finality. No MEV by design. Native Layer-1 covenant scripting. A blockDAG that processes transactions in parallel instead of sequentially. The chain that was missing for this product class finally exists — and KOM is built to take advantage of every property of it.

What KOM is.

KOM is a binary prediction market protocol. Users bet on yes-or-no outcomes — will KAS be above $0.0304 at 09:35 UTC? — by locking KAS into per-market covenant addresses on Kaspa. When the market closes, an oracle-witnessed transaction sweeps the losing side's pool pro-rata to the winners. No off-chain accounting. No custody intermediary. The pool you see on chain is the pool that pays out.

The rest of this page walks through how the protocol actually works — the architecture, the on-chain primitives, the bet lifecycle, and why we believe Kaspa is the right base layer for this. If you want the short version: it's covenants, oracles, and a blockDAG fast enough that the entire bet-resolve cycle fits inside a five-minute window. If you want the long version, keep reading.

A different model from Polymarket.

This is the part that trips people up, so it's worth being precise. KOM and Polymarket look similar on the surface — bet yes or no, get paid if you're right — but the machinery underneath is fundamentally different. Polymarket runs an order book. KOM runs a pool.

How pool funding works

When you place a 5 KAS bet on YES, that 5 KAS goes into the YES BetLock pool. Nothing is wrapped, nothing is lent, nothing is matched. Your stake just sits in the pool until the market closes. At settlement the rule is simple:

The losing pool is swept to the winners in a single oracle-witnessed transaction, divided in proportion to how much each winner staked. KOM takes no rake — the only deduction is the network's own transaction fee, a fraction of a cent shared across the payout. Your profit is, quite literally, your slice of the money the losing side staked.

What if there are no losers?

This is the edge case worth understanding, because a pooled model has to answer it cleanly. Suppose a market closes and every bettor was on the winning side — the losing pool is empty. There's nothing to distribute, because no one was wrong. So the math does exactly what you'd hope:

This is a direct consequence of the model being honest: in a real parimutuel pool, winnings come only from the losing side's stake. No losers means no winnings — and crucially, no phantom fees, no house edge eating an uncontested bet. The pool you can see on chain is exactly the pool that pays out.

How markets resolve.

A prediction market is only as trustworthy as the thing that decides who won. KOM's resolution layer is built around a single principle: the oracle should refuse to sign unless the data behind the outcome is genuinely reliable. It's not enough to read one price and pay out — the protocol cross-checks, gates on confidence, and waits.

Two independent sources, cross-checked

For crypto markets, KOM doesn't trust a single venue. The closing measurement is cross-checked across two independent exchanges — Coinbase and Kraken — and the oracle only acts on a price the two venues agree on. A single exchange can wick, lag, or be manipulated for a moment; two unrelated venues agreeing is a far harder thing to fake. For weather markets, the equivalent source is a meteorological data feed, read once at resolution to settle every temperature bucket at that close.

The confidence gate

Before the oracle signs anything, the measurement passes through a confidence gate. If the data source has fallen back to anything other than a live, cross-checked feed — a cached value, a demo source, a single venue that lost its counterpart — the gate blocks the signature. No live data, no resolution. The market simply stays open for settlement until reliable data is available again. The oracle's only real risk is mis-resolving from bad data, so the system is designed to fail closed: it would rather wait than sign on a number it doesn't trust.

Propose, wait, finalize

Resolution isn't a single instantaneous act. It runs in three phases, preserving a window for scrutiny before money moves:

The oracle proposes an outcome from the cross-checked data, a challenge window elapses during which the proposal can be scrutinized, and only then does the oracle finalize — signing the settlement transaction that the BetLock covenant requires. Remember: the covenant won't release a single sompi without a valid oracle signature, so this is the one gate every payout must pass.

The trust model, stated honestly

On testnet today, the oracle is a single authorized key — the holder of the schnorr private key matching the oraclePubkey baked into each BetLock at compile time. We don't dress this up: v1 is an honest single-oracle model, gated by cross-checked data and a challenge window, but ultimately one signer. The covenant is oracle-gated, not trustless, and we'd rather say so plainly than overclaim.

The mainnet path replaces that single key with a multi-signature oracle — a set of independent price providers, with a formal dispute window before final settlement. Because the covenant only checks for a valid signature against a baked-in pubkey, upgrading from one signer to a multi-sig is a change in who holds the key, not a rewrite of the contract. The final design will be locked and published in the whitepaper before mainnet launch.

Architecture.

KOM is four moving pieces: a browser client where users sign their own bets, a Next.js server that derives addresses and forwards transactions, the Kaspa testnet node that holds the canonical state, and a 60-second cron that creates new markets and settles closed ones. The browser never sees the server's keys. The server never sees the user's keys. The chain mediates everything.

BetLock & ShareToken.

A KOM market is made of two on-chain primitives: BetLock covenants that hold the stake pool, and ShareToken UTXOs that prove ownership of individual positions. They're separated because the pot needs to be sweepable by the resolver in a single transaction, while ownership has to remain attributable per-bet. One pot, many receipts.

BetLock — the per-side pool

Each market deploys a fresh pair of BetLock covenants — one for YES, one for NO — compiled at market-creation time using Kaspa's Silverscript covenant language, with three constructor arguments:

The compiled output is a 65-byte script that produces a unique kaspatest:… address. Every bet on the YES side of a market lands at the same YES address; every NO bet at the sibling. Together the two addresses are the market's pot — verifiable by anyone on a block explorer. The script enforces a single rule: this UTXO can only be spent by a transaction including a valid oracle signature attesting to the outcome. No oracle signature, no spend. That's the entire contract.

ShareToken — the per-bet receipt

Every bet creates a second covenant UTXO holding 2 KAS (Kaspa's minimum-UTXO dust) at a ShareToken address keyed by (ownerPubkey, marketId, side, shareAmount). This is your proof-of-bet, spendable two ways: by you, with your schnorr signature, to redeem winnings or list on the secondary market; or by the settlement transaction at maturity, which consumes losing-side ShareTokens in the pro-rata payout. Because the receipt is on chain and tied to your pubkey, your position is recoverable from any wallet — you don't need KOM's frontend to claim.

A single bet transaction

When you place a bet, KOM constructs one transaction with three outputs:

One transaction. Three outputs. Two land at on-chain covenant addresses you can inspect; the third is your change. The transaction is signed entirely in your browser — your private key never leaves your device. The server only forwards the signed bytes to kaspad.

Bet lifecycle.

Here's exactly what happens when you click YES on a market. Five steps, all visible in your browser's network tab, all ending in a single transaction that lands on chain within ~1 second.

Market state machine

A market moves through five states: Created when the cron compiles its BetLock artifacts; Open once published and accepting bets; Closed the moment its closesAt passes; Settling when the next cron tick computes the outcome and broadcasts payout; Resolved once payout confirms. After 24 hours, markets are pruned to an archive.

Why Kaspa.

Building a prediction market on Ethereum-family chains forces compromises. Block times too slow to settle 5-minute windows. Gas that eats any bet under $10. MEV bots front-running high-information resolutions. The workaround — moving to L2s — introduces a new trust problem: the sequencer, the bridge, the upgrade authority. The cure is worse than the disease for a protocol that's supposed to be trust-minimized. Kaspa solves the underlying problem instead of layering trust on top of it.

You can build a prediction market on any chain. You can only build this protocol — sub-minute markets, native UTXO custody, no bridges, no L2 — on Kaspa. That's the bet.

Roadmap.

KOM is live on Kaspa testnet-12 today, running the full bet-and-settle loop end-to-end. The path to mainnet has four checkpoints. Each one is gated on real evidence, not a calendar.

Questions.