A contract audit is a review of the roulette contract’s source code by a security firm, looking for ways the code could pay the wrong amount, draw an unfair number, lose the bankroll or be changed without notice, and it ends in a written report that lists every finding by severity. It certifies that a named firm looked for a named set of problems on a named date and found, or did not find, each one.
Three areas cover what a roulette audit examines, and each has a set of checks that appear in almost every report. Sites on lists of the best crypto roulette sites on-chain generally link the report from their fairness page.
Randomness checks
- Randomness source – Whether the pocket comes from a VRF, a commit and reveal, or a block hash, and whether any party can influence or predict it.
- Reveal timeouts – On commit and reveal tables, whether a side that refuses to reveal is penalised, and whether the windows can be gamed by delaying.
- Callback restrictions – On VRF tables, whether the fulfilment function accepts calls only from the coordinator, and whether a stale or duplicate fulfilment is rejected.
- Bet locking – Whether the bet is fixed before the randomness is requested, so that no one can bet after seeing the number.
Money checks
- Payout arithmetic – Whether multipliers are applied correctly for every bet type, whether rounding is consistent, and whether an overflow or underflow can produce a wrong payout on large or tiny stakes.
- Bankroll checks – Whether the contract confirms it holds enough to pay the maximum possible win before accepting a bet.
- Reentrancy – Whether the payout function can be called again before it finishes, which is the classic way a contract is drained.
- Refunds – Whether a bet that cannot be settled, because a VRF request fails or a reveal window lapses, is returned to the player rather than kept.
Control checks
- Owner powers – What the operator can do: pause, change limits, change multipliers, withdraw the bankroll. Each is listed with whether it has a timelock.
- Upgradeability – Whether the contract sits behind a proxy that can swap its logic, who can trigger the swap, and whether a delay gives players time to withdraw first.
- Access control – Whether functions meant for the owner or the oracle can be called by anyone else through a missing modifier.
- Emergency withdrawal – Whether there is a function to pull all funds in one call, and who holds the key to it.
Reading the report takes four steps:
- Check the date and the contract address in the report against the address the table uses. An audit of a previous version, or a different address, does not cover the table you are betting on.
- Read the findings summary, which lists counts by severity: critical, high, medium, low and informational. Findings marked resolved were fixed before publication.
- Read the high and critical findings in full. Each describes the problem, the code line and the fix.
- Check for a follow-up or re-audit note confirming the fixes were reviewed.
An audit with no unresolved high findings, on the address you bet at, dated after the last upgrade, is as much assurance as the code can give. One that fails any of those tests is a document about a different contract.
