Before t_close
A ticket coin must be confirmed with a birth timestamp strictly before close. Published future tables are already open; each has its own deadline.
Terms before entry
Know the table. Know the flow.
Every table publishes its ticket price, pool, ticket count, sponsor threshold, closing time, future drand round and protocol destinations. A ticket participates only in the table for which it was created.
Operator share of ticket money0% per table
Tickets per approvalup to the published maximum
Maximum winners3 ranks
Numbers on this page are read from the deployed epoch itself rather than typed here by hand: ticket as published, threshold as published tickets, one table every published period, claim window as published, refunds as published after the claim window closes, and at most the published number of ticket coins per table.
Round lifecycle
Four published boundaries govern every table.
There is no separate on-chain start timestamp. Once an epoch is deployed and published, its round-specific ticket puzzles may accept entries until each table’s close boundary. The lobby therefore counts down to close, not to an invented opening time.
The full current epoch is shown as the forward horizon. After its final table closes, another table requires a new genesis deployment.
Before
Close to claim-open
Sales are closed and the committed drand output is still unavailable. No valid ranking exists during this interval.
Until t_claim_close
The verified beacon ranks the tickets. Anyone can claim eligible ticket coins into the round census; the embedded owner and ticket identity cannot be replaced.
After the claim window
Permissionless settlement merges the pool and creates the winner, bounty, jackpot and rollover outputs enforced by the puzzle.
From t_refund
A valid but unclaimed ticket can return its full amount only to its embedded owner address. Anyone may submit that refund transaction.
Entry conditions
What counts as a ticket.
A valid entry is a round-specific ticket coin created before that table’s sales close. Sending TXCH directly to the displayed pool address is a sponsor transfer, not a ticket.
The browser builds the coin spends locally and asks the server to reproduce them byte for byte. Only after that comparison does Sage receive the signing request. Your seed phrase and private key never leave Sage; the page receives the approved signature. In Sage, verify the full ticket output address, ticket amount and the change output marked “You.”
Testnet11 only. This deployment uses TXCH. Do not send mainnet XCH to any Testnet11 address.
| Condition | Rule | What it means |
|---|---|---|
| Ticket price | Fixed per epoch and shown on each table | Changing price requires a new published genesis; there are no price tiers. |
| Network fee | Shown separately during purchase | It goes to the Chia network, not into the table pool or to the operator. |
| Sales deadline | Ticket coin birth time must be strictly before close | A coin created at or after close cannot enter the draw. |
| Payout address | Curried into the ticket | Prize and any late refund are constrained to the player address used during purchase. |
| Missed claim | Unclaimed ticket can be refunded after the published refund time | Anyone may trigger it, but the full ticket amount can only return to its embedded owner address. |
| Table capacity | A finite number of seats, counted in purchases | One purchase takes one seat whether it carries a single ticket or the maximum. The live count is shown on the table; when it is reached, the table stops selling. |
Table capacity
A table has a published number of seats.
A seat is one purchase, not one ticket. Every purchase becomes exactly one coin on chain, and the settlement cost of a table is driven by how many coins it must process — not by how many tickets those coins carry. Buying many tickets in one purchase therefore costs the table one seat, the same as buying one.
The capacity is not a chosen marketing number. It is derived from the claim window of the epoch, the measured cost of a census batch and the merge limit of the pool, taking the heaviest purchase the table allows. It is deliberately conservative: the figure must hold even if every seat is filled with a maximum-size purchase.
| Condition | Rule | What it means |
|---|---|---|
| Unit of capacity | Coins, not tickets | Seats used and seats total are both shown above the buy button during sales. |
| Full table | Selling stops in the interface | The buy button is disabled and names the reason; other open tables are unaffected. |
| Bought past capacity | Refund, not loss | Chia is permissionless, so an entry created outside this website can still exceed the capacity. It cannot be drawn, and its full amount returns to its owner address after the published refund time. |
Money flow
Where ticket money goes.
The table first sets aside a 1% executor bounty. The remaining 99% is the prize base. With three or more tickets, the fixed shares below use that base. Integer rounding is absorbed by the next-round output so every mojo remains accounted for.
the published share of the prize base when at least three tickets exist.
the published share of the prize base when at least two tickets exist.
the published share of the prize base when at least three tickets exist.
Paid to whoever submits the valid settlement first. It is the pay for doing the work a validator does: reading the chain, ranking the tickets and pushing the payout transaction. Anyone may take it, including you.
the published share of the prize base, routed to the published pool of the week’s final table. On the final table itself this share has nowhere further to go — see the card beside it.
The residual seeds the next table of the epoch and also absorbs integer rounding, so no mojo is lost.
The final table has no next table and no later final, so the jackpot and rollover shares merge into one coin and leave the raffle to the operator reserve address published before the week starts. This is the only payment the operator receives out of ticket money, and it happens once per week.
An ordinary table pays the operator nothing out of ticket money, and the weekly final pays the operator the published share of its pool. Both statements are needed; either one alone would be misleading. Every share above is fixed in the pool puzzle, and on an ordinary table none of them is the operator: the money moves between winners, the settler and the next tables. The week’s final table is the exception, because the chain of tables ends there — its jackpot and rollover shares have no later table to seed, so they merge into one coin and go to the published operator reserve address. Sponsor money is separate again and pays the operator the published share — see below. Every one of these destinations is visible in the payout transaction, and the Verify page lists them coin by coin.
Sponsor money
Where sponsor money goes.
Sponsorship is not ticket money and follows a different, published route. Each table offers two addresses, and they are two different products.
| You send to | You get | The money |
|---|---|---|
| That table’s sponsor address | Your name and optional link on that round | 80% into the table pool, 20% to the operator. Below one ticket price nothing is taken and no mention is shown. |
| That table’s pool address | Nothing; the contribution is anonymous | 100% into the table pool. |
The 20% is a listing fee, not a cut of the game. It is charged only on contributions that earn a mention, it is fixed in the sponsor puzzle rather than promised in text, and it never touches ticket money. Anyone can read the share directly from the puzzle at the published sponsor address.
Fewer entries
Empty prize places do not disappear.
One valid ticket: first place receives 96% of the prize base.
Two valid tickets: first receives 83% and second receives 13% of the prize base.
Three or more: first, second and third receive 74%, 13% and 9% of the prize base.
No valid tickets: no winner, bounty or jackpot allocation is promised; the whole pool rolls forward.
Full-pool threshold
Sponsor funds play only when the published threshold is met.
Ticket-funded value remains playable even below the threshold. Sponsor and seed funds join the playable pool only when the table reaches its published k_min ticket count. Otherwise, that sponsor/seed portion rolls forward intact. The deployed epoch currently requires the published number of tickets, and the storefront reads that value from each table rather than hard-coding it.
Protocol actions
Settlement is a sequence, not a private button.
Several on-chain transactions may be needed after sales close. Anyone can submit a valid next action; none of these actions gives the submitter discretion over ticket ownership, ranking or winner destinations.
| Action | When and who | What the puzzles enforce |
|---|---|---|
| Deploy epoch | The publisher before any advertised sale | One atomic transaction creates and immediately spends every leaderboard launcher, fixing singleton IDs, table times, price, pool routes and future beacon rounds without leaving a launcher for takeover. |
| Create ticket | The player approves one Sage transaction before t_close | A round-specific ticket coin is created with its payout owner fixed and its amount set to the ticket price times the number of tickets bought. A transfer to the pool is not a ticket. |
| Claim / census | Anyone during the claim window | The ticket authenticates its own coin identity, moves its value into the pool and submits one score-bearing place per ticket it carries to the singleton leaderboard. |
| Merge pool | Anyone before payout | Fragmented pool coins can be combined only back into the same pool puzzle. The happy path merges the whole known bank before paying. |
| Finalize / payout | Anyone after t_claim_close | The leaderboard finalizes once; the pool accepts its top-three result and creates only the fixed winner, bounty, jackpot and rollover outputs. |
| Refund ticket | Anyone from the published t_refund | An unclaimed valid ticket returns its full nominal amount only to the owner embedded in that ticket. |
| Sweep remainder | Anyone one hour after t_claim_close | Late additions or pool coins omitted from payout move only to the next published pool destination; they cannot be redirected to the caller. |
Why a submitter cannot choose the winner: the leaderboard singleton carries the authenticated top-three state, the drand signature is verified against the fixed round, and the pot puzzle accepts only the corresponding destinations. A malicious transaction may fail or delay settlement, but it cannot turn an invalid recipient into a valid one.
Roles and limits
What is on-chain—and what is not promised.
The Chialisp puzzles constrain ticket ownership, eligible claims, drand proof, ranking state and payout destinations. The website indexes chain data, forecasts the same fixed payout math and helps Sage construct a ticket; it does not hold the pool or choose winners.
Deployment tools publish new epochs. The permissionless settlement driver advances rounds, and the independent verifier reproduces results. These are operator or verifier tools, not private authority over prize addresses.
| Feature or claim | Current status | Consequence |
|---|---|---|
| Source publication | Source paths are identified; the official public repository URL is still pending | The deployed puzzle reveals are public, but the site does not pretend an unverified repository account is official. |
| External audit | Not planned | An adversarial live-run and puzzle freeze are required in its place; the internal review and tests remain evidence, not an independent certification. |
| Express tables | Not enabled | No 10, 20 or 30-minute game is advertised or sold by this deployment. |
| Overlapping schedules | Supported by separate round coins | Ticket sales for a later table may overlap claim or settlement of an earlier one; their banks, leaderboard states and rankings remain separate. |
| Very short periods | Protocol-valid, but not a current product | If a period is shorter than the one-hour sweep delay, late remainder may cascade through later table pools rather than play immediately. |
| Referral payouts | None | A referrer hash remains part of ticket identity and anti-grinding design, but no referral reward exists. |
| Automatic settlement | No privileged automatic executor | Anyone may submit the valid transaction; liveness still depends on someone doing so. |
| Randomness guarantee | The beacon round is committed before sales open; drand publishes the value later and the puzzle verifies its signature on chain | No operator, player or bot can predict or replace it. Single assumption: no collusion of a threshold of League of Entropy nodes. |