A smart contract can pass its unit tests, compile successfully, and still contain a flaw that an attacker can exploit.
Tests check the scenarios and behaviours developers have defined, while automated scanners can catch known vulnerability patterns. Neither will necessarily catch a problem in the protocol’s business logic. A contract could give the wrong user permission, allow an unexpected sequence of transactions, or handle an interaction with another contract unsafely.
A smart contract security audit reviews these risks through automated tools, testing, and expert review. It considers how the contract is meant to work, how different functions interact, and what could happen when someone uses those functions in a way the developers did not expect.
Who Is a Smart Contract Security Audit For?
A smart contract security audit is especially useful for projects where contracts control assets, permissions, or important protocol functions. The level of review should depend on factors such as the value at risk, contract complexity, and how different parts of the system interact.
Projects that commonly need this type of review include DeFi protocols, Web3 applications and dApps, token projects, DAOs and governance systems, NFT and blockchain gaming projects, and infrastructure or enterprise blockchain projects.
A basic ERC-20 token contract is very different from a lending protocol that manages user collateral, liquidations, and price oracles. A lending protocol may also rely on several contracts, external price data, and privileged permissions. A problem in any of these areas could affect how user funds are handled. The review therefore needs to consider how the different parts work together, not just whether individual functions work as expected.
What Is a Smart Contract Security Audit?
A smart contract security audit is a detailed review of smart contract code to find vulnerabilities and other security weaknesses before deployment or a major update. It checks whether the contracts behave as intended and whether their design or implementation creates ways for an attacker to misuse them.
Testing, automated analysis, and manual review each provide different checks:
- Testing checks whether the contract behaves as expected across the inputs, transactions, and conditions being tested.
- Automated analysis looks for known vulnerability patterns, unsafe coding practices, and suspicious code that security tools can detect.
- Manual review checks how the contract’s functions work together and whether the protocol’s rules can be abused in ways automated tools or predefined tests may not cover.
The consequences can also be different from those of a typical application bug. A software defect may cause downtime or require engineering work to fix. A smart contract vulnerability can allow an attacker to move or steal assets directly, depending on what the contract controls. The 2016 DAO exploit is a well-known example: a reentrancy flaw was used to drain more than 3.6 million ETH from the vulnerable contract.
An audit provides additional security assurance, not a guarantee that the contracts contain no vulnerabilities.
What Does a Smart Contract Audit Cover?
A smart contract audit covers more than individual functions. Reviewers examine whether the code follows the protocol’s intended rules, whether permissions are enforced correctly, and whether interactions with other contracts, external data, and financial calculations could create security problems.
Contract Logic and Business Rules
The review starts with how the code implements the protocol’s rules.
For example, if a protocol requires total token supply to match the sum of user balances, does that remain true after the transactions that can change those values? If users can withdraw only under certain conditions, can another function bypass those conditions? If liquidations should happen when collateral falls below a set ratio, can someone manipulate the conditions and avoid liquidation?
The question is whether the code follows the rules the protocol is supposed to enforce.
Access Control and Privileged Functions
Functions that can change important parts of a protocol need careful review, along with the roles allowed to call them. These may include functions for minting tokens, changing fees, pausing contracts, moving funds, or upgrading implementations.
The review checks whether each privilege is assigned to the right role and whether those permissions can be changed or bypassed unexpectedly. An incorrectly configured admin or upgrade role could give an attacker access to functions that affect user funds or protocol behaviour.
External Calls and Contract Interactions
Smart contracts often call other contracts, and those calls can introduce risks that are easy to miss when a function is viewed on its own.
Reentrancy is one example. An external contract can call back into the original contract before the first function has finished, potentially interacting with state before it has been updated as intended. Auditors also look at callbacks, user-supplied contract addresses, return values, and assumptions about how external contracts will behave.
Financial and Numerical Logic
Financial contracts rely heavily on calculations, so auditors check how values are stored, converted, rounded, and updated.
A small rounding error can become a larger problem when it is repeated across many transactions. Share-to-asset conversions, fees, interest, rewards, balances, and liquidation values can all produce incorrect results when formulas or precision are handled poorly. Auditors also check important financial invariants, such as rules about balances or total supply, to make sure they continue to hold when the contract state changes.
Upgradeability and Deployment Design
Upgradeable contracts create additional security risks because their implementation can be changed after deployment through an upgrade mechanism.
The review should check who controls upgrades, whether initialization can be abused or repeated, and whether a new implementation is compatible with the existing storage layout. Auditors also compare the code and configuration that were reviewed with what is planned for deployment. An audit of one implementation does not automatically cover later changes.
Oracles and External Dependencies
Protocols often depend on external data or other protocols. Price oracles are particularly important because incorrect or manipulated prices can affect lending, trading, collateral, and liquidation decisions.
The review should check whether price data can become stale, how the contract behaves when an oracle fails, and what assumptions it makes about external protocols. Dependencies such as Chainlink price feeds, Curve pools, or Uniswap contracts can also introduce conditions that need to be considered during the review.
| Area | What Gets Examined | Why It Matters |
| Business Logic | Whether the code follows the protocol’s rules | Incorrect rules can produce unintended outcomes |
| Access Control | Who can call privileged functions | Misconfigured permissions can allow unauthorised actions |
| External Interactions | Calls to other contracts and callbacks | Unexpected behaviour can affect state or funds |
| Numerical Logic | Calculations, rounding, and accounting | Errors can cause incorrect balances or value loss |
| Upgradeability | Upgrade and initialization mechanisms | Changes can introduce new vulnerabilities or affect stored data |
| Oracles and External Dependencies | Oracles and interactions with other protocols | Failures or manipulation can affect contract behaviour |
Smart Contract Security Audit Checklist
Audit preparation starts before the code review. This checklist covers what the project team should prepare, what the review should include, and what needs to be checked before deployment.
Before the Audit Begins
- Freeze the code version: Record the exact commit hash that will be reviewed.
- Define the scope: List the contracts, libraries, and external dependencies included in the audit, along with anything outside the review.
- Provide architecture documentation: Explain how the contracts interact and where external systems are involved.
- Document intended behaviour: Provide the protocol specification, important assumptions, and key security properties.
- Document privileged roles: List admin, owner, upgrade, and other privileged accounts and what each can do.
- Disclose known issues: Tell the auditor about known vulnerabilities, limitations, and other security concerns already found by the team.
- Provide deployment configuration: Document the addresses, parameters, and other settings planned for deployment.
- List external dependencies: Include oracles, protocols, libraries, and other contracts that the system relies on.
- Document upgradeability: Explain how contracts can be upgraded and who controls the upgrade mechanism.
- Share existing tests: Provide the current unit, integration, fuzz, or property-based tests and their results.
During the Audit Process
- Use static analysis: Run tools such as Slither where appropriate to detect known vulnerability patterns and suspicious code.
- Review existing tests: Check whether important contract behaviour and security properties are covered.
- Use fuzzing and property-based testing where appropriate: Test unusual inputs, transaction sequences, and contract states.
- Perform manual code review: Check for issues that automated tools and predefined tests may miss.
- Test attack paths: Check whether different functions or transactions can be combined to produce an unintended result.
- Review access control: Verify that privileged functions are restricted to the correct roles.
- Review business and economic logic: Check financial rules, incentives, and accounting under unusual conditions.
- Review dependencies: Check how external contracts, oracles, and other services are trusted and handled.
- Check protocol invariants: Verify that important security and accounting properties remain true as contract state changes.
- Use formal verification where justified: Apply it to critical properties when the project’s risk and complexity make it worthwhile.
Before Deployment
-
- Review all findings: Confirm that Critical and High findings have been fixed, mitigated, or formally accepted by the project team with a documented reason.
- Verify fixes: Have changes reviewed to confirm that the remediation works and does not introduce another issue.
- Compare the final deployment with the audited code: Confirm that the final commit and material configuration changes match the reviewed version or have been reviewed separately.
- Verify deployment configuration: Confirm that addresses, parameters, roles, and other settings match the audited design.
- Confirm privileged roles: Check that owner, admin, upgrade, and other privileged accounts are assigned correctly.
- Prepare for incidents: Document how the team will respond if a vulnerability is discovered after deployment, including any available pause, upgrade, or recovery mechanisms.
Smart Contract Audit Tools and Methods: What Each One Does
| Approach | What it does | Where it helps | What it does not prove |
| Static analysis | Scans code for known vulnerability patterns, unsafe practices, and suspicious constructs | Finds detectable code issues early | Does not assess the protocol’s full business logic or whether the design matches the specification |
| Unit and integration testing | Checks expected behaviour across defined inputs, functions, and interactions | Confirms that intended functionality works across tested scenarios | Cannot cover every possible input, state, or transaction sequence |
| Fuzzing and property-based testing | Generates many inputs, states, or transaction sequences to test defined properties and invariants | Finds unexpected states and edge cases that predefined tests may miss | Only tests the properties and behaviours that have been defined and exercised |
| Formal verification | Uses mathematical methods to prove specified properties under defined assumptions | Provides stronger assurance for critical security properties | Does not prove that the entire protocol is secure; it covers only the properties included in the verification and its assumptions |
| Manual expert review | Examines code, protocol logic, assumptions, permissions, and interactions | Finds context-specific issues and complex attack paths | Cannot guarantee that every vulnerability will be found |
How the Smart Contract Audit Process Works
The exact process depends on the size and complexity of the codebase, the number of contracts in scope, and the level of testing required.
1. Scoping and Documentation
The process begins with the protocol specification, architecture, and codebase. The team defines the contracts and components in scope, records the audited commit or code version, and clarifies how the system is expected to behave.
This stage also covers privileged roles, upgrade mechanisms, external dependencies, known limitations, and other assumptions that could affect the review.
2. Automated Analysis and Initial Review
The review uses appropriate static analysis, existing test results, and fuzzing or property-based testing where relevant. These checks can highlight suspicious code, known vulnerability patterns, unexpected behaviour, and areas that need closer investigation.
3. Manual Review
The next stage focuses on the code and protocol logic. This includes tracing attack paths, reviewing business logic, checking access controls and external interactions, and testing assumptions that automated analysis may not cover.
Potential vulnerabilities are reproduced or otherwise validated where possible before they are assigned a severity level.
4. Findings and Recommendations
Confirmed findings are documented with the affected code, security impact, severity, and recommended remediation. The report should make clear which issues need immediate attention and which can be addressed later.
5. Remediation and Re-review
The development team addresses the reported findings, after which the auditors review the changes. The re-review confirms whether the original issues have been fixed and checks whether the changes introduced new security concerns.
An audit covers the code and configuration that were actually reviewed. Changes made after the audited commit fall outside that review and should be assessed separately before deployment.
How Are Smart Contract Vulnerabilities Rated?
There is no single universal severity standard used across all smart contract audits. Auditors typically consider a vulnerability’s potential impact, exploitability, required conditions, and the assets or functions affected. Severity ratings help security teams prioritise remediation, so a vulnerability that could drain user funds requires a different response from an issue with limited or indirect impact.
| Severity | What it generally means | Example |
| Critical | An issue that can cause severe loss of funds, unauthorised control, or major protocol compromise, often with a viable path to exploitation | A reentrancy vulnerability that allows an attacker to drain funds from a vulnerable withdrawal mechanism |
| High | A serious vulnerability that could cause substantial financial loss or compromise an important protocol function under specific conditions | An access-control flaw that allows an unauthorised user to call a privileged function affecting user assets |
| Medium | A security issue with more limited impact or additional conditions required for exploitation | A rounding or accounting issue that can cause users to receive incorrect amounts under certain transaction conditions |
| Low | A weakness with limited security impact that is unlikely to cause material loss on its own | A low-impact validation weakness that does not allow an attacker to bypass a critical security control |
| Informational | An observation, recommendation, or code-quality issue with no direct security impact | A code-quality or security recommendation that does not create a direct exploitable vulnerability |
What Determines Severity?
Severity depends on several factors, including how difficult the issue is to exploit, what happens if it is exploited, and what conditions an attacker needs. Auditors also consider the affected assets or functions and whether exploitation requires a specific contract state, transaction sequence, market condition, or privileged access. They also consider what assets or functions are affected and whether the attacker needs a privileged account or control over another component.
Severity and remediation priority are not always the same. A lower-severity issue may still deserve prompt attention if it affects a widely used function or can combine with another weakness to create a larger attack path.
What Should a Smart Contract Audit Report Contain?
A useful security audit report gives development, security, and leadership teams enough information to understand the findings, track what happened after the review, and decide whether the code is ready for deployment.
Executive Summary
The opening section should give readers a quick view of the engagement and its main results. It should state the project name and purpose, audit period, repositories and contracts reviewed, the specific commits covered, the overall findings, and any deployment considerations arising from the review.
Scope and Versioning
The report should make clear what was reviewed and which version of the code was used. It should record the contracts and files in scope, the exact commit or version identifier, any exclusions, external dependencies considered, and the testing environment and assumptions used during the review.
This information helps readers confirm which code was reviewed and whether the deployed version matches it.
Findings
Each confirmed finding should give the development team enough detail to understand and fix the issue. A finding commonly includes:
- Title and severity
- Affected contract, function, and code location
- Description of the vulnerability
- Technical cause (why the issue occurs)
- Impact (what could happen if it is exploited)
- Attack scenario or conditions required for exploitation
- Recommended remediation
- Status (such as fixed, acknowledged, disputed, or unresolved)
Where useful, findings may also include proof-of-concept code, screenshots, transaction traces, or other evidence that helps confirm the issue.
Remediation Tracking
The report or final audit update should also record what happened after the initial findings were issued. It should state which findings were fixed, which were acknowledged but left unresolved, how disputed findings were resolved, and whether the fixes were retested.
Limitations
The report should also state what the audit did not cover and any conditions that limited the review. This may include off-chain components, frontend applications, deployment procedures, third-party contracts, areas outside the defined code scope, assumptions made during testing, or properties not covered by formal verification.
Clear limitations help readers understand what conclusions can and cannot be drawn from the audit.
What Should You Do After the Audit?
An audit report is not the end of the security process. Once fixes are implemented, they should be tested and re-reviewed where appropriate. The final deployment should also be checked against the code version and configuration that were reviewed.
Security work continues after deployment. Significant code changes, new integrations, governance changes, or changes to protocol economics can change the security risks present after the original audit. Ongoing monitoring, vulnerability disclosure or bug bounty programmes, and periodic security reviews can provide additional coverage as the protocol changes.
How Qualysec Approaches Smart Contract Security Audits
A scanner alone cannot tell you whether a smart contract follows the protocol’s intended rules. Qualysec combines automated testing with manual security testing for Web3 environments, including smart contracts, dApps, and blockchain infrastructure. Its Web3 testing approach uses static and dynamic analysis alongside manual exploit simulation based on the protocol’s logic.
For teams preparing to launch or update a Web application, the review can cover areas such as business logic, access control, transaction flows, and interactions between connected blockchain components. The aim is to find issues that may not be visible through automated scanning alone.
Findings are documented with their security impact and recommended fixes, followed by remediation testing where required. Qualysec’s security testing process also includes reporting and remediation testing after vulnerabilities are found.
For a protocol team, the practical outcome is a clearer view of which issues need attention before release and whether reported fixes have been tested again.
Conclusion
A smart contract security audit gives a project team a detailed look at its code, protocol logic, permissions, dependencies, and the assumptions that affect how the system behaves.
But an audit is not a guarantee of security. Its value depends on reviewing the right scope, testing important behaviours, finding weaknesses, fixing them, and checking those changes before deployment. As the protocol changes, its security review should change with it.
If you are preparing to launch or update a Web3 application, Qualysec can help assess your smart contracts and connected blockchain components through automated and manual security testing, with remediation testing after vulnerabilities are found.
Frequently Asked Questions (FAQ)
1. What is a smart contract security audit?
A smart contract security audit is an expert review of smart contract code, design, and interactions to find vulnerabilities such as business-logic flaws, access-control issues, unsafe dependencies, and exploitable attack paths.
2. How long does a smart contract audit take?
The timeline depends on codebase size, complexity, scope, and testing requirements. Smaller contracts may take less time, while complex protocols with multiple contracts and dependencies can require substantially more review time.
3. How much does a smart contract audit cost?
Cost depends on code volume, complexity, protocol risk, scope, and testing requirements. Pricing varies between projects and security firms, so there is no universal fixed cost.
4. What tools are used for smart contract audits?
Auditors may use static analysis tools such as Slither, fuzzing and property-testing tools such as Echidna or Foundry, alongside manual review. Formal verification may also be used for specific security properties.
5. Does an audit guarantee a smart contract is secure?
No. An audit provides additional security assurance but cannot guarantee that every vulnerability has been found. Its effectiveness depends on the scope, code version, testing methods, and assumptions covered by the review.
