NFT raffle
One winner drawn from a committed entry list, every entry weighted the same.
Live on devnet
Nine scenarios. One primitive.
Each card below is a real call into the engine. Press the button and the rules are committed on-chain, the program resolves them, and you get a transaction signature that replays to the same result for anyone who checks it. No key, no wallet, no signup — this page talks to a public demo endpoint.
Scenarios
Multi-winner giveaway
Three distinct winners in a single call, returned as an ordered list you can pay out against.
Ticket-weighted raffle
Weights are ticket counts. More tickets means proportionally more chance, fixed on-chain before the draw.
Trading competition
Top two by committed PnL. Ties break on input order, so the ranking reproduces byte for byte.
Lowest-bid contest
The smallest committed bid takes the lot. Same ranking kernel, read from the other end.
Guess the value
The prediction nearest the target wins. The target is committed alongside the entries, not chosen after.
First-come airdrop
The first three of a registration-ordered list. No randomness involved, and still fully replayable.
Loot box drop table
Rarity tiers carry the weights. Players can read the drop table before the roll and check it after.
NFT mint allocation
Five slots pulled from an oversubscribed allowlist, with the full list committed before allocation.
Conditions
Multi-leg conditions, scored deterministically.
When the outcome is a combination of proven facts rather than a pick from a list, the engine scores each entry against the committed conditions. Same kernel off-chain and on-chain: the bytes below are what resolve_conditions recomputes.
Three entries, two legs each, scored against two settled fixtures. The response carries the ranking, each entry's commitment hash, and the exact artifact bytes.
Scoring only — this call writes nothing on-chain. The full commit → resolve path runs under a partner key.
Sortition
Sortition by claim, step by step.
The cards above resolve in one call. This one takes four: create the draw, register a ticket commitment, seal against slot hashes that do not exist yet, then claim. Same public demo endpoint, same operator signing server-side — no key here either.
Derived in your browser as sha256(secret ‖ ticket_id ‖ draw_id) — the same preimage the program recomputes when the ticket is claimed. The secret never leaves this page until step 4. The threshold is set to half the 256-bit space, so a ticket wins about half the time.
Responses appear here.
Sealing cannot be rushed: the draw commits to three slots roughly 40 seconds ahead, and the program refuses to seal until those slot hashes exist. That wait is the point: at registration time the seed does not exist yet. A validator that produces one of those slots keeps limited influence over its hash; the spec puts numbers on it.
More paths
Beyond a single call.
The cards above resolve in one request and the console right above this takes four. What is left: draws over lists too large for one request, and one entropy source that is implemented but not deployed.
implemented · not deployed
Unicorn-G entropy
An alternative entropy source for the same draw: the seed arrives with a proof the program verifies on-chain, and a forged one is rejected before anything is sealed. No button here — such a draw does not reproduce through the public verifier yet, so putting it next to the cards above would promise more than it delivers.
partner API
Merkle-committed snapshots
Upload the participant list in chunks; the server publishes it, commits its hash, Merkle root and address on-chain, and draws on future slot hashes. Anyone replays the draw from the published list and checks any address with an inclusion proof against the on-chain root. Measured on devnet with 10,001 participants in 23 s. No button here: it needs a partner key.