← Back to SolFlip

1. Introduction

Online gambling has long suffered from a fundamental trust problem: the house controls the random number generator. Players must accept on faith that outcomes are fair. Public-key cryptography removes this requirement: when the operator commits to a secret before resolution and reveals it afterwards, any player can verify that the published outcome follows from the committed secret — no faith in the house required.

SolFlip combines provably fair randomness with a deflationary token model. Each flip — win or lose — permanently reduces the supply of SFLIP. The longer the protocol runs, the scarcer SFLIP becomes. This is not a design choice subject to future governance votes; it is an invariant of the settlement logic.

The protocol is deployed on Solana, chosen for its sub-second finality, negligible transaction fees, and mature SPL token standard. The game client requires only a Phantom wallet. There is no account registration, no KYC, and no custody of funds beyond the player's own deposit wallet.

2. Token — SFLIP

Property	Value
Standard	SPL Token-2022 on Solana
Decimals	6
Supply	Fixed at launch — mint authority revoked after creation
Burns	Deflationary — supply decreases with every flip played
Utility	Exclusive betting token for the SolFlip game ecosystem

SFLIP has no mint authority after launch. No additional tokens can ever be created. The total supply is a ceiling, not a floor — it can only decrease over time as the game is played.

3. Game Mechanics

Players deposit SFLIP into a personal deposit wallet managed by the backend. Balances are tracked virtually in the database. All game actions update virtual balances instantly — no on-chain confirmation is required per flip.

3.1 Bet Resolution

1. Player chooses HEADS or TAILS and submits bet_amount
2. Server generates server_secret (32 random bytes)
3. Server publishes commitment = SHA-256(server_secret) to client
4. Outcome = SHA-256(server_secret || wallet_address || bet_amount) % 2
   0 = HEADS,  1 = TAILS
5. Server reveals server_secret — player can independently verify

3.2 Burn Rates

Event	Burn	Notes
Bet placed	Variable	Deducted before payout calculation
Win payout	Variable	Applied to gross win; net payout = gross × (1 − rate)
Loss	Variable	Remainder credits the prize pool

Burn rates are operator-configurable and may be adjusted over time to balance token deflation with player experience. Current rates are published in the Admin dashboard and reflected in-game at all times.

Burns accumulate virtually in the database and execute on-chain at withdrawal. This batching eliminates per-flip Solana transaction fees (~5,000 lamports each).

4. Prize Pool

The prize pool is a virtual ledger: credited on every loss, debited on every win. It represents the house's current liability for outstanding payouts.

A configurable minimum balance acts as a stop gate — when the pool falls below the configured threshold, the game pauses automatically into maintenance mode, protecting the house from insolvency. The maximum bet is dynamically capped at a configurable percentage of the live prize pool balance (default: 25%), limiting single-bet exposure.

5. Provably Fair RNG — Commit-Reveal

SolFlip uses a commit-reveal scheme to guarantee the house cannot retroactively alter flip outcomes.

5.1 Protocol

BEFORE you place a bet (and before the server knows your stake or side):
  1. Server generates server_secret (32 cryptographically random bytes)
     for your NEXT flip only. This step takes no input — there is no bet
     to optimise against.
  2. Publishes commitment = SHA-256(server_secret). Fetchable at any time
     from /game/commitment, and returned with every flip result as the
     binding for the following flip. Record it before you bet.

You then choose your stake and side. The flip resolves against that
already-published commitment:
  3. Server reveals server_secret
  4. Outcome = SHA-256(server_secret || wallet_address || bet_amount) % 2
  5. A fresh commitment is issued for your next flip

The ordering is the guarantee. Because the secret is committed before the stake exists, the server can neither alter the outcome afterwards (the revealed secret must hash to the published commitment) nor select a favourable secret in advance (when it commits, it does not know what you will bet or which side you will pick). Requesting the commitment repeatedly returns the same value until it is consumed, so it cannot be re-rolled on demand.

5.2 Player Verification

Any player can independently verify any past flip using any SHA-256 tool (openssl, Python, etc.):

$ echo -n "{secret}{wallet}{bet}" | sha256sum
# Divide result (hex) by 2 — remainder is the outcome (0=H, 1=T)

Step 1: SHA-256(secret) === published_commitment  →  server committed honestly
Step 2: Re-derive outcome from the seed           →  result matches game record

Every flip's commitment, secret, wallet, and bet amount is persisted to the game_rounds table and available for third-party audit.

6. Settlement Model

Zero on-chain transactions occur during gameplay. Settlement fires at two points only:

6.1 Withdrawal (Player-Triggered)

1. House tops up the deposit wallet: shortfall + pending_burns
2. Player receives virtual balance on-chain
3. Surplus ≈ pending_burns is burned from the deposit wallet
4. House receives any surplus beyond the burn obligation

6.2 Daily Sweep (02:00 UTC, Automated)

For each idle deposit wallet with on-chain surplus:
  burn   = min(player.pending_burns, surplus)
  house  = surplus - burn

The house receives genuine profit only — not a fixed ratio.
Pending_burns are decremented on-chain after each confirmed burn.
Only applies to wallets not yet settled via withdrawal.

This model eliminates per-flip fees entirely and defers all on-chain activity to the minimum necessary settlement events.

7. Prize Draws — Mini Win & Maxi Win

7.1 Mini Win — Weekly SOL Draw

Property	Value
Schedule	Every Monday at 12:00 UTC
Eligibility	Any player who flipped at least once in the past 7 days
Winner selection	Random from eligible wallets, drawn with the same commit-reveal scheme as flips (Section 5)
Prize	Full SOL pool balance — paid on-chain to winner's wallet
Pool funding	Operator-seeded; balance displayed live on game page

7.2 Maxi Win — Monthly SOL Jackpot

Property	Value
Schedule	1st of each month at 12:00 UTC
Eligibility	Any player active in the past 30 days
Winner selection	Random from eligible wallets, drawn with the same commit-reveal scheme as flips (Section 5)
Prize	Full SOL jackpot pool — paid on-chain to winner's wallet
Pool funding	Operator-seeded; displayed live on game page

Both draws are funded by operator discretion and do not draw from the SFLIP prize pool. No additional entry steps are required — playing the game is sufficient for eligibility.

8. House Edge

The house edge derives from the burn mechanics, not from a biased coin. The flip itself is a true 50/50. The house advantage comes from the compounding burn applied to every action:

Expected value per unit wagered:
  Effective bet    = bet × (1 - 0.10)             = 0.90 × bet

  Win case (50%):  gross_win = 2 × effective_bet = 1.80 × bet
                   less the 10% win burn
                   payout    = 1.62 × bet   (credited to balance —
                                             includes the returned stake)
                   net gain  = +0.62 × bet

  Loss case (50%): the full bet leaves the balance = -1.00 × bet
                   of which 0.28 × bet is burned
                   and       0.72 × bet credits the prize pool

  EV per bet = 0.5 × (+0.62) + 0.5 × (-1.00)  =  -0.19 × bet

The house edge is therefore approximately 19% of the amount wagered, captured as token burns (permanent supply reduction) plus prize-pool accrual — not as a biased coin. Realised EV depends on player win rate and session length.

8.1 Prize Pool Sustainability

The prize pool funds only the profit on a winning flip (0.62 × bet) — the player's stake returns from their own already-deducted balance — while a losing flip credits 0.72 × bet to the pool. The pool's expected change is therefore +0.05 × bet: it accrues with volume rather than depleting, independently of any individual player's luck. A stop-gate additionally pauses play if the pool falls below its configured minimum, so the protocol cannot accept a wager it might be unable to pay.

9. The Flywheel Effect

SolFlip is designed as a self-reinforcing economic system. Each component of the protocol feeds the next, creating a compounding growth loop that benefits players, token holders, and the long-term health of the ecosystem simultaneously.

9.1 The Six-Stage Loop

  [1] PLAYERS FLIP
       │  SFLIP is wagered on each flip
       ▼
  [2] SFLIP BURNS
       │  A variable burn tax permanently destroys tokens on every action
       ▼
  [3] SUPPLY SHRINKS
       │  Fixed 1B maximum supply deflates continuously; tokens destroyed
       │  cannot be re-minted under any circumstance
       ▼
  [4] VALUE RISES
       │  Scarcity exerts upward price pressure on remaining supply
       ▼
  [5] PRIZES WORTH MORE
       │  The SOL prize pool (Mini Win / Maxi Win) grows as losses are
       │  credited to it; simultaneously, SFLIP scarcity means the same
       │  SOL jackpot represents greater purchasing power for winners
       ▼
  [6] MORE PLAYERS JOIN
       │  Higher expected prize value attracts new participants
       └──► back to [1]
  

9.2 Secondary Loop — Prize Pool Accumulation

In parallel with the deflation loop, every losing flip credits a portion of the effective bet to the SOL prize pool. This is independent of token price and ensures the jackpot grows monotonically with game volume. The two loops compound: higher player count increases both burn rate (deflationary pressure) and prize pool deposits (SOL jackpot size), each independently attracting further participation.

9.3 Flywheel Sustainability

Unlike yield-farming schemes that depend on new capital to pay existing holders, the SolFlip flywheel derives its energy from game activity. Burns are irreversible and require no counterparty. The prize pool is funded by losses, not by the protocol treasury. This means the loop continues to function at any level of player volume — it does not require exponential growth to remain solvent.

The 500M Game Rewards tranche (released over 20 months via Streamflow Finance) provides a further deflationary tailwind: controlled emission prevents supply shocks while ensuring team and operations wallets cannot dump ahead of the community.

Lock & vesting schedule

70% of total supply vests through Streamflow Finance. Every vesting contract is created non-cancellable: once locked, the schedule cannot be shortened, reversed or reclaimed by anyone, including the team. Contract addresses are published on the site on launch day and are verifiable on Streamflow and any Solana explorer.

Tranche	Amount	Type	Schedule
🎮 Game Rewards	500M	Vesting stream, non-cancellable	20 months linear, no cliff (~25M/month, released into the prize pool)
💧 Future LP	200M	Vesting stream, non-cancellable	20 months linear, 3-month cliff (~10M/month)
👥 Team	10M	Hard lock, non-cancellable	6-month cliff, then 6 months linear
🤝 Partnerships	15M	Locked per deal	12-month vest, created when each grant is made
📣 Marketing & CEX	~55M	Liquid, labelled wallets	Unlocked by necessity; addresses published, spending visible on-chain
🧯 LP buffer	~20M	Liquid, labelled wallet	Held for liquidity depth top-ups on new pools or listings

The Future LP mechanism. Each month, as ~10M SFLIP unlocks, half is sold — solely to raise the SOL side of a liquidity pair — and the remaining half is paired with that SOL and added as liquidity. The resulting LP tokens are then burned, so that liquidity can never be withdrawn. We disclose the sell explicitly because it is visible on-chain in any case: its purpose is liquidity depth, and every pair-and-burn transaction is published.

Allocation figures are targets and may vary slightly — the exact split depends on how much supply the bonding curve releases at launch. Final on-chain figures and every vesting contract address are published on the site on launch day.

10. Security

• Wallet authentication: Phantom signs a server-issued nonce (Ed25519). Backend verifies and issues a 24-hour HMAC session token. All game and withdrawal calls require this token.
• Deposit replay guard: Each deposit transaction signature is checked for uniqueness before crediting. Replayed signatures are rejected.
• Race condition protection: Player rows are locked with SELECT FOR UPDATE during balance updates, preventing double-spend via concurrent requests.
• Admin authentication: TOTP (Google Authenticator) plus password required for all admin operations. Session tokens expire after 8 hours.
• Commit-reveal RNG: House cannot retroactively alter outcomes. The cryptographic commitment is published before the flip resolves (see §5).
• Treasury custody: The protocol treasury is held on a Ledger hardware wallet. No private key is stored on or accessible to the server — balance tracking is read-only via public RPC.
• HTTPS: All production traffic encrypted via TLS (Let's Encrypt).

11. Legal Disclaimer