Token overview

Token distribution

Genesis Airdrop · 31%

310,000,000 tokens distributed retroactively at TGE to the people who used the product before there was a token. This is the largest single allocation in the supply, and it goes to users — not investors.

• Pre-beta and beta mainnet players
• Waitlist signups with verified wallet activity
• Genesis Points accruers (see Genesis Points page)
• Leaderboard participants across all qualifying seasons

The distribution mirrors Hyperliquid's approach. There is no claim form, no Twitter task, no Discord role gate — allocation is computed from on-chain activity and credited directly to the wallet that earned it.

Future Emissions & Community Rewards · 38.88%

388,800,000 tokens reserved for ongoing community rewards across multiple seasons. Released programmatically as the product grows, funding continued player rewards, ecosystem partnerships, and seasonal Genesis-Points-equivalent campaigns.

Core Contributors · 23.8%

238,000,000 tokens allocated to the core team. One-year cliff from TGE, then linear vesting through 2028. The longest lock in the supply distribution — community gets liquidity first, the team waits.

Foundation, Grants & Liquidity · 6.32%

63,200,000 tokens for operational allocations: foundation budget, ecosystem grants, on-chain liquidity bootstrap. Not investor allocations.

What's not in the supply

Season 1

How to earn

The vast majority of Genesis Points come from real gameplay — bets settled on the protocol, scaling with rounds played and volume wagered. Smaller secondary sources include referring players who genuinely play, and community contributions. The system is built to reward real players, not airdrop farmers.

FAQ

Where can I see my points?

Genesis Points are displayed in real time in the player dashboard once you connect your wallet, alongside your standing relative to other players.

Can I transfer points?

No. Genesis Points are bound to the wallet that earned them. At TGE, that wallet receives the corresponding token allocation directly — no claim step.

What if I miss Season 1?

Later seasons will distribute the remaining Genesis allocation, but the earliest seasons receive the largest share.

The four-step protocol

Timeout rules

What the settlement proof establishes

A single ~600-byte Plonky2 proof per bet establishes three sub-claims at once:

• VRF correctness — in-circuit ECVRF verification proves the output is a valid evaluation of the house key (ECVRF construction over BLS12-381 G1, adapted from the RFC 9381 / draft-irtf-cfrg-vrf-15 design for a pairing-friendly curve).
• Payout computation — outcome = final_seed mod N, with the multiplier looked up via Merkle membership against the committed payout table.
• Balance transition — new_balance = prev_balance − bet_amount + payout_amount, checked against the state tree, with prev_balance ≥ bet_amount asserted.

Every bet emits a full artifact set — commitment, VRF output and proof, outcome, payout, settlement proof, and state roots before and after — all published on-chain. Any external party with the public verifier keys can re-verify any bet. The protocol depends on the math, not on the operator's good behavior.

One percent — and as low as 0.12%

The 1% is the base edge. Through the VIP System, players earn rakeback that rises with status — up to 88% at the top tier, which brings the effective edge down to roughly 0.12%, among the lowest anywhere. See the VIP System page for the full rakeback ladder.

How RTP is committed and verified

Each game has a payout table mapping outcomes to multipliers, which fully determines its RTP via RTP = Σ pᵢ × payoutᵢ. At deployment, the protocol publishes a Poseidon commitment to the table (the RTP commitment), a Groth16 proof that the committed table satisfies the claimed RTP, and the on-chain verifier address. The table itself stays private — publishing it would expose proprietary game design — but the proof lets anyone confirm the RTP is exactly what's claimed without seeing the table. This is the canonical use of a zero-knowledge proof: prove a property of a secret without revealing the secret.

Verification is three steps: query GET /games/:gameId/rtp for the claimed RTP, the commitment, the on-chain verifier address, and the game version; verify the Groth16 proof locally or on-chain; confirm that each bet's settlement proof binds to the same payout table (via the per-bet Merkle commitment exposed by the settlement circuit). The protocol cannot settle against a different table than the one it committed to.

RTP by game

Memecoin promotions are games where a token issuer funds a positive-EV experience as a marketing campaign — RTP can exceed 100% for the promotion's duration. Each is a separate committed game version.

System diagram

Everything on-chain

Hypergamble's defining property is that every component lives on-chain. There is no off-chain database holding balances, no centralized server adjudicating outcomes, and no operator account that funds flow through. Game contracts, the settlement verifier, the state tree, the treasury, and the sequencer all run on the appchain itself. Players, balances, bets, and proofs are part of chain state — auditable by anyone, controllable by no single party.

The sequencer & encrypted mempool

The sequencer decides which bets get included in each block. In a provably-fair system the house can't rig an outcome — but a dishonest sequencer could still hurt players by refusing to include the bets that would cost the house money: dropping a large bet, or sitting on it until the reveal window times out. That's liveness suppression, and it's the one real lever a sequencer has.

The threshold ElGamal encrypted mempool closes it. Bets are encrypted to a committee public key and stay sealed while the sequencer commits them to a block; only afterwards are they decrypted, via threshold decryption across the committee (no single member can open a bet alone). Because the sequencer has to include bets it cannot read, it has no way to tell which ones are the big or about-to-win bets — so it cannot selectively censor, delay, or time-out the bets that would lose the house money. It includes them blind, or not at all.

The proving layer

The only component that runs off the chain itself is the cryptographic proving layer — and it has no authority over outcomes or funds. It cannot move a balance, alter a result, or settle a bet on its own; it only produces proofs that the on-chain verifier then checks. If a proof is invalid, the chain rejects it. The proving layer provides three services:

• VRF prover — ECVRF over BLS12-381 G1, following the RFC 9381 / draft-irtf-cfrg-vrf-15 design adapted to a pairing-friendly curve. Generates the house's verifiable seed contribution per bet.
• Settlement prover — Plonky2 proof generation for the per-bet settlement circuit, combining VRF correctness, payout computation, and balance transition into a single ~600-byte proof.
• RTP prover and block wrapper — Groth16 proofs for static RTP commitments at game-deployment time, and the STARK-to-SNARK wrapper that compresses each block's recursive Plonky2 proof to ~200 bytes for L1.

Because every proof is verified on-chain before it takes effect, the proving layer is a convenience for performance, not a trusted party. Anyone can run their own prover and produce the same proofs — the path to a permissionless proving market.

How a bet flows through the system

Performance characteristics

The block-validity pipeline sustains around 200 TPS with 1-second blocks (~200 per-bet proofs aggregated in 2–5 seconds on a dedicated proving machine), and scales to 10k TPS as the proving layer is horizontally distributed across the permissionless prover set.

Proof systems

For L1 consumption, the recursive Plonky2 block proof is wrapped in Groth16 (STARK-to-SNARK) to compress it from ~kilobytes to 200 bytes. This is the only place a trusted setup applies to runtime proving, and it's done once per epoch, not per bet.

Hash function

Commitments that must be verified on Ethereum L1 use Keccak256 externally and bridge to the appropriate Poseidon variant internally via a Merkle representation. Goldilocks is chosen for native Plonky2 efficiency, enabling sub-millisecond Poseidon evaluation in-circuit.

Verifiable random function

BLS12-381 is chosen for pairing-friendliness (enabling efficient in-circuit VRF verification within the settlement proof) and for its production-grade security level (~128 bits). The curve is also the foundation of Ethereum's BLS signature scheme, making bridge-side verification straightforward.

Primitive performance

The cryptographic primitives are fast enough to run on commodity hardware — Poseidon hashing in under a microsecond, ECVRF generation and verification well under a millisecond each. In practice this is what lets the games feel instant: settlement happens in milliseconds, not the multi-second waits typical of on-chain systems.

Settlement circuit constraint budget

The per-bet Plonky2 settlement circuit comprises three sub-claims combined into a single proof. Constraint distribution:

Proving time on commodity hardware: 150–400 ms per bet. With GPU acceleration: 15–50 ms per bet. The VRF split optimization moves sub-claim A to a shared batch proof, reducing the per-bet circuit to ~6,000 constraints.

Trusted setup

Two trusted-setup ceremonies are required, both for Groth16 circuits only (Plonky2 needs no setup):

• Per-game RTP setup. One Groth16 trusted setup per game version. Public MPC ceremony with multiple independent participants. Once a single participant burns their toxic waste, the setup is secure. The ceremony is version-locked to the specific circuit hash.
• Block-proof wrapper setup. One Groth16 trusted setup for the STARK-to-SNARK wrapper circuit. Universal across all games and epochs.

Both ceremonies are conducted as public Powers-of-Tau extensions, with the contribution transcripts published for permanent auditability.

The state tree

A single Poseidon sparse Merkle tree holds four leaf types, each keyed by a deterministic value:

The Merkle root is the appchain's canonical state commitment. It is included as a public input in every block validity proof and posted alongside the block on Celestia.

Per-bet on-chain artifacts

For each settled bet, a fixed set of artifacts is published. Every bet is independently auditable by any external party from these artifacts alone:

Block validity

Each block contains a single Plonky2 recursive proof that aggregates all per-bet settlement proofs in that block. The block validity proof establishes three properties:

L1 settlement

At each epoch boundary, the recursive Plonky2 block proof is wrapped to Groth16 (STARK-to-SNARK) and submitted to the L1 bridge contract. The wrapped proof is ~200 bytes; verification costs ~250k gas. The bridge contract maintains the verified appchain state root on Ethereum, and withdrawals are processed against this root.

L1 gas cost is amortized across all bets in the epoch:

Larger epochs reduce per-bet L1 cost at the price of withdrawal latency. Current epoch sizing targets sub-second per-bet cost at expected production throughput.

Data availability

All per-bet artifacts and state-diff data are posted to a dedicated Celestia namespace at each block close, and the Celestia data root is a public input in the block validity proof — cryptographically binding the chain's state to the published data. The compact per-bet summary record is roughly 600 bytes (transaction core, VRF output and proof, outcome and payout, settlement public inputs, and state roots; the full Plonky2 proof itself is larger and re-derivable from the aggregate). At current Celestia pricing the per-bet DA cost lands around $0.000048.

Withdrawal flow

Withdrawals are processed against the L1-verified state root via Merkle inclusion proofs:

Withdrawal is a cryptographic operation, not a customer-service request. The operator cannot block, delay, or partially process a valid withdrawal claim — the bridge contract is the only party with custody.

Why it exists

The single hardest question to answer for any on-chain casino is: what happens to my money if you shut down? On a custodial platform, the answer is "you lose it." On Hypergamble, the answer is "you withdraw it from Ethereum yourself." Because the appchain's state root is verified on L1 by the block validity proof, the record of your balance lives on Ethereum independently of the casino's own infrastructure.

How a normal withdrawal works

The escape path

The Exit Hatch is the same machinery, available even when the casino's own services are offline. If the front-end is down, the sequencer stops producing blocks, or the team is gone, you can interact with the L1 bridge contract directly:

• Your balance is already on L1. The most recent verified state root committed to Ethereum contains your balance. No new cooperation from the operator is needed to establish what you are owed.
• The proof is permissionless. Anyone can generate the Merkle inclusion proof from public on-chain and DA data. The casino does not gatekeep it.
• The bridge contract is autonomous. It verifies proofs and releases funds based purely on the math. It has no "pause withdrawals" admin switch that can trap player funds.

What is cryptographically guaranteed

These properties hold by math. They do not depend on the operator behaving honestly — a dishonest operator simply cannot violate them, because the on-chain verifier rejects any state change that lacks a valid proof.

What the system relies on

Two reliances remain, both explicitly bounded and both on a clear path to removal. Neither lets anyone steal funds or rig an outcome — they concern liveness (whether your bet gets included and proven), not correctness.

Failure modes, and what protects you

Audits

The cryptographic core has undergone independent review, and every new circuit deployment or contract upgrade is audited before it ships. No audit can guarantee the absence of all bugs; players should commit only what they can afford to lose. Audit reports are published as they are completed.

How you earn

Play any game in the ecosystem, or stake in the VIP Vault, to earn three things:

Effective house edge

The base house edge is 1%. VIP status returns a share of that edge to you as rakeback — rising from 5% rakeback at the bottom to 88% rakeback at Red Diamond. At the highest status the effective edge falls to approximately 0.12%, among the lowest in the entire industry.

As a rule of thumb, total rakeback is roughly the VIP Multiplier divided by 10 — so a 5x multiplier corresponds to about 50% rakeback, and the 8.8x top tier to 88%.

VIP levels

Higher XP unlocks a larger rebate on the committed RTP plus higher reward multipliers, which in turn accelerate how quickly you earn rewards. The committed RTP per game is fixed at deployment; the rebate is paid back to you post-settlement. XP brackets are read lower-inclusive, upper-exclusive — e.g. 75 – 200 means 75 ≤ XP < 200. The full ladder of 28 statuses:

XP calculation

XP is a function of the rake you generate, scaled by your VIP multiplier and any temporary boost:

rake = (1 - RTP / 100) * volume_wagered
XP   = rake * VIP_multiplier * 2500 * temporary_boost
( 2,500 XP = 1 $HYPE of rake )

Rake is measured in $HYPE; the VIP multiplier corresponds to your current level; the temporary boost is an occasional multiplier earned randomly in certain games.

Rewards distribution

Rewards are computed as rake × VIP_multiplier / 10 and split across seven streams:

Temporary boosts

Some games award temporary boosts that multiply XP earned for a limited window. Each qualifying bet has a small chance to trigger one.

How you receive gHYPE

Redeeming gHYPE for $HYPE

gHYPE becomes redeemable once you meet a wagering requirement tied to the amount you received:

What you can do with gHYPE

• Bet in games. Every gHYPE bet counts toward your volume requirement and reduces your gHYPE balance.
• Earn VIP progress. gHYPE bets contribute to the VIP System progress bar and earn VIP points just like $HYPE bets.
• Redeem for $HYPE. Once the volume requirement is cleared, convert via the redemption feature.

Why gHYPE is non-transferable

gHYPE cannot be sent between wallets. This is deliberate: it prevents players from shuffling tokens across accounts to artificially satisfy the betting-volume requirement. The token only has meaning in the hands of the player who received it.

FAQ

How do I get gHYPE?

Through promotional campaigns and the VIP rewards system, and by staking $HYPE in the gHYPE Vault.

Can I sell or transfer it?

No. gHYPE is non-transferable and cannot be sold or sent to another wallet.

What if I don't meet the volume requirement?

You keep playing with it, but it won't convert to $HYPE until the 20× wagering requirement is cleared.

How affiliate earnings are calculated

Affiliates are paid in $HYPE, on the net revenue (rake minus rewards) their players produce:

Affiliate $HYPE = (Rake - Rewards) × (Affiliate Tier % + Affiliate Boost %)

Rake and Rewards are the same figures defined on the VIP System page. The percentage you earn is the sum of your tier rate and any active monthly boost.

Affiliate tiers

Your tier rate scales with the net revenue (Rake − Rewards) your active players generate. Brackets are read lower-inclusive, upper-exclusive — e.g. 200 – 400 means 200 ≤ x < 400:

Monthly boosts

On top of your tier rate, you earn a bonus boost based on how many new active players you refer in a calendar month. Boosts reset every month and recalculate on new active-player counts: