semantic-guard-analysis

Name: semantic-guard-analysis
Author: quillai-network

114stars23forks

How to install semantic-guard-analysis?

quillai-network/quillshield_skills/semantic-guard-analysis

$npx -y skills add quillai-network/quillshield_skills --skill semantic-guard-analysis

Installs into the current project.

Summary

Detects logic vulnerabilities in smart contracts by analyzing guard-state consistency patterns. Identifies functions that bypass security checks (require, modifiers) that other functions consistently apply. Uses the Consistency Principle — a contract is its own specification. Use

Files · 1

View on GitHub

SKILL.md

1	# Semantic Guard Analysis
2
3	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.
4
5	## When to Use
6
7	- Auditing smart contracts where traditional tools find nothing suspicious
8	- Looking for missing `require` checks, forgotten modifiers, inconsistent access control
9	- Analyzing contracts with emergency/admin functions that might bypass safety mechanisms
10	- Detecting logic bugs that are syntactically correct but semantically dangerous
11	- When you suspect "forgotten check" vulnerabilities
12
13	## When NOT to Use
14
15	- Pure state-state invariant analysis (use state-invariant-detection)
16	- Full multi-dimensional audit (use behavioral-state-analysis)
17	- Code quality or gas optimization reviews
18
19	## Core Principle: The Consistency Hypothesis
20
21	> "A smart contract is its own specification."
22
23	Instead of checking against external rules, analyze what the contract claims to enforce, then find where it breaks its own rules.
24
25	> 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.
26
27	## The Three-Phase Detection Architecture
28
29	### Phase 1: AST Extraction & State Mapping
30
31	Parse the Solidity code and build a State Interaction Matrix.
32
33	For each state variable, track every function that touches it:
34
35	```
36	State Variable: balance
37	├─ deposit() → [WRITE] + Guards: [paused, initialized]
38	├─ withdraw() → [WRITE] + Guards: [paused, initialized]
39	├─ transfer() → [WRITE] + Guards: [paused]
40	└─ emergencyWithdraw() → [WRITE] + Guards: [] ⚠️
41	```
42
43	For each function-variable interaction, record:
44
45	\| Attribute \| Description \|
46	\|-----------\|-------------\|
47	\| Write Access \| Does the function modify this variable? \|
48	\| Guard Access \| Does the function check this variable in `require()` or `if()`? \|
49	\| Read Access \| Does the function only read this variable? \|
50
51	Extract guard sources:
52	- Modifier chains (`onlyOwner`, `nonReentrant`, `whenNotPaused`)
53	- Explicit `require` statements
54	- Conditional branches gating state changes
55	- External calls affecting state
56	- Event emissions signaling state changes
57
58	### Phase 2: Dependency Graph Construction
59
60	Build a mathematical model of how variables protect each other.
61
62	Guard Relationship: If Variable A is checked before Variable B is modified:
63
64	```
65	A → B (A guards B)
66	```
67
68	Example:
69
70	```
71	paused ──────┐
72	├──→ balance
73	initialized ─┘
74
75	owner ───→ paused
76	owner ───→ totalSupply
77	```
78
79	Frequency Weighting: Each guard relationship gets a confidence score:
80
81	```
82	Confidence(guard → state) = \|functions applying guard\| / \|functions modifying state\|
83	```
84
85	- `paused` guards `balance` in 9/10 functions → 90% confidence
86	- `owner` guards `totalSupply` in 3/10 functions → 30% confidence (weak)
87
88	Composite Dependencies: Track multi-variable guards:
89
90	```
91	(owner AND timeLock) → criticalFunction
92	(paused OR emergency) → userAccess
93	```
94
95	### Phase 3: Anomaly Detection (The Solver)
96
97	Identify functions that violate established patterns.
98
99	Algorithm:
100
101	```
102	For each state variable S that can be modified:
103	1. M = all functions that write to S
104	2. G = common guards across those functions (above threshold)
105	3. V = M \ G (functions that modify without guards)
106	4. V is the vulnerability set
107	```
108
109	Threshold-Based Inference:
110
111	\| Guard Frequency \| Classification \| Action \|
112	\|-----------------\|---------------\|--------\|
113	\| ≥ 80% \| Strong Invariant \| Flag violations as HIGH/CRITICAL \|
114	\| 50-79% \| Weak Invariant \| Flag violations as MEDIUM \|
115	\| < 50% \| No Pattern \| Ignore (too inconsistent) \|
116
117	Severity Classification:
118
119	\| Bypass Type \| Severity \|
120	\|-------------\|----------\|
121	\| Strong invariant on financial state (`balance`, `totalSupply`) \| Critical \|
122	\| Strong invariant on access control (`owner`, admin roles) \| High \|
123	\| Weak invariant on any state \| Medium \|
124	\| Inconsistent pattern with no security implications \| Low/Info \|
125
126	Context-Aware Filtering:
127	- Constructor and `initialize()` functions may legitimately bypass patterns
128	- `view`/`pure` functions cannot modify state — skip
129	- Proxy pattern `delegatecall` requires special handling
130	- Emergency functions may intentionally bypass some guards
131
132	## Workflow
133
134	```
135	Task Progress:
136	- [ ] Step 1: Parse contract AST and build State Interaction Mat

People who liked this also viewed

6 picks

Type

semantic-guard-analysis

114stars23forks

View on GitHub

How to install semantic-guard-analysis?

quillai-network/quillshield_skills/semantic-guard-analysis

$npx -y skills add quillai-network/quillshield_skills --skill semantic-guard-analysis

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Semantic Guard Analysis
2
3	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.
4
5	## When to Use
6
7	- Auditing smart contracts where traditional tools find nothing suspicious
8	- Looking for missing `require` checks, forgotten modifiers, inconsistent access control
9	- Analyzing contracts with emergency/admin functions that might bypass safety mechanisms
10	- Detecting logic bugs that are syntactically correct but semantically dangerous
11	- When you suspect "forgotten check" vulnerabilities
12
13	## When NOT to Use
14
15	- Pure state-state invariant analysis (use state-invariant-detection)
16	- Full multi-dimensional audit (use behavioral-state-analysis)
17	- Code quality or gas optimization reviews
18
19	## Core Principle: The Consistency Hypothesis
20
21	> "A smart contract is its own specification."
22
23	Instead of checking against external rules, analyze what the contract claims to enforce, then find where it breaks its own rules.
24
25	> 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.
26
27	## The Three-Phase Detection Architecture
28
29	### Phase 1: AST Extraction & State Mapping
30
31	Parse the Solidity code and build a State Interaction Matrix.
32
33	For each state variable, track every function that touches it:
34
35	```
36	State Variable: balance
37	├─ deposit() → [WRITE] + Guards: [paused, initialized]
38	├─ withdraw() → [WRITE] + Guards: [paused, initialized]
39	├─ transfer() → [WRITE] + Guards: [paused]
40	└─ emergencyWithdraw() → [WRITE] + Guards: [] ⚠️
41	```
42
43	For each function-variable interaction, record:
44
45	\| Attribute \| Description \|
46	\|-----------\|-------------\|
47	\| Write Access \| Does the function modify this variable? \|
48	\| Guard Access \| Does the function check this variable in `require()` or `if()`? \|
49	\| Read Access \| Does the function only read this variable? \|
50
51	Extract guard sources:
52	- Modifier chains (`onlyOwner`, `nonReentrant`, `whenNotPaused`)
53	- Explicit `require` statements
54	- Conditional branches gating state changes
55	- External calls affecting state
56	- Event emissions signaling state changes
57
58	### Phase 2: Dependency Graph Construction
59
60	Build a mathematical model of how variables protect each other.
61
62	Guard Relationship: If Variable A is checked before Variable B is modified:
63
64	```
65	A → B (A guards B)
66	```
67
68	Example:
69
70	```
71	paused ──────┐
72	├──→ balance
73	initialized ─┘
74
75	owner ───→ paused
76	owner ───→ totalSupply
77	```
78
79	Frequency Weighting: Each guard relationship gets a confidence score:
80
81	```
82	Confidence(guard → state) = \|functions applying guard\| / \|functions modifying state\|
83	```
84
85	- `paused` guards `balance` in 9/10 functions → 90% confidence
86	- `owner` guards `totalSupply` in 3/10 functions → 30% confidence (weak)
87
88	Composite Dependencies: Track multi-variable guards:
89
90	```
91	(owner AND timeLock) → criticalFunction
92	(paused OR emergency) → userAccess
93	```
94
95	### Phase 3: Anomaly Detection (The Solver)
96
97	Identify functions that violate established patterns.
98
99	Algorithm:
100
101	```
102	For each state variable S that can be modified:
103	1. M = all functions that write to S
104	2. G = common guards across those functions (above threshold)
105	3. V = M \ G (functions that modify without guards)
106	4. V is the vulnerability set
107	```
108
109	Threshold-Based Inference:
110
111	\| Guard Frequency \| Classification \| Action \|
112	\|-----------------\|---------------\|--------\|
113	\| ≥ 80% \| Strong Invariant \| Flag violations as HIGH/CRITICAL \|
114	\| 50-79% \| Weak Invariant \| Flag violations as MEDIUM \|
115	\| < 50% \| No Pattern \| Ignore (too inconsistent) \|
116
117	Severity Classification:
118
119	\| Bypass Type \| Severity \|
120	\|-------------\|----------\|
121	\| Strong invariant on financial state (`balance`, `totalSupply`) \| Critical \|
122	\| Strong invariant on access control (`owner`, admin roles) \| High \|
123	\| Weak invariant on any state \| Medium \|
124	\| Inconsistent pattern with no security implications \| Low/Info \|
125
126	Context-Aware Filtering:
127	- Constructor and `initialize()` functions may legitimately bypass patterns
128	- `view`/`pure` functions cannot modify state — skip
129	- Proxy pattern `delegatecall` requires special handling
130	- Emergency functions may intentionally bypass some guards
131
132	## Workflow
133
134	```
135	Task Progress:
136	- [ ] Step 1: Parse contract AST and build State Interaction Mat

People who liked this also viewed

6 picks

Type