Skip to main content
My Crypto Casino is built around a single Solana program that holds the funds, keeps the books, and settles every bet. This page explains, at a high level, what actually lives on-chain and why that lets you rely on code instead of promises.

The program

The MCC program is deployed on Solana mainnet at: MCCd7ygQjPaZFtRenN9nfTPjSW5ynJefxZFKDfBwaxu You can inspect it, and every transaction it has ever processed, on any Solana explorer: Every deposit, withdrawal, bet, and payout is an instruction executed by this program and permanently recorded on the blockchain.

Where the money lives

When you deposit USDC, it does not go to a company bank account or an exchange wallet. It goes into a casino token account owned by the program, and the program simultaneously credits a per-player balance account derived from your wallet address. The books and the vault are the same system:
  • Your balance account records exactly how much of the pooled USDC is yours. It is a public Solana account: you can look it up on an explorer and check it against the app.
  • The casino bankroll is the program’s own balance, funding all payouts. Player stakes flow into it when bets are placed; winnings flow out of it when bets are paid.
  • Releasing your funds requires your signature. A withdrawal is an instruction signed by your wallet; the program checks your recorded balance and transfers the USDC back to you. The platform’s servers cannot spend your balance, and no operator approval is involved.
This is precise custody: the funds are held by an auditable, public program under fixed rules, not by people. Custody model: your wallet signs deposits and withdrawals, the public program holds your balance and the bankroll, and the operator settles games without any path to your funds

Why payouts are enforceable

In a traditional casino, a payout is a promise. On MCC, it is a consequence of program logic:
  • Bets and payouts are program instructions. When a bet settles, the payout math runs inside the program, against the on-chain bankroll. There is no separate “payment processing” step that could stall or be overruled.
  • Max profit caps are sized against the live bankroll. Each bet’s maximum win is a small fraction of the bankroll at bet time (see Betting limits & max profit), so every payout the program can owe is a payout the program can fund.
  • Withdrawals cannot be frozen by policy. The withdrawal path is the same public program: your signature plus a sufficient balance is all it takes.

Separation of powers

Administrative capabilities inside the program are deliberately split across separate keys: the authority that can tune economic parameters is not the one that can move bankroll liquidity, which in turn is not the one that settles games. Each capability has a narrow scope, so no single key controls everything. Program upgrades are gated behind a multi-signature approval process rather than a single key.

Fairness is a separate proof

The architecture above proves your funds are handled by fixed rules; it does not by itself prove game outcomes are fair. That is handled by the commit–reveal provably-fair system, where each result can be independently recomputed and verified. See Provably fair.
The exact economic parameters (house edge, caps, the referral network’s share of the edge) are runtime configuration stored in on-chain accounts. Current values are listed in Fees & limits; the on-chain accounts are always the authoritative source.