Audits and bug bounties - how smart contracts are examined and how to read a report

A smart contract cannot be fixed after launch, and a mistake can cost millions. So code is examined before launch (an audit) and those who find a vulnerability afterwards are rewarded (a bug bounty). For a user it is important to understand what "the project is audited" really means and what it does not guarantee. Context is in the catalogue of vulnerabilities and the article on testing.

What an audit is

An audit is an independent review of source code by security specialists. The goal is to find vulnerabilities, logic errors and risks before attackers do. The result is a report listing findings and recommendations.

An audit is:

• a review of a specific version of the code (by commit hash);
• a time-limited investigation (usually 1-4 weeks);
• an expert assessment, not a mathematical proof.

How an audit proceeds

1. Defining the scope. Which contracts, versions and external dependencies are included.
2. Preparation. The project team provides documentation, a description of expected behaviour, tests.
3. Automated analysis. Static analysers (for example Slither), fuzzing, symbolic execution.
4. Manual review. Experts read the code line by line, look for logic errors, check invariants and edge cases, model attacks.
5. Report and discussion. Findings are classified, the team comments.
6. Fixes. Developers make changes.
7. Re-check. The auditors confirm the fixes closed the problems and did not create new ones.
8. Publication. The final report is published (sometimes after launch).

Severity levels

For each finding the report states a status: fixed, acknowledged without a fix (with a justification) or not fixed.

What an audit is not

• Not proof of the absence of bugs. Auditors find what they see in the time allotted.
• Only this version of the code. Any change after the audit lies outside the review.
• Not a check of the whole system. The frontend, servers, key-management processes and people's behaviour often remain out of scope.
• Not protection against the team's misconduct. If the team can upgrade a contract, auditing a version does not protect against a future swap (proxies).
• Quality varies. The reputation and experience of the firm matter.

How to read a report and assess a project

1. Does the audited code match what is deployed? The report gives a commit hash or address; compare against the verified contract.
2. Who is the auditor and how long have they been on the market? Are there public reports, a reputation?
3. What is in scope? Were all contracts included?
4. The status of findings. Are critical and high ones fixed? "Not fixed" on criticals is a serious alarm.
5. The date. Was the audit long ago and were there changes since?
6. Assumptions. What trust assumptions does the system make (roles, oracles, administrator)? (owner rights)
7. Several independent reviews are better than one.

The absence of an audit in a project holding significant sums is a reason for caution. When assessing any service, including ours, check current information and compare the address and source code yourself.

Other ways of checking

• Auditing contests. Platforms (Code4rena, Sherlock, Cantina and others) put code up for public examination with a prize pool. Many independent eyes find different problems.
• Formal verification. A mathematical proof that code matches a specification. Powerful but laborious and applicable to limited properties.
• Internal review and tests - Foundry, fuzzing, invariants.
• Monitoring after launch. Systems that spot suspicious activity and let you hit pause.

Bug bounties

A bug bounty is a reward programme for researchers who find vulnerabilities in a live project and report them responsibly.

How it works:

1. The project publishes rules: what is in scope, which vulnerabilities are accepted, reward sizes by severity.
2. The researcher reports privately (without publishing) through a dedicated platform or security contact.
3. The team verifies and fixes the problem.
4. The researcher is paid a reward; information is disclosed after the fix.

Rewards depend on the size of the risks; for critical vulnerabilities they can be very large, usually as a share of the potentially affected funds. The idea is simple: it is cheaper for a project to pay an honest researcher than to lose money.

Responsible disclosure

If you found a vulnerability:

1. Do not exploit it for gain and do not demonstrate it on real funds.
2. Report privately to the developers.
3. Allow time for a fix before publishing.
4. Follow the rules of the bounty programme.

Exploiting a vulnerability is a crime, while responsible disclosure is a legal and often well-paid path.

What an ordinary user can do

• Check whether a project has reports and a bounty programme.
• Do not invest more than you can afford to lose while a project is young.
• Follow security updates.
• Apply personal protection measures: most losses come not from contracts but from people (phishing).
• For deals, remember that escrow lowers the risk of the counterparty but does not remove the risk of the software code.

What to read next

Return to practice: the security checklist or the deal lifecycle. For developers - gas optimization without harming security.