Markets that resolve
in minutes.

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.

Because the odds are just the pool ratio, KOM can show you when the crowd is mispricing a market. Every market surfaces an expected-value signal — the gap between an independent probability estimate and the pool's implied odds — alongside a pool-health grade for liquidity and balance. It's information, framed as disagreement between model and crowd, never a recommendation. The decision stays yours.

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. For sports markets, the source is the official final score from a sports data feed — and a game that doesn't finish cleanly doesn't get force-settled.

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.

The same principle governs sports. A game that's postponed, suspended, or hasn't reached a final score doesn't get a forced outcome — the market voids and every stake is refunded in full, no fee. The refund path runs through the same covenant as a normal payout and has been proven on chain. Failing closed means nobody loses a bet to an event that never properly happened.

Event markets: propose, wait, finalize

Price markets settle instantly against a signed feed the covenant checks on chain (above). Event markets — where the outcome is a judgement, not a number — take a slower path that preserves a window for scrutiny before money moves. It runs in three phases:

For price markets, the covenant now verifies the settlement itself. A signed price feed is checked inside the script, on chain, against a pinned public key — and the covenant releases the pool only if that signature is valid over the exact market predicate (asset, threshold, comparator, close time). KOM signs nothing and holds no key over the pool. A forged verdict, a wrong amount, or a redirected payout are all rejected by the script, not by us.

The trust model, stated honestly

Live on testnet-10 today: price-market settlement is trustless at the script level. Funds sit in a Silverscript covenant (PoolReleaseFeed) that verifies a Feed-signed price verdict on chain and pays the winning side pro-rata. We proved it end to end with real settlement transactions — created a market, bet through the app, and let the covenant release the pool against the signed verdict. KOM's key never touches it. There is no operator signature on the payout.

Event markets (weather and similar) settle by the same mechanism, gated on a signed attestation with a public challenge window instead of an instant price verdict — released by the covenant, not by us. During migration, some market types still route through the earlier oracle-signed path; those are being moved onto the covenant-verified model, and we'll say plainly which is which rather than blur the line.

The feed itself is what hardens on the way to mainnet: from a single signing key today to a multi-source signer set with a formal dispute window. Because the covenant already checks the signature on chain against a baked-in key, that is a change in who signs the feed — not a rewrite of the contract. The final design will be locked and published in the whitepaper before mainnet.

Roadmap.

KOM is live on Kaspa testnet-10 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.

Under the hood.

The protocol internals — architecture, on-chain primitives, the bet lifecycle, and why Kaspa is the base layer. For Kaspa builders and the technically curious.

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 that carries a valid signed feed — a price verdict (or, for event markets, an attestation) verified inside the script against a pinned key. For price markets the covenant checks that signature itself and releases the pool with no operator signature at all. No valid signed feed, 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.

Questions.

The attestation layer underneath.

The same engine that resolves KOM's markets is built as a standalone layer — multi-source signed feeds and optimistic assertion with real on-chain bonds. KOM is its first customer; any Kaspa app can be next.

Explore KOM Oracle →