Crypto/Blockchain Attack Surface — Full Analysis for AllySec Agent Integration
Purpose
Assess what the allysec-agent can and cannot test in the crypto/blockchain domain, map the professional tooling and methodology landscape, and identify integration points for building a competitive AI-powered crypto security testing capability.
1. Current AllySec Crypto Capability: Zero
After auditing every tool, skill, Kali package, and attack guide in the agent codebase:
| Layer | AllySec Has | Gap |
|---|---|---|
| Smart contract SAST | Nothing | No Slither, Mythril, Aderyn, Foundry, semgrep-solidity |
| ZK circuit analysis | Nothing | No circomspect, Ecne, Picus, halo2-analyzer |
| Binary node RE | radare2/rizin (manual) | No Ghidra MCP, no automated decompiler integration |
| Fuzzing | AFL++, Honggfuzz (Kali) | No Foundry/Echidna for EVM, no cargo-fuzz for Rust nodes |
| Crypto protocol review | Nothing | No domain-specific attack guides for consensus, P2P, key mgmt |
| Blockchain regtest | Nothing | Can't spin up local nodes for exploit PoC validation |
| Wallet security | Nothing | No wallet extraction, no blind-signing detection |
| API testing (bridges) | Generic REST/GraphQL | No cross-chain message verification testing |
What we CAN test today with existing tools:
- Block explorers: XSS, CSRF, auth bypass (Client-Side/Web App Executor)
- Wallet APIs: REST auth issues (Auth/API Executor)
- Validator admin panels: RCE if web-based (Web App Exploit Hunter)
- Secrets in repos: TruffleHog/gitleaks (source-code-auditor)
- Docker escapes on containerized nodes (Post-Exploitation Executor)
- Dependency confusion in crypto project repos (source-code-auditor)
- SSRF in JSON-RPC endpoints (Server-Side Executor)
These are all traditional web/API/infra tests — useful for peripheral attack surface but not for finding protocol-level bugs.
2. The 6 Crypto Attack Surface Domains
Domain 1: Smart Contract (EVM, Solana, Move, CosmWasm)
Tools that exist in the wild:
| Tool | Type | Lang | Open Source | CLI | Stars | LLM-Integrable |
|---|---|---|---|---|---|---|
| Slither | Static analysis | Solidity/Vyper | Yes (AGPL) | Yes | 5.5k+ | Yes |
| Mythril | Symbolic exec | EVM bytecode | Yes (MIT) | Yes | 4k+ | Yes |
| Echidna | Property fuzzer | Solidity | Yes (AGPL) | Yes | 2.8k+ | Yes |
| Foundry (forge) | Test framework + fuzzer | Solidity | Yes (MIT/Apache) | Yes | 8.5k+ | Yes |
| Hardhat | Dev framework | Solidity | Yes (MIT) | Yes | 7k+ | Yes |
| Certora Prover | Formal verification | Solidity | No (proprietary) | Yes | N/A | Partial (requires Certora account) |
| Manticore | Symbolic exec | EVM/native | Yes (AGPL) | Yes | 3.8k+ | Yes |
| Aderyn | Static analysis | Solidity | Yes (MIT) | Yes | 1.2k+ | Yes |
| 4nalyzer | Report generator | Solidity | Yes | Yes | 500+ | Yes |
| Halmos | Symbolic testing | Solidity | Yes | Yes | 500+ | Yes |
| MedusaFuzz | Property fuzzer (Echidna successor) | Solidity | Yes | Yes | 400+ | Yes |
| HEVM | Symbolic EVM (Foundry) | EVM | Yes | Yes | Bundled | Yes |
| Scribble | Runtime verification | Solidity | Yes | Yes | 300+ | Yes |
| Surya | Code visualization | Solidity | Yes | Yes | 1k+ | Yes |
| solc-select | Compiler version mgmt | Solidity | Yes | Yes | 200+ | Yes |
Non-EVM Tools:
| Tool | Target | Lang |
|---|---|---|
| Move Prover | Aptos/Sui Move | Formal verification built into language |
| Soteria | Solana Anchor/Rust | Static analysis |
| cargo-audit | Rust (CosmWasm, Solana, node clients) | Dependency vuln scanning |
| cargo-geiger | Rust | Unsafe code detection |
Integration assessment: All major Solidity tools are Python or Rust with clean CLIs. Slither, Echidna, Foundry, Aderyn can be pip install'd into the Kali container and invoked via KaliTool. Certora requires API access. Halmos and HEVM ship with Foundry.
Domain 2: ZK Circuit Analysis
Tools (the smallest, most specialized ecosystem):
| Tool | Input | What It Does |
|---|---|---|
| circomspect | Circom | Static analyzer for circom circuits — finds common constraint bugs |
| Ecne | R1CS | Under-constrained circuit detection via matrix rank analysis |
| Picus | Circom | Automated detection of under-constrained signals |
| QED | Circom | R1CS constraint verification |
| halo2-analyzer | Halo2 (Rust) | Constraint completeness checker (early stage) |
| Vulcan | Circom | Circom linter/static analysis |
| circom-ecdsa-poc | Circom | Template verification for ECDSA circuit correctness |
Key insight: ZK circuit analysis tooling is 3-5 years behind smart contract tooling. The Orchard bug was found by a human (Taylor Hornby) with AI assistance (Opus 4.8), NOT by an automated tool. This is the frontier.
What Taylor had that we'd need to replicate:
- Opus 4.8 or equivalent frontier model with ZK math reasoning
- Custom prompt harness targeting Halo2 constraint completeness
- Local Zcash regtest for exploit PoC validation
- Ability to parse Rust + ZK circuit DSLs (Halo2 uses Rust macros)
- Cryptographic reasoning: "input must be on the curve" — soundness property
Domain 3: Blockchain Protocol & P2P
Tools:
| Tool | Target | What It Does |
|---|---|---|
| Kurtosis | Multi-client | Deterministic devnets (Ethereum multi-client) |
| Antithesis | Deterministic sim | Distributed system property testing |
| ethereum/tests | EVM exec spec | Consensus test vectors |
| hive | Ethereum clients | Client compliance testing |
| assertoor | eth2 | Beacon chain testing framework |
| chaos-mesh | Kubernetes | Consensus chaos testing |
| Substrate test suite | Polkadot/Substrate | Framework-level testing |
| Shadow | Network sim | P2P network simulation |
| eth-fuzzer | devp2p | Ethereum P2P fuzzer |
| Solana test validator | Solana | Local test validator |
Attack classes that need covering:
- Eclipse attacks (P2P isolation)
- Erebus attacks (BGP hijacking of P2P)
- Timejacking (NTP manipulation)
- Balance attacks (equivocation)
- MEV-Boost/PBS relay manipulation
- Chain reorganization depth exploitation
Domain 4: Bridge & Cross-Chain
No specialized automated tools exist for bridge security. All bridge audits are manual review + bespoke testing. The attack surface:
- Message verification: Do validators/threshold signers properly check source chain state?
- Proof validation: SPV proofs, ZK proofs, oracle attestations — is the proof verifier sound?
- Relayer economics: Can relayers be griefed, bribed, or DOS'd?
- Upgrade mechanisms: Can the bridge multisig be compromised?
Major bridge hacks ($3.3B+ stolen since 2021):
- Wormhole ($326M) — Solana-side signature verification bypass
- Ronin ($624M) — 5/9 validator compromise
- Nomad ($190M) — spoofed root hash accepted any message
- BNB Bridge ($586M) — fake IAVL Merkle proof
- Poly Network ($611M) — keeper privilege abuse
Domain 5: Wallet & Key Management
Tools:
| Tool | Target | What It Does |
|---|---|---|
| eth-hd-wallet | BIP32/BIP39 | Key derivation audit |
| mnemonic-check | BIP39 | Entropy quality assessment |
| foundry cast wallet | Ethereum | Vanity address, key operations |
| MetaMask Snaps audit | MetaMask | Snap security review |
Attack classes:
- Transaction simulation spoofing (blind signing)
- Address poisoning
- Nonce reuse (ECDSA r-value recovery)
- BIP39 entropy weakness
- WalletConnect bridge attacks
- MPC/TSS side channels
Domain 6: Node Implementation (Rust/Go/C++)
Tools:
| Tool | Target | What It Does |
|---|---|---|
| cargo-fuzz | Rust | Coverage-guided fuzzing |
| cargo-audit | Rust | Advisory DB check |
| go-fuzz | Go | Coverage-guided fuzzing |
| AFL++ | C/C++/binary | Mutational fuzzing |
| Honggfuzz | Binary | Hardware-assisted fuzzing |
| radare2/rizin | Binary | Reverse engineering |
| Ghidra | Binary | NSA decompiler (Java, needs MCP server) |
Node attack classes:
- P2P message parsing bugs
- JSON-RPC auth bypass / SSRF
- Database corruption during state sync
- Chain reorganization handling bugs
- Mempool DOS (tx flooding, large txs)
3. Professional Crypto Audit Methodologies
Consensus Auditor Workflow (Across 15 Firms)
Based on public methodology docs from Trail of Bits, OpenZeppelin, Spearbit, Code4rena, Zellic, Consensys Diligence, Halborn, CertiK, Quantstamp, Veridise, and others:
Phase 1: Scoping & Threat Modeling (5-15% of budget)
- Define system boundaries and invariants
- Build threat model (STRIDE/asset-flow)
- Identify highest-risk components
- Agree on severity classification (Critical/High/Medium/Low/Informational)
- Set test coverage targets
Phase 2: Automated Analysis (10-20% of budget)
- Run Slither + detectors against all contracts
- Run Mythril/Halmos for symbolic analysis
- Run Foundry fuzz tests with invariant checks
- Run Echidna/Medusa property fuzzing
- Run Surya for dependency/architecture visualization
- Diff against known vulnerable patterns
Phase 3: Manual Review (50-65% of budget)
- Line-by-line review of critical contracts
- Business logic analysis against spec
- Access control review
- Upgrade proxy pattern review
- Economic attack simulation (MEV, oracle, flash loans)
- Cross-contract interaction analysis
- Integration point review (bridges, oracles, keepers)
Phase 4: Exploit PoC Development (10-15% of budget)
- Reproduce high-severity findings
- Deploy to local fork (foundry/anvil)
- Write executable PoCs
- Validate on mainnet-fork test environment
- Estimate exploit profitability/cost
Phase 5: Reporting & Fix Review (5-10% of budget)
- Detailed findings with PoC code
- Severity classification with rationale
- Fix recommendations with code examples
- Fix review round (retest after remediation)
- Executive summary for non-technical stakeholders
Tool Usage Ratios (Typical)
| Phase | % Automated | % Manual |
|---|---|---|
| Scoping | 5% | 95% |
| Automated Analysis | 85% | 15% |
| Manual Review | 10% | 90% |
| PoC Development | 30% | 70% |
| Reporting | 20% | 80% |
Code4rena Contest Structure
- 2-8 day competitions
- 30-200 wardens competing
- Prize pool: $20K-$500K+
- Judges grade findings: High (unique + valuable), Medium, QA, Gas
- Gas optimization is a separate category (EVM-specific)
- Known issues list prevents duplicate reporting
- M-of-N multisig for sponsor/judge decision
Trail of Bits Methodology (Most Thorough Publicly Documented)
- Threat Modeling: Identify invariants — properties that must always hold
- Property-Based Testing: Encode invariants in Echidna — fuzz for violations
- Static Analysis: Slither + custom detectors
- Symbolic Execution: Manticore for path coverage
- Manual Review: Each auditor reviews every line
- Pairing: Junior + senior auditor on each component
- Tool-Augmented Review: Custom Python scripts for pattern detection
- Exploit PoC: Reproduce all Critical/High findings
- Fix Review: Full re-review after remediation
Spearbit Distributed Audit Model
- Lead auditor (senior) + 2-3 independent reviewers
- Reviewers work independently, then cross-review each other's findings
- "Red team" approach: each reviewer tries to break, not review
- Findings consolidated by lead
- Security researchers vetted through Spearbit's network
4. Complete Vulnerability Taxonomy by Domain
Smart Contract (EVM/Solidity)
Tier 1 — Found by Static Analysis (AI-Auditable: 5/5)
| Bug Class | Tool Detection | Real Example | Lost |
|---|---|---|---|
| Reentrancy (single-function) | Slither, Mythril, Aderyn | The DAO (2016) | $150M |
| Reentrancy (cross-function) | Slither (partial) | Cream Finance (2021) | $130M |
| Unchecked return value | Slither | King of the Ether | N/A |
| tx.origin auth | Slither, Mythril | Multiple DEX drainers | $10M+ |
| Unprotected selfdestruct | Slither | Parity multisig freeze | $300M frozen |
| Incorrect inheritance order | Slither | Multiple | Varied |
| Uninitialized storage pointer | Slither | Multiple wallets | Varied |
| Access control (missing onlyOwner) | Slither, 4nalyzer | Multiple | Varied |
| Floating pragma | Slither, Aderyn | Determinism risk | N/A |
| Integer overflow (pre-0.8) | Slither, Mythril | BeautyChain (BEC) | $900M |
Tier 2 — Found by Manual Review + Fuzzing (AI-Auditable: 3/5)
| Bug Class | Detection Method | Real Example | Lost |
|---|---|---|---|
| Oracle manipulation | Manual + Foundry fork-test | Mango Markets (2022) | $114M |
| Flash loan attack chain | Manual + economic sim | Euler Finance (2023) | $197M |
| Read-only reentrancy | Manual (Slither partial) | Curve/Vyper (2023) | $70M |
| Governance attacks | Manual threat model | Beanstalk (2022) | $182M |
| Upgrade proxy storage collision | Manual + OpenZeppelin plugin | Multiple | Varied |
| ERC-4626 vault inflation | Manual + Foundry fuzz | Multiple DeFi | $10M+ |
| MEV sandwich/liquidation | Manual + mempool analysis | Ongoing | Billions/year |
| Permit signature phishing | Manual | Multiple wallet drains | $100M+ |
Tier 3 — Protocol-Genesis (AI-Auditable: 2/5)
| Bug Class | Detection Method | Real Example | Lost |
|---|---|---|---|
| Fee-on-transfer incompatibility | Manual | Multiple AMMs | $5M+ |
| Rounding/precision loss | Formal verification + manual | Multiple DEX LPs | $50M+ |
| Weird ERC-20 behaviors | Manual audit | Multiple | Varied |
ZK Circuit Vulnerabilities
| Bug Class | Detection | Real Example | Impact |
|---|---|---|---|
| Under-constrained signals | Circomspect, Picus, Ecne | Zcash Orchard (2026) | Unlimited counterfeit |
| Unconstrained signal assignments | Circomspect | Multiple circom audits | False proofs |
| R1CS rank deficiency | Ecne | Theoretical (pre-Ecne) | Soundness loss |
| Missing input validation in circuits | Manual | Zcash Sprout (2019, fixed) | Infinite ZEC |
| Trusted setup compromise | Manual + ceremony audit | Aztec trusted setup | Privacy loss |
| Elliptic curve point validation | Manual math review | Zcash Orchard (2026) | Counterfeit |
| Halo2 lookup argument bugs | Manual (new) | Theoretical | Soundness loss |
| Noir/Circom language-level bugs | Manual | Aztec Connect | False proofs |
Key insight for AI-assisted ZK auditing: The Orchard bug was found because Taylor specifically checked: "Is every constraint enforced? Are there witnesses that could be arbitrary values?" An LLM can be prompted to ask these exact questions. The methodology is:
- Parse the constraint system (Circom/Halo2/Noir)
- For each signal: is it constrained? By what? Is the constraint sufficient?
- For EC operations: is the point validated to be on the curve?
- For arithmetic: are all intermediates constrained?
- For public inputs: is the circuit bound to the correct instance?
Consensus & P2P Vulnerabilities
| Bug Class | Detection | Real Example |
|---|---|---|
| Eclipse attack | Network sim (Shadow) | Bitcoin (2015), Ethereum (2022) |
| Long-range attack (PoS) | Formal model | Theoretical on weak subjectivity chains |
| Timejacking | NTP audit | Bitcoin (theoretical) |
| Finality reversion | Consensus testing | Ethereum Gasper (2018 spec bug) |
| MEV relay manipulation | Manual review | Multiple relays |
| RANDAO bias | Formal analysis | Ethereum RANDAO (known bias, accepted) |
| Uncle/nephew equivocation | P2P monitoring | Ethereum PoW era |
| Empty block proposal | Observability | Ethereum (3-8% of slots) |
Node Implementation (Rust/Go/C++)
| Bug Class | Detection | Real Example |
|---|---|---|
| P2P message parsing | Fuzzing (cargo-fuzz, go-fuzz, AFL++) | Multiple nodes |
| JSON-RPC SSRF/IDOR | Manual + web testing | OpenEthereum, Geth |
| State sync corruption | Manual + fuzzing | Multiple nodes |
| Memory/CPU DOS | Fuzzing + profiling | All major nodes |
| Config exposure (debug APIs) | Scanning | Geth debug API, Prysm |
| Chain reorg handling | Consensus testing | Multiple clients |
Cryptographic
| Bug Class | Detection | Real Example |
|---|---|---|
| Nonce reuse (ECDSA: r-value recovery) | Sherlock-style TX scanning | Bitcoin (2013), Ethereum (various) |
| Weak randomness (PRNG predictability) | Entropy analysis | Blockchain Cuties, Poly Network |
| BLS signature aggregation bug | Formal verification | Ethereum eth2 spec |
| VRF manipulation | Manual review | Chainlink VRF |
| Merkle tree second preimage | Manual + formal | Solana, multiple bridges |
5. What We'd Need to Build for Full Crypto Coverage
Phase 1: Install Tools in Kali Container (Day 1)
bash
# Smart contract
pip3 install slither-analyzer crytic-compile
pip3 install mythril
pip3 install echidna
# Foundry (Rust binary)
curl -L https://foundry.paradigm.xyz | bash && foundryup
# Solidity compilation
pip3 install solc-select && solc-select install
# Aderyn (Rust binary)
cargo install aderyn
# Node/binary fuzzing (already partially in Kali)
# cargo-fuzz, go-fuzz, AFL++
# ZK circuit analysis
# circomspect: npm install -g circomspect
# Picus: cargo install picus
# Ecne: cargo install ecneEffort: ~1 hour, all installable. Kali container has pip3, npm, cargo.
Phase 2: Create Crypto Attack Methodology Guides (~30 guides)
Following the same pattern as our 151 existing attack guides, create quickstarts for:
Category A — Smart Contract Auditing (12 guides):
- reentrancy (single, cross-function, cross-contract, read-only)
- access-control (Ownable, proxy, multisig)
- oracle-manipulation (TWAP, VWAP, Chainlink)
- flash-loan-attacks
- upgrade-proxy-patterns (UUPS, Transparent, Beacon)
- integer-precision-loss
- wei
- MEV-analysis (sandwich, liquidation, arbitrage)
- governance-attacks
- permit-signature-phishing
- erc20-erc721-edge-cases
- vyper-vulnerabilities
Category B — ZK Circuit Analysis (6 guides):
- circom-constraint-analysis (under-constrained signal detection)
- halo2-constraint-completeness (the Orchard bug class)
- trusted-setup-security
- noir-circuit-auditing (Aztec DSL)
- groth16-soundness
- plonk-plonky2-constraint-review
Category C — Consensus & P2P (5 guides):
- eclipse-attack-testing
- p2p-fuzzing-methodology
- consensus-finality-testing
- mev-boost-pbs-audit
- node-configuration-hardening
Category D — Cryptographic Review (4 guides):
- ecdsa-nonce-reuse-detection
- bls-aggregation-verification
- mpc-tss-key-generation-audit
- randomness-entropy-assessment
Category E — Bridge & Cross-Chain (3 guides):
- cross-chain-message-verification
- bridge-relayer-security
- light-client-proof-validation
Phase 3: Build Crypto Sub-Agent Type
Following our existing Pattern (Injection Executor, Auth Executor, etc.):
CryptoAudit Executor
├── Phase 1: Scope & Threat Model
│ ├── Load project codebase (clone repo)
│ ├── Run solc-select / cargo / go build
│ ├── Map contract dependencies (Surya)
│ ├── Identify invariants from docs/spec
│ └── Build attack surface map
├── Phase 2: Automated Scan
│ ├── Slither with all detectors
│ ├── Aderyn Rust analysis
│ ├── Mythril symbolic execution
│ ├── Circomspect (if ZK)
│ └── cargo-audit / npm audit (deps)
├── Phase 3: LLM-Guided Manual Review
│ ├── Load attack methodology guide for each finding class
│ ├── Per-contract: identify violation of invariants
│ ├── Cross-contract: trace call chains
│ └── Economic simulation (flash loan, MEV)
├── Phase 4: Exploit PoC
│ ├── Deploy to Foundry local fork
│ ├── Write executable PoC
│ └── Validate exploit profitability
└── Phase 5: Report
├── Findings with severity
├── PoC code blocks
├── Fix recommendations
└── Executive summaryPhase 4: Wire Into Existing Infrastructure
Following the same pattern as Points A-D from the 151 guide wiring:
| Injection Point | Crypto Equivalent |
|---|---|
| A: Script execution | KaliTool → slither, mythril, foundry, echidna — results enriched with crypto methodology guide |
| B: Sub-agent preloading | CryptoAudit Executor gets 5-8 crypto attack quickstarts preloaded (~3K lines) |
| C: Skill view | /skill view pentest attacks crypto shows crypto attack categories |
| D: Pipeline | Pipeline(action="attack-plan", techStack="solidity,foundry,openzeppelin") loads crypto guides |
Phase 5: Crypto-Specific AttackGrader Integration
Map crypto severity differently from web:
- Critical: Direct fund loss, infinite mint, proof forgery, bridge bypass
- High: Fund loss with preconditions, unauthorized state changes
- Medium: Gas griefing, oracle staleness, information leak
- Low: Code style, gas optimization opportunities
- Informational: Best practice deviations without direct impact
Phase 6: Ghidra MCP Server (Node Binary Analysis)
Replicate Claroty Team82's setup:
- MCP server wrapping Ghidra's headless API
- Auto-import binary, auto-analyze, expose:
list_functions,decompile_function,xrefs_to,get_strings - Combine with crypto node-specific methodology guides for P2P message parsing, consensus logic, key management code paths
6. Priority Ranking: Where to Start
Ranked by (impact × feasibility × competitive advantage from AI):
| Rank | Domain | Why | Effort | AI Advantage |
|---|---|---|---|---|
| 1 | Smart Contract Auditing (Solidity) | Most mature tooling, largest attack surface, best AI-auditability | Medium | Very High — Slither/Foundry are CLI-invokable, LLMs excel at Solidity |
| 2 | ZK Circuit Analysis | Frontier domain. Taylor Hornby just proved AI-assisted ZK audit finds protocol-critical bugs | High | Very High — domain where humans are scarce, AI fills gap |
| 3 | Node Implementation Review | Existing SAST/fuzzing adapts well. Most nodes are Rust/Go | Medium | Medium — LLMs good at code review, fuzzing is classical |
| 4 | Bridge/Cross-Chain | $3.3B+ lost. No automated tools exist — manual+AI is the only option | High | Medium — requires cross-chain reasoning |
| 5 | Consensus/P2P | Very specialized, few practitioners | Very High | Low — needs live testnets, network simulation |
| 6 | Wallet/Key Management | Fragmented surface, many wallets | Low | High — LLMs good at traditional app sec |
7. What Makes This Different from Web Pentesting
Crypto security testing has fundamental differences from web app pentesting:
| Dimension | Web Pentesting | Crypto Security Testing |
|---|---|---|
| Primary target | HTTP servers, web apps | Source code, binary nodes, consensus protocols |
| Bug classes | Injection, XSS, auth bypass | Reentrancy, under-constrained circuits, roundig errors |
| Exploit validation | HTTP requests | Local blockchain fork + transaction simulation |
| Severity | Data breach, RCE | Direct fund loss, infinite mint, protocol halt |
| Tool ecosystem | Mature (Burp, nmap, sqlmap) | Maturing (Foundry, Slither, Echidna) |
| Manual vs Auto | 60/40 | 80/20 (manual review dominant) |
| Exploit verification | Can re-exploit live (with auth) | Need local fork to avoid $ loss |
| Audit deliverable | Vulnerability report | PoC + fix + gas optimization suggestions |
The intelligence layer (attack methodology guides, sub-agent specialization, pipeline routing) we've built for web pentesting transfers directly — but the tools and domain knowledge are completely different.
8. Bottom Line
We have zero crypto capability today. But we have the entire agent architecture (sub-agents, pipeline, attack guides, skill suites, Kali tool routing) that we can populate with crypto content. The Claroty Team82 + Taylor Hornby results validate that AI-assisted security testing is extremely effective for crypto — potentially more so than for web, because:
- Code is open source (white-box review is comprehensive)
- Bug classes are often logical (perfect for LLM reasoning)
- Few human practitioners exist (AI fills the talent gap)
- Exploit validation is deterministic (blockchain state transitions)
- Impact is directly measurable ($ amount at risk)
The build plan is clear: install tools, write methodology guides, create sub-agent, wire into pipeline. The only question is which domain to start with.