white-hat-scanner 1.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +2 -0
- package/dist/analyzer.js +852 -0
- package/dist/contest.js +144 -0
- package/dist/disclosure.js +85 -0
- package/dist/discovery.js +260 -0
- package/dist/index.js +88 -0
- package/dist/notifier.js +51 -0
- package/dist/redis.js +36 -0
- package/dist/scorer.js +33 -0
- package/dist/submission.js +103 -0
- package/dist/test/smoke.js +511 -0
- package/package.json +23 -0
- package/research/bounty-economics.md +145 -0
- package/research/tooling-landscape.md +216 -0
- package/research/vuln-pattern-library.md +401 -0
- package/src/analyzer.ts +974 -0
- package/src/contest.ts +172 -0
- package/src/disclosure.ts +111 -0
- package/src/discovery.ts +297 -0
- package/src/index.ts +105 -0
- package/src/notifier.ts +58 -0
- package/src/redis.ts +31 -0
- package/src/scorer.ts +46 -0
- package/src/submission.ts +124 -0
- package/src/test/smoke.ts +457 -0
- package/system/architecture.md +488 -0
- package/system/scanner-mvp.md +305 -0
- package/targets/active-bounty-programs.md +111 -0
- package/tsconfig.json +15 -0
package/package.json
ADDED
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "white-hat-scanner",
|
|
3
|
+
"version": "1.0.1",
|
|
4
|
+
"description": "Autonomous white-hat security scanner for DeFi protocols",
|
|
5
|
+
"main": "dist/index.js",
|
|
6
|
+
"bin": {
|
|
7
|
+
"white-hat-scanner": "dist/index.js"
|
|
8
|
+
},
|
|
9
|
+
"scripts": {
|
|
10
|
+
"build": "tsc",
|
|
11
|
+
"start": "ts-node src/index.ts",
|
|
12
|
+
"test": "ts-node src/test/smoke.ts"
|
|
13
|
+
},
|
|
14
|
+
"dependencies": {
|
|
15
|
+
"ioredis": "5.3.2",
|
|
16
|
+
"node-fetch": "3.3.2"
|
|
17
|
+
},
|
|
18
|
+
"devDependencies": {
|
|
19
|
+
"@types/node": "22.10.0",
|
|
20
|
+
"ts-node": "10.9.2",
|
|
21
|
+
"typescript": "5.3.3"
|
|
22
|
+
}
|
|
23
|
+
}
|
|
@@ -0,0 +1,145 @@
|
|
|
1
|
+
# Bug Bounty Economics
|
|
2
|
+
|
|
3
|
+
> Data sourced from Immunefi leaderboard and explore pages — last refreshed **2026-04-03**.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Top Immunefi Earners (All-Time)
|
|
8
|
+
|
|
9
|
+
| Rank | Handle | Total Earnings | Paid Reports | Avg / Report |
|
|
10
|
+
|------|--------|---------------|-------------|-------------|
|
|
11
|
+
| 1 | Barracuda3172 | $14,439,800 | 7 | ~$2.06M |
|
|
12
|
+
| 2 | RetailDdene2946 | $10,020,000 | 2 | ~$5.01M |
|
|
13
|
+
| 3 | PwningEth | $8,000,000 | 8 | ~$1.00M |
|
|
14
|
+
| 4 | GothicShanon89238 | $4,181,150 | 16 | ~$261K |
|
|
15
|
+
| 5 | LonelySloth *(Elite Auditor)* | $3,612,409 | 60 | ~$60K |
|
|
16
|
+
| 6 | usmannk *(Elite Auditor)* | $3,250,727 | 16 | ~$203K |
|
|
17
|
+
| 7 | Bobface | $3,391,900 | 8 | ~$424K |
|
|
18
|
+
| 8 | ily2 | $3,030,000 | 3 | ~$1.01M |
|
|
19
|
+
| 9 | kankodu *(Elite Auditor)* | $2,681,250 | 17 | ~$158K |
|
|
20
|
+
| 10 | TrustSec | — | — | — |
|
|
21
|
+
| 11 | Paludo0x | — | — | — |
|
|
22
|
+
| 12 | ibrahimatix0x01 | — | — | — |
|
|
23
|
+
|
|
24
|
+
**Key insight:** The top 3 each averaged ≥ $1M per accepted critical report. RetailDdene2946 earned $10M from just 2 reports — textbook precision strategy.
|
|
25
|
+
|
|
26
|
+
---
|
|
27
|
+
|
|
28
|
+
## 2. Current High-Paying Programs (Immunefi, April 2026)
|
|
29
|
+
|
|
30
|
+
| Protocol | Chain | Max Bounty | Vault TVL | Total Paid | Med. Resolution |
|
|
31
|
+
|----------|-------|-----------|-----------|-----------|----------------|
|
|
32
|
+
| Ethena | Ethereum | **$3,000,000** | $12.4k | Private | Private |
|
|
33
|
+
| SSV Network | Ethereum | **$1,000,000** | $137.5k | Private | Private |
|
|
34
|
+
| DeXe Protocol | Ethereum | **$500,000** | $60.5k | Private | Private |
|
|
35
|
+
| Lombard Finance | Ethereum | **$250,000** | $40k | Private | Private |
|
|
36
|
+
| Ref Finance | NEAR | **$250,000** | $7.8k | $98.9k | 2 weeks |
|
|
37
|
+
| Bitflow | Stacks | **$100,000** | $2.8k | Private | Private |
|
|
38
|
+
| StackingDAO | Stacks | **$100,000** | $2.8k | Private | Private |
|
|
39
|
+
| The Graph | Ethereum | $50,000 | $82.5k | $1.5M | **1 day** |
|
|
40
|
+
| Immunefi Platform | Ethereum | $50,000 | $4.6k | $63.8k | **9 hours** |
|
|
41
|
+
| Hedera | Hedera | $30,000 | $26.7k | Private | Private |
|
|
42
|
+
|
|
43
|
+
*240 active bounty programs as of data refresh. Programs with public resolution times tend to be fastest payers.*
|
|
44
|
+
|
|
45
|
+
---
|
|
46
|
+
|
|
47
|
+
## 3. What Vuln Classes Hit $500K+
|
|
48
|
+
|
|
49
|
+
Based on historical Immunefi disclosures and leaderboard payouts, critical payouts at the $500K–$10M tier consistently come from:
|
|
50
|
+
|
|
51
|
+
| Vuln Class | Why it Pays Max | Example Protocols |
|
|
52
|
+
|-----------|----------------|------------------|
|
|
53
|
+
| **Direct fund drain via logic bug** | Arbitrary withdrawal, incorrect accounting, broken invariant lets attacker take all protocol TVL | AMMs, lending protocols |
|
|
54
|
+
| **Bridge exploit / validator takeover** | Cross-chain bridges hold billions in escrow; single message-verification flaw can drain everything | Wormhole ($320M patched), Ronin |
|
|
55
|
+
| **Governance manipulation** | Flash-loan vote, timelock bypass, proposal spam that executes malicious code | DAOs with on-chain governance |
|
|
56
|
+
| **Oracle price manipulation** | TWAP manipulation, sandwich attacks on spot-price oracles feeding liquidation logic | DeFi money markets |
|
|
57
|
+
| **Upgrade proxy misconfiguration** | Unprotected `upgradeTo()`, uninitialized proxy implementation can transfer ownership to attacker | Any UUPS / Transparent proxy |
|
|
58
|
+
| **Signature replay / malleability** | `ecrecover` without nonce or chain-id allows replaying signed messages across chains or re-spending | Permit-based tokens, meta-tx relayers |
|
|
59
|
+
|
|
60
|
+
---
|
|
61
|
+
|
|
62
|
+
## 4. Time-to-Payout (Disclosure → Payment)
|
|
63
|
+
|
|
64
|
+
| Platform | Typical Range | Best Case | Notes |
|
|
65
|
+
|----------|--------------|-----------|-------|
|
|
66
|
+
| Immunefi (managed triage) | 2–6 weeks | 9 hours (Immunefi itself) | Managed triage programs resolve fastest |
|
|
67
|
+
| Immunefi (self-managed) | 4–12 weeks | 1 day (The Graph) | Depends on protocol team responsiveness |
|
|
68
|
+
| HackerOne | 2–8 weeks | Same-day (H1 fast-track) | More mature disclosure SLAs |
|
|
69
|
+
| Direct disclosure | 1–6 months | Varies | No SLA guarantee; ghosting risk |
|
|
70
|
+
|
|
71
|
+
**Process steps consuming the most time:**
|
|
72
|
+
1. Triage confirmation (can take days if team is small)
|
|
73
|
+
2. Root-cause + fix agreement
|
|
74
|
+
3. Fix deployment + mainnet verification
|
|
75
|
+
4. Payment processing (crypto transfer is fast once approved)
|
|
76
|
+
|
|
77
|
+
---
|
|
78
|
+
|
|
79
|
+
## 5. Legal Framework
|
|
80
|
+
|
|
81
|
+
### Safe Harbor
|
|
82
|
+
Immunefi operates a formal **Safe Harbor** program: protocols that opt in agree not to pursue legal action against researchers who disclose responsibly within scope. As of 2026, ~30+ protocols have opted in. Always verify a specific program's safe harbor status before testing.
|
|
83
|
+
|
|
84
|
+
- HackerOne programs have their own legal safe harbor language in each program policy.
|
|
85
|
+
- **Always** read the program policy's legal section before starting research.
|
|
86
|
+
|
|
87
|
+
### Key Jurisdictions
|
|
88
|
+
| Jurisdiction | Relevant Law | Researcher Risk |
|
|
89
|
+
|-------------|-------------|----------------|
|
|
90
|
+
| USA | CFAA (Computer Fraud & Abuse Act) | High if out-of-scope; authorized research generally protected |
|
|
91
|
+
| EU | NIS2 / national cyber laws | Varies by country; Germany / Netherlands generally researcher-friendly |
|
|
92
|
+
| Singapore | Computer Misuse Act | Generally tolerant of authorized research |
|
|
93
|
+
| Cayman Islands | Few crypto-specific laws | Many DeFi entities incorporated here |
|
|
94
|
+
|
|
95
|
+
**Practical rule:** Stick strictly to in-scope assets. Never exploit a live production system beyond confirming exploitability. Submit PoC to testnets or forked state when possible.
|
|
96
|
+
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
## 6. Business Models: Volume vs. Precision
|
|
100
|
+
|
|
101
|
+
### Model A — Precision (Few Critical Bugs)
|
|
102
|
+
- Target: $500K–$10M per find
|
|
103
|
+
- Focus: Bridges, large lending protocols, canonical cross-chain infrastructure
|
|
104
|
+
- Team size: 1–3 senior researchers
|
|
105
|
+
- Tools: Manual code review + custom fuzzing harnesses + formal verification
|
|
106
|
+
- **RetailDdene2946** is the archetype: $10M from 2 reports
|
|
107
|
+
- Downside: Long dry spells; high variance income
|
|
108
|
+
|
|
109
|
+
### Model B — Volume (Many Medium/High Bugs)
|
|
110
|
+
- Target: $10K–$100K per find, 4–12 finds per quarter
|
|
111
|
+
- Focus: Long-tail DeFi protocols, new launches, audit competition overlap
|
|
112
|
+
- Team size: 3–8 researchers
|
|
113
|
+
- Tools: Slither + Echidna automation pipeline, rapid triage, templates
|
|
114
|
+
- **LonelySloth** exemplifies this: $3.6M from 60 reports (~$60K avg)
|
|
115
|
+
- Downside: Diminishing returns as low-hanging fruit gets picked
|
|
116
|
+
|
|
117
|
+
### Model C — Hybrid (Systematic with Precision Escalation)
|
|
118
|
+
- Run automated tooling across many protocols to find low/medium bugs quickly
|
|
119
|
+
- Escalate suspicious patterns to deep manual review for critical potential
|
|
120
|
+
- Use audit competition wins as intelligence on target codebases
|
|
121
|
+
- **Recommended for a team operation**: predictable base income + upside optionality
|
|
122
|
+
|
|
123
|
+
### Realistic Annual Revenue Estimates (2026)
|
|
124
|
+
| Team Tier | Reports/yr | Avg Payout | Gross Revenue |
|
|
125
|
+
|-----------|-----------|-----------|--------------|
|
|
126
|
+
| Solo beginner | 4–8 | $5K | $20–40K |
|
|
127
|
+
| Solo experienced | 12–24 | $25K | $300K–600K |
|
|
128
|
+
| Small team (3 ppl) | 30–60 | $40K | $1.2M–2.4M |
|
|
129
|
+
| Elite precision team | 3–8 | $500K+ | $1.5M–4M+ |
|
|
130
|
+
|
|
131
|
+
---
|
|
132
|
+
|
|
133
|
+
## 7. Notable Historical Payouts
|
|
134
|
+
|
|
135
|
+
| Year | Protocol | Researcher / Team | Payout | Vuln Type |
|
|
136
|
+
|------|----------|-------------------|--------|-----------|
|
|
137
|
+
| 2022 | Wormhole | External (post-exploit) | N/A — $320M exploited | Signature verification bypass |
|
|
138
|
+
| 2022 | Aurora | pwning.eth | $6,000,000 | Integer overflow in NEAR/EVM bridge |
|
|
139
|
+
| 2022 | Polygon | Leon Spacewalker | $2,000,000 | Double-spend in Plasma bridge |
|
|
140
|
+
| 2023 | Ethereum 2.0 | Various | $250,000 each | Consensus client bugs |
|
|
141
|
+
| 2023 | Arbitrum | Various | $400,000 | Nitro bridge logic |
|
|
142
|
+
| 2024 | Ethena | Barracuda3172 (est.) | $3M+ | Critical smart contract logic |
|
|
143
|
+
| 2024–25 | Multiple | RetailDdene2946 | ~$10M | Critical (undisclosed) |
|
|
144
|
+
|
|
145
|
+
*Most Immunefi payouts above $1M remain undisclosed per request of the receiving protocol.*
|
|
@@ -0,0 +1,216 @@
|
|
|
1
|
+
# Smart Contract Security Tooling Landscape
|
|
2
|
+
|
|
3
|
+
> Tool versions current as of April 2026. Sources: GitHub repos for Slither (crytic/slither), Echidna (crytic/echidna), Foundry (foundry-rs/foundry).
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Slither — Static Analysis
|
|
8
|
+
|
|
9
|
+
**Repo:** https://github.com/crytic/slither
|
|
10
|
+
**Language:** Python 3.10+
|
|
11
|
+
**Targets:** Solidity ≥ 0.4, Vyper
|
|
12
|
+
**Install:** `pip install slither-analyzer` or `uv tool install slither-analyzer`
|
|
13
|
+
|
|
14
|
+
### All Detectors (by Impact)
|
|
15
|
+
|
|
16
|
+
#### HIGH Impact / HIGH Confidence — *Auto-triage as critical leads*
|
|
17
|
+
| # | Detector | What It Finds |
|
|
18
|
+
|---|----------|--------------|
|
|
19
|
+
| 1 | `abiencoderv2-array` | Storage abiencoderv2 array bugs |
|
|
20
|
+
| 2 | `arbitrary-send-erc20` | `transferFrom` with arbitrary `from` |
|
|
21
|
+
| 3 | `array-by-reference` | Modifying storage array by value |
|
|
22
|
+
| 4 | `encode-packed-collision` | `abi.encodePacked` hash collision |
|
|
23
|
+
| 5 | `incorrect-shift` | Wrong parameter order in shift ops |
|
|
24
|
+
| 6 | `multiple-constructors` | Multiple constructor definitions |
|
|
25
|
+
| 7 | `name-reused` | Contract name collision |
|
|
26
|
+
| 8 | `protected-vars` | Unprotected variables |
|
|
27
|
+
| 9 | `public-mappings-nested` | Nested public mappings |
|
|
28
|
+
| 10 | `rtlo` | Right-to-left override Unicode character (malicious code hiding) |
|
|
29
|
+
| 11 | `shadowing-state` | State variable shadowing |
|
|
30
|
+
| 12 | `suicidal` | Anyone can call `selfdestruct` |
|
|
31
|
+
| 13 | `uninitialized-state` | Uninitialized state variables |
|
|
32
|
+
| 14 | `uninitialized-storage` | Uninitialized storage pointers |
|
|
33
|
+
| 15 | `unprotected-upgrade` | Proxy upgrade without access control ⚠️ *Critical bug class* |
|
|
34
|
+
|
|
35
|
+
#### HIGH Impact / MEDIUM Confidence — *Worth manual follow-up*
|
|
36
|
+
| # | Detector | What It Finds |
|
|
37
|
+
|---|----------|--------------|
|
|
38
|
+
| 16 | `arbitrary-send-erc20-permit` | `transferFrom` + permit with arbitrary `from` |
|
|
39
|
+
| 17 | `arbitrary-send-eth` | ETH sent to arbitrary address |
|
|
40
|
+
| 18 | `controlled-array-length` | Tainted array length assignment |
|
|
41
|
+
| 19 | `controlled-delegatecall` | Attacker-controlled delegatecall target |
|
|
42
|
+
| 20 | `delegatecall-loop` | Payable + delegatecall in loop |
|
|
43
|
+
| 21 | `incorrect-exp` | `^` used as XOR instead of exponentiation |
|
|
44
|
+
| 22 | `incorrect-return` | Wrong `return` in assembly |
|
|
45
|
+
| 23 | `msg-value-loop` | `msg.value` read inside a loop |
|
|
46
|
+
| 24 | `reentrancy-eth` | Classic reentrancy (ETH theft) |
|
|
47
|
+
| 25 | `reentrancy-balance` | Reentrancy with stale balance |
|
|
48
|
+
| 26 | `return-leave` | `return` instead of `leave` in Yul |
|
|
49
|
+
| 27 | `storage-array` | Signed integer storage array compiler bug |
|
|
50
|
+
| 28 | `unchecked-transfer` | ERC20 transfer return value ignored |
|
|
51
|
+
| 29 | `weak-prng` | On-chain randomness predictable |
|
|
52
|
+
|
|
53
|
+
#### MEDIUM Impact / HIGH Confidence
|
|
54
|
+
| # | Detector | What It Finds |
|
|
55
|
+
|---|----------|--------------|
|
|
56
|
+
| 30 | `domain-separator-collision` | EIP-2612 DOMAIN_SEPARATOR collision |
|
|
57
|
+
| 31 | `enum-conversion` | Dangerous enum cast |
|
|
58
|
+
| 32 | `erc20-interface` | Wrong ERC-20 interface |
|
|
59
|
+
| 33 | `erc721-interface` | Wrong ERC-721 interface |
|
|
60
|
+
| 34 | `incorrect-equality` | Dangerous strict equality (`==` on balances) |
|
|
61
|
+
| 35 | `locked-ether` | Contract receives ETH but has no withdrawal |
|
|
62
|
+
| 36 | `mapping-deletion` | Delete on struct-containing mapping |
|
|
63
|
+
| 37 | `pyth-deprecated-functions` | Pyth oracle deprecated API |
|
|
64
|
+
| 38 | `pyth-unchecked-confidence` | Pyth price confidence not validated |
|
|
65
|
+
| 39 | `pyth-unchecked-publishtime` | Pyth price staleness not checked |
|
|
66
|
+
| 40 | `shadowing-abstract` | Abstract contract state shadowing |
|
|
67
|
+
| 41 | `tautological-compare` | Variable compared to itself |
|
|
68
|
+
| 42 | `tautology` | Boolean tautology / contradiction |
|
|
69
|
+
| 43 | `write-after-write` | Dead write (result immediately overwritten) |
|
|
70
|
+
|
|
71
|
+
#### MEDIUM Impact / MEDIUM Confidence (selected)
|
|
72
|
+
| # | Detector | What It Finds |
|
|
73
|
+
|---|----------|--------------|
|
|
74
|
+
| 44 | `boolean-cst` | Misuse of boolean constant |
|
|
75
|
+
| 45 | `chronicle-unchecked-price` | Chronicle oracle price not validated |
|
|
76
|
+
| 46 | `constant-function-asm` | `view`/`pure` + assembly writes state |
|
|
77
|
+
| 47 | `constant-function-state` | `view`/`pure` actually changes state |
|
|
78
|
+
| ... | + ~50 more low/info detectors | Code quality, gas, best practices |
|
|
79
|
+
|
|
80
|
+
**Total detectors: ~100+** across High/Medium/Low/Informational tiers.
|
|
81
|
+
|
|
82
|
+
### What Slither Does NOT Catch
|
|
83
|
+
- Business logic bugs (protocol-specific invariants)
|
|
84
|
+
- Economic attack vectors (MEV, oracle manipulation requiring live price context)
|
|
85
|
+
- Cross-contract state dependencies requiring transaction simulation
|
|
86
|
+
- Governance attacks (voting math, quorum edge cases)
|
|
87
|
+
- Flash loan attack paths (multi-step economic sequences)
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
91
|
+
## 2. Echidna — Property-Based Fuzzer
|
|
92
|
+
|
|
93
|
+
**Repo:** https://github.com/crytic/echidna
|
|
94
|
+
**Language:** Haskell; tests Solidity/Vyper
|
|
95
|
+
**Powered by:** Slither (for pre-fuzzing analysis)
|
|
96
|
+
|
|
97
|
+
### Testing Modes
|
|
98
|
+
| Mode | What It Tests |
|
|
99
|
+
|------|--------------|
|
|
100
|
+
| `property` (default) | `echidna_`-prefixed functions returning `bool` |
|
|
101
|
+
| `assertion` | `assert()` / Foundry `assertX` failures |
|
|
102
|
+
| `foundry` | Foundry `test_` unit tests + `invariant_` stateful tests |
|
|
103
|
+
| `overflow` | Integer over/underflows (Solidity ≥ 0.8) |
|
|
104
|
+
| `optimization` | Maximize return value of `int256`-returning functions |
|
|
105
|
+
| `exploration` | Coverage collection only |
|
|
106
|
+
|
|
107
|
+
### What Echidna Catches That Slither Misses
|
|
108
|
+
- **Stateful invariant violations**: Protocol-level rules (e.g., "total shares never exceed total assets") that only break after a sequence of transactions
|
|
109
|
+
- **Integer over/underflows** in complex arithmetic paths
|
|
110
|
+
- **Access control edge cases** discovered through random call sequencing
|
|
111
|
+
- **Economic invariants**: e.g., `x * y == k` in AMMs after multiple swaps
|
|
112
|
+
- **Fork-based testing**: Can test against mainnet state forks to catch real-world interaction bugs
|
|
113
|
+
|
|
114
|
+
### Echidna Workflow
|
|
115
|
+
```bash
|
|
116
|
+
# Write invariant in Solidity
|
|
117
|
+
function echidna_total_supply_never_exceeds_cap() public returns (bool) {
|
|
118
|
+
return token.totalSupply() <= token.cap();
|
|
119
|
+
}
|
|
120
|
+
|
|
121
|
+
# Run fuzzer
|
|
122
|
+
echidna MyContract.sol --config echidna.yaml --test-mode property
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
---
|
|
126
|
+
|
|
127
|
+
## 3. Foundry Invariant Fuzzing
|
|
128
|
+
|
|
129
|
+
**Repo:** https://github.com/foundry-rs/foundry
|
|
130
|
+
**Components:** Forge (test/fuzz), Cast (on-chain interaction), Anvil (local node), Chisel (REPL)
|
|
131
|
+
|
|
132
|
+
### Forge Fuzzing Capabilities
|
|
133
|
+
- **Unit fuzzing**: `forge test` automatically fuzzes function inputs marked with `uint256 fuzzedInput` parameter
|
|
134
|
+
- **Invariant testing**: `invariant_`-prefixed test functions are called across randomized call sequences against a deployed contract system
|
|
135
|
+
- **Forked state testing**: `--fork-url` runs tests against a mainnet fork
|
|
136
|
+
- **Coverage**: `forge coverage` generates line/branch coverage reports
|
|
137
|
+
|
|
138
|
+
### What Foundry Catches vs Echidna
|
|
139
|
+
| Capability | Foundry | Echidna |
|
|
140
|
+
|-----------|---------|---------|
|
|
141
|
+
| Invariant testing | ✅ | ✅ |
|
|
142
|
+
| Fork-state testing | ✅ (built-in) | ✅ (config option) |
|
|
143
|
+
| Assertion mode | ✅ | ✅ |
|
|
144
|
+
| Corpus persistence | Partial | ✅ Full corpus directory |
|
|
145
|
+
| Coverage guidance | ✅ | ✅ |
|
|
146
|
+
| Speed | ✅ Fast (Rust EVM) | Slower (Haskell) |
|
|
147
|
+
| Custom mutation strategies | Limited | ✅ More configurable |
|
|
148
|
+
| Best for | Integration in CI, broad coverage | Deep invariant campaigns |
|
|
149
|
+
|
|
150
|
+
---
|
|
151
|
+
|
|
152
|
+
## 4. Where LLM / Claude Review Adds the Most Value
|
|
153
|
+
|
|
154
|
+
Static analysis and fuzzing leave significant gaps. LLM-assisted review is highest-signal for:
|
|
155
|
+
|
|
156
|
+
### High-Value LLM Review Areas
|
|
157
|
+
|
|
158
|
+
| Category | Why Automation Fails | LLM Advantage |
|
|
159
|
+
|----------|---------------------|---------------|
|
|
160
|
+
| **Business logic correctness** | No tool knows the protocol spec; rules aren't in code | Can reason about intent vs. implementation |
|
|
161
|
+
| **Governance logic** | Quorum, timelock, proposal encoding — context-dependent | Understands multi-step governance flows |
|
|
162
|
+
| **Economic / game-theory attacks** | Flash loans, MEV, incentive manipulation — require reasoning about adversarial actors | Can model "what would a rational attacker do?" |
|
|
163
|
+
| **Fee-on-transfer / rebase token interactions** | Protocol says it handles these; LLM can challenge assumptions | Cross-contract assumption verification |
|
|
164
|
+
| **Access control intent** | Slither flags missing modifiers, but LLM can question whether the right roles have the right permissions | Can map roles to intended access matrix |
|
|
165
|
+
| **Upgrade compatibility** | Storage layout collisions in proxy upgrades; new initializer gaps | Can compare old vs new storage layout |
|
|
166
|
+
| **Cross-chain message validation** | Bridge message parsing, chain-id confusion, replay paths | Can trace message lifecycle across chains |
|
|
167
|
+
| **NatSpec vs implementation divergence** | Comments say one thing; code does another | Direct comparison of documentation to code |
|
|
168
|
+
| **EIP compliance gaps** | Token implements EIP-4626 but misses edge case in `convertToShares` | Can verify against spec line-by-line |
|
|
169
|
+
|
|
170
|
+
### LLM Prompt Patterns That Work
|
|
171
|
+
```
|
|
172
|
+
"Given this contract, what invariants should always hold? Which ones can you
|
|
173
|
+
verify are enforced, and which ones lack enforcement?"
|
|
174
|
+
|
|
175
|
+
"Trace the path of funds from deposit to withdrawal. Where could an attacker
|
|
176
|
+
divert funds or extract more than deposited?"
|
|
177
|
+
|
|
178
|
+
"This contract uses a flash loan in function X. What state changes happen
|
|
179
|
+
before the callback vs after? Is there any state the callback can manipulate
|
|
180
|
+
to extract value?"
|
|
181
|
+
```
|
|
182
|
+
|
|
183
|
+
---
|
|
184
|
+
|
|
185
|
+
## 5. Gap Analysis — Vuln Classes With No Good Automated Tool
|
|
186
|
+
|
|
187
|
+
These are the classes where the most unclaimed bounties still exist:
|
|
188
|
+
|
|
189
|
+
| Vuln Class | Coverage Today | Gap |
|
|
190
|
+
|-----------|---------------|-----|
|
|
191
|
+
| **Protocol-level economic attacks** | No tool | Requires modeling token economics + adversary incentives; needs human + LLM |
|
|
192
|
+
| **Cross-chain replay / chain confusion** | Partial (chain-id checks) | Full message lifecycle across heterogeneous VMs is unsolved |
|
|
193
|
+
| **Governance takeover paths** | No tool | Requires modeling token distribution + quorum + timelock |
|
|
194
|
+
| **Oracle manipulation profitability** | No tool | Needs real price data + gas modeling to determine if attack is profitable |
|
|
195
|
+
| **Composability bugs** (3+ protocols interacting) | No tool | State space explosion; current fuzzers handle 1–2 contracts well |
|
|
196
|
+
| **Upgrade path correctness** | Slither partial | Full storage slot diff + initializer audit is manual |
|
|
197
|
+
| **MEV extraction paths** | No tool | Block construction awareness required |
|
|
198
|
+
| **Stale oracle price window** | Slither pyth/chronicle detectors | Only covers specific oracle integrations; Chainlink staleness widely missed |
|
|
199
|
+
| **Permit signature abuse across chains** | No tool | EIP-2612 permits are chain-specific but many protocols assume they aren't |
|
|
200
|
+
| **Fee accumulation / rounding attacks** | No tool | Requires modeling fee math over many transactions |
|
|
201
|
+
|
|
202
|
+
**Build opportunity:** The composability bug class (multi-protocol interaction fuzzing with forked state) has the highest potential payout-per-find ratio and the weakest tooling coverage.
|
|
203
|
+
|
|
204
|
+
---
|
|
205
|
+
|
|
206
|
+
## 6. Recommended Toolchain Stack
|
|
207
|
+
|
|
208
|
+
```
|
|
209
|
+
Recon → Slither (auto-scan, flag high-confidence issues)
|
|
210
|
+
→ Slither printers: call-graph, inheritance, cfg
|
|
211
|
+
Fuzzing → Foundry invariant tests (CI integration)
|
|
212
|
+
→ Echidna (deep campaign for high-value targets)
|
|
213
|
+
Simulation → Anvil (fork mainnet state, simulate attacks)
|
|
214
|
+
LLM Review → Claude on business logic, governance, economic attack surface
|
|
215
|
+
Reporting → Slither --checklist --markdown-root for automated findings
|
|
216
|
+
```
|