It's arguably our most trust-minimized category yet — the resolution rule points at public, reproducible data, not "trust the resolver."
Live on testnet now (TN12, real on-chain covenant settlement, testnet funds).
New on KOMarkets: Economics markets.
You can now trade on US unemployment & CPI — "Will June unemployment be above 4.1%?" — settled trustlessly on Kaspa.
No house. No custodian. Losers pay winners.
How it works 👇
Markets auto-generate from the official BLS release calendar — a threshold ladder per upcoming CPI & jobs release.
Settlement is covenant-locked on Kaspa L1: same on-chain machinery as our weather & crypto markets. No one holds your funds.
Honest scope: the proof is a known fixture, not my own circuit. No stake, no voting, no Sybil resistance. This is building block proven on-chain; generating an app-specific proof is the next, separate piece of work.
Verified a Groth16 zero-knowledge proof on-chain on #Kaspa TN12 — consensus ran the ZK verify opcode (KIP-16, OpZkPrecompile) as a covenant spend condition and released funds only because the proof checked out
Not a DVM, not a tally — the verified primitive you'd build one on. 🧵
v1 tx mechanics, for anyone reproducing: version=1, input.computeBudget≈1410 (to cover the units), sigOpCount=0. The node taught me each gate via its own rejection messages.
That's the trusted-backstop phase and it's the weakest part of the model — I won't call it anything else. The whole operator→federated→native-voting ladder exists because "a random person (me) picks" is not acceptable as an endpoint, only as a v1 starting point.
I hope you don't mind me reposting our conversation as such, but I like when there is more visibility for the #kaspa community. Please excuse me if I'm blunt at times, but these questions should help you understand the shortcomings of certain oracle models, and help you improve yours.
"If disputed, it escalates to the resolver" -> who is the resolver
"The feed finds the largest cluster of sources that agree within a tolerance" -> what if I pull up 50 exchanges and all make them agree on a ridiculous price, do you hand pick exchanges, if so how do you chose them ?
median -> how do you differentiate an exchange being more rapid (eg. first one to dump if someone sells there before arb is closed) from it being an “outlier” and disregarded from the median
What exchanges did you choose for $KAS ?
Trust model -> so you take from many sources, and if there is a dispute a random person (you) gets to choose what the correct price was ? I know you have assumed this as a current layer, but it’s an important aspect, who solves a dispute (cf. same question as above)
For the answer to my previous questions (thanks for putting those in the link)
- Do we agree any CEX can be cheaply manipulated (the API is centralized after all) ? In that case aren’t most sources bad ? Agree for the derived feeds and ambiguous methodology.
- Multiple venues are queried -> which ones. What happens if no value is published, if your oracle is confused it just waits until it’s bak to normal ? In the case of the 10/10 of last year doesn’t that mean your oracle wakes back up once prices have definitely crashed to the lowest ? Okay for no volume weighing (even tho this is problematic), why 0.8% ? This seems pretty large imo.
- You admit this is still something you’re working on, fair
- Again, you’re honest, fair
finally, a Schnorr signature can prove data came from Binance only if binance themselves sign the data with a key you trust. So this model doesn’t prove you took the data from the correct source. The signature only proves that you CLAIM you took it from a certain CEX.
Net: v1 is an honest optimistic-attestation layer with a single operator and conservative aggregation, live on testnet. Several things you raised are limitations I can't wave away — they're documented now rather than hidden.