Smart Contract Security Audit Agreements: Audit Scope and Limitations of Liability
Defining the code and scope under review, liability caps and exclusions, re-audits, and the presentation of audit reports
When a project launching a token or DeFi service commissions an external smart contract security audit, the scope and liability limitations in the audit agreement can significantly affect the extent to which the auditor may be held liable after a hack. Most overseas audit agreements disclaim any guarantee that all vulnerabilities will be identified or that no hack will occur.
This article outlines the key considerations when reviewing the code and scope covered by a smart contract security audit agreement, liability caps and exclusions, remediation and re-audits, and the publication and presentation of audit reports.
1. Continuing Hacking Risks After an Audit
On November 27, 2025, virtual assets worth approximately KRW 44.5 billion were abnormally withdrawn from Upbit’s Solana-related wallets to external addresses. Although the incident involved exchange wallets, it illustrates the scale of losses that a security incident in a blockchain service can cause.
A smart contract audit is a service that reviews code submitted at a particular point in time. If the code changes after the audit, or a problem arises in a component outside its scope, the audit findings do not provide assurance regarding that change or component.
For this reason, most overseas audit agreements state that the auditor does not warrant that every vulnerability has been identified or that the project will not be hacked.
2. Code and Scope Covered by the Audit
The agreement should identify the repository, commit hash, and list of contracts to be audited. An ambiguous scope can lead to a dispute over whether the affected code was covered in the first place after a hack occurs.
Excluded items, such as oracles, the front end, administrator key management, and integrations with external protocols, should be expressly identified, with separate plans for reviewing them.
The audit methodology also requires review. The substance of the audit varies depending on whether it includes manual code review, automated tools, and analysis of economic attack scenarios.
3. Enforceability of Liability Caps and Exclusions
Auditors commonly cap their liability at the amount of the audit fee and exclude liability for indirect damages and user losses. From the project’s perspective, the recoverable amount may be very small compared with its actual losses.
Where Korean law applies, a provision in standard terms prepared in advance by a business that excludes liability even for its own intentional misconduct or gross negligence is invalid under the Act on the Regulation of Terms and Conditions. The assessment may differ, however, for individually negotiated provisions or agreements governed by foreign law.
The project may negotiate a cap set at a multiple of the audit fee, or an exception to the cap for clear omissions in the review.
4. Remediation and Re-Audits
When the auditor identifies vulnerabilities, the project corrects the code and the auditor then reviews the remediation.
The agreement should specify whether remediation reviews are included in the audit fee, how many rounds are available, and how code changes immediately before launch will be handled. It should also establish a process for verifying that the final deployed code is identical to the code for which the audit was completed.
If upgrades are planned after launch, the conditions and fees for additional audits should also be agreed in advance.
| Clause | Key considerations |
|---|---|
| Audit scope | Specify the repository, commit hash, covered contracts, and excluded items |
| Audit methods | Whether manual review, automated tools, and economic attack scenarios are included |
| Limits on liability | Liability-cap multiple, enforceability of exclusions for intent or gross negligence, and governing law |
| Re-audit | Number and cost of remediation reviews, and verification that the final deployed code matches the audited code |
| Report presentation | Disclosure of the audit scope and date, confidentiality, and timing of vulnerability disclosure |
5. Publication and Presentation of Audit Reports
Projects seek to build user and investor confidence by publishing audit reports. Auditors, in turn, seek to prevent exaggerated use of their names.
Presenting completion of an audit as a guarantee of security may mislead users and increase the project’s liability. The parties should agree on how the audit scope, date, and unresolved findings will be disclosed together.
The agreement should also address the confidentiality of code and internal materials provided during the audit, and the timing of disclosure of vulnerability information.
6. Implications for Businesses
The assurance provided by a smart contract audit is limited to the scope and point in time defined in the audit agreement. Clearly specifying the scope and exclusions helps identify security gaps and provides a basis for determining responsibility if an incident occurs.
Because the auditor’s liability cap may be small relative to the actual loss, projects need internal security review and incident response systems alongside the negotiation of their audit agreements.
