Ask the awkward questions first.

Arithmetic does. After ticket sales close, a drand Quicknet beacon publishes one BLS signature for a round number that was committed before sales opened. The signature is hashed into a seed, and every ticket gets sha256(seed + coin_id + index). The smallest hash wins. The comparison runs inside the Chia puzzle, so a payout transaction that names a different winner is simply rejected by the network.

We cannot pick the winner, and neither can a miner, the API, or this website.

The pool is not an account we control — it is a coin locked by a puzzle. That puzzle only accepts a payout that pairs with the table’s leaderboard result, and it only creates coins for destinations fixed when the table was published: the three winners, the settler’s bounty, the jackpot reserve and the next table. There is no branch that pays an arbitrary address.

The one thing the operator does receive from ticket money is the week’s final share, the published share of the final table’s pool, and it is paid by that same puzzle to an address published before the week starts.

Chia’s consensus confirms it, the same way it confirms any other coin. There is no private ledger and no “raffle server” that decides outcomes. A settlement is an ordinary transaction: the network runs the puzzle, checks the beacon signature, checks that the coins created match the rules, and either includes the transaction in a block or rejects it.

Our bot has no privileged position in this. It just happens to be the program that usually submits the transaction first.

Four things, plainly:

The drand network. The single assumption behind the draw is that a threshold of League of Entropy nodes has not colluded. If it does collude, the beacon stops being unpredictable. If drand stops publishing at all, no table can be drawn — tickets become refundable instead.

Chia itself. A consensus failure is out of our hands.

The published genesis. You are trusting that the addresses on this site are the ones deployed on chain. That is checkable — see “How do I verify a draw myself?” — and it is worth checking once.

This website. It can be offline, wrong or replaced. It never holds funds, and nothing here is required to play or to get paid.

No, because the beacon that decides the table is published after ticket sales close, with a margin of a published delay on top. Nobody — including us — can know the seed while a ticket can still be bought.

The margin is not decorative: a Chia block timestamp may run ahead of real time, so the gap is set at three times that allowance.

Sending dust to the pool address does not create tickets: a ticket is a coin at an address derived from the buyer, not a transfer. Dust only makes settlement slower, and the settlement driver merges coins in bounded batches and ignores amounts below one ticket price.

That is why each table has a published seat limit — currently a published number of ticket coins. It is not an arbitrary cap; it is the number the settlement can still finish within the claim window.

It can compete for the bounty, and that is the intended design. It cannot change the result: whoever submits the payout must submit the ranking the beacon produces, or the puzzle rejects the spend. A losing race costs the loser a network fee and nothing else.

Then the pool does not vanish. After the claim window plus a published delay, anyone may sweep the remaining pool forward into the next table, and unclaimed tickets stay refundable to their owners. The sweep branch has to prove the table was actually settled or that it never played; it cannot be used to empty a table that is still being paid out.

The tables already deployed keep working, because settling one requires no permission from us. The driver that does it is public, and the bounty exists precisely so that somebody has a reason to run it. What stops is new epochs: a new table needs a new genesis deployment.

Sage on Testnet11, connected over WalletConnect. The site never sees your seed phrase or private key: it builds an unsigned transaction, Sage shows it to you, and only your approval creates the ticket.

Check two things in the Sage dialog before approving: the ticket amount, and that the destination matches the ticket address shown on the table page. A dApp name proves nothing — anyone can copy a name.

No. A transfer to the pool address is a donation: it increases the prize and gives you no entry. A ticket lives at an address derived from your address and the table, which is why buying is a constructed transaction and not a payment.

If you meant to sponsor a table, use the sponsor address instead — it also gives you the public mention.

Up to the published maximum in one approval, and they arrive as a single coin carrying that many entries. Each entry is ranked separately — a coin with ten tickets has ten independent chances, not one.

The limit is a capacity decision, not a technical wall: seat count is measured against the heaviest purchase a table must still be able to settle.

Almost always because some of your coins are still reserved by an earlier transaction that has not been confirmed yet. The wallet shows you the total balance, but it will only hand spendable coins to a new transaction.

Wait for the next block and try again. The storefront now tells these two cases apart and says which one you are in.

The rule is the coin’s confirmed birth timestamp, not the moment you pressed the button. If the coin was confirmed before close, it plays. If the transaction landed a block too late, the ticket is valid but cannot be drawn on that table — it becomes refundable to your address after the refund boundary, a published delay after the claim window.

The purchase transaction itself carries a deadline condition, so a badly delayed bundle is dropped by the network instead of creating a late ticket.

A ticket belongs to exactly one table, because the table’s identity is embedded in the ticket address. A ticket bought for a table that has already been drawn cannot enter the next one; it is refundable to the address that paid for it.

Archived tables stay inspectable on this site for exactly this reason: you can look up any past table and see the state of your ticket.

Nothing. The payout transaction creates a coin directly at the address that bought the ticket. There is no claim button, no withdrawal form and no address to give us — if there were, that would be a place where funds could get stuck.

The draw does not happen at all, and no prize is promised to anyone. Ticket money returns: any valid unclaimed ticket can be refunded, and the refund can go only to the address embedded in the ticket, so anyone may submit that transaction on your behalf without being able to redirect it.

The pool itself — sponsor money and anything rolled over — moves on to the next table intact.

Because a pool and a draw are different things. A table with no valid tickets at all settles without a winner and hands the whole pool to the next table — the table page says this in words and shows dashes instead of prizes, and the payout transaction on chain shows exactly one output. Fewer tickets than the full-pool threshold is a different case: the draw still happens and winners are paid, but from ticket money only — the sponsor and rollover portion rolls to the next table intact.

Whoever submits the valid settlement first — that is the whole rule. It is the published share of the pool, and it is the pay for doing a validator’s job: reading the chain, ranking the tickets, merging the pool and pushing the transaction that pays everyone else.

Today that is usually our bot, and it earns the bounty the same way anyone else would — by being first, not by being ours. If you run the public driver and win the race, the bounty is yours.

Three independent steps, none of which needs our API:

1. Get the beacon. Fetch the signature for the table’s committed round from any drand relay — chain published in the epoch. The relay cannot choose it; it is a threshold signature.

2. Recompute the ranking. Hash the seed with each ticket coin id and index and sort. The repository ships this as a standalone script that talks to drand and to a Chia node, and not to our backend.

3. Read the payout. Look up the pool coin in any block explorer and compare its outputs with what the Verify page lists. If those disagree, believe the chain.

Each table publishes its pool address, its leaderboard singleton and the deploy transaction of its epoch. The deploy transaction is on chain and it created those singletons; if a published address were invented, no coin at it would exist.

Archived tables keep the addresses they were deployed with, stored alongside the epoch — recomputing them from today’s code would silently rewrite history the moment the code changes.

The chain is right and the site has a bug. Everything shown here is a convenience rendering of on-chain data; it holds no authority, and the payout has already happened whether the page renders it correctly or not.

Please report it — several defects on this list were found exactly this way.

It adds money to the prize and buys a public mention on that table. Of a sponsor transfer, the published pool share goes into the pool and the published listing share to the operator as the listing fee. That split is enforced by its own small puzzle, so the money can leave the sponsor address in no other proportion.

Sponsor money only becomes playable when the table reaches its ticket threshold. Below it, the sponsor portion rolls forward to the next table intact rather than being paid out or returned. The mention is shown from one ticket price upward; smaller transfers still reach the pool but buy no listing.

No. Sponsor money changes the size of the prize and nothing else. It creates no ticket, no rank and no ability to see the beacon early.

Not yet. This deployment runs on Chia Testnet11, and TXCH has no monetary value. Treat everything here as a public rehearsal — including the failure cases.

No. There is no operating company, no licence and no jurisdiction in which this is registered as gambling. If that matters where you live, and it might, this is not for you.

There is no account, no email and no tracking. What exists is what the chain records: coin addresses, amounts and times, public to everyone including us. A wallet address is a pseudonym, not anonymity.