Season 1

How to earn

Most of it comes from real gameplay: bets settled on the protocol, scaling with rounds played and volume wagered. Smaller sources add a bit more, referring players who genuinely play, community contributions. Show up once to farm an airdrop, though, and you get nothing.

FAQ

Where can I see my points?

Connect your wallet, and your dashboard shows your points in real time, right alongside where you rank against everyone else.

Can I transfer points?

No. They stay bound to the wallet that earned them. Once the token launches, that same wallet gets the allocation directly. No separate claim step.

What if I miss Season 1?

You can still earn later. Remaining seasons split what's left of the allocation, though the earliest seasons keep the biggest cut.

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. The multiplier gets 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 of it gets 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.31%

1% is the base. It drops from there. The VIP System pays rakeback that climbs with status, up to 69% at the top tier, and that's what pulls the effective edge down to roughly 0.31%, about as low as you'll find anywhere. The full rakeback ladder lives on the VIP System page.

How RTP is committed and verified

Every game has a payout table, outcomes mapped to multipliers, and that table is what its RTP comes down to. It's public*, too: pull it straight from GET /games/:gameId/rtp, nothing hidden about it. The table being visible isn't what protects you, though. The protocol also locks in a cryptographic fingerprint of it at deployment (the RTP commitment, backed by a Groth16 proof and an on-chain verifier address). This commitment protects you: even though the table is public, nobody, Hypergamble included, can swap it out later without everyone noticing.

* This is expected to change. The plan is for the payout table itself to become private, with only the claimed RTP provable via cryptography, rather than the full table being fetchable as it is today. Not yet implemented.

Verification takes three steps. First, pull the claimed RTP and commitment data from GET /games/:gameId/rtp. Next, verify the Groth16 proof either locally or on-chain. Finally, the settlement circuit exposes a per-bet Merkle commitment. Confirm your bet's settlement proof binds directly to it. There's no way to settle against a different table than the one committed to.

RTP by game

* Platform baseline (see above), not yet a game-specific committed figure.

Memecoin promotions work differently: a token issuer funds a positive-EV experience as a marketing campaign, so RTP can exceed 100% for as long as the promotion runs. Each one still gets its own separately committed game version.

The three services

What "provably fair" actually means here

Two separate things both have to be true for a bet to be trustworthy, and each one is checked in its own way:

The fairness verification how-to walks you through checking both of these yourself, using nothing but public information. You don't have to take Hypergamble's word for any of it.

Where trust still sits today

Everything above removes the need to trust that any one bet's outcome or payout was fair. It doesn't mean you never have to trust the operator about anything. A few things today are still promises rather than mathematical guarantees, and a couple of contracts can still be upgraded rather than being permanently locked in place. The trust assumption registry is the honest, itemized list of exactly what those are, and which ones already have a fix shipped or in progress versus which ones don't yet.

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.

Data availability

All per-bet artifacts and state-diff data get posted to a dedicated Celestia namespace at each block close. 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 runs 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.

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 gaming platform 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 Hypergamble's own infrastructure.

How a normal withdrawal works

The escape path

The Exit Hatch is the same machinery, available even when Hypergamble'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. Hypergamble 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 don't 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 one lets anyone steal funds or rig an outcome. What they concern is liveness, whether your bet gets included and proven, not correctness.

Failure modes, and what protects you

Audits

No independent security audit has taken place yet. Hypergamble is currently in beta, and you're responsible for any loss of funds. Only play with what you can afford to lose. Audit reports will be published here once any 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% at the bottom all the way to 69% at Red Diamond. At the highest status, the effective edge falls to approximately 0.31%, among the lowest in the entire industry.

Rule of thumb: total rakeback is roughly the VIP Multiplier divided by 10. A 5x multiplier gets you about 50% rakeback. The 6.9x top tier gets you 69%.

VIP levels

Higher XP unlocks higher reward multipliers, which accelerate how quickly you earn rewards. One thing worth flagging: brackets are lower-inclusive, upper-exclusive, so 75 – 200 means 75 ≤ XP < 200. Here's the full ladder, all 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. One thing worth flagging: brackets are lower-inclusive, upper-exclusive, so 200 – 400 means 200 ≤ x < 400.

Monthly boosts

There's a boost on top of your tier rate, too, tied to how many new active players you bring in during a calendar month. It resets every month and recalculates fresh off that month's count:

Base URL

https://api.hypergamble.bet

Authentication

Every call to the Player API needs two things:

In sandbox, the token is shared. We issue it to you along with your sandbox credentials, and it has to be paired with the x-player-address header naming the address you're acting as. Production works differently: the token is a JWT tied to one specific player address, and the team handles how that gets issued for your integration. Here's the part that trips people up. The server trusts the address baked into the JWT itself, not the header, so your header still has to match it exactly.

Every response comes back as JSON. Errors all share one shape, and status codes stay boring on purpose: 400 for validation problems, 401 for missing or bad auth, 402 for insufficient funds, 403 for forbidden (an address mismatch, say), 404 for not found, 409 for a conflict, 412 for a failed precondition, 429 when you're rate limited.

Two ways to place a bet

There are two completely separate ways to place a bet today, and they're not interchangeable. A bet placed one way gives you nothing the other way can use.

The round flow is what you want for an actual outcome and payout. The bet-intent flow suits a different case: backing a bet with an offline signature instead of keeping a live session open. See How to Verify a Bet to check any round's outcome and payout yourself, independently, using nothing but public data.

Worked example: round flow, start to finish

Every request below assumes the headers from Authentication above. They're left out here just to keep things short.

POST /faucet/claim

GET /players/{address}/next-counter

POST /commitment/hash
{
  "playerNonce": ["<your secret nonce, as one or more numeric strings>"],
  "betParams": ["<bet-type-specific parameters, numeric strings>"],
  "roundCounter": <the value from step 2>
}

POST /games/{gameId}/rounds
{
  "betId": "<a unique id you generate, 8-128 chars>",
  "roundCounter": <same value as step 2/3>,
  "cPlayer": "<from step 3>",
  "betAmount": "<stake, as a numeric string, in base chip units>",
  "betParams": ["<same values as step 3's betParams>"],
  "stakeProvenance": "play" | "withdrawable",
  "betTypeId": "<from GET /games/{gameId}/rtp>"
}

POST /games/{gameId}/rounds/{betId}/reveal
{
  "playerNonce": ["<the secret nonce from step 3, now revealed>"]
}

GET /bet/{betId}

Other useful endpoints

The typed data

{
  "domain": {
    "name": "HyperL2BetIntent",
    "version": "1",
    "chainId": "<runtime: appchain chainId, e.g. 4287>",
    "verifyingContract": "<runtime: deployed verifier address>"
  },
  "primaryType": "BetIntent",
  "types": {
    "BetIntent": [
      { "name": "player", "type": "address" },
      { "name": "gameId", "type": "string" },
      { "name": "betTypeId", "type": "string" },
      { "name": "numOutcomes", "type": "uint32" },
      { "name": "choice", "type": "uint32" },
      { "name": "stake", "type": "uint256" },
      { "name": "bucket", "type": "string" },
      { "name": "provenance", "type": "string" },
      { "name": "nonce", "type": "uint64" },
      { "name": "deadline", "type": "uint64" },
      { "name": "chainId", "type": "uint64" }
    ]
  }
}

Field notes

Worked example

The fixture below is a real signed message, produced from the exact values it contains. Use it to check that your own signing code reproduces the same signature before you wire it into anything unattended.

{
  "domain": {
    "name": "HyperL2BetIntent",
    "version": "1",
    "chainId": 4287,
    "verifyingContract": "0x0000000000000000000000000000000000000000"
  },
  "primaryType": "BetIntent",
  "message": {
    "player": "0x70997970C51812dc3A010C7d01b50e0d17dc79C8",
    "gameId": "dice",
    "betTypeId": "over",
    "numOutcomes": 6,
    "choice": 3,
    "stake": "1000000000000000000",
    "bucket": "available",
    "provenance": "play",
    "nonce": 1,
    "deadline": 9999999999,
    "chainId": 4287
  },
  "expectedSigner": "0x70997970C51812dc3A010C7d01b50e0d17dc79C8",
  "signature": "0x38f3f431299a911428cbf60e5348ddc7db27b41dd4ca02ab7f12f5f0a89e6afe185b79043f1a9550ecf3637be68b3407c51312fc169ce1465acb4c4928a5e1eb1c"
}

verifyingContract here is the zero address. That's a test-fixture value, not a real deployed contract. Swap in the real one for your environment, per Field notes above.

Submitting the signed intent

POST /games/{gameId}/intents
Authorization: Bearer <token>
x-player-address: 0x...   (must equal message.player)

{
  "intent": { ...the message object above... },
  "signature": "0x..."
}

A successful response looks like this:

{
  "betId": "<internal record id>",
  "relayTxHash": "<the on-chain transaction hash the relay submitted>",
  "idempotent": false
}

This applies to bets placed through the round flow (POST /games/{gameId}/rounds → reveal), described in the API integration guide. It does not apply to bets placed through the EIP-712 signed bet-intent flow. That flow doesn't produce the VRF, outcome, and payout artifacts this page verifies. See the API guide's comparison of the two flows if you're not sure which one you used.

What's actually being checked

Three independent things, all reproducible from public data:

You don't have to trust a Hypergamble API response as ground truth for any of this. The verification logic recomputes each of the three from primitives (the published RTP table, a VRF beta, an EIP-712 message), using the same open-source package regardless of where the bet came from.

Verification is source-agnostic; artifact-fetching isn't

The actual math doesn't care whose bet it is: recompute the outcome, check the payout leaf against the root, verify a signature. What differs between checking your own bet and checking someone else's comes down entirely to how you get the artifacts that feed it:

The tool: hyperl2-verifier

hyperl2-verifier is a standalone package that does the recomputation above. It makes zero network calls and imports nothing from the Hypergamble backend. Pure functions in, a verdict out, so you can audit exactly what it does.

pnpm add github:Chainreels/HyperL2Verifier#main

Self-verification, step by step

This is the path that works today: verifying a bet you placed yourself.

const roundJson = await fetch(`https://api.hypergamble.bet/bet/${betId}`, {
  headers: {
    authorization: `Bearer ${yourSessionToken}`,
    'x-player-address': yourAddress,
  },
}).then((r) => r.json());

const rtp = await fetch(`https://api.hypergamble.bet/games/${roundJson.gameId}/rtp`)
  .then((r) => r.json());

import { verifyOutcomeAndPayout, type SettledBetArtifacts, type BetTypeAuditDetail } from 'hyperl2-verifier';

const round: SettledBetArtifacts = {
  betId: roundJson.betId,
  gameId: roundJson.gameId,
  betTypeId: roundJson.betTypeId,
  numOutcomes: roundJson.numOutcomes,
  cTable: roundJson.cTable,
  betAmount: roundJson.betAmount,
  vrfOutputHex: roundJson.vrfOutputHex,
  outcome: { result: roundJson.outcome.result, payout: roundJson.outcome.payout },
};

const betType: BetTypeAuditDetail | undefined = rtp.betTypes.find(
  (bt) => bt.betTypeId === round.betTypeId,
);
if (!betType) throw new Error(`bet type ${round.betTypeId} not found`);

const result = verifyOutcomeAndPayout(round, betType);
if (result.ok) {
  console.log(`Verified: outcome=${result.outcome} payout=${result.payout}`);
} else {
  // reason is one of: OUTCOME_MISMATCH, PAYOUT_MISMATCH, ROOT_MISMATCH,
  // BET_TYPE_ROOT_MISMATCH, LEAF_NOT_FOUND, BET_TYPE_MISMATCH
  console.error(`Verification failed: ${result.reason}`, result.expected, result.actual);
}

Bonus: checking a game's advertised RTP

Separately from any one bet, you can check whether a game's payout table actually pays out what it claims to, across the whole table. It's a registry-level check, not a per-bet one, and it's fully public too:

import { verifyClaimedRtp, type BetTypeAuditDetail } from 'hyperl2-verifier';

const rtp = await fetch('https://api.hypergamble.bet/games/dice/rtp').then((r) => r.json());
const betType = rtp.betTypes.find((bt) => bt.betTypeId === 'over');
if (!betType) throw new Error('bet type not found');

const result = verifyClaimedRtp(betType);
if (result.ok) {
  console.log(`Claimed ${result.claimedBps} bps, table actually pays ${result.computedBps} bps.`);
} else {
  console.error(`RTP claim rejected: claimed=${result.claimedBps} computed=${result.computedBps} tolerance=${result.toleranceBps}`);
}

Signature-only bet-intent verification

If you're checking a signed bet intent rather than a settled round's outcome (for example, confirming a relay is genuinely relaying what a player signed, before it's submitted), that's a separate, narrower check. It confirms authenticity of the message, not fairness of an outcome, since the bet-intent flow doesn't produce outcome artifacts at all (see the EIP-712 guide):

import { verifyBetIntentSignature } from 'hyperl2-verifier';

const result = await verifyBetIntentSignature({
  message: { /* the signed intent's message object */ },
  signature: '0x...',
  expectedChainId: 4287,
  verifyingContract: '0x...', // the deployed bet-intent verifier for your environment
});

if (result.ok) {
  console.log(`Signed by ${result.recoveredSigner}`);
} else {
  // reason is one of: CHAIN_ID_MISMATCH, INVALID_SIGNATURE, SIGNER_MISMATCH, EXPIRED
  console.error(`Signature verification failed: ${result.reason}`);
}

Verifying any bet

Everything above works because you're logged in as yourself, fetching your own bet. Checking a bet you didn't place, an auditor spot-checking random bets, a public explorer widget, anyone who isn't the player themselves, uses the exact same verifyOutcomeAndPayout call. It's just fed from a different, public source: the bet explorer.

const explorerBet = await fetch(`https://api.hypergamble.bet/explorer/bets/${betId}`)
  .then((r) => r.json());

const rtp = await fetch(`https://api.hypergamble.bet/games/${explorerBet.gameId}/rtp`)
  .then((r) => r.json());

import { verifyOutcomeAndPayout, type SettledBetArtifacts, type BetTypeAuditDetail } from 'hyperl2-verifier';

const round: SettledBetArtifacts = {
  betId: explorerBet.betId,
  gameId: explorerBet.gameId,
  betTypeId: explorerBet.betTypeId,
  numOutcomes: explorerBet.bet.numOutcomes,
  cTable: explorerBet.commitments.payoutTableCommitment,
  betAmount: explorerBet.bet.amount,
  vrfOutputHex: explorerBet.vrf.output,
  outcome: { result: explorerBet.bet.outcome, payout: explorerBet.bet.payoutAmount },
};

const betType: BetTypeAuditDetail | undefined = rtp.betTypes.find(
  (bt) => bt.betTypeId === round.betTypeId,
);
if (!betType) throw new Error(`bet type ${round.betTypeId} not found`);

const result = verifyOutcomeAndPayout(round, betType);
if (result.ok) {
  console.log(`Verified: outcome=${result.outcome} payout=${result.payout}`);
} else {
  console.error(`Verification failed: ${result.reason}`, result.expected, result.actual);
}

Contracts get one of four labels: Immutable (deployed with no way to ever change it), Upgradeable (admin) (an admin key can swap out its logic), Upgradeable (timelock) (same, but any change has to sit publicly visible for a delay before it takes effect, so nobody gets surprised by it), or Not yet deployed (built and merged, but not running anywhere live yet).

Every contract, at a glance

Everything else you're trusting

A few things aren't contracts at all, so the table above doesn't cover them. Here's what's actually going on with each, in plain terms:

If Hypergamble ever disappears

This is the backstop for "what if Hypergamble stops responding, or won't process my withdrawal." You can exit entirely on your own, against a balance snapshot the team already published, and nobody has to approve it in the moment.

Who holds which keys