What Are Smart Contract Audits?

What Are Smart Contract Audits?

In traditional software, bugs might cause an app to crash or display incorrect data — annoying but usually recoverable. In DeFi, a smart contract bug can result in the permanent, irreversible loss of millions of dollars. This stark reality is why smart contract audits exist: they are the primary line of defense between a protocol's code and the funds it controls.

A smart contract audit is a rigorous, independent security review of a protocol's codebase. Professional auditors systematically examine every function, state transition, and external interaction to identify vulnerabilities before they can be exploited. For anyone using DeFi protocols — especially for high-value operations like Bitcoin-backed borrowing — understanding what audits do and don't guarantee is essential.

Why Audits Matter in DeFi

The Immutability Problem

Once a smart contract is deployed to a blockchain, its code is (in most cases) immutable. Unlike a web application where you can push a hotfix in minutes, a deployed smart contract cannot be patched. If a vulnerability exists, it exists permanently — unless the protocol has built-in upgrade mechanisms (which themselves introduce governance risks).

The Scale of DeFi Exploits

The numbers speak for themselves. DeFi exploits have resulted in billions of dollars in cumulative losses. Major incidents include:

• The DAO hack (2016) — $60M exploited through a reentrancy vulnerability.
• Wormhole bridge (2022) — $320M lost due to a signature verification bypass.
• Euler Finance (2023) — $197M exploited through a donation attack vector, later returned.

Every one of these exploits targeted code that had been reviewed to some degree. The question is never whether to audit, but how thoroughly.

How a Smart Contract Audit Works

Phase 1: Scoping and Documentation Review

The audit begins with the auditing firm understanding what the code is supposed to do. They review:

• Technical documentation and specifications
• Architecture diagrams showing how contracts interact
• Previous audit reports if the code has been audited before
• Known issues and design trade-offs acknowledged by the team

This phase establishes the baseline against which the code will be evaluated.

Phase 2: Automated Analysis

Auditors run the codebase through automated tools that catch common vulnerability patterns:

• Static analyzers (Slither, Mythril, Securify) scan for known vulnerability patterns like reentrancy, integer overflow, and unchecked return values.
• Fuzzers (Echidna, Foundry's fuzzer) feed random inputs to functions to find edge cases that break invariants.
• Symbolic execution tools (Manticore, HEVM) explore all possible execution paths mathematically.

Automated tools catch the "low-hanging fruit" but cannot understand business logic or complex multi-step attack scenarios.

Phase 3: Manual Review

This is the most critical and time-intensive phase. Experienced auditors read through every line of code, asking questions like:

• Can this function be called by an unauthorized actor?
• What happens if this external call fails or returns unexpected data?
• Can the ordering of operations be exploited (reentrancy)?
• Are there rounding errors that compound over time?
• Can an attacker manipulate oracle prices to exploit this logic?
• What happens under extreme market conditions (99% price drops, zero liquidity)?

Manual review is where the most critical, protocol-specific vulnerabilities are discovered.

Phase 4: Report and Classification

Auditors compile their findings into a detailed report, classifying each issue by severity:

Phase 5: Fix Review

After the development team addresses the findings, auditors verify the fixes. This is essential — poorly implemented fixes can introduce new vulnerabilities. The final report includes the original findings, the team's responses, and the auditors' assessment of each fix.

What Auditors Look For

Common Vulnerability Classes

Reentrancy — When a contract calls an external contract before updating its own state, the external contract can "re-enter" the original function and exploit the stale state. The DAO hack was a reentrancy attack.

Access control flaws — Functions that should be restricted (e.g., to the protocol admin) but are callable by anyone. A missing onlyOwner modifier on a withdrawal function is a textbook critical vulnerability.

Oracle manipulation — DeFi protocols rely on price oracles to determine collateral values. If an attacker can manipulate the oracle price (e.g., through a flash loan), they can borrow more than their collateral is worth or trigger unfair liquidations.

Flash loan attacks — Composability allows attackers to borrow enormous sums, manipulate state, extract value, and repay — all in a single transaction. Auditors evaluate whether any function is vulnerable to these atomic operations.

Precision and rounding errors — Financial math on the blockchain uses integer arithmetic. Rounding errors that seem insignificant can compound across millions of transactions or be deliberately exploited.

Front-running and MEV — Transactions in a public mempool can be observed and front-run. Auditors check whether any operations are vulnerable to sandwich attacks or other MEV extraction.

DeFi-Specific Concerns

For lending protocols — the kind aggregated by Borrow — auditors pay special attention to:

• Liquidation logic — Can liquidations be blocked, front-run, or manipulated?
• Interest rate calculations — Do rates accrue correctly over time? Are there edge cases?
• Collateral handling — Is collateral properly isolated? Can it be double-counted?
• Upgrade mechanisms — If the protocol is upgradeable, who controls upgrades and what safeguards exist?

Beyond Traditional Audits

Formal Verification

Formal verification uses mathematical proofs to verify that a smart contract behaves exactly as specified under all possible inputs. While audits rely on human judgment, formal verification provides mathematical certainty about specific properties. It is computationally expensive and limited in scope, but for critical functions (like a token's transfer logic), it provides the strongest possible guarantee.

Competitive Audits

Platforms like Code4rena and Sherlock run competitive audits where dozens or hundreds of independent auditors ("wardens") review the code simultaneously. This crowdsourced approach can surface vulnerabilities that a single team might miss, and the competitive structure incentivizes thorough review.

Bug Bounties

A bug bounty program offers financial rewards to anyone who discovers and responsibly discloses vulnerabilities in production code. Platforms like Immunefi host bounty programs for major DeFi protocols, with payouts reaching millions of dollars for critical findings. Bug bounties complement audits by providing ongoing security coverage after deployment.

Continuous Monitoring

Real-time monitoring tools (like Forta, OpenZeppelin Defender, and Hypernative) watch on-chain activity for suspicious patterns — large flash loans, unusual governance proposals, or anomalous price movements. These systems can trigger automated responses (like pausing a protocol) faster than humans can react.

How to Evaluate a Protocol's Security

When considering whether to deposit collateral or borrow from a DeFi protocol, assess its security posture:

Audit Checklist

1. Has the protocol been audited? Check for published audit reports on the protocol's docs or GitHub.
2. Who audited it? Reputable firms (Trail of Bits, OpenZeppelin, Spearbit) carry more weight than unknown auditors.
3. How many audits? Multiple independent audits provide more coverage.
4. Are the audited contracts the same ones deployed? Verify that the deployed bytecode matches the audited code.
5. When was the last audit? If the code has changed significantly since the audit, the report may not reflect the current state.

Beyond the Audit Report

• Bug bounty program — Does the protocol offer meaningful bounties via Immunefi or similar platforms?
• Incident response plan — Does the protocol have a documented plan for handling exploits?
• Protocol risk track record — Has the protocol survived previous market stress events without issues?
• Timelock and governance — Are there safeguards against rapid, unchecked changes?

Audits and Bitcoin-Backed Borrowing

When you use your Bitcoin as collateral on a lending protocol, you are trusting that protocol's smart contracts with your assets. The audit history of that protocol is one of the most important factors in assessing whether that trust is warranted.

Aggregators like Borrow list protocols that meet baseline security standards, including audit history and operational track record. By comparing across multiple audited protocols, you can choose not only the best rates but also the security profile that matches your risk tolerance.

Limitations of Audits

It is critical to understand what audits cannot do:

• Audits are point-in-time. They cover the code as it existed during the review period.
• Audits cannot catch all bugs. Novel attack vectors and complex multi-protocol interactions may not be considered.
• Audits do not cover economic design. A contract can be technically correct but economically exploitable.
• Audits do not cover operational security. Compromised admin keys, social engineering, and insider threats are outside an audit's scope.

Key Takeaways

• A smart contract audit is a systematic security review by independent experts.
• Audits combine automated tools with deep manual analysis to find vulnerabilities before deployment.
• No audit guarantees zero bugs — they reduce risk but cannot eliminate it.
• Multiple audits, formal verification, bug bounties, and monitoring together form a robust security posture.
• When borrowing against Bitcoin, prioritize protocols with strong audit histories and active security programs.
• Borrow aggregates protocols that meet security standards, helping you compare not just rates but also the risk profiles of the protocols you use.