Smart contract audit

Smart contracts are unusual software. They hold money directly, they run in public where anyone can study them, and once deployed they are hard or impossible to change. One overlooked line can let an attacker drain a protocol in a single transaction. An audit is the main defence before launch: specialists read the code before attackers do.

What auditors look for

• Logic errors: code that does what it says but not what was intended, such as a reward formula that pays twice.
• Access control: functions anyone can call that should be restricted to an administrator.
• Reentrancy: an external call that lets an attacker re-enter a function before the first call finishes, the bug behind the 2016 DAO hack.
• Price manipulation: logic that trusts a price that can be moved within one transaction, often through a weak oracle.
• Economic design: incentives that a well-funded actor could game even when every line works as written.

Auditors combine manual review with automated tools and, increasingly, formal verification, which proves mathematically that code meets a written specification.

Two audit models

In a traditional firm audit, a small team of security engineers studies a codebase for a fixed period and delivers a report. In a competitive audit, many independent researchers review the same code at once and are paid according to the issues they find. The two models tend to catch different things, so protocols often use both.

How to read an audit report

Start with the scope: which contracts, which version of the code and which dates. An audit of version one says little about version two. Then read the findings by severity. Critical and high findings can lead to loss of funds; medium findings usually need specific conditions; low and informational findings are about hygiene. For each finding, check whether it is marked fixed, acknowledged or disputed, and whether the fix was reviewed again.

A simple example

A report lists one high-severity finding: a rounding error lets a user withdraw slightly more than they put in, and repeating it across thousands of transactions could drain a vault. The team fixes it before launch and the auditors confirm the fix. Nobody outside ever hears about the bug. That is an audit doing its job, and it is why the findings section matters more than the logo on the cover.

Risks and limits

An audit is a snapshot. Code changes after the review, new contracts interact with it and attack techniques improve. Some costly DeFi exploits have hit audited protocols, often through code outside the scope or through the way several protocols interacted. Audits also cannot judge the offchain parts of a system, such as how keys are managed or what reserves are made of. That is why an audit is most useful as one layer among several: a bug bounty that keeps rewarding researchers after launch, runtime monitoring that watches live transactions, and proof of reserves for the assets themselves.

Tori Finance's smart contracts are audited by Sherlock and Nethermind. Audits are one layer of its security, alongside runtime monitoring by Hypernative and proof of reserves by Accountable.