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 guarantee — at registration time nobody, operator included, can know the seed.
More paths
Beyond a single call.
The cards above resolve in one request and the console right above this takes four. What is left is one direction that is still on paper, and one entropy source you can select per draw.
implemented · opt-in
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.
not shipped
Merkle-committed snapshots
Commit a participant snapshot as a single root and hand every winner an inclusion proof, so a draw over hundreds of thousands of addresses stays one on-chain artifact. Designed, not shipped.