"What are the three modes of a smart contract security harness?"	"Detect (find vulnerabilities), Patch (generate fixes), Exploit (build and run PoC exploits). EVMbench evaluates agents across all three independently — you can score well on Detect and poorly on Exploit."	c2a::s11::recall
"What is EVMbench and what does it cover?"	"Benchmark from OpenAI/Paradigm. 117 curated vulnerabilities across 40 EVM repositories. Spans reentrancy, integer overflow, access control, flash loan, and business logic classes. Scores Detect/Patch/Exploit modes independently."	c2a::s11::recall
"Name the three reasons LLMs alone fail on smart contracts."	"(1) Hallucinations on EVM semantics (overflow wraps at 2^256, transfer=2300 gas — model applies Python/JS intuitions to opcode-precise semantics). (2) Context overflow on 5K-50K LOC codebases (compaction drops load-bearing storage vars). (3) False positives on benign patterns (flags every external call as reentrancy)."	c2a::s11::analysis
"Why is the LLM hallucination on Solidity systematic rather than random?"	"The model applies general-language intuitions (Python/JS semantics) to a domain where those intuitions mislead. EVM semantics are counter-intuitive: integer overflow wraps (doesn't throw), transfer forwards exactly 2300 gas, address(this).balance reads actual ether not accounting variable. The errors cluster around these specific semantic mismatches."	c2a::s11::analysis
"What is the harness detection pipeline (static + LLM)?"	"Source → static analysis (Slither/Mythril/Semgrep) → structured candidates → LLM semantic reasoning (intent + exploitability) → vulnerability hypothesis → cascaded verification → finding output. The LLM starts from structured candidates, NOT raw source."	c2a::s11::recall
"Why does the LLM reason from static-analysis candidates rather than raw source?"	"Shifts the LLM's job from 'find the bug from raw source' (hard, hallucination-prone) to 'is this candidate real and exploitable in context' (tractable, verifiable). Static tools do taint/pattern work; LLM does intent/economic reasoning. Each does what it's good at."	c2a::s11::analysis
"What are Heimdallr's three innovations and its headline metrics?"	"(1) Function-level code reorganization (minimize context). (2) Heuristic reasoning for business logic (domain scaffold). (3) Cascaded verification (eliminate FPs). Metrics: 92.45% detection rate, $2.31 per 10K LOC, 17/20 real-world attacks reconstructed (post-June 2025)."	c2a::s11::recall
"What is Heimdallr's function-level code reorganization and why does it matter?"	"Instead of feeding the LLM an entire contract (overflows context or forces lossy compaction), splits code into function-level units and feeds the model the relevant function + call-graph context (called functions, touched storage vars). Minimizes context overhead while preserving info needed for semantic reasoning."	c2a::s11::analysis
"What is cascaded verification and what does it achieve?"	"Every LLM-produced hypothesis passes through: static analysis re-check → test suite → formal verification where feasible. A finding is output only if it survives. Eliminates false positives BEFORE they reach the auditor — drives high precision."	c2a::s11::analysis
"Why are business-logic bugs the hardest class to detect?"	"No syntactic signature. Code is syntactically valid, passes all static checks, but is economically exploitable. The bug is not in any single line — it's in the relationship between code and the protocol's intended invariants. Static analysis checks patterns, not intent. Example: Beanstalk governance attack ($182M, flash-loan-funded proposal)."	c2a::s11::analysis
"What is invariant extraction and how does it find logic bugs?"	"Strategy: identify what the protocol intends to be always-true (invariants), then check whether code enforces them. Pipeline: read source+docs → LLM extracts candidate invariants → formalize each to a checkable property → verify (fuzz/symbolic/formal) → violation found → LLM confirms exploitable? → confirmed finding."	c2a::s11::application
"How does the harness distinguish a critical logic finding from a theoretical one?"	"LLM confirms whether the invariant violation is economically exploitable. Flash-loan reachable in a single transaction = CRITICAL. Requires attacker to already own 51% of token supply = theoretical, downgraded. The distinction is economic reachability, not just code correctness."	c2a::s11::application
"What is a flash loan and why does it change the threat model?"	"A borrower borrows any amount with no collateral, provided the loan is repaid in the same transaction. Collapses the constraint that an attacker needs capital — they act as a whale for one transaction. Any protocol whose safety depends on 'attacker cannot afford to manipulate the market' is vulnerable if a flash loan substitutes for capital."	c2a::s11::analysis
"How does the harness detect flash loan attack paths?"	"Traces data flow from external price/oracle sources through to state-changing operations. Checks if the price source is manipulable in a single transaction. Spot DEX price = manipulable (flash loan can swap, move price, exploit, swap back). TWAP over N blocks = resistant (manipulation can't persist across blocks in one tx)."	c2a::s11::application
"What are the three phases of a PoC exploit?"	"(1) Setup: fork mainnet at block N, fund attacker, deploy prerequisites (malicious token, fake oracle). (2) Attack transaction: execute the exploit (reentrancy callback / flash-loan sequence / governance vote). (3) Verification: assert balance delta, calculate $ impact at fork-block prices. If assertion fails, exploit didn't work → downgrade/retract."	c2a::s11::recall
"Why run PoCs on forked mainnet rather than a clean local chain?"	"Forked mainnet reproduces the target's actual storage, real token contracts it integrates with, and actual oracle prices at the forked block. Many exploits depend on precise on-chain state — DEX pool liquidity, governance proposal queue, oracle's last reported price. A clean chain does not reproduce these."	c2a::s11::analysis
"What structured evidence does an exploit finding include?"	"Transaction hash, block number (the forked block — state at which exploit is valid), state before/after (storage slots + balances), call trace (internal + external call sequence), economic impact (token amounts + dollar value at fork prices), PoC file (reproducible with forge test)."	c2a::s11::recall
"What are the four cascaded verification gates for a patch?"	"Gate 1: Slither/Mythril on patched code — original finding gone, no new findings. Gate 2: Test suite / property tests — all pass (behavior preserved). Gate 3: Exploit PoC re-run — exploit now FAILS (attack path closed). Gate 4: Formal verification — property holds (where expressible). Fail any gate → reject/regenerate."	c2a::s11::recall
"What is the 'patch that fixes the PoC not the bug' trap, and how is it caught?"	"Patch addresses the specific PoC but leaves the underlying vulnerability. PoC used 10 ETH deposit; patch rejects exactly 10 ETH. PoC fails (gate 3 passes) but vulnerability remains (50 ETH still exploits). Caught by static-analysis re-check (gate 1 still flags pattern) and formal verification (gate 4 shows invariant violable). Exploit re-run alone is INSUFFICIENT."	c2a::s11::analysis
"Why is the human approval gate non-negotiable for patch deployment?"	"Smart contracts are immutable once deployed (upgradeable proxies aside). A buggy patch on mainnet causes irreversible losses. The four automated gates check what is automatable; some properties (does this patch change economic behavior in a way the team intends?) require human judgment. The harness generates patches; a human approves them. The harness does NOT deploy."	c2a::s11::application