A Solidity audit is a review of one specific version of a contract's source code — usually pinned to a single commit — by people and tools looking for ways the contract can be made to misbehave. Teams commission one before a launch, a listing or a fundraise, and the report becomes part of how they answer the question every investor eventually asks: is this contract safe to hold? The audit answers part of that question well. It says what the reviewed code does and where it can break. It does not follow the contract onto the chain, where ownership, liquidity and upgrade rights keep changing after the report is signed. Both halves matter to the people deciding whether to buy.
Before the Solidity audit: what a reviewer needs
Most of the value of an audit is decided before it starts. A reviewer can only reason about code that holds still and about intentions that are written down. The preparation that pays for itself:
- A frozen scope. A list of the files under review and the commit hash they come from. Anything changed after the freeze is outside the report, however small the change looks.
- Written intent. Who is allowed to call what, which values must never change, which limits must always hold — for example, that total supply never exceeds the cap. A reviewer compares the code against this; without it, there is nothing to compare against.
- A passing test suite with measured coverage. Untested paths are where reviewers spend the most time, and the client pays for that time.
- The deployment plan. Constructor arguments, proxy setup, and who will hold the owner and admin keys after deployment.
- Known issues and deliberate trade-offs, so reviewers do not spend hours rediscovering them.
A few commands cover the mechanical part of that preparation in a Foundry project:
# Pin the exact code under review
git rev-parse HEAD
# Run the suite and measure coverage before the reviewer does
forge test
forge coverage
# A free static-analysis pass catches the cheapest findings first
slither .What a Solidity security audit checks
The exact list depends on the code, but a Solidity security audit works through the same families of questions every time. The table below is a practical audit checklist, not an exhaustive one:
| Area | The question a reviewer asks | A typical finding |
|---|---|---|
| Access control | Who can call privileged functions, and can that set of callers change? | A mint or upgrade function without a role check; an initializer anyone can call |
| Reentrancy | Can an external call re-enter before state is updated? | A balance cleared only after funds are sent |
| Upgradeability | Who can upgrade, is the implementation initialized, can storage collide? | A storage layout reordered between versions |
| External calls and oracles | Are return values checked, can a price be moved within one block? | A spot price read from a single thin pool |
| Token mechanics | Who controls fees, blacklists, pausing and transfer limits, and within what bounds? | An owner able to raise the sell tax without a ceiling |
| Arithmetic and precision | Which way does rounding go, what runs inside unchecked blocks? | Rounding in the user's favour on withdrawals |
| Denial of service | Can a loop or a failing recipient block everyone else? | A payout loop over an unbounded list of holders |
Reentrancy is the classic example of why order matters. The vulnerable version sends funds before clearing the balance, so a malicious recipient can call back in and be paid again from the same balance:
// Vulnerable: the balance is cleared after the external call
function withdrawAll() external {
uint256 amount = balances[msg.sender];
(bool ok, ) = msg.sender.call{value: amount}("");
require(ok, "transfer failed");
balances[msg.sender] = 0; // too late: a re-entrant call saw the old balance
}
// Checks-effects-interactions, plus OpenZeppelin's ReentrancyGuard
function withdrawAll() external nonReentrant {
uint256 amount = balances[msg.sender];
balances[msg.sender] = 0; // effects before interactions
(bool ok, ) = msg.sender.call{value: amount}("");
require(ok, "transfer failed");
}How smart contract audit cost is set
Smart contract audit cost follows the work. The main drivers are the amount of code in scope, how unusual its logic is, how many contracts interact, whether upgradeability is involved, how soon the report is needed, and the reputation of the firm. Publicly reported ranges for manual reviews run from about $5,000 for a compact token contract to $100,000 or more for large protocols at top-tier firms; the audit firm pricing comparison sets those ranges side by side.
Two questions change the final number more than the headline quote. First, is a review of the fixes included, or billed as a second engagement? Second, what exactly is in scope — a single token contract, or the token plus its staking, vesting and treasury contracts? Automated scans cost a small fraction of a manual review and are useful before one and between releases. They do not replace a reviewer reasoning about novel logic.
Choosing a smart contract auditor
A smart contract auditor is easier to judge by their published work than by their marketing. Before signing, it is worth checking:
- Reports on similar code. A firm that has reviewed many ERC-20 tokens is not automatically the right reviewer for a lending protocol, and the reverse also holds.
- What the report will state. The commit hash, the list of files, the severity definitions, and how each finding was resolved.
- Fix review. Whether the auditor confirms that each fix actually resolves its finding.
- Timeline against the launch date. Reported turnarounds for manual audits range from roughly one to eight weeks, and a rushed scope is a narrower scope.
- Publication. Whether the report will be public, and where investors will find it.
After the report: fix, confirm, deploy what was audited
An audit ends with findings, not with safety. The team fixes them, the auditor reviews the fixes, and the final report records which were resolved and which were accepted as known risks. One step is skipped surprisingly often: making sure the contract deployed on-chain is the code that was audited. Publishing the verified source on Etherscan, or the matching explorer for another EVM chain, lets anyone compare the deployed contract with the audited commit. A report about code that never shipped describes nothing.
What investors check once the contract is live
A Solidity audit is pinned to a commit. Once the contract is deployed, a second set of facts takes over, and investors can check them without reading a line of code. Does the owner still hold privileged roles, or was ownership renounced or moved to a multisig? Can an upgrade admin replace the logic? Can new supply still be minted? Can trading be paused or addresses blacklisted? Where does the liquidity sit, and is it locked? How concentrated are the holders?
A good audit flags which of these powers exist in the code. Whether they are still held, by whom, and whether the pool is locked are facts about the deployment, and they keep changing after the report is signed.
A dated public record of the deployed token
Quantum Audit is an automated smart-contract security analysis platform for Web3 that reads a deployed token's contract and on-chain facts and publishes the result as a dated, public record. Risk score is computed by a deterministic, auditable function. Each contributing factor is recorded and reproducible across runs — same contract, same score, every time. The scoring methodology lists every factor and how it moves the score, and each record lives on the public token security dashboard that traders check before they buy.
For a team that has been through an audit, the record is the part investors can open next to the report. The Founder plan puts one token on that public record for $149 for 12 months. Ownership is confirmed before anything is published. The record carries the Verified badge with scheduled re-verification of the on-chain facts, the project's own links on the page, and a share card the team can post to its community. Verified records also appear in the dashboard's Verified view.
Verified means the owner confirmed ownership and keeps the record re-verified for the plan's term. It is not a guarantee that a token is safe and not a substitute for an audit of novel code. The score is not for sale — re-verification can move it in either direction, on the owner's own page — which is exactly why an investor can take it at face value.
FAQ
How much does a Solidity audit cost?
It depends on the amount and complexity of the code in scope, the timeline and the firm. Publicly reported ranges for manual reviews start around $5,000 for a compact token contract and reach $100,000 or more for large protocols. Ask whether a review of the fixes is included before comparing quotes.
How long does a Solidity audit take?
Reported turnarounds for manual audits range from roughly one to eight weeks, depending on the firm, the scope and the queue. Automated scans return in minutes and are useful before and between manual reviews, not instead of them.
What should be ready before a Solidity audit starts?
A frozen scope with a commit hash, written documentation of intended behaviour and roles, a passing test suite with measured coverage, the deployment plan including who holds admin keys, and a list of known issues.
What does a Verified record on Quantum Audit mean?
It means the token's owner confirmed ownership before publication and keeps the record re-verified on a schedule for the plan's 12-month term. It is not a guarantee of safety and not an endorsement. The score is computed the same way for every token, cannot be bought, and can move in either direction when the facts change.