SKN3X.COM

Smart contract risk: the failure classes

Where contracts actually fail — and why “audited” is a statement about a point in time, not a property.

This lesson has had no expert review. It was written for this platform and against the evidence it cites; nobody has gone through it independently.

Learning objectives

  • You can name and distinguish the principal failure classes.
  • You can say what an audit report evidences and what it does not.

Check your prior knowledge

Answer these for yourself before reading on. Wherever you hesitate is where this lesson pays off.

Core concept

Fact

Four classes, only one of them a coding bug

First, implementation bugs: the code does not do what it should. Second, access failures: it does what it should, but for the wrong party. Third, economic failures: every function works correctly, yet their interaction yields a sequence profitable to an attacker. Fourth, dependency failures: your own code is sound, but something it relies on supplies wrong values. An audit chiefly addresses the first two.

Assumption

An audit is a snapshot with a scope

An audit report refers to a named code version, a named scope and a point in time. After an upgrade, different code runs. Whatever lay outside the scope — often the economic design and the dependencies — was not reviewed. The useful question is therefore not “is there an audit” but: which version, which scope, which findings, and what has changed since?

Interpretation

Assurance itself is an object of research

The market for smart contract assurance is young, and its emergence is now being studied empirically. It does not follow that audits are worthless — they are demonstrably useful. It follows that their evidential weight is itself a fair question: by whom, with what method, under what incentive.

Definitions

Access control
The rules for which address may call which function.
Economic exploit
An attack using only intended functions, in a profitable sequence.
Smart contract risk in the glossary
The risk that the contract or its environment behaves differently than assumed.

Model

  1. Implementation bugs — within an audit's scope

  2. Access failures — within an audit's scope

  3. Economic design — only with an explicit mandate

  4. Dependencies (oracle, other contracts) — usually outside

  5. Later upgrades — outside by definition

What an audit reaches — and what lies beside it

Worked example

Two protocols, both “audited”

Protocol A
audit of the current version, scope: core contracts and economics
Protocol B
audit from two upgrades ago, scope: core contracts only
Public claim
both: “audited”

The same claim, two very different facts: in B the audited code is not the running code, and the economic design was never in scope.

“Audited” separates nothing here.

Reading: The claim becomes information only with version, scope and date. Without those three it is marketing.

Retrieval

A protocol loses funds although every individual contract function works correctly. Which failure class is this?
Which three details make “audited” meaningful at all?

Exercise on real data

Read the smart contract questions and record which are answerable from an audit report — and which must come from chain state.

Dimension 4 of the analysis framework →

Application

You receive an audit report for a protocol your organization wants to invest in. Which four checks do you run on it?

Related case studies

Institutional reading

Bank
Does the report meet internal requirements for an external review?
Insurance
Which of the four failure classes could be formulated in an insurable way?

Key takeaways

Evidence