{
  "module": "S12 — Advanced Smart Contract Harnesses",
  "course": "2A — Building AI Harnesses for Cybersecurity",
  "version": "1.0.0",
  "duration_minutes": 35,
  "total_questions": 15,
  "bloom_distribution": {
    "target": "20% recall / 40% application / 40% analysis-design",
    "actual": { "recall": 3, "application": 6, "analysis": 6 }
  },
  "passing_score_percent": 70,
  "questions": [
    { "id": "Q01", "bloom": "recall", "type": "multiple_choice", "prompt": "What are the three EVMbench scores?", "options": ["Precision, Recall, F1", "Detect recall, Patch quality, Exploit success rate", "Accuracy, Speed, Cost", "Coverage, Depth, Confidence"], "answer_index": 1, "rationale": "EVMbench scores Detect recall (how many of 117 found), Patch quality (fix removes bug + preserves behavior), and Exploit success rate (working PoC on forked mainnet). All three measured independently." },
    { "id": "Q02", "bloom": "recall", "type": "multiple_choice", "prompt": "What is the 92% vs 34% gap?", "options": ["EVMbench pass rate for two agent versions", "Purpose-built agents achieve ~92% detection on DeFi-specific classes vs ~34% for GPT-5.1 (general LLM baseline). Nearly 3x — the quantified value of domain-specific tooling", "Slither vs Mythril detection rates", "Solana vs EVM detection rates"], "answer_index": 1, "rationale": "Purpose-built agents hit ~92% on DeFi-specific vulnerability classes; general LLMs (GPT-5.1) hit ~34%. The gap is structural — DeFi classes require domain knowledge general LLMs lack." },
    { "id": "Q03", "bloom": "recall", "type": "multiple_choice", "prompt": "What are the five audit severity levels?", "options": ["P0, P1, P2, P3, P4", "Critical, High, Medium, Low, Informational", "Blocker, Major, Minor, Trivial, Note", "Sev1, Sev2, Sev3, Sev4, Sev5"], "answer_index": 1, "rationale": "Critical (funds at immediate risk), High (funds at risk under conditions), Medium (logic error, no immediate loss), Low (best-practice violation), Informational (optimization/style). Matches Trail of Bits/Consensys/OpenZeppelin format." },
    { "id": "Q04", "bloom": "application", "type": "multiple_choice", "prompt": "A harness scores 88% Detect, 25% Patch, 20% Exploit on EVMbench. What is your assessment?", "options": ["It's a strong audit harness — 88% Detect is excellent", "It's a detection engine, not an audit harness. It finds bugs but cannot fix or exploit them. The Patch and Exploit pipelines need major work before it's a genuine audit tool", "It's broken — all three scores should match", "It's acceptable if the 88% Detect is on Critical-severity bugs only"], "answer_index": 1, "rationale": "A harness scoring high on Detect but low on Patch and Exploit is a detection engine, not an audit harness. All three scores must be reported together. 80% across all three would be a genuine audit tool." },
    { "id": "Q05", "bloom": "application", "type": "multiple_choice", "prompt": "Your team is auditing a Solana Anchor program. You run Slither on it. What went wrong?", "options": ["Nothing — Slither supports Solana", "Slither does not analyze Rust/Anchor code. The harness needs Solana-specific tools: Anchor constraint checking, custom Semgrep rules for Rust, solana-security-txt", "The Solana RPC endpoint is misconfigured", "Slither needs a newer version"], "answer_index": 1, "rationale": "Slither and Mythril are EVM-only. Solana requires adapted tools: Anchor #[derive(Accounts)] constraint checking, custom Semgrep for Rust/Anchor patterns, and bankrun/solana-test-validator for PoCs." },
    { "id": "Q06", "bloom": "application", "type": "multiple_choice", "prompt": "An Anchor program's #[derive(Accounts)] struct omits a has_one constraint on a vault account. What vulnerability class and severity?", "options": ["Integer overflow, medium", "Account confusion — the program may accept a non-vault account. Critical if it allows value transfer to/from the wrong account. The missing constraint is a silent security gap", "Missing signer check, high", "PDA misuse, critical"], "answer_index": 1, "rationale": "A missing has_one constraint in #[derive(Accounts)] is account confusion — the program does not verify the account relationship. An attacker can pass a malicious account satisfying the struct layout. Critical if it enables value transfer." },
    { "id": "Q07", "bloom": "application", "type": "multiple_choice", "prompt": "You are auditing a cross-chain bridge. Where is the primary attack surface?", "options": ["The token contract on Chain A", "The cross-chain verification protocol — how Chain B knows Chain A locked assets. Signature verification, message passing, relayer trust, wrapped-asset accounting", "The UI of the bridge", "The gas pricing on Chain B"], "answer_index": 1, "rationale": "Bridge security is about the verification protocol, not a single contract. The attack surface is the logic that lets Chain B mint wrapped assets based on Chain A's lock. Failure modes: signature flaws, message forgery, relayer fraud, unbacked minting." },
    { "id": "Q08", "bloom": "application", "type": "multiple_choice", "prompt": "The LLM triage assigns 'Medium' severity to a finding where a flash loan can drain the vault in one transaction. What should happen?", "options": ["Ship the report with Medium severity", "Human-confirm before shipping. The harness severity is a DRAFT; the auditor's is final. A flash-loan-reachable drain is Critical (funds at immediate risk), not Medium. The LLM under-rated it", "Downgrade to Low — flash loans are theoretical", "Run more benchmarks before deciding"], "answer_index": 1, "rationale": "Every severity is human-confirmed before the report ships. The harness's severity is a draft. A flash-loan-reachable vault drain is Critical (funds at immediate risk, exploitable now). The LLM under-rated it; the auditor corrects it to Critical." },
    { "id": "Q09", "bloom": "application", "type": "multiple_choice", "prompt": "Your audit firm publishes '92% Detect on EVMbench' but no Patch or Exploit scores. What anti-pattern is this?", "options": ["The tool-dump report", "Reporting only Detect recall — hides weaknesses in Patch and Exploit pipelines. Clients cannot assess whether the harness can actually fix or exploit what it finds", "Severity inflation", "Scope creep"], "answer_index": 1, "rationale": "Reporting only Detect recall hides that the harness may not be able to patch or exploit the bugs it finds. All three EVMbench scores must be reported together. 92% Detect with 30% Patch/Exploit is a detection engine, not an audit harness." },
    { "id": "Q10", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why does a general LLM (GPT-5.1) score only 34% on DeFi-specific vulnerability classes while a purpose-built agent scores 92%?", "options": ["The general LLM has a smaller context window", "DeFi classes (flash loans, oracles, rebase tokens, governance, liquidation) require domain knowledge general LLMs lack. Purpose-built agents embed it via heuristic scaffolds, tool integration, context engineering, and DeFi-specific cascaded verification", "The general LLM is slower", "The benchmark is biased toward purpose-built agents"], "answer_index": 1, "rationale": "The gap is structural. DeFi vulnerabilities are semantic and economic (not just syntactic patterns). Purpose-built agents embed domain knowledge via four mechanisms: heuristic scaffolds, tool integration, context engineering, and cascaded verification. A general LLM applies general-language intuitions that mislead on DeFi economics." },
    { "id": "Q11", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why is account confusion a vulnerability class with no EVM analog?", "options": ["The EVM does not have accounts", "The EVM's state tree is keyed by contract address, which is type-bound — you cannot pass 'the wrong contract' to a call. Solana passes accounts explicitly into instructions, so the program must verify each account's owner/type. Missing verification = account confusion", "Solana uses a different programming language", "The EVM is faster"], "answer_index": 1, "rationale": "The EVM has a single global state tree where contract addresses are type-bound. Solana's account-passing model means programs receive accounts as parameters and must explicitly verify owner/type. This creates account confusion (accepting the wrong account type) — a class with no EVM equivalent." },
    { "id": "Q12", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why is bridge auditing described as 'beyond single-contract analysis'?", "options": ["Bridges have more code than single contracts", "The security boundary is the cross-chain verification protocol, which spans two chains. Must model the message flow as a distributed-system state machine, trace asset flows on both chains, and check invariants (minted <= locked). A single-contract audit misses the protocol-level vulnerability", "Bridge contracts are written in multiple languages", "Bridges require more gas to audit"], "answer_index": 1, "rationale": "The bridge vulnerability is in the verification protocol — how Chain B knows Chain A locked assets. This spans both chains. The attacker targets the verification logic (signatures, messages, relayers), not a single contract. Single-contract analysis cannot model the distributed-system property." },
    { "id": "Q13", "bloom": "analysis", "type": "multiple_choice", "prompt": "Compare Detect recall and Exploit success rate. Why might a harness score high on Detect but low on Exploit?", "options": ["The benchmark is inconsistent", "Detection is pattern identification (easier). Exploitation is attack construction — building a working PoC that runs on forked mainnet. A harness can identify a reentrancy pattern but be unable to construct the malicious contract and transaction sequence that actually drains funds. Exploit requires different capabilities", "The harness has a bug", "Exploit mode is not scored fairly"], "answer_index": 1, "rationale": "Detection identifies the vulnerability pattern. Exploitation constructs a working attack — the malicious contract, the transaction sequence, the state setup. A harness can detect what it cannot exploit. This is why EVMbench scores them independently and why all three must be reported." },
    { "id": "Q14", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why is the audit report's scope section legally and operationally important?", "options": ["It's just a formality", "The scope defines what was reviewed AND, by omission, what was NOT. This is the legal boundary of the audit — a vulnerability in an out-of-scope contract is not the auditor's liability. Operationally, it tells the client which contracts are covered by the audit's findings and remediation", "It determines the price", "It's required by the SEC"], "answer_index": 1, "rationale": "Scope defines the audit's boundary — which contracts, which commit hash, which dates. By omission, it defines what was NOT audited. This is the legal and operational boundary: an out-of-scope vulnerability is not the auditor's liability. The scope makes the audit's coverage explicit and defensible." },
    { "id": "Q15", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why does pricing an AI-assisted audit capture the gap between cost ($2.31/10K LOC) and value (92% detection)?", "options": ["It shouldn't — price should equal cost plus margin", "The marginal cost of running the harness is low ($2.31/10K LOC), but the value delivered is high (92% detection finds bugs that could prevent million-dollar losses). Pricing for finding quality (not compute time) captures this gap. The client pays for the outcome, not the compute", "Because AI audits are always expensive", "To match traditional manual audit pricing"], "answer_index": 1, "rationale": "The audit-as-product positioning: the harness is the engine, the report is the product, benchmark scores are the proof. The marginal compute cost is low, but the delivered value (preventing catastrophic losses via 92% detection) is high. Pricing for finding quality captures the cost-value gap — the client pays for the outcome, not the compute time." }
  ]
}