frequently asked

No. This runs on Solana devnet. devnet SOL is issued free by a faucet and has no monetary value, cannot be exchanged for anything, and is not the SOL you may hold in a wallet on mainnet.

There is no mainnet deployment of this program and no way to send real funds to it. The wallet connection itself is pinned to devnet in the code — it is not a setting — so the site cannot be pointed at mainnet by configuration. No program is deployed in this build, so no transaction is sent at all.

Two cuts come off the top of every ticket, as separate transfers in the same transaction as the purchase: 3% to conservation, and an administrative rate that differs by game — 2% on every game. Conservation is a floor that may only ever be raised; administration has its own floor of 2% that the program refuses to go below, so every game earns something.

They pay two different accounts, deliberately, so donated money and operating money can never be confused for one another. Everything that remains is prize money — the pool takes the remainder rather than a fixed share, so the rounding dust from those divisions lands with the players rather than with the house.

• nēnē: 73.9% prizes · 21.1% jackpot · 2% admin · 3% conservation
• manō: 95% prizes · 2% admin · 3% conservation
• honu: 95% prizes · 2% admin · 3% conservation
• humuhumunukunukuāpuaʻa: 95% prizes · 2% admin · 3% conservation
• pueo: 95% prizes · 2% admin · 3% conservation

Solana's own transaction fee is separate, is paid to the network rather than to us, and is a small fraction of a cent.

Today: to a dedicated wallet, in the same transaction as each purchase. The program adds each ticket's cut to a running lifetime total on the game account, so the amount collected is a number anyone can read off the chain rather than a figure we publish.

What is not built: nothing has been distributed to any organisation, because this is a devnet deployment and the balance is play money. The quarterly reports on the conservation page are labelled sample data, and the site does not yet read the real lifetime total from chain — it can, and does not.

The randomness is committed before it can be known. When ticket sales close, the round permanently records which randomness account will decide it, and the slot it closed in — at that moment the account holds no value. The oracle seeds it afterwards, and the program rejects any account seeded earlier than the close, so a value that already existed cannot be substituted.

Reveal and resolve then happen in one transaction, because a revealed value is only readable in the slot it was revealed. There is no window in which someone could see the outcome and decide whether to submit it.

The seed that decided the round is stored on the round account, so the winner is recomputable: the selection is a pure function of that seed and the ticket count. Triggering a draw and choosing one are different things, and only the first is a power anybody here holds.

Nobody, including us. The key that triggers draws runs unattended on a server and can do exactly three things: end a round after its scheduled close, reveal a card, and resolve. It cannot choose an outcome, cannot move funds, cannot pause a game, cannot cut ticket sales short, and cannot upgrade the program. Those powers are held by separate keys that stay offline.

The honest limit: the offline administrative key can pause games and open rounds, so it can stall the platform. It cannot take a pot — prizes pay the wallet recorded on the winning ticket and nothing else moves a round's money.

Then the money comes back. After a round's close time plus the claim window, anyone may return each ticket's stake to the wallet that bought it — recomputed from the ticket price and the rates, not divided out of the pot, so an odd pot cannot strand a remainder or overpay whoever claims last.

The same path covers a round that was drawn and whose winner never claimed. It is permissionless on purpose: a timeout that paid somewhere convenient would hand whoever runs the crank a way to take funds by simply waiting. This one can only ever pay the buyer recorded on the ticket, so it is safe to leave open to anyone.

The exception, stated plainly: a honu scratch card that is bought and never revealed has no equivalent exit. The pooled games have one; honu does not yet.

At least. The tier percentages are shares of a full prize table, and a round can only fill as many places as it sold tickets. The whole prize pool is always paid out, so when the field is smaller than the table, the places that were filled scale up together and keep the same ratios between them.

A nēnē round with three tickets pays those three winners the entire pool, keeping the ratio the table gives them — where the published shares would have handed them 70% of it and stranded the rest. One ticket takes the lot. Read the published percentages as a floor on what a place is worth, never as a ceiling. 50% of the pot, or more in a small round.

No, and it never could be — 25,000× a 0.1 SOL ticket is 2500 SOL, and a round with ten thousand tickets in it holds a few hundred. A fixed multiplier with no bankroll behind it is an insolvency waiting for a winner.

humu is pari-mutuel. The published multipliers are used as weights: the pot is divided between winning tickets in proportion to them. The ratios hold exactly — a 25,000 weight really is 500× the share of a 50 weight — but the amount depends on the size of the pot and on how many other people matched. Nothing is paid until every ticket in the round has been counted, because a share against a partial total is not a share of anything.

A platform-wide reserve that a share of every nēnē ticket seeds — 21.1% of each one. manō's own tickets fund its round pot; the jackpot arrives on top. It is released at 500 SOL, or a round scheduled to run 72 hours.

When it is released it is paid into the round's pot rather than to a person, so from that moment it can only reach that round's ticket holders — by claim, or by the refund path if nobody claims. That is the whole design: a jackpot whose only exit is a trigger that might not fire is a jackpot that can be stranded, and money should never be able to enter a place it cannot leave.

No. One prize table applies to all three stakes, so a bigger stake multiplies the same outcome by more and raises the ceiling to 500× that stake — the chance of reaching any given multiple is identical. 49.5% of cards pay something, and the table returns 89.9% to players over time.

The house holds back the maximum a card could win from the moment it is sold and refuses the sale if it cannot cover that, so it can never owe more than it holds.

The five games, the prize splits, the fee cuts, the draws and the payouts are real program behaviour on devnet. Draw history, the leaderboard, wallet ticket history, the conservation reports and the referral figures are sample data, labelled as such wherever they appear.

Referrals, the creature collection, seasonal events and the leaderboard are described in the design and are not implemented — there is no tracking behind them and no on-chain payout.

No. The limits and self-exclusion controls on the mālama page live only in your browser for as long as the page is open. Nothing is stored, nothing is enforced on-chain, and nothing prevents a wallet from buying a ticket. The page previously implied otherwise; it does not now.

Enforcement would need program-level state per wallet, which is real work and is not done. Until it is, treat those controls as a note to yourself and not as a mechanism.

Not from this site yet. Verifying a draw needs indexed history — a record of every resolved round with its seed and signature — and there is no indexer. The "verify" buttons that used to be on the draws page pointed at signatures that never existed, and were removed rather than left pointing somewhere plausible.

What you can do today: read the round account from the chain yourself. It carries the seed, the winner indices and the amounts, and the winner selection is a pure function of the seed and the ticket count.

Not by a third party. It has an internal adversarial test suite — account substitution, resolve-twice, claim-twice, payout arithmetic at the limits of a 64-bit integer, conservation of every lamport across the whole lifecycle of a round — and the program is tested against its own compiled bytecode rather than a mock. That is not the same thing as an audit, and this line will say so until one exists.