Devnet

Test funds only. Transactions are not real.

Verifiable Fairness

Fair by design.
Auditable by anyone.

Proof of Chance uses player-submitted lucky secrets and strict on-chain checks to keep the draw transparent. The provider can upload lucky secrets, but the chain verifies reveals, records reveal inclusion, and keeps exclusions auditable. Everything you need to audit the winners we pick, whether one or many, is public.

Audit with AI (TLDR)

Click any lottery card, hit Audit, and copy the audit bundle. Paste it into your favorite AI assistant and ask for a transparency verdict on the draw.

  1. 1
    Open a lottery card and click Audit.
  2. 2
    Copy the audit bundle (events + accounts).
  3. 3
    Paste into AI and request a fairness verdict.

Trust you can verify

On-chain commitments

Every ticket and proof-of-chance hash is recorded on-chain with an owner and index. The prize pool, participant counts, and winner votes are public and verifiable.

Attestation guard

During the upload window, participants attest after sending their lucky secrets. Anyone who does not reveal is excluded from winner eligibility, and after deadline the draw can still finalize from revealed participants only.

Deterministic settlement

Winner selection is driven by a deterministic reveal-plaintext draw over reveal-included participants and ticket ranges, so anyone can recompute winners exactly from public data.

How winner selection works

1

Commit on purchase

You submit a proof-of-chance hash (your lucky secret + random salt) when buying tickets. The random salt makes the lucky secret unguessable, even to the game admin, and the hash is stored on-chain for later verification.
2

Attest upload

During the upload window you send your lucky secret to the provider and attest on-chain. Attestations lock your vote for winner count and make missing reveals visible in audit outputs.
3

Verify + aggregate

The program verifies each lucky secret against its on-chain hash and aggregates reveal-derived digests into a deterministic on-chain entropy input (`poc_aggregate_hash`).
4

Deterministic winners

Winner count comes from participant votes (weighted by tickets). Winners are selected deterministically from on-chain state and ticket ranges, and payouts are recorded on-chain for permanent auditability.

Winner selection math (simple example)

The program sorts reveal-included wallets, builds a deterministic seed from lottery fields + `poc_aggregate_hash` + `(wallet,tickets)` tuples, then does `SHA256(seed + round) % remaining_tickets` each round. Ticket ranges are walked in canonical wallet order so everyone gets the same result. Full algorithm details.

draw_index = SHA256(seed || round) % remaining_tickets
  1. 1
    Ada buys 3 tickets and reveals. Jesus buys 2 tickets and reveals. The lottery seed is derived from sorted wallets + tickets and poc_aggregate_hash.
  2. 2
    Round 1 computes draw_index = SHA256(seed || 0) % 5. If draw_index = 3, ticket ranges (Ada 0-2, Jesus 3-4) select Jesus.
  3. 3
    For round 2, remove Jesus, remaining_tickets = 3, then recompute SHA256(seed || 1) % 3 to select the next winner.

Winner count comes from participant votes (weighted by tickets), and the loop repeats until the selected number of winners is reached.

Transparency you can prove

Public trail

Every state change is an on-chain event. You can audit ticket purchases, lucky secret uploads, winner selection, and claims without trusting our UI.

Open data

The lottery state lives in public program accounts. Any RPC, indexer, or explorer can reconstruct the entire draw, including votes and entropy inputs.

No hidden control

Attestations and on-chain verification prevent silent exclusion. Admin actions are visible, so you can verify any parameter changes and confirm no one can steer outcomes.

Powered by Solana
Proof-of-Chance entropy
Open Source