Bringing truth on-chain,
at Kaspa speed.
Every app on a programmable Kaspa needs a way to bring real-world and market data on-chain. KOM Oracle is that layer: multi-source signed feeds and optimistic assertion backed by real on-chain bonds. Live on testnet-10 today — and honest about exactly where trust sits.
Two services, one attestation layer.
KOM Oracle started as the resolution engine for KOM's own prediction markets. It's built as a standalone layer so any Kaspa app can use it — KOM is simply its first customer.
Feed — push data
Continuous values aggregated across multiple independent sources. Each value is cross-checked: sources must agree within tolerance, or no value is published. Every reading is schnorr-signed by the oracle — proving the value is the oracle's genuine attestation and unaltered since signing (not a proof of which exchange it came from) — and persisted so a market can ask "what was the value at time T?" at settlement.
Assert — optimistic truth
For discrete real-world outcomes. A proposer asserts an outcome and posts a bond — real KAS locked in a Silverscript covenant on L1. A challenge window opens; if undisputed, the assertion finalizes. If disputed, it escalates to the resolver. Winner takes the loser's bond.
The assertion lifecycle.
An optimistic oracle assumes honesty by default and only escalates when challenged — fast in the common case, secured by economics in the rare disputed one.
The bond is a real covenant UTXO on Kaspa L1. The undisputed path reclaims it after an on-chain timelock (enforced by the covenant itself, via relative sequence locks). The disputed path lets the resolver direct the bond to the winner. Both paths are proven on testnet — see Verify it yourself.
How the feed cross-checks.
Multiple venues are queried in parallel. The feed finds the largest cluster of sources that agree within a tolerance and returns that cluster's median — outliers are dropped, and if no cluster agrees, no value is published rather than a possibly-bad one. The number of agreeing sources differs by asset and domain — and we state which below, honestly.
Prove the source, not just the answer.
Every oracle's hardest problem isn't the contract — it's the source. A centralized exchange never signs that its price is correct. Provenance proves a value came from its named source, unaltered, via zkTLS — without the source's cooperation — then anchors that verified record on Kaspa L1.
What this removes from trust: the KOM relay — and, with in-covenant verification, the off-chain verifier itself. The attestor signature is checked by Kaspa consensus, not taken on our word. What it does not do: make a dishonest source honest. Provenance proves origin, not truth — a manipulated source still serves a manipulated value. We trust the source and Reclaim's attestor network, not the relay.
It's built for point-in-time settlement reads — proving what a source served at an exact moment (a price tick you can't re-query later), not for the live ticker. The next-phase capability — verifying the attestor signature inside the covenant, so Kaspa consensus enforces it rather than our relay — is now demonstrated on testnet-10: a real attestor signature over a live Kraken price, verified in-covenant via a RISC0 proof through Kaspa's OpZkPrecompile (KIP-16). It's a demonstrated milestone, not yet wired into the live Feed — proving runs off-machine and each verification is settlement-grade. A first provenance record is anchored on testnet, and the in-covenant verification is a redeemable testnet transaction — see Verify it yourself.
Settle the pool, enforced by the chain.
For verifiable markets, resolution shouldn't end at a signed value — it should end at funds that can only move one way. KOM's settlement covenant locks a market's pool in a Kaspa L1 covenant with two spend paths, and the chain itself enforces which one is valid.
Settle by proof. To release the pool, a transaction must carry a resolution proof — a RISC0 receipt verified by Kaspa consensus through OpZkPrecompile — and its outputs must exactly match the payout that proof committed to. The covenant rebuilds the payout set from the transaction's own outputs, hashes it, and compares it to the proof's commitment. Wrong recipient, wrong amount, or wrong proof, and the script rejects the spend. The payout isn't computed by us and trusted; it's re-derived and checked on-chain.
Reclaim by timelock. A market that can't resolve must never trap funds. The same covenant has a second branch: after a relative timelock, the pool is reclaimable with a signature — a refund path that needs no proof and no permission.
What this changes: payout enforcement moves from “the operator computes it” to “the chain rejects any payout that doesn't match the proof.” Combined with in-covenant provenance verification above, a verifiable market can resolve and settle with the trusted step removed from the payout itself.
Honest scope. Proven end-to-end on testnet-10 — a real proof-gated settlement and a timelock reclaim, both spending one combined covenant (see Verify it yourself). It's demonstrated on a test pool, not yet wired into live markets with real bettor funds, and proving runs off-machine (settlement-grade, not a hot path). The mechanism is proven; integration into the live resolver pipeline is next.
More than crypto.
An attestation layer is only as useful as the truth it can bring on-chain. KOM Oracle already spans three domains — and each has a different, honestly-stated source model.
| Domain | Sources | Cross-checked | Status |
|---|---|---|---|
| Crypto prices | BTC/ETH/SOL: Coinbase, Kraken, Binance (3) · KAS: Kraken, MEXC, Bybit (3) | Curated allowlist | Live · TN10 |
| Weather | Public meteorological data | Single primary source | Live · TN10 |
| Electricity prices | Grid/market data (single provider) | Single source today | Live · TN10 |
We won't dress this up: only the crypto feed is genuinely multi-source cross-checked today. Weather and electricity run on a single data source for now — fully functional, but not yet cross-validated across providers. Broadening them to multiple independent sources is on the roadmap, and we'd rather tell you exactly where each domain stands than imply uniform robustness.
Verify it yourself.
Bonds are real covenant UTXOs on Kaspa testnet-10. Here are live covenant addresses you can inspect on the explorer — the bond was funded, then spent back out through the covenant's own logic.
Each address shows the bond UTXO being funded and then spent — the covenant releasing the locked KAS only through its reclaim (timelocked) or resolve (resolver-directed) path. The Silverscript covenant, its compiled script, and the spend logic are reproducible from the same compiler the Kaspa testnet uses.
The trust model, stated plainly.
The same honesty KOM applies to its own oracle applies here. Today, disputes are resolved by a single operator key. That is a trusted backstop, not a trustless mechanism — and we say so. What matters is that the path to reducing that trust is designed in, not hand-waved.
Today · Operator-adjudicated
A single resolver key settles disputes. Bonds are held on-chain by the covenant; the timelocked undisputed path needs no trust at all. Disputes need trust in one operator. Honest label: trusted backstop.
Next · Verifiable-dispute resolution
For markets whose outcome is provable — prices, on-chain facts, anything checkable via a signed feed value or a zkTLS provenance proof — disputes settle by verifying that proof in-covenant, with no adjudicator key. This is the same in-covenant verification already demonstrated for provenance. KOM's front-end lists only verifiable markets; subjective outcomes are out of scope, not hand-waved.
Future · Native-voting-ready
Kaspa's own research into consensus-level oracle voting points toward a credibly-neutral dispute primitive at the base layer. KOM Oracle's dispute resolution is built behind a swappable interface, so it can delegate to that native mechanism when it ships — without rearchitecting the layer above.
One thing we explicitly do not do: launch a token. A decentralized dispute mechanism is a hard problem the Kaspa ecosystem is actively researching at the protocol layer. We'd rather plug into a credibly-neutral primitive than mint our own and call the result decentralized.
A typed client.
Consume the oracle from a thin TypeScript SDK. Feed values verify their own signatures; assertions walk the request → bond → resolve lifecycle.
// signed, cross-checked feed value (signature auto-verified)
const btc = await oracle.feed.get("BTC/USD");
// btc.value, btc.sources, btc.agree, btc.sig …
// open an optimistic assertion
const { requestId } = await oracle.assert.request({
question: "Did event X occur by the deadline?",
outcomeSpace: ["YES", "NO"],
bondAmount: 100_000_000, // sompi
windowMs: 7_200_000, // challenge window
});
// the oracle returns the covenant address the proposer funds,
// then verifies the bond is real on-chain before accepting.
const { bondAddress } = await oracle.assert.bondAddress(requestId, proposerPk);The feed productizes multi-source cross-checking; the assert service handles the optimistic lifecycle and on-chain bonds. The dispute backend is swappable behind a single interface — your integration doesn't change as the trust model decentralizes.
The source problem, honestly.
Every oracle's real weakness is its data inputs, not its smart contracts. The Polymarket weather markets that resolved on a single tampered airport sensor are the live example everyone points to — and rightly so. Here's where KOM Oracle actually stands on the questions that matter, including where the honest answer is "not yet."
What do you consider a bad source?+
Three things make a source bad. (1) A single physical point an attacker can cheaply manipulate — the tampered airport sensor is the textbook case; swapping to a nearby station just moves the single point of failure. (2) Re-published or derived feeds that inherit an upstream's vulnerability. (3) Ambiguous methodology — two providers reading the same station can report different daily highs from timezone-reset or rounding differences. And to concede a fair point: any single CEX API is itself a trust assumption — the API can be wrong or compromised independent of the real traded price. Multi-source doesn't eliminate that class of risk; it raises the cost (you'd need several independent venues compromised or colluding at once). "Bad" isn't only wrong data — it's data that's cheap to manipulate, derived, or ambiguous.
What does your source testing actually consist of today?+
For the crypto feed: multiple venues are queried in parallel, the largest cluster of sources agreeing within a tolerance is found, outliers are dropped, and if no cluster agrees, no value is published rather than a possibly-bad one. For majors, agreement is required across three venues within 0.5% (Coinbase, Kraken, Binance). For KAS it's now three venues within 0.5% (Kraken, MEXC, Bybit) — KAS isn't on Coinbase or Binance, so we use the venues where it actually has liquidity. With three sources the feed takes a real median and drops an outlier, so a single bad print can be outvoted rather than skewing a pairwise average. This brings KAS to parity with the majors (three venues, 0.5%). Observed cross-venue spread in normal conditions is ~0.1–0.2%, well inside the 0.5% band. Every value is schnorr-signed by the oracle. Important precision (and a fair critique we've had): that signature proves the value is the oracle's genuine attestation and hasn't been altered since signing — it does not prove which exchange the number came from. Proving source provenance would require the exchange itself to sign the data, which CEXes don't. So treat the signature as operator attestation + tamper-evidence, not proof of source. What we do not yet have, and won't pretend to: a formal source-vetting framework, per-source liveness SLAs, statistical outlier modeling, or volume-weighting. Today's test is agreement-clustering and operator attestation — real, but not a complete source-quality methodology.
What if your sources don't capture >90% of price discovery (fragmentation)?+
This is a fair limit. For liquid majors (BTC, ETH, SOL), the venues we query capture the bulk of price discovery. We do not claim that generalizes: for fragmented or thinly-traded assets, a handful of venues can miss where price is actually formed. And source independence matters more than source count — five venues that all derive from one upstream are not five sources. We don't currently weight by volume or audit cross-source independence. For long-tail assets, this is a genuine gap, not a solved problem.
If anyone could add sources, couldn't I flood it with colluding venues?+
Yes — which is why sources are a fixed, curated allowlist per asset, not open submission. You can't register 50 venues and become the "largest agreeing cluster." But this honestly just relocates the trust: now you're trusting our curation. We don't yet have a formal, published criterion for why a given exchange is included — that's a real gap, and "trust the operator's source list" is a weaker position than we'd like long-term.
How do you tell a fast exchange (leading a real move) from an outlier to discard?+
We don't, well. Median-of-the-agreeing-cluster deliberately discards the divergent source — but during genuine price discovery, the divergent venue may be correct (the place the move started, before arbitrage propagates). So our aggregation is conservative by design: it resists a single venue being manipulated, at the cost of lagging real moves and sometimes dismissing the leading edge as noise. For a fast, short-window market that's a real weakness, not just a tunable parameter.
What happens during a violent move — does the feed just go quiet?+
This is the sharpest limitation, and we'll state it plainly. Sources diverge most exactly when price is moving fast. Previously the feed published nothing in that window — going blind during the very event a market exists to price. We've changed that: instead of going dark, the feed now publishes the median of responding sources flagged low confidence, with the full observed spread, schnorr-signed like any other value (the confidence level is inside the signature, so it can't be forged to look certain). Consumers decide what to do with a low-confidence reading. This is a mitigation, not a solution. The underlying reality hasn't changed — venues genuinely disagree during fast moves, and a low-confidence price is still uncertain. What changed is that we surface the uncertainty (signed, with the spread) instead of concealing it behind silence. Whether to settle on a low-confidence value is a risk decision we push to the consuming application, with the data to make it.
What tolerance does KAS use, and why?+
KAS now uses 0.5% across three venues (Kraken, MEXC, Bybit) — the same tolerance as the majors. It previously ran at 0.8% across only two venues, which we'd called a heuristic and weren't satisfied with: a wide band over a pairwise check is easy to skew and has no third source to break a tie. Adding Bybit (a top-liquidity KAS venue) gave a real third reading; measured cross-venue spread sits around 0.1–0.2% in normal conditions, so 0.5% holds comfortably while still catching a genuine outlier. The band is still empirical, not derived from first principles — but it's now backed by three agreeing sources and a median, not two.
Even with the right sources, how do you push on-chain in a decentralized way?+
Honestly: today, we don't. The undisputed bond path is genuinely trustless — the covenant releases funds on a timelock with no signer required. But the attestation itself is signed by a single operator key. That's a trusted backstop, not decentralized resolution. The path to reducing that trust is designed in, and it differs by outcome type. For verifiable markets (prices, on-chain facts), disputes resolve by checking a signed feed value or a zkTLS provenance proof in-covenant — no operator verdict, the same mechanism already demonstrated for provenance. Our front-end lists only verifiable markets. For genuinely subjective outcomes, no covenant can check ground truth; those stay out of scope until a credibly-neutral primitive (e.g. Kaspa's consensus-level oracle-voting research) ships, and the dispute backend is built behind a swappable interface to delegate to it then. See the trust model above. We'd rather state this plainly than claim a decentralization we haven't built.
These are the right questions to ask any oracle. Our answer to several of them is "on the roadmap, not in production" — and we think saying so is more useful than a robustness claim that can't survive a hair dryer.
Roadmap.
No dates we can't guarantee — phases we can defend. Each step is gated by the one before it.
Working attestation layer
Multi-source signed crypto feed, optimistic assertion with real on-chain bonds (both covenant spend paths proven), a typed SDK, and operator-adjudicated dispute resolution. A proof-gated settlement covenant — proof-checked payout plus timelock reclaim — is demonstrated on testnet. KOM is the first consumer.
Broaden and weight sources
Extend weather and electricity beyond a single source to independent cross-checked providers; add volume-weighting and source-independence auditing for the crypto feed; formalize a source-quality methodology.
Verifiable-dispute resolution
Disputed verifiable assertions settle via in-covenant proof — the signed feed value or a zkTLS provenance receipt, checked by Kaspa consensus rather than an operator key. Extends the in-covenant verification already demonstrated for provenance. Subjective markets stay off the verifiable-only front-end.
Native-voting-ready
Delegate dispute resolution to Kaspa's consensus-level oracle-voting primitive as it matures. The swappable interface is already in place; this becomes a configuration change, not a rewrite.
Mainnet
External audit of the Silverscript covenants, removal of all developer-mode logging, and a published, locked dispute design before any mainnet settlement holds real value.
An attestation layer for Kaspa's next chapter.
If you're building on Kaspa and need real-world or market truth on-chain — prediction markets, coordination markets, DeFi — let's talk. KOM Oracle is live on testnet and looking for its next customer.
aj@komarkets.io →