Frequently asked questions

Luckotto is two things sharing one ledger. For players, it is the public record of the game: every round, every ticket, every draw, and every piece of proof is published here for inspection. For resellers, it is a wholesale platform: they pay Bitcoin up front for tickets and sell them on through their own websites and channels.

The defining feature is that fairness does not rest on reputation. The complete ticket list of every round is fingerprinted into the Bitcoin blockchain before the block that decides the winner exists, and the winner is computed from public data by fixed, public arithmetic. How Luckotto works gives the illustrated tour; Provably fair builds the proof from first principles.

The tile set decides survival: at the draw, 6 tiles are drawn one at a time, and a ticket stays live only while every drawn tile appears on it. The stake — the ticket's weight — decides everything about money: the ticket's chance of winning and its contribution to the jackpot.

Once created, a ticket is frozen. No edits, no top-ups, no refunds — a reseller that wants more exposure simply creates another ticket, and reusing the same tiles is allowed. A ticket's public identity is its round number plus entry number, which is how you find it in the round's committed ticket file and on its public ticket page.

Resellers buy tickets from Luckotto in Bitcoin, and jackpots are settled in Bitcoin. How a reseller charges its own customers is its own business: prices, currencies, and payment methods vary from reseller to reseller. What never varies is the on-chain accounting — a ticket's stake, its weight, and the round's jackpot are always denominated in satoshis, so the numbers you verify are the numbers that count.

Every round page and the homepage show the scheduled close as a plain timestamp — that published time is authoritative. The default schedule closes rounds weekly, and the operator can adjust individual rounds, which is why the page, not the pattern, is the reference.

The draw itself is a chain event, not a clock event. After close, the final ticket list is sealed and committed on-chain; the draw block is the Bitcoin block exactly 2 blocks after that commitment confirms — roughly 20 minutes later on average. Results follow as soon as the draw block is processed.

Every funded ticket adds its full stake to the round's pot, across all resellers. There is no separate seeded prize and no rollover formula: the jackpot is the round's total stake — including any tickets the House itself holds — and the whole pot goes to the single winning ticket. Deposit and ticket fees are charged separately and never touch the jackpot or any ticket's weight.

Because the committed ticket file lists every entry's weight, the displayed jackpot is itself verifiable: sum the weight column and compare.

Luckotto runs the game: rounds, on-chain commitments, draws, and jackpot settlement to resellers. Resellers own the player relationship: pricing, checkout, support, and paying their own winners. The reseller directory lists verified resellers, each with a public profile and a fixed jackpot address. Unverified resellers can sell, but public Luckotto pages show only their jackpot address.

The separation is what keeps the core small and auditable — a verifiable ledger rather than a consumer casino — and it means your purchase terms come from your reseller. Read them before you buy; the proof machinery covers the draw, not your reseller's customer service.

Three facts do all the work. First, the full ticket list is sealed the moment a round locks, and its cryptographic fingerprint is written into a Bitcoin transaction before the block that supplies the randomness exists. Second, the randomness comes from that later Bitcoin block's hash — something Luckotto does not produce and cannot pick. Third, the rule that turns list-plus-randomness into a winner is fixed, published arithmetic.

“Provably” is meant literally, not as marketing. The provably fair page draws a toy round by hand, publishes a per-round evidence packet you can check in a few shell commands, and ends in a specification precise enough to reimplement the entire verifier from scratch.

The draw takes no cut and carries no hidden odds penalty. The entire pot of stakes is paid to one winning ticket, and each ticket's probability is precisely weight ÷ total weight. Both halves of that sentence are checkable: the pot is the sum of the committed ticket file, and the draw's sampling rule provably preserves weight-proportional odds at every step.

The honest caveat lives in the resale layer. Resellers set their own prices — typically above the raw stake — and are expected to send half of their net resale profit to Luckotto as the House profit share. So the economics you experience are set by your reseller's markup, never by the draw.

The draw eliminates tickets tile by tile, but every step samples tile buckets weighted by funded sats, a construction that keeps each ticket's overall chance at exactly weight ÷ total weight no matter which tiles it holds or how many other tickets share them. That is a designed property of the sampler, pinned by tests and replayable by hand in the worked example.

So pick birthdays, primes, or a diagonal — it is purely aesthetic. The one lever that moves odds is the stake.

Any number of tickets may use the same tile set; each keeps its own entry number and its own stake. Tiles only decide survival. Among the tickets still live after the last tile, the final checkpoint selects one winner by weight — so there are no ties and no split pots, ever. Equal-stake duplicates have equal chances, and a bigger-stake duplicate is proportionally more likely to be the one selected.

When a round's commitment transaction confirms at some height, the draw block is fixed: the block exactly 2 blocks later. Its hash is then stretched through 1,000,000,000 strictly sequential SHA-256 hashes per checkpoint — one checkpoint per drawn tile plus one for the winner — and each checkpoint is mixed with the round secret to produce the draw samples.

No server-side random number generator exists anywhere in the protocol. The sequential stretching is deliberate: it makes even testing a single candidate block expensive, which is what prices out a miner quietly re-rolling the draw. The threat model does that arithmetic in the open.

Once the ticket list is sealed and its fingerprint committed on-chain, no ticket can be added, dropped, or reweighted without the published file failing its own fingerprint check — forever, and publicly. The winner is then forced by the draw block, which Luckotto does not mine, through arithmetic anyone can rerun.

The one subtle avenue is collusion with a miner to privately test candidate draw blocks before publishing them. The protocol prices that attack rather than pretending it away: every candidate costs a full sequential-hash pass per checkpoint, and the threat model walks through why the price is high. If a round ever were rigged, the reject rules state exactly what public evidence would convict it.

Only tiles that appear on a live funded ticket can be drawn, so the live list can never empty itself: after 6 tile draws, at least one ticket always survives, and one final weighted sample picks the winner from the survivors. The pot never rolls over and is never retained. The only exception is a round with zero tickets, which still seals, commits, and resolves — with no winner and an empty jackpot.

Every round on the round ledger shows its status live: open, then locked, then resolved with the draw tiles and the winning ticket. If you know your ticket's round and entry number, its public ticket page shows the same outcome directly.

Your reseller sold you the ticket, so winner notification and prize claims run through the reseller — serious resellers watch resolutions and contact their winners. The public record exists precisely so you never have to take their word for what happened.

Every reseller has exactly one jackpot address, fixed at creation and unchangeable afterward — changing it requires a new reseller. That address is snapshotted into each ticket at creation, so the destination of a potential win is decided before the draw, not negotiated after it.

Your claim on the prize is against your reseller, under the terms you bought on. That is worth checking before you buy — the reseller directory shows verified reseller profiles and jackpot addresses. Unverified resellers are shown publicly by jackpot address only, and any reseller's payout history is visible on-chain.

The draw follows the canonical Bitcoin chain. If a chain reorganization replaces the draw block before it is buried 100 blocks deep, the winner is recomputed from the replacement block — using the same sealed ticket list, which no reorg can touch. The entrants are fixed; only the randomness can move, and only until depth.

In practice jackpot settlement is deliberate and slow, so the depth threshold passes long before money moves; the operator's own tooling warns loudly if a payment is ever recorded early.

The proof machinery establishes beyond argument which ticket won and where the jackpot should go. The payment itself is an on-chain transaction signed by humans from cold storage and then recorded against the round. The recorded payment txid is operator evidence anyone can inspect on the chain — it is not an automated escrow, and this page will not pretend otherwise.

What disciplines the operator is total visibility: the winner, the amount, the fixed destination address, and the payment are all public, so a skipped or short payment is provable by anyone holding the round's evidence packet. The proof boundary draws this exact line between what is proved and what is promised.

The server holds exactly one small hot key, used only to write round commitments on-chain — a float, not a treasury. Reseller deposits land in addresses derived from a watch-only wallet whose private keys never touch the server, and every jackpot or consolidation is signed externally by humans. An attacker with total control of the site could corrupt bookkeeping — detectably — but could not sweep funds.

History is similarly durable: a round's evidence is the committed ticket file, a Bitcoin transaction, and a Bitcoin block. The chain outlives any website, and anyone who saved the published files can verify past rounds without Luckotto's help.

As soon as a round locks and seals, Luckotto publishes the committed ticket file (CSV), the round secret hash, and the file's HMAC fingerprint — all before the draw block exists. Find your entry number in the file and check the fingerprint against the sealed commitment; the round verifier automates both steps.

This is the protocol's inclusion guarantee, and it has teeth: a paid ticket missing from the fingerprint-matching file is not a support ticket, it is grounds to reject the round as a protocol violation — publicly, with evidence anyone can re-check.

The browser verifier runs eight checks with every input editable and the data-source endpoints swappable for your own node. The evidence packet does the same job in a few shell commands — one of which reads the on-chain commitment from a third-party node and never touches Luckotto's servers at all. And the standalone Go tool, luckotto-verify, replays everything natively while trusting nothing from this site.

The last step of independence is yours: the published LUCKOTTO-1 spec is deliberately precise enough that you can write your own verifier and never run anyone else's code.

Public from the moment a round locks: the committed ticket file — entry numbers, tiles, weights, and each ticket's reseller jackpot address — plus the round secret hash and the file's HMAC fingerprint. Public at resolution: the revealed round secret, the draw tiles, and the winner; draw checkpoints appear as soon as they are stored. The reseller directory and reseller profiles are public all along.

Private: a ticket's metadata and creation time are visible only to the reseller that owns it. Player identity is more than private — Luckotto never has it. Resellers keep their own customer records, entirely outside this system.

A pass proves the entrant list was fixed before the randomness existed, that the randomness came from the designated later block, and that replaying the fixed rule over those inputs yields the published draw tiles and winning ticket. Combined with the inclusion check on your own entry number, that covers everything the draw itself can be accused of.

It does not prove the jackpot was paid — that is a separate on-chain record. It does not make miner manipulation impossible — only expensive and quantified. And it does not make an early resolution final before the burial depth. The proof boundary lists both columns side by side, which is exactly how a proof should behave.

Most failures are mechanical. The usual suspects: the wrong round number, a copy-pasted ticket file instead of the exact downloaded bytes (the fingerprint covers every byte, including line endings), or running resolved-only checks — the secret reveal, the winner replay — against a round that has not resolved yet.

If a discrepancy survives those checks, treat it as what it is: a protocol violation. Keep the downloaded file and the chain references. The beauty of public evidence is that your finding needs no trust either — anyone can rerun the same reject rules and reach the same verdict, which is what makes publicizing a real failure devastatingly effective.

Reseller creation stores your display details, an optional website, and the Bitcoin address that will receive any jackpot you win. You can create API keys, deposit addresses, and tickets immediately. Verification is a separate manual review for public listing and public profile text.

Choose the jackpot address with care — it is your permanent identity. It can never be changed; a different address means a fresh reseller. It is also snapshotted into every ticket you create, which is what makes your payout destination provable in advance. Create a reseller.

Your deposit addresses are derived from a watch-only wallet: the server sees deposits and credits your balance, but holds no keys — the coins themselves sit in cold storage and move only through externally signed, human-controlled transactions. Inside Luckotto, balance has exactly one use: funding tickets. There is no withdrawal endpoint and no refund flow, deliberately — it is the property that makes the platform safe to operate online.

So deposit with intent to buy. You can also automate the buying: create a deposit address with autoTicket metadata and each confirmed deposit to it purchases one ticket automatically once it is deep enough. The exact metadata shape is in the API reference.

The deposit fee covers the future cost of consolidating your deposit out of cold storage and is deducted when a confirmed deposit credits your balance — you are credited the gross amount minus the fee. The ticket fee is a small anti-spam charge on each ticket creation. Neither fee ever touches a ticket's weight or the jackpot: the pot is pure stakes.

Current fee values are published live at GET /api/constants — integrations should read them from there rather than hardcode them.

Every reseller gets a dedicated, House-owned profit-share deposit address. Profit-share deposits credit the House account — not your balance — and are automatically recycled into House-owned tickets in future rounds. Since nothing can be withdrawn, profit-share funds only ever leave the system the same way any stake does: by winning a jackpot.

There is no automated profit measurement and the House profit share is not part of jackpot settlement — reporting is honest-by-declaration. The enforcement is commercial rather than cryptographic: a reseller caught underreporting can lose verification, which removes public discovery and hides its chosen profile text.

Mempool sightings and shallow confirmations appear as pending balance so you can watch a deposit arrive, but ticket creation accepts only sufficiently confirmed balance — 6 confirmations at current settings, published live at /api/constants.

Reorgs are handled conservatively: if a confirmed deposit is reorged out of the chain, it leaves your balance while your tickets remain. Balance can therefore go negative, and new ticket creation is rejected until confirmed balance covers the request again.

Immutability is load-bearing, not bureaucratic: the sealed round file commits every ticket exactly as created, which is what makes pre-draw inclusion proofs and post-draw replays possible at all. To increase exposure, create another ticket — the same tile set is allowed. Price that finality into your own customer terms, because Luckotto will not unwind a funded ticket for anyone.

Ticket and deposit-address creation are both idempotent on a client-supplied UUIDv4 id. After an unknown network failure, retry the exact same body: you get the original resource back, and the replay is only accepted when every field matches the original request — so a mutated retry fails loudly instead of silently creating something new.

If you need lookup by your own order key, derive the UUID from a private HMAC seed over that key and replay the create request to recover the resource. Private, not a public hash — so nobody else can reserve your ids first. The API reference documents the full contract with examples.

Poll your /deposit-events endpoint with a cursor and reduce the stream: lifecycle events (confirmed, reorged_out) are immutable history, while accounting events (credited, uncredited) mirror Luckotto's spendability decisions. The canonical reducers for reseller balance and checkout status are in the API reference.

One nuance worth engineering for: credited means spendable at Luckotto's configured depth — it is not a finality promise. If your product wants a deeper threshold, compare each deposit's confirmation height from the event stream against /api/chain-tip and apply your own policy.

Fees, tile geometry, draw delay, sufficient-confirmation depth, and the commitment descriptor are all served machine-readably at /api/constants. Every number on this page is rendered from those same sources, so the FAQ and the API cannot drift apart.

One caution: constants that define verification identity — the commitment descriptor, draw delay, CSV derivation — are fixed per deployment. Changing them would break public replay of existing rounds, so treat them as protocol, not configuration. The canonical constants table explains what each one is for.