Business Logic Errors in Smart Contracts

A business logic error occurs when reachable contract behavior violates the protocol's intended rules. The code may compile and every individual statement may behave as written, but the system still permits an invalid transition, pays the wrong party, counts value twice, or leaves assets without a valid exit. Business logic flaws are code vulnerabilities; the label describes their dependence on protocol-specific intent, not a separate category outside implementation.

COMMON FAILURE MODES

Typical defects include claiming the same entitlement twice, borrowing against collateral that has already been withdrawn, applying fees in the wrong unit, accepting an operation in the wrong lifecycle state, or updating one side of an accounting relationship without the other. Cross-contract composition creates more cases: an adapter may assume a token transfers exactly the requested amount, or a vault may trust a downstream quote that changes before settlement.

Exploitability requires a reachable sequence that turns the mismatch into unauthorized value, control, or denial of service. A suspicious line without the surrounding state machine is not enough to establish impact.

REVIEW AND TEST

Start from a written specification. Define conservation properties, solvency requirements, privilege boundaries, state-transition rules, and liveness guarantees. Examples include “a position cannot withdraw collateral while debt remains,” “one authorization creates at most one payout,” and “all solvent users retain an exit path.”

Build a transition table for deposit, borrow, repay, liquidate, claim, pause, upgrade, and settle paths. Review each operation before and after every external call. Include multiple actors, repeated calls, zero and dust amounts, stale checkpoints, partial completion, fee-on-transfer behavior, and unusual call orderings.

Foundry's invariant-testing documentation describes randomized sequences of calls with assertions after each step. Those tests are strongest when handlers model realistic actions and ghost variables provide an independent accounting oracle. Solidity's SMTChecker documentation explains how assertions can express invariants for symbolic analysis, although external calls and complex environments limit what can be proved automatically.

MITIGATIONS AND LIMITS

• Make lifecycle states explicit and reject transitions outside the allowed graph.
• Update all related accounting before handing control to untrusted code, then verify received amounts when token behavior matters.
• Bind claims and authorizations to a unique subject, amount, domain, and nonce.
• Keep one canonical source for balances, debt, and exchange rates; reconcile cached totals against it.
• Use differential tests against a simple reference model for interest, shares, fees, and liquidation math.
• Test recovery and exit properties as aggressively as value conservation.

Assertions are valuable tripwires, but a production assertion that depends on enumerating every account may be impractical or itself create denial of service. Keep global reconciliation in tests or bounded maintenance paths.

Firepan can help map submitted state transitions, value flows, and candidate invariant violations. It cannot infer every undocumented business rule or prove economic correctness without the protocol specification, integrations, and deployment assumptions.

FREQUENTLY ASKED QUESTIONS

Why do unit tests miss logic errors?

They often exercise happy-path calls in isolation. Exploits emerge from sequences, multiple actors, boundary values, and unexpected integration behavior.

Does checks-effects-interactions prevent business logic bugs?

It reduces some reentrancy risk, but it does not validate the protocol's accounting or state machine.