Smart Contract Audits Explained
What security audits cover, how they are conducted, which vulnerability classes they catch, and why an audit is not a guarantee that a contract is safe.
“Audited by [Famous Security Firm]” appears on the landing page of nearly every serious smart contract gambling platform. It is meant to reassure: independent experts have reviewed the code and found it sound. That reassurance is partially justified. An audit from a reputable firm is genuinely meaningful due diligence — and it is nowhere near a guarantee of safety. Understanding what audits actually do, and what they cannot do, is essential for anyone evaluating an on-chain casino.
What an Audit Is
A smart contract audit is a systematic code review performed by a security firm. The firm’s engineers read the contract source code manually, run automated analysis tools, and attempt to identify vulnerabilities before the contract handles real money. The output is a report classifying findings by severity — typically Critical, High, Medium, Low, and Informational — along with recommendations for remediation.
Audits can be narrow (a single contract) or broad (an entire protocol, including off-chain components). They typically take two to six weeks for a meaningful-sized codebase. The cost ranges from tens of thousands to several hundred thousand dollars. Well-known audit firms include Trail of Bits, OpenZeppelin, Certik, Halborn, Spearbit, and Code4rena (which runs competitive “audit contests” with many independent researchers).
What Auditors Actually Check
Reentrancy
The classic Ethereum vulnerability: a contract sends ETH to an external address before updating its own state, allowing a malicious contract to call back in and drain funds repeatedly. The 2016 DAO hack exploited exactly this. Auditors look for patterns where external calls precede state updates and flag them for the “checks-effects-interactions” fix.
// Vulnerable pattern
function withdraw(uint256 amount) external {
require(balances[msg.sender] >= amount);
(bool success,) = msg.sender.call{value: amount}(""); // external call first
require(success);
balances[msg.sender] -= amount; // state update after — too late
}
// Corrected pattern
function withdraw(uint256 amount) external {
require(balances[msg.sender] >= amount);
balances[msg.sender] -= amount; // update state first
(bool success,) = msg.sender.call{value: amount}("");
require(success);
}
Integer Overflow and Underflow
Before Solidity 0.8, arithmetic did not revert on overflow. A balance of 0 minus 1 would wrap around to the maximum uint256 value. Auditors check for pre-0.8 contracts without SafeMath or similar protections, and verify that post-0.8 contracts handle unchecked blocks carefully.
Oracle Manipulation
Gambling contracts that rely on price feeds or external data sources are vulnerable if those feeds can be manipulated. Auditors examine whether price oracles can be influenced by a single large transaction (flash loan attacks), whether data feeds have adequate time-weighted averaging, and whether a single oracle source creates a single point of failure.
Access Control
Who can call privileged functions — pausing the contract, upgrading it, withdrawing the bankroll? Auditors verify that only intended parties hold admin roles, that ownership transfers require confirmation (to prevent accidental loss of admin keys), and that timelocks are in place for high-impact changes.
Randomness Weaknesses
If a casino contract uses block hashes, block timestamps, or other miner-influenceable values as randomness sources, auditors flag it. They check that VRF integrations are correctly implemented — that the contract actually verifies the proof before using the random number, and that the request-fulfillment cycle cannot be exploited.
Logic Errors
Beyond specific vulnerability classes, auditors read the business logic: does the payout formula correctly implement the stated house edge? Can a player construct a bet that extracts more than the maximum allowed win? Are edge cases (zero bets, max-value inputs, simultaneous transactions) handled gracefully?
The Audit Report
A good audit report is public, named, and version-specific. It names the code commit hash that was audited, lists findings with severity classifications, and shows which findings were fixed, acknowledged, or accepted as known risks before the report was finalized. Legitimate platforms publish their full audit reports, not just a “passed audit” badge.
Red flags: audit reports that are private, undated, cover a different version of the code than what is deployed, or are from firms with no track record or verifiable reputation.
Why an Audit Is Not a Guarantee
This is the critical point that marketing materials obscure.
Audits are point-in-time. The report covers the code as it existed during the audit window. Post-audit changes — a bug fix, a feature addition, an upgrade via proxy — are not covered. Many hacks have exploited code added after the last audit.
Auditors are human. Novel attack vectors, complex multi-contract interactions, and subtle logic errors in business rules are genuinely hard to spot. Some of the most significant DeFi exploits passed audits from multiple respected firms before being discovered in production.
Scope limitations are real. An audit of Contract A does not audit the oracle it relies on, the frontend that constructs transactions, the admin multi-sig setup, or the off-chain components. A vulnerability in any of these can cause losses even if the core contract is sound.
Economic attacks are often out of scope. Auditors typically do not model every possible market manipulation or flash loan sequence. A contract can be technically correct and still be economically exploitable under adversarial conditions.
Bug Bounty Programs
Reputable protocols supplement audits with ongoing bug bounty programs — public offers to pay researchers who find and responsibly disclose vulnerabilities. Immunefi is the dominant platform for on-chain bug bounties. A substantial bug bounty (six or seven figures for critical findings) signals that a team takes security seriously and wants vulnerabilities found before attackers find them.
A casino with no bug bounty, or a token bounty offering rather than cash, is missing a meaningful layer of ongoing security incentive.
How to Evaluate an Audit
When a platform claims to be audited, ask:
- Which firm? Does the firm have a public track record and verifiable staff?
- When? Was the audit before or after the most recent code changes?
- What scope? Does it cover the full contract suite, or just the core game logic?
- What was found? How many criticals and highs, and were they all resolved?
- Is the report public? Can you read it yourself?
Audits are necessary but insufficient due diligence. They are one input among many — including the platform’s history, the team’s transparency, the upgrade mechanisms in place, and the size of the bankroll relative to maximum exposure. For context on the vulnerability classes that audits target, see smart contract exploits and hacks. For broader due diligence guidance, see our methodology or visit responsible gambling before committing funds to any on-chain platform.