FAIRNESS
Almost every link in the chain is yours to check.
We describe GATCHA as verifiable rather than “provably fair”, because verifiable is the more precise word — and the more useful one. It names things you can actually do: inspect the inputs, check the commitment, and reproduce the outcome. Here is all of it, and then the parts we decline to claim.
HOW A DRAW HAPPENS
THE HOLDER LIST IS BUILT
Every wallet holding GATCHA is read from chain and aggregated by owner, with a published exclusion list applied. A supply-conservation check refuses the whole snapshot unless the aggregated balances, the exclusions and the burned supply add back up to the total supply exactly.ITS HASH GOES ON CHAIN FIRST
The list is hashed and that commitment is written to the round BEFORE any randomness is requested. The list cannot be changed afterwards without changing the hash, and the hash is already public.RANDOMNESS ARRIVES
The round requests verifiable randomness from ORAO. The request address is derived from the round id and its generation, so a retry can never be confused with the original.THE DRAW IS DERIVED
A seed is derived from the fulfilled randomness. From the seed alone: a 0–99 roll decides holder or Vault, and a ticket number in the range of total eligible weight decides which holder. Same seed, same answer, forever.ANYONE RE-RUNS IT
Every catch page shows the seed, the roll and the ticket. The published holder list turns that ticket into a wallet. Our own verifier reimplements the serialisation independently of the code that produced it — a verifier that calls our own code would prove only that we agree with ourselves.WHAT YOU CAN VERIFY
- The holder snapshot is published — the full list of eligible wallets and the weight each one carried, together with the declared exclusion set and the exclusion version hashed into the commitment.
- The balances behind it are on Solana, at a stated slot. The published list is a claim about public data, so it can be checked against the chain rather than taken on our word.
- The totals have to reconcile. Aggregated balances plus exclusions plus burned supply must equal total supply exactly. A truncated or partial holder set fails this identity and is refused rather than published.
- The hash is committed before randomness is requested, on chain. The list cannot be changed afterwards without changing a hash that is already public.
- The randomness, the roll and the ticket are all inspectable. Every catch page shows the seed, the 0–99 outcome roll and the resulting ticket number.
- The draw can be re-run independently. Our verifier reimplements the canonical serialisation separately from the code that produced the snapshot — a verifier calling our own code would prove only that we agree with ourselves.
WHAT WE DO NOT CLAIM
We do not use “provably fair” as a blanket slogan. It is a label, and the list above is a set of things you can do.
GATCHA retains the program's upgrade authority. It is held on a hardware wallet and its only standing job is upgrading the program. Burning it would make the guarantees above permanent, and that belongs with a future trust-minimised version.
The snapshot is generated by our infrastructure. The rules are public, the inputs are public, and the output is checkable against the chain — but the software that applies those rules to that data is ours. That is an auditable step, not an unknowable one, and it is the reason we say verifiable instead of proven.
A separate operator key can pause the machine. Its entire surface is pause, unpause and rotating the keeper. It cannot reach either vault and it cannot choose a winner.
What no key can do: choose the outcome of a round, choose which holder catches it, change the 1,510 SV151 threshold on a live machine, or move SV151 out of the Vault. Those are properties of the deployed program, not promises.
SNAPSHOTS
Your weight in a round is the sum of your GATCHA balance across the snapshots that round committed. Up to three holder snapshots are taken while a machine fills — the first credit, one from the middle, and always the credit that fills it. A machine that fills in one go has one.
You cannot time them: snapshots follow fee flow, not a published schedule, so there is no percentage to buy in front of. Your weight is the sum across every snapshot the round committed, so a holder counted in all of them carries more weight than one counted in a single snapshot with the same balance.