draw_hashes_per_elimination is a draw input, not a tuning knob: two replays of the same round with different hash counts produce different digests and therefore different eliminations. That is why it is a fixed protocol constant rather than a per-round setting — every round, past and future, draws with the value above.

The final round CSV is the committed artifact. Its SHA-256 is taken over the exact bytes served at /rounds/<N>.csv.

• Encoding MUST be UTF-8 with no byte-order mark.
• Rows are separated by a single line feed (0x0a). The file MUST end with a trailing line feed.
• The header row is exactly tiles,weight,ticketId,partnerPayoutAddress.
• tiles is the sorted tile list joined with underscores, e.g. 3_8_13_21_25_31. Tiles are ascending and unique. Duplicate tile sets may appear on multiple ticket rows.
• weightis the ticket's draw weight in sats as a decimal integer. Weight is the ticket's fair value: the confirmed sats paid to it minus the partner's house-edge fee, computed per payment as fee = round(amount × house_edge) rounded to the nearest satoshi, with the edge fixed when the ticket was sold. Replay treats the committed weight as authoritative; the price paid is bookkeeping outside the protocol.
• ticketId is the UUIDv7 Luckotto ticket id. It is the committed ticket identity and the final winner tie-break identity.
• partnerPayoutAddressis the partner's payout Bitcoin address snapshotted when the ticket was sold.
• A field containing ", ,, \n, or \r is wrapped in double quotes with inner quotes doubled (RFC 4180). This does not occur in practice with the current tile, UUID, address, and integer fields, but parsers MUST support it.
• Only tickets with positive confirmed weight appear. Zero-weight reservations are excluded before the CSV is built.

Row order is deterministic: sort by weight descending, then by the sorted tile list ascending, then by ticketId ascending. Within one round, a ticket is identified by its UUID, not by its tile set.

The commitment address for round N is the P2WPKH address of commitment_xpub/N (one unhardened child step). The canonical commitment transaction is the first outbound transaction from that address: among all transactions spending at least one input from the address, order confirmed transactions before unconfirmed ones, then by block height, then by block time, then by lexicographic txid; the first transaction in that order is canonical.

Output 0 of the canonical transaction MUST be:

script = OP_RETURN <32-byte payload>
hex    = 6a 20 <payload>

payload = SHA-256 of the exact final CSV bytes

Output 1 MUST use the same script shape, with payload equal to SHA-256(raw minor seed bytes). Output 2 MUST roll remaining sats forward to commitment_xpub/(N + 1). The complete ticket list and hidden minor seed are therefore committed in one timestamped Bitcoin transaction before the draw block exists.

The draw block is the block at commitment_block_height + 2 in the active best chain, written as 64 lowercase hex characters in standard display order. Once that block exists, the raw minor seed is revealed and the draw seed is hex(bytes(minor_seed) || bytes(draw_block_hash)). The winner is computed from the committed CSV and published as soon as that block exists, but it is provisional until the draw block is buried 100 confirmations deep.

The draw always follows the canonical chain: if a reorganization changes the commitment confirmation or draw block while the result is still provisional, the recorded confirmation and draw block are replaced by the values from the new best chain and the winner is re-derived from the same committed CSV and minor seed. No win is ever paid out before 100 blocks have been built on top of the draw block.

The entire draw derives its randomness from a single sequential SHA-256 chain seeded by the derived draw seed. The chain input is the UTF-8 string:

input = seed + ":draw:chain"

where seed is the 64-byte hex string derived from minor seed bytes plus draw block hash bytes. The first invocation hashes the input bytes; every later invocation hashes the previous 32-byte digest. The chain is consumed in segments of exactly draw_hashes_per_elimination invocations, each yielding one 256-bit sample value:

bytes = utf8(input)
next_value():
  repeat draw_hashes_per_elimination times:
    bytes = SHA256(bytes)
  return bytes  // 32 bytes, interpreted below as a big-endian integer

The whole draw is strictly sequential: invocation i+1 hashes the output of invocation i, and each elimination's segment continues from the previous elimination's final digest. No elimination — and no rejection retry — can be computed in parallel, out of order, or ahead of time; the only way to learn where a segment starts is to finish every segment before it.

Parse the committed CSV into tickets, preserving file order. Discard zero-weight tickets. Duplicate ticket ids are protocol violations: replay MUST abort. Duplicate tile sets are valid and share a survivor group. Then eliminate losing tiles until one tile set remains:

chain      = sha256_chain(seed)  // section 4; one chain for the whole draw
candidates = tickets             // file order; indexes below refer to this list
eliminated = {}
while count(unique_tile_sets(candidates)) > 1:
  choices = next_elimination_choices(candidates, eliminated)
  choice  = rejection_sample(chain, choices)          // section 6
  eliminate choice.tile; add it to eliminated
  candidates = [candidates[i] for i in choice.candidate_indexes]
winner = candidates[0] if count(candidates) == 1 else weighted_pick(candidates sorted by ticketId)
draw_tiles = winner.tiles

Elimination choices

Every pool tile that has not already been eliminated is tested. The survivor list for that tile is the ascending list of current candidate indexes whose tickets do not contain the tile. A tile with no survivors is not a valid choice. Every other tile becomes one weighted choice.

The choice weight is the sum of the surviving candidate ticket weights in sats, so duplicate tile sets contribute their combined weight while they survive together. Choices are ordered by their survivor index list lexicographically, with ascending tile number as the tiebreak. Reordering intervals under a uniform draw changes no probabilities; it only determines which valid elimination a given seed maps to.

W     = sum of choice weights          // MUST be >= 1
limit = 2^256 - (2^256 mod W)
repeat at most 10,000 times:
  v = chain.next_value()               // one segment, section 4
  if v >= limit: continue              // rejected; consume the next segment
  r = v mod W
  running_sum = 0
  for choice in choices, in the section-5 choice-list order:
    running_sum += choice.weight
    if running_sum > r: return choice
  error                                // unreachable if W is correct

Restricting accepted values to the largest exact multiple of W below 2^256 removes modulo bias: every weight unit has exactly the same probability. The probability that a single segment is rejected is (2^256 mod W) / 2^256 < W / 2^256, which is negligible for any realistic weight total; exhausting 10,000 segments for one elimination is cryptographically unreachable and replay MUST treat it as an error.

The boundary rule is cumulative weight with half-open intervals. For a choice list with weights [5, 3], r values 0 through 4 select the first choice and values 5 through 7select the second. Equivalently, after adding each choice's weight, select when running_sum > r, not running_sum >= r.

Winner uniqueness

A ticket survives exactly while none of its tiles have been eliminated. The tile-elimination phase stops as soon as all remaining candidates share one tile set. If multiple tickets remain, replay MUST consume the next chain sample and rejection-sample among those tickets by weight, ordered by ticketId. The stored draw_tilesvalue is the selected winner's sorted tile set, and winningTicketId is the selected UUID.

These vectors are recomputed on every render by the same production code that settles real rounds, using a chain length of 1 so they run instantly — real rounds always use the protocol constant. Check your implementation stage by stage before attempting a multi-minute production replay.

Vector CSV

tiles,weight,ticketId,partnerPayoutAddress
2_3_4_5_6_7,2500,018f58d2-2800-7000-8000-000000000002,tb1q022amqf3jv7mg744rcjmst222dfazqvm72jgzc
1_2_3_4_5_6,1000,018f58d2-2800-7000-8000-000000000001,tb1q022amqf3jv7mg744rcjmst222dfazqvm72jgzc
8_9_10_11_12_13,500,018f58d2-2800-7000-8000-000000000003,tb1q022amqf3jv7mg744rcjmst222dfazqvm72jgzc

Hash chain vectors (start of the chain)

Full draw result

These vectors are for from-scratch implementations: make the chain length configurable while testing, reproduce the vectors at chain length 1, then pin it to the protocol constant before replaying real rounds.

Verifiers do not need to scrape the round page. Fetch /api/luckotto/rounds/<N>/proof for the public proof metadata, then fetch csvUrl and hash those exact bytes. Fields that are not available yet are null; status tells the verifier how far the round has advanced.

type RoundProof = {
  roundNumber: number;
  status: "open" | "closed" | "locked" | "drawn" | "resolved" | "paid_out";
  csvUrl: string | null;
  csvHash: string | null;
  minorSeedHash: string | null;
  minorSeed: string | null;
  commitmentTxid: string | null;
  commitmentBlockHeight: number | null;
  drawBlockHeight: number | null;
  drawBlockHash: string | null;
  drawTiles: number[] | null;
  winningTicketId: string | null;
  payoutTxid: string | null;
};

Luckotto has no app-defined minimum ticket price. A player reserves one round-scoped deposit address and sends any positive Bitcoin amount — that amount is the ticket's price, and it is what the player-facing UI shows.

The draw cares about weight, the ticket's fair value: the price minus the partner's house-edge fee, fixed when the ticket was sold. Weight enters the committed CSV and sets the odds; the fee is tracked as partner profit. With a zero house edge, price and weight are identical. Payments that confirm after close roll forward into the next available round.

credited_ticket = original_ticket_or_late_payment_roll_forward(address)
price  = sum(confirmed_payments_credited_to(credited_ticket))
fee    = sum(round(payment × house_edge))   // nearest sat, edge fixed at sale
credited_ticket.weight = price - fee

Luckotto deposit addresses are not arbitrary server-side strings. The ticket's payload is signed with HMAC-SHA256 (a keyed fingerprint) under the hash-tweak label — a fixed protocol constant that namespaces the derivation. The first 21 bytes are split into seven 3-byte big-endian child indexes, which derive a native SegWit address from the configured xpub (an extended public key that derives addresses without exposing any private key).

The payload is the partner payout address, the player identifier, the round number, and the selected tiles. The player identifier is a per-player secret generated unpredictably by the partner, so only that player and their partner can re-derive the address. That is the point: at payout time, knowing the winning ticket's identifier is what proves the claim belongs to the right player. It proves the address belongs to the published derivation scheme, not custody of the private keys.

payload = partner_payout_address + player_identifier + round_number + tiles
hmac = HMAC_SHA256('hash-tweak', payload)
tweak = first_21_bytes(hmac)
path = split_into_7_uint24_be(tweak)
deposit_address = p2wpkh(deposit_xpub / path)

extended public key = deposit_xpub
payload = partner_payout_address, player_identifier, round_number, tiles
derived path = /uint24_be(hmac[0:3])/.../uint24_be(hmac[18:21])
deposit address = p2wpkh(deposit_xpub / derived path)

A player-selected ticket is reserved for the round stored on its deposit address, and Luckotto records confirmed sats against the ticket they are credited to.

The allocation rule is short: unpaid reservations carry no draw weight, duplicate tile sets are allowed across tickets, and players may reserve multiple tickets.

ticket = reserved_ticket_for(deposit_address)
credited_ticket = ticket if confirmed_before_close else roll_forward(ticket)
credited_ticket.weight += payment_sats - partner_fee(payment_sats)

After a round closes, Luckotto waits a short finality buffer so deposits that confirmed near the close have time to bury before the list is fixed. At the commit point, the complete final ticket list is serialized as CSV, a plain-text table of the round's tickets. Luckotto hashes the exact byte stream and publishes that hash in output 0 of the first outbound transaction from the round's commitment address, which is itself derived from the public commitment xpub and the round number. Those exact CSV bytes are also stored immutably, and every later step — settlement and the published final CSV — reads them, never the live database.

What matters is ordering in time. The commitment transaction confirms first; the draw block comes later. A list chosen after seeing the block would produce a different hash, and the OP_RETURN value would no longer match. The widget below shows why: a single changed byte rewrites the whole fingerprint.

tickets = final_allocated_tickets_for_round(round)
csv = format_csv(secret_sorted_ticket_order(tickets))
csv_hash = SHA256(csv_bytes)
commitment_address_N = p2wpkh(commitment_xpub / roundNumber)
tx = first_outbound_transaction(commitment_address_N)
assert tx.vout[0] == OP_RETURN(csv_hash)

round N address = p2wpkh(commitment_xpub / N)
canonical tx = first outbound spend from round N address
vout 0 = OP_RETURN(SHA256(exact final CSV bytes))
vout 1 = OP_RETURN(SHA256(raw minor seed bytes))
vout 2 = commitment_xpub / (N + 1)
draw block height = canonical_tx.block_height + 2

The draw uses the raw minor seed plus the block hash 2 confirmations after the commitment transaction confirms, eliminating losing pool tiles from the final committed CSV until one tile set remains. The winner is computed and published as soon as that block exists, but it stays provisional until the draw block is buried 100 confirmations deep — a reorg before then re-derives the winner from the same committed CSV and minor seed rather than leaving a stale result.

Each elimination choice is weighted by the draw weight behind the candidate tickets that would survive if that tile were eliminated. Each sample runs a sequential SHA-256 chain of exactly draw_hashes_per_elimination invocations, with rejection sampling so the 256-bit digest selects among weighted choices without modulo bias. If multiple tickets share the winning tile set, the next chain sample selects one ticket UUID from that group by weight.

seed = hex(bytes(minor_seed) || bytes(draw_block_hash))
tickets = parse_final_csv(csv)
candidates = tickets
eliminated = []
while count(unique_tile_sets(candidates)) > 1:
  tile = weighted_elimination_pick(seed, position, candidates, eliminated)
  eliminated.append(tile)
  candidates = tickets_without_eliminated_tiles(candidates, eliminated)
winner = weighted_pick_by_ticket_id(candidates) if count(candidates) > 1 else candidates[0]
draw_tiles = winner.tiles
assert winner.id == round.winning_ticket_id
assert draw_tiles == round.draw_tiles

chain seed = bytes of '<seed>:draw:chain'
each sample advances the chain draw_hashes_per_elimination SHA-256 steps
one chain feeds all eliminations; rejection retries advance it further
tile = unbiased weighted sample from candidate elimination choices