The player-facing action is intentionally simple: choose between 6 and 25 unique numbers from 1-100, then pay a quoted Bitcoin amount. Those requested numbers are a hint and a budget target. They are not a reservation, because reserving unpaid claims would let abandoned checkouts block the round for everyone else.
After payment confirmation, the allocator finalizes one actual ticket for the current open round. A ticket is a set of numbers, but mathematically it represents every six-number subset inside that set. A six-number ticket contains one atomic claim; a 25-number ticket contains 177,100 internal atomic claims, out of 1,192,052,400 possible six-number claims in the full pool. The database stores the allocated numbers and uses the rule conflict(A, B) = size(intersection(A, B)) >= 6 to prevent two tickets from owning the same six-number outcome.
claim_count(S) = choose(size(S), 6)
price(S) + explicit_fee(S) <= paid_amount
conflict(A, B) = size(intersection(A, B)) >= 6Confirmed money creates claims. Hints guide the allocator, but only finalized non-overlapping tickets enter the prize pool.
This separation keeps the player experience familiar while keeping the ledger precise. The prize pool is the sum of allocated weighted claim prices only. The explicit partner fee and any unused paid budget are not hidden inside the odds and do not increase the prize pool.