Builder’s Corner: Auditing Smart-Contract Casinos Without Tears

Why casino contracts are different

Casino contracts combine two hard problems: provable randomness and immediate money movement. Both are MEV magnets and fail closed in user-visible ways. Your audit should prove that outcomes are unpredictable, that funds cannot be drained or stuck, and that operations survive adverse chain conditions. Treat this like safety-critical software, not a weekend hack. Trail of Bits calls this shift “invariant-driven development,” emphasizing properties that must always hold.

The audit mindset: specifications → properties → proofs

Start by writing a plain-English spec and encode it in code comments using Solidity’s NatSpec so it survives code rotations and feeds tools. Then derive invariants and properties that you can fuzz, symbolically explore, or formally check.

• Document intent and edge cases in NatSpec so tests and auditors see the contract’s truth.
• Turn requirements into properties and invariants (e.g., “houseEdge ≤ maxEdge,” “sum(bets) − sum(payouts) = profit ± fees,” “bankroll ≥ maxPayout”). Property-based techniques are the standard in smart-contract security and are well supported by Echidna/Foundry.

Randomness that stands up to adversaries

Randomness is the heart of fairness.

Do not use block.timestamp, blockhash, or similar block values as entropy; they are miner/validator-influenced and predictable. Solidity’s own docs warn against it, and SWC-116 catalogs this hazard.

Preferred options:

1. Chainlink VRF (v2.5) for on-chain, verifiable randomness. Follow the official integration and security notes: match requestId to fulfillments, avoid accepting bets after requesting randomness, and make fulfillment paths non-reverting.
2. Commit-reveal when you can tolerate latency or multi-party interaction. Use a pre-commit hash, then reveal the nonce after bets close; see the formal analyses that describe commit-reveal as a standard anti-front-running construction.
3. For advanced builds, consider beacon randomness networks (e.g., drand) as external sources, still acknowledging on-chain verification and miner effects.

Audit properties to assert:

• A bet’s outcome is determined only by an approved RNG result (VRF proof verified or valid commit-reveal).
• No function allows re-requesting or canceling randomness to cherry-pick outcomes.

Payouts & bankroll: getting money flows right

Two principles prevent griefing and stalled casinos:

• Pull over push: avoid paying users inside loops or during state-changing flows; let winners withdraw themselves. This mitigates DoS with failed calls (SWC-113) and reduces reentrancy blast radius. OpenZeppelin provides PullPayment and emergency Pausable.
• Never rely on a single external call succeeding: SWC-113 demonstrates how one failing recipient can revert the whole transaction. Validate and isolate transfers.

Audit properties to assert:

• Total bankroll after a bet equals prior bankroll ± bet − payout − fees.
• Maximum payout per game ≤ current bankroll and respects per-bet caps.
• No winner or the house can be permanently blocked from withdrawing due to another user’s failure.

ERC-20 realities that break casinos

Casinos often accept/deposit tokens, not just native ETH. Real-world ERC-20s are messy:

• Non-standard returns (e.g., USDT) require wrappers; always use SafeERC20.
• Fee-on-transfer/rebasing tokens mean the contract may receive fewer tokens than requested; adjust accounting to balanceAfter − balanceBefore, not the requested amount. Uniswap documents “inclusive fee-on-transfer” behavior; multiple security write-ups echo this pitfall.

Audit properties to assert:

• Deposits credit exactly what the contract actually received.
• Withdrawals send exactly what the contract debits.
• No underflow/overflow in aggregates (Solidity ≥0.8 checks this by default, unless explicitly unchecked).

Reentrancy, CEI, and emergency brakes

Reentrancy is still the top casino killer if payouts or token calls are intertwined with state updates.

• Follow Checks-Effects-Interactions (CEI): validate, update state, then interact externally. Solidity and industry guides promote CEI as a baseline mitigation.
• Guard sensitive flows with ReentrancyGuard where appropriate.
• Build an emergency circuit breaker (Pausable) for halting betting/payouts during incidents.

Also review SWC-107 (Reentrancy) patterns during code review.

Upgrades without foot-guns

Upgradeable casinos let you fix bugs, but proxy mistakes are catastrophic.

• Understand Transparent vs UUPS proxies and storage slots under ERC-1967. OpenZeppelin’s docs summarize the trade-offs.
• If you use UUPS, initialize and then disable further initializers on the implementation to avoid known 2021-era exploits; see the official Oz advisory and guidance on _disableInitializers.
• Study common proxy risks: uninitialized proxies, storage collisions, malicious upgrades. Recent overviews and best-practice primers can help you build runbooks and tests.

Audit properties to assert:

• Only a designated role can upgrade; upgrades emit events; post-upgrade invariants still hold.
• The implementation cannot be self-destructed or hijacked through initializer misuse.

Gas & DoS: make “place bet” always callable

Casinos are hot paths; they must not fail because a data structure grew.

• Avoid unbounded loops on user-controlled data. SWC-128 catalogs “block-gas-limit DoS”; real reports show loops over growing arrays eventually make functions uncallable. Use batching and pagination.

Audit properties to assert:

• Gas cost per hot function is bounded with respect to user inputs.
• No write path depends on iterating an unbounded set.

Tooling pipeline you can automate

A repeatable pipeline catches classes of bugs quickly and proves your properties:

1. Static analysis with Slither to flag common hazards and generate architecture views.
2. Property-based fuzzing with Echidna and invariant testing with Foundry to encode fairness/solvency guarantees as code.
3. Symbolic execution with Mythril or Manticore to explore tricky paths beyond random fuzzing.
4. Formal verification (rule-based) when feasible (e.g., payout conservation, access control) using Certora Prover or Solidity’s SMTChecker.

Production hardening and ops

• Access control: Use roles instead of monolithic ownership; separate upgrade, pause, and bankroll roles.
• Monitoring & alerts: Track VRF request/fulfillment mismatches and unexpected payout ratios following Chainlink’s security considerations.
• Documentation: Keep NatSpec accurate so UIs, users, and auditors see the intended behavior.

Pre-launch audit checklist

Use this as a “no-tears” gate before mainnet:

• Randomness
  • No block values used for entropy. VRF v2.5 or commit-reveal only.
• Payouts & Bankroll
  • Pull over push; withdrawals are isolated and non-blocking. SWC-113 mitigated.
• Tokens
  • SafeERC20 for all token interactions; fee-on-transfer accounted by measuring balances.
• Reentrancy & CEI
  • CEI respected; ReentrancyGuard on sensitive paths; pause switch present.
• Upgrades
  • Proxy pattern documented and tested; UUPS implementations initialized and initializers disabled; storage layout checked.
• Gas/DoS
  • No unbounded loops on user data; hot paths benchmarked; batch ops where needed.
• Properties & Tests
  • Invariant suite for solvency/edge; Echidna/Foundry runs green; symbolic pass on critical functions.

FAQ

Is Solidity 0.8 enough to prevent math bugs?
It adds checked arithmetic by default; over/underflows now revert unless you explicitly use unchecked. You still need property tests to catch logic errors.

Is the SWC registry still relevant?
It’s a handy taxonomy for checklists, but it’s not actively maintained; don’t treat it as complete.

Can I skip VRF and use a hash of inputs?
Not for production casinos. Block values are miner-influenced; use VRF or a well-designed commit-reveal with betting closed before reveals.