semantic-guard-analysis

Semantic Guard Analysis

Detect logic vulnerabilities by finding functions that violate the contract's own internal guard patterns. Unlike pattern-matching tools, this approach uses the contract's consistent behavior as its specification.

When to Use

• Auditing smart contracts where traditional tools find nothing suspicious
• Looking for missing require checks, forgotten modifiers, inconsistent access control
• Analyzing contracts with emergency/admin functions that might bypass safety mechanisms
• Detecting logic bugs that are syntactically correct but semantically dangerous
• When you suspect "forgotten check" vulnerabilities

When NOT to Use

• Pure state-state invariant analysis (use state-invariant-detection)
• Full multi-dimensional audit (use behavioral-state-analysis)
• Code quality or gas optimization reviews

Core Principle: The Consistency Hypothesis

"A smart contract is its own specification."

Instead of checking against external rules, analyze what the contract claims to enforce, then find where it breaks its own rules.

If a critical state variable (like user balances) is protected by a security check (like a pause mechanism) in 90% of functions, the 10% without that check are likely vulnerabilities.

The Three-Phase Detection Architecture

Phase 1: AST Extraction & State Mapping

Parse the Solidity code and build a State Interaction Matrix.

For each state variable, track every function that touches it:

State Variable: balance
├─ deposit()        → [WRITE] + Guards: [paused, initialized]
├─ withdraw()       → [WRITE] + Guards: [paused, initialized]
├─ transfer()       → [WRITE] + Guards: [paused]
└─ emergencyWithdraw() → [WRITE] + Guards: [] ⚠️

For each function-variable interaction, record:

Attribute	Description
Write Access	Does the function modify this variable?
Guard Access	Does the function check this variable in require() or if()?
Read Access	Does the function only read this variable?