Tickets, funds and rules
Chia coins hold every ticket and pool balance. The published puzzles constrain which tickets count, when each phase begins and where settlement outputs may go.
The draw, without mythology
Unpredictable before close. Verifiable after.
XCH Raffle does not use player secrets, a commit–reveal ceremony, a server random number or a block hash. Each table commits to one future drand Quicknet round before ticket sales, then Chialisp verifies the published signature.
Randomness sourcedrand Quicknet
Ticket scoreSHA-256(seed ‖ coin ID ‖ index)
WinnerLowest score
Architecture at a glance
Two networks. One deterministic bridge.
The raffle separates custody, randomness and execution. No website process is allowed to invent a winner or provide an unverified seed.
A future public input
Quicknet supplies one threshold BLS signature for the round committed by the table. It does not hold funds, select tickets or submit the payout.
The cryptographic bridge
The leaderboard verifies the drand signature inside CLVM, derives one seed and combines it with authenticated Chia ticket coin IDs.
The API is transport, not authority. A relay may deliver the signature and the storefront may summarize the table, but neither can make invalid bytes pass the embedded verifier.
Exact sequence
From published table to final ranking.
The computation is deterministic once the beacon signature exists. That is a feature: independent software must reach exactly the same result as the on-chain leaderboard.
The complete table is fixed
The epoch publishes the ticket price, pool and ticket puzzle hashes, phase times, minimum ticket threshold, payout destinations, Quicknet public key and one future beacon round. Changing any of them creates a different on-chain table.
A purchase creates a ticket coin
Sage signs a normal Chia spend that creates a round-specific ticket. Its immutable coin ID commits to the parent coin, ticket puzzle hash and its amount, which is the ticket price times the number of tickets bought; the owner address is embedded in that ticket puzzle.
The entry set stops changing
Only ticket coins confirmed before the published close belong to the draw. The selected drand round is scheduled after close with a margin, so its signature is not available while valid entries are still being collected.
Quicknet publishes one signature
A threshold of drand participants produces the BLS signature for the committed round message. Anyone may fetch the same bytes from any relay; the relay does not get to choose the signature.
CLVM authenticates the beacon
The leaderboard’s embedded beacon verifier checks the BLS pairing equation against the fixed public key, domain separation tag and round message. Corrupted bytes or a valid signature from another round fail the spend.
Tickets authenticate themselves
Claim transactions are processed in bounded batches. For each claim, the leaderboard reconstructs the expected ticket puzzle and coin ID, then requires the matching ticket coin message before adding it to the count.
Every authenticated ticket gets a score
The verified seed is SHA-256 of the signature. A coin carrying n tickets holds n places: each score is SHA-256 of the seed, the ticket coin ID and the place index 0 … n-1. The singleton keeps the three lowest unsigned hashes; independent software can reproduce the same order.
The pool pays only allowed outputs
After the claim window, anyone may submit finalization. The pot verifies the authenticated leaderboard state, applies the fixed bounty and prize allocation, then sends winner, reserve and rollover outputs only to puzzle-approved destinations.
message = SHA-256(uint64_be(drand_round))
seed = SHA-256(verified_drand_signature)
n = coin_amount / ticket_price
score(i) = SHA-256(seed ‖ ticket_coin_id ‖ clvm_int(i)), i = 0 … n-1
ranking = ascending unsigned score
The first three ranks receive prizes when three or more valid tickets exist. With fewer tickets, the unused winner shares collapse into first place according to the fixed payout rules.
Current Testnet11 boundary. The storefront checks the closing time before signing and again before broadcast, while the census excludes late coins. A consensus-level deadline on the wallet spend that creates a ticket remains a published pre-mainnet requirement.
Committed before entry
What cannot be edited mid-round.
These values are part of the published puzzle chain. A new price, schedule, beacon or destination requires a new epoch rather than an administrator setting.
| Published value | What it controls | After deployment |
|---|---|---|
| Round ID and puzzle hashes | The exact ticket, leaderboard and pool programs accepted by this table. | Immutable for the table |
| Ticket price and k_min | The value of each entry and the ticket threshold required before sponsor value participates. | Immutable for the table |
| Close, claim and refund times | When entries stop, census runs, settlement begins and unplayed tickets may refund. | Immutable Unix timestamps |
| drand key, DST and message | The Quicknet identity and exact future round signature that CLVM will accept. | A different beacon is rejected |
| Pool, reserve and rollover destinations | Where sponsor funds enter and where non-winner allocations are allowed to leave. | Fixed by the round puzzles |
Why an external beacon
Why not use a Chia block hash?
Chia consensus contains challenges, Proofs of Space and VDF outputs, but a Chialisp puzzle cannot read the outside world or inspect the current block height, header hash or VDF output. It can return time and height conditions for consensus to check; those conditions do not return an unpredictable value to the puzzle.
A server could place a future block hash in the solution, but without a native canonical-header condition the puzzle could not prove that the supplied hash belongs to the required Chia block. A block producer also has more influence over block construction and publication than a lottery participant should have over its seed.
Quicknet fits the primitives Chia does expose: CLVM can map the committed message onto BLS12-381, verify a pairing against the pinned group key and reject every other signature. Chia remains the enforcement layer; drand supplies the future public input.
Primary references: Chialisp conditions and environment, Chia consensus challenges and Quicknet security model.
What “random” means here
A precise security claim.
The beacon round is committed before ticket sales open, and its value does not exist yet. drand publishes the signature for that round afterwards, and the puzzle verifies it inside CLVM before any payout is possible. Nobody involved — the operator, a player, a bot or this website — can predict that value or put a different one in its place. One assumption carries the guarantee: that a threshold of League of Entropy nodes has not colluded. Everyone who uses drand relies on exactly that assumption, and it is named here instead of hidden.
drand describes Quicknet as an unchained threshold BLS beacon: a valid output requires enough independent network participants, and future outputs cannot be biased after the distributed key ceremony without changing the group key. XCH Raffle additionally verifies the signature inside CLVM.
Read the primary references: drand protocol specification and Quicknet developer guide.
No hidden preview. Before beacon publication the API returns “unavailable”; it does not display a provisional leader because no valid ranking exists yet.
Failure and trust model
What happens when a component fails.
Safety and availability are different. Invalid data must never move funds, while unavailable data may delay settlement and eventually lead to the published refund path.
| Component | Failure or dishonest action | Protocol outcome |
|---|---|---|
| Storefront or API | Shows stale figures or returns a fabricated signature. | The displayed information may be wrong, but invalid settlement bytes fail CLVM. Verify from chain data or use another interface. |
| drand relay | Returns corrupted bytes or stops answering. | Corrupted signatures are rejected. The same signed round may be fetched from another relay. |
| Quicknet threshold | Enough participants collude or no threshold publishes the round. | Collusion breaks the unpredictability assumption; no signature breaks liveness, not signature verification. Unplayed tickets retain their refund path. |
| Executor | Delays settlement or submits a competing valid transaction. | The executor cannot redirect winner outputs. The accepted P-1 merge race and its rollover effect are documented on the Audit page. |
| Chia chain | A recent transaction is reorganized before finality. | Only coins on the canonical chain count; clients must refresh and reconstruct state from the new peak. |
Independent check
You do not need our server to trust a result.
Every number here — pool, tickets, winners, amounts — is recomputed from Chia coins rather than kept in a database of ours. There is nothing on our side to adjust. That also means the page can lag: you are looking at a snapshot stamped with the moment it was read, and if the node is unreachable the last good value stays on screen instead of an error. And you never have to take our word for it — the Verify page, the open verifier or the chain itself gives the same answer without this site.
A verifier needs the published genesis parameters, authenticated ticket coins from the Chia chain and the committed drand signature. It reconstructs ticket coin IDs, verifies the BLS pairing, hashes and sorts every entry, then compares the expected winners and amounts with the settlement transaction. The project test suite performs the same independent Python-versus-CLVM comparison.