A smart contract is software stored and executed through a blockchain. It can hold assets, calculate balances, enforce collateral rules, or call other contracts without a human processing each request. That consistency is useful, but it also means a reachable flaw can be exercised repeatedly and quickly against every asset the contract controls.
Contract risk is broader than coding mistakes. Safety also depends on who can upgrade the system, which price feeds and bridges it trusts, whether incentives remain stable under stress, and how users grant permissions. An audit is evidence about a defined version and scope; it is not insurance, continuous monitoring, or proof that every surrounding assumption is sound.
What you will learn
- Separate code defects from administrative, integration, and economic risks
- Interpret audit scope, findings, fixes, and deployment correspondence
- Evaluate how upgrades and dependencies change a protocol's effective trust model
Code translates rules into irreversible actions
Contracts expose functions that read or change blockchain state. Security failures occur when an unintended caller can reach a privileged function, calculations behave incorrectly at boundary values, external calls reenter unfinished logic, or accounting assumptions diverge from actual token behavior. Plainly, the program permits a sequence its designers did not expect and the blockchain faithfully executes it.
The visible line containing a bug may be small, but exploitability depends on context: available liquidity, transaction ordering, caller permissions, and interactions with other protocols. Attackers can borrow large temporary balances within one transaction, combine several contracts, and repeat operations. Testing normal user flows therefore does not cover the adversarial sequences that matter most.
Privileged controls can rewrite the promise
Many applications use upgradeable contracts so developers can fix bugs or add features. A proxy contract holds state and delegates behavior to an implementation that an administrator may replace. This flexibility transfers risk to the upgrade process: whoever controls the administrator can potentially introduce arbitrary logic, intentionally or after key compromise.
Inspect which roles can upgrade, pause, mint, seize, change fees, replace price feeds, or withdraw reserves. Then inspect how those roles are controlled: one externally owned account, a multisignature wallet, a delayed governance process, or a distributed voting system. A time delay gives observers time to exit only if changes are visible, monitoring works, and exits remain functional.
Dependencies widen the attack surface
A lending market may be internally correct yet fail when an oracle reports a manipulated price. A vault may rely on a token whose transfer behavior changes. A cross-chain application may accept assets created by a compromised bridge. Composability means applications can reuse public infrastructure, but each dependency imports its failure modes and administrative controls.
Map dependencies one layer beyond the application: tokens, oracles, bridges, liquidity venues, governance modules, front ends, automation services, and base networks. Ask what happens when each component is delayed, paused, manipulated, or unavailable. The important question is not merely whether a dependency is reputable, but whether the protocol fails closed, limits exposure, or continues using bad information.
Read security evidence with boundaries
An audit report should identify the reviewed code revision, dates, methodology, severity definitions, exclusions, and status of findings. Confirm that the deployed bytecode or verified source corresponds to the reviewed version when practical. A report for an earlier implementation, one module, or a limited engagement cannot support broad claims about a later deployment and all integrations.
Complement audits with public testing, bug-bounty scope, incident history, upgrade records, monitoring, and the team's response process. Longer operation under meaningful load can reveal issues, but time and total value locked do not prove safety. Exposure can instead increase the reward for discovering a rare flaw, and new upgrades can reset parts of the evidence base.
Euler Labs' account of its March 2023 exploit reports that a 2022 patch introduced the `donateToReserves` path, that the proposed change went through audit, and that the critical issue still went unnoticed before roughly $197 million in assets were taken. The incident is a concrete reason to track change history and test system invariants across modules: an audit can be relevant evidence without being a guarantee that a newly introduced interaction is safe.
Common misconceptions
“An audited contract cannot be exploited.”
Audits are bounded reviews that can miss defects, exclude dependencies, or cover code different from the live deployment. They reduce uncertainty without eliminating it.
“Immutable code is always safer than upgradeable code.”
Immutability removes upgrade-key risk but also prevents direct fixes. Safety depends on design quality, migration options, and the consequences of each governance model.
“Open-source code means someone has verified it.”
Availability enables review but does not prove that qualified reviewers examined the relevant version or that the deployed bytecode matches it.
Risks and limitations
- A previously reviewed contract can become materially different after an upgrade or parameter change.
- External dependencies can fail even when the protocol's own code behaves exactly as designed.
- Emergency pause controls may reduce losses but also create censorship, availability, and administrator-compromise risks.
- Formal verification proves specified properties, not that the specification captures every desired real-world behavior.
Key takeaways
- Model code, permissions, dependencies, and incentives as one system.
- Match audit evidence to the exact scope and deployed version.
- Treat upgrade authority as a direct control over user outcomes.
- Ask how the protocol behaves when each dependency supplies bad data or stops.
- Use several kinds of evidence; no badge or metric proves safety alone.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.