Resonance futures
Skill NickFlach/kannaka-plugin/plugins/kannaka/skills/resonance-futures
Design and run an agent-native, evidence-settled prediction market — the trust model (who proposes, trades, settles), the propose→open→settle lifecycle, machine-measurable settlement, anti-gaming rules, and the path from play-credits to real money. Use when building a prediction market that autonomous agents originate and settle.From its SKILL.md
npx -y skills add NickFlach/kannaka-plugin --skill resonance-futuresAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
7.4 KB, ~1.6k tokens by cl100k_base, as published. Nobody here has run it
Resonance Futures — an agent-native prediction market
A prediction market run by and for autonomous agents is only trustworthy if it is a market, not a poll: claims are falsifiable and machine-measurable, identity is verified, and settlement is evidence-first and separated from authorship. This skill is the architecture, distilled from building one across a multi-service constellation and hardening it with an adversarial review.
The one-sentence thesis
Labs measure · the Exchange settles · a public ledger witnesses. Keep those three responsibilities in different hands and most of the failure modes disappear.
Trust model — separate the credentials
Give each capability a distinct credential; do not reuse one bearer token for everything.
| Capability | Who | Why it's separate |
|---|---|---|
| Propose a prediction | any verified identity (user or agent) | origination should be open, but attributable |
| Curate — open / reject | the Labs oracle (service) or an admin | opens the measurability gate |
| Trade / vote | any verified identity | one account per verified principal |
| Settle / resolve | the oracle service only | a proposer must never settle their own market |
| Dispute | any verified identity, within a window | a check on the oracle |
Identity provider. Issue short-lived, asymmetrically-signed tokens (EdDSA)
from one provider; every surface verifies them locally against a published
JWKS — no per-request introspection. Harden the verifier: pin the algorithm
allowlist (reject alg=none and HMAC-with-the-public-key confusion), require
exp/iat/nbf, select the key by kid, and fail closed if the JWKS
can't be fetched. Bind an agent token to an identity the provider has proven
control of (e.g. a challenge the agent answers through a channel only it
controls) — never to a merely-observed id. Derive a trader's id from the
verified token sub, never from a request-body string (that's the sybil door).
Lifecycle
proposed → open → settled (plus rejected, disputed).
- Propose — a verified principal submits a statement + a settlement method, attributed to them. It carries no tradeable market yet.
- Curate / open — the oracle applies the measurability gate and, if it passes, opens the market (and pairs a tradeable market if you have one).
- Trade — verified principals take positions.
- Settle — the oracle measures and records the reading (the actual measurement output), sets TRUE/FALSE, and witnesses it.
The measurability gate
A proposal may not open unless it can actually be settled by evidence: either a machine-readable measurement spec (auto-settle) or a named settlement procedure plus a deadline. "Will X be cool?" is rejected at curation, not settled by whoever shows up at the deadline.
A measurement spec is a small, declarative object your settler can execute — e.g. count entities matching a condition in a named external data source at a deadline; settle TRUE if the count meets a threshold. Store the spec with the prediction so settlement is reproducible and auditable.
Settlement — evidence-first and safe
- Record the reading. Every settlement stores what was actually measured, who/what settled it, and when. Push it to an append-only public ledger.
- Early settlement only for monotone, irreversible facts, and only after the condition has held across several consecutive checks — an external signal that can be reverted (a claim that gets undone) must not lock a permanent wrong outcome on a single transient read.
- Partial/ambiguous measurements are a skip, not a settle. A truncated or paginated data read that yields a low count must be treated as "measurement failed → stay open," never as a settlement. Never settle FALSE at a deadline off one unconfirmed read.
- Cross-service consistency. If settlement writes to more than one store (a registry, a ledger, a paired market), use a durable outbox and idempotent, retried deliveries — never fire-and-forget. Otherwise the ledger says TRUE while the market paid FALSE.
Anti-gaming rules (the ones that actually bite)
- No self-fulfilling conditions. If a market participant can cause the measured fact (e.g. "someone builds a building" is trivially caused by a Yes-holder), the market is theft-at-real-money. Require the triggering fact to be attributable to a non-participant, exclude actions by principals holding a position, and/or gate settlement behind independent corroboration.
- Sybil-proof the price. An open, self-registration market's displayed price is trivially forgeable by one actor with N free accounts — never cite it as authoritative signal. Require verified-identity trading (and per-principal position caps) on any market whose price you quote.
- Halt trading before a deterministic settlement, and snapshot the price at the freeze — otherwise anyone who sees the reading flip buys in risk-free.
- Single-flip settlement. Guard the resolve in the database
(
… WHERE resolved = 0+ changed-rows check) so a manual settle racing an automated one can't pay winners twice and mint credits. Guard the debit (… WHERE balance >= cost) so concurrent trades can't overdraw.
Ledger — before any real money
- Double-entry, append-only, hash-chained. Balances are derived from balanced postings, never stored-and-mutated. Each entry commits to the previous entry's hash; enforce no-UPDATE/no-DELETE as a database grant, not an app-code convention. A witnessed settlement is a new superseding row, never an in-place rewrite.
- Integer minor units for money-shaped amounts; keep market prices floating but settle amounts as integers, with one canonical rounding rule.
- The automated market maker is a funded account. Its bounded subsidy is a real posting escrowed at market creation, so payouts don't mint unbacked credit and total value is conserved.
From play-credits to real money — a hard gate
Real-money event contracts are regulated in most jurisdictions. Treat legal review as a launch precondition, not a to-do. Build so the gate is the only blocker: KYC + geo-fencing hooks at the identity layer; custody keys physically separated from the settlement oracle (different box / HSM / multisig, so no single credential both settles and pays); a continuous reconciler that halts settlement on any on-chain/off-chain divergence; and play vs real ledgers segregated and never fungible. Until the gate opens, the market's realness comes from integrity, not stakes — verified identity, measurable claims, evidence-first settlement, and an append-only public record.
Before you build it
This is exactly the "hard to reverse" territory an adversarial design review pays for: identity, settlement authority, and money. Attack the design first — have specialists each hunt one lens (capability/identity, ledger integrity, oracle/market economics, cross-service consistency) for concrete failure scenarios — then implement the survivors.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.