How it works
There is nothing to buy per draw and nothing to stake. Hold $LOTTO in your own wallet and you are entered into every round you are eligible for.
Acquire $LOTTO through the official Meteora liquidity pool. Always confirm the mint address before you swap.
Keep it in your own wallet. There is nothing to stake or register — your eligible balance is your entry.
Your share of the eligible supply is your share of the lottery. Hold 1% of eligible $LOTTO, get 1% of the chances.
When the round ends, a snapshot of eligible holders is locked on-chain first. Only then is verifiable randomness requested to pick the winning ticket.
The program transfers the prize from its on-chain vault straight to the winning wallet. Anyone can check every step.
Your probability of winning a draw is your eligible balance divided by the total eligible balance.
P(wallet wins) = wallet's eligible balance ÷ total eligible balance
Example with 1,000,000 eligible $LOTTO:
| Wallet | Holds | Owns tickets | Weight = odds |
|---|---|---|---|
| Wallet A | 100,000 | 0 – 99,999 | 10% |
| Wallet B | 50,000 | 100,000 – 149,999 | 5% |
| Wallet C | 10,000 | 150,000 – 159,999 | 1% |
| Everyone else | 840,000 | 160,000 – 999,999 | 84% |
Balances are integers in the token's smallest unit, so weights add up to exactly 100% with no rounding. A wallet with 0 eligible $LOTTO, an excluded wallet, or one below the minimum has weight 0.
When a round closes, the keeper reads every $LOTTO token account at a single slot, adds up each wallet's balances, removes excluded and ineligible wallets, applies the minimum balance and any per-wallet cap, and builds a canonical snapshot file. Its Merkle-sum root and sha256 hash are committed into the round account on-chain. After that, the snapshot can never change.
The rules and exclusion list used are the ones frozen into the round when it opened, so admin changes made mid-round only affect later rounds.
The winning ticket comes from ORAO VRF, a verifiable random function on Solana. The program derives the request seed from the committed snapshot and the latest Solana slot hash at the moment the snapshot is locked, so the seed does not exist until the eligible set is fixed and nobody — including the team — can see the random value in advance. No server-side or browser random number is ever used.
The program then computes ticket = randomness mod total weight and will only pay the wallet whose ticket range contains it.
What happens in the situations people ask about most.
With one balance sample per round (the default), a balance held at the snapshot slot counts in full. If the round is configured with several samples, your weight is the lowest balance across all samples, so last-minute buys add nothing.
Only the balance you hold at the snapshot counts (or your lowest sampled balance). Tokens you sold are counted for their new holder instead.
Each wallet is weighed separately by what it holds at the snapshot. Splitting tokens across wallets does not change your combined odds (unless a wallet falls below the minimum, or a per-wallet cap is configured). With multiple samples, tokens moved mid-round only count where they stayed for every sample.
Excluded and burn addresses get zero weight, and burned tokens no longer exist, so they simply leave the eligible supply and everyone else’s share grows.
They get exactly the same weight. Each owns its own ticket range, so ties are impossible to resolve unfairly — the ticket falls in exactly one range.
It owns every ticket and wins that draw. The program handles a single-leaf snapshot like any other.
The round is cancelled on-chain with the reason recorded. No prize leaves the vault; it rolls over to the next round.
Anyone can submit the randomness request once the snapshot is locked. If the provider has not answered a request within the timeout, the operator may bind a fresh seed, up to a configured number of attempts. A retry is refused if the randomness was delivered or if the request was never made, so it can never be used to discard a result. If every attempt fails the round is cancelled and the prize rolls over.
Every on-chain step checks the round state, so steps cannot run twice. The keeper resumes from chain state after any crash, and anyone — including the winner — can submit the settlement.
Read from the on-chain configuration and the active exclusion list.
Want the technical detail? Read the transparency page or the security model.