Smart Contract Audit Agreements and Security Research Authorization

By Hank FasthoffSeptember 19, 2026

A wallet business pays for an audit, receives a report, and changes its withdrawal code before launch. Months afterward, an attacker exploits the revised code, and an independent researcher transfers some endangered assets to a recovery wallet. The audit agreement, release records, research policy, and rescue authorization may each govern a different part of the resulting dispute.

For a business operating software that controls digital assets, these documents should correspond to the systems and decisions they address. A smart contract is a program operating on a blockchain. Reviewing that program, authorizing someone to test it, and permitting someone to transfer assets during an attack involve separate services and permissions.

Identify the Code and the Scope of the Audit

An audit scope should identify the repository, files, and exact code version under review. A commit identifier records a particular version in the development history, allowing the parties to distinguish the code examined from subsequent changes. You should also establish whether the engagement covers the full system, selected components, or only changes since an earlier review.

Consensys Diligence's October 2024 MetaMask Delegation Framework report illustrates that distinction. It identifies a particular commit, lists the files reviewed, and states that the engagement examined changes since a previous audit. A business describing such an engagement to customers should preserve those limits when stating what was audited.

The technical scope can address administrative permissions, upgrade mechanisms, external dependencies, and deployment settings, along with exclusions for websites or infrastructure. Engineers and security personnel should assess which components need examination. The agreement should record the resulting scope, the assumptions the auditor may rely on, and how additional services are authorized and priced.

Define Deliverables and Review of Repairs

A contract promising an audit can leave unanswered what the provider must deliver. The statement of work should specify the report, supporting explanation of findings, severity classifications, and procedure for communicating a vulnerability before the scheduled report date. You should establish who receives urgent findings and how the provider confirms that someone capable of acting has received them.

Repairing a reported defect and examining the repair are separate tasks. The engagement can specify how many rounds of review are included, the time allowed for submitting fixes, and whether the auditor checks only the identified defect or also the effects of the revised code. A finding marked acknowledged may record the client's acceptance of a risk without indicating that anyone corrected it.

Substantial changes can justify another audit. In its Panoptic report, OpenZeppelin recommended another audit because the code underwent substantial refactoring between the initial examination and review of fixes. Your agreement should address who identifies such a change, how the revised scope and schedule are approved, and what the final report says about code the auditor did not examine.

The business also needs a record connecting the audited version to the version deployed. You should assign responsibility for documenting that comparison and any changes accepted without further review. The contract can define the provider's role in that process without implying that delivery of a report authorizes every subsequent release.

Set Publication Rights and Limits on Audit Claims

Audit reports can serve different audiences. Your business may want to share a report with customers, insurers, commercial partners, or another security provider, while the auditor may reserve control over publication and use of its name. The agreement should address those uses, permitted redactions, and how the parties coordinate disclosure while a vulnerability is being repaired.

The MetaMask Delegation Framework report's disclosure provisions state that reports are produced for clients and published with their consent, disclaim a guarantee of security, and reject reliance by third parties. Those provisions illustrate why access to a report does not establish the contractual rights a customer or partner may expect from reading it.

You should distinguish an accurate statement that a specified version received an audit from a broader promise that the product is secure. Customer terms, website claims, and sales materials should identify the service the auditor performed without extending it to excluded systems or unreviewed changes. The business can also agree with the auditor how to correct an outdated description after an upgrade.

Examine the Remedy Alongside the Service Promise

The standard of performance and the remedy for breach should be assessed together. OpenZeppelin's terms, dated March 25, 2026, state in § 2.6 that services will be performed with reasonable skill and care and materially in accordance with their description. For security services that breach that warranty, the clause limits the remedy to performing the services again.

Section 11.3 of those terms separately limits liability in each year measured from the applicable order and its anniversaries to fees paid under that order during that year. Section 11.5 preserves specified exceptions, including fraud and liability that cannot lawfully be limited. These provisions warrant examination alongside the signed order and any negotiated amendments.

For your engagement, a remedy consisting of another review may have limited value after assets have been stolen. You should assess exclusions of damages, liability caps, confidentiality obligations, and responsibility for subcontractors against the losses that the engagement could involve. A missed vulnerability does not, by itself, establish that the auditor breached its contractual standard; that question depends on the promised services and evidence of performance.

Indemnity provisions can also assign responsibility for claims brought by customers or other outsiders. The drafting should identify which claims each party assumes, who controls the defense, and whether those obligations fall within the liability cap. Governing law, dispute procedures, and the enforceability of proposed limitations belong in the same review.

Define Permission for Routine Security Research

A bug bounty program offers rewards for qualifying vulnerability reports under stated rules. Its terms should identify the covered systems, permitted testing methods, prohibited conduct, reporting procedure, and conditions for payment. You should distinguish permission to investigate a weakness from permission to interact with customer funds.

Aave's bug bounty scope on Immunefi prohibits testing against deployed code on the live network or public test networks and directs testing to local copies of those environments. It also prohibits testing involving third party systems and specified disruptive conduct. A listing of covered smart contracts therefore has to be read together with restrictions on how a researcher may test them.

A research policy can state which claims the business agrees not to pursue when a researcher complies with the authorization. GitHub's legal safe harbor provides an example while stating that GitHub cannot bind other entities or authorize research on their behalf. A wallet business relying on a hosting provider, identity vendor, or external payment service should account for those parties' permissions separately.

Reward terms should address eligibility, duplicate reports, severity disputes, payment timing, and disclosure of unresolved vulnerabilities. The documents should also explain whether a researcher can receive protection for compliant conduct even when a report does not qualify for a reward. Payment eligibility and permission to test should each be understandable before testing begins.

Authorize Emergency Rescues Separately

An emergency rescue can involve taking control of assets to prevent an attacker from stealing them. A whitehat is a security researcher acting to protect a system or its users. That intervention involves authority beyond reporting a vulnerability, including instructions about which assets the researcher may transfer and where they must be returned.

Security Alliance's Whitehat Safe Harbor framework is designed for qualifying urgent exploits and offers a structure for authorizing rescues in advance. It distinguishes those interventions from ordinary vulnerability disclosure and excludes an attacker who initiates an exploit and then claims to rescue the assets. A business considering adoption should assess the agreement's eligibility conditions against the conduct it intends to authorize.

The version 3.0.0 agreement requires prompt return of assets under § 2.4(d) and further notice if return cannot occur within six hours of obtaining control. Its separate 72 hour limit in § 2.3(c)(ii) concerns specified rescues by automated arbitrage software and runs from the exploit. SEAL's overview describes a 72 hour return deadline without that distinction. You should use the applicable agreement's return and notice requirements when drafting operating procedures and customer disclosures.

SEAL's scope terms address covered addresses and networks, recovery destinations, researcher identification, and reward parameters. They distinguish a reward a researcher may deduct from recovered assets from a reward paid after all required assets are returned. The terms also provide for an aggregate reward cap, which requires return of the assets before rewards are allocated.

Your adoption documents should establish who may select or change those parameters and who controls the recovery destination. If a business promises customers that only they can authorize transfers, counsel should assess how that representation corresponds to the proposed rescue authority. The consent and customer disclosures should be settled before the business announces participation.

Obtain the Authority and Consent the Arrangement Assumes

A decision by an operator does not establish that every affected asset owner has accepted the same terms. SEAL's adoption guide calls for changes to user terms addressing consent to attempted rescues, deductions for rewards, and possible losses during an intervention. Those are substantive changes to the customer relationship.

The model terms also include a hold harmless provision for specified losses and an acknowledgment that deducting a bounty may constitute a taxable disposition. You should assess the scope and enforceability of the liability provision and obtain separate tax advice concerning the proposed acknowledgment.

You should identify who can adopt the arrangement for the business and how affected users accept the relevant provisions. Updating a website and recording an adoption transaction do not, by themselves, settle every question about assent or authority over customer property. Existing custody agreements, customer terms, and governance documents may impose additional conditions.

Releases of claims also deserve examination against the actual agreement. Section 6.2 of SEAL's agreement describes a release for qualifying successful rescues, subject to exceptions for noncompliance and specified indemnity obligations. The scope of that release, the persons bound, and applicable law determine which claims it can address.

Explain the Limits of Legal Protection

The Department of Justice's Computer Fraud and Abuse Act charging policy directs prosecutors to decline prosecution when the evidence establishes the conduct and intent specified for good faith security research. The policy considers the research purpose, efforts to avoid harm, and use of the information to promote security. It also states that it does not establish an enforceable right against the United States.

That policy therefore cannot serve as a promise of immunity in a private research agreement. 18 U.S.C. § 1030(g) separately permits civil claims when its conditions are met, and a private agreement cannot waive claims belonging to people who are not bound by it. Other applicable laws and the researcher's actual conduct require assessment beyond the company's authorization.

Before adopting rescue terms, you should also have the proposed releases, reward arrangements, and transfers assessed against relevant insurance policies and contracts with custodians or other providers. A commitment to cooperate during an incident should identify who can make decisions and how the parties communicate. A policy that assumes immediate access to an unavailable signer can frustrate an otherwise authorized response.

The legal engagement addresses the audit contract, research authorization, adoption documents, and customer terms. Technical auditors assess the code and proposed intervention methods. With those responsibilities defined, your business can commission the review it intends to buy and document the conduct it is prepared to authorize.