Symbolic Execution

Symbolic Execution Explained in Detail

Symbolic execution treats inputs as variables and explores possible paths through the program. When it reaches an unsafe state, it tries to produce constraints that explain how the path can happen.

For EVM contracts, this can reveal authorization, arithmetic, assertion, and call-flow issues that normal tests may not cover.

Smart contract example

function withdraw(uint256 amount) external {
    require(amount <= balances[msg.sender]);
    balances[msg.sender] -= amount;
}

A symbolic tool can explore many amount values instead of one hand-written test case.

Symbolic Execution in Auditing

Symbolic execution helps find edge cases, but it can also produce unrealistic paths. Auditors use it to generate leads, then validate important findings with concrete tests.

The hard part is judging feasibility in the real protocol context.

Red flags in code

• Tool findings are accepted without checking path constraints.

• External calls are modeled unrealistically.

• Path explosion hides deeper states.

• The tool runs on an isolated contract while the bug depends on integrations.

• Counterexamples are not reproduced in tests.

How to test or review it

• Inspect the path constraints behind each finding.

• Reproduce feasible issues with a Foundry or unit test.

• Compare symbolic results with manual review.

• Constrain inputs to realistic protocol states.

• Use it alongside static analysis, not as a replacement.