Diagrams — Module S12: Advanced Smart Contract Harnesses

All Mermaid validated in Mermaid Live Editor. n8n JSON is structurally valid and importable.

Diagram 1 — EVMbench: The Three Scores

Type: Mermaid (flowchart) Purpose: Shows the three independent EVMbench scores and what each measures (and does not measure). A harness must report all three — Detect recall alone hides weaknesses.

flowchart TD
    BENCH["EVMbench evaluation<br/>117 vulnerabilities · 40 repositories"]

    DETECT["DETECT RECALL<br/>Of 117, how many found?"]
    DETECT_MEAS["Measures: can the harness find known bugs?"]
    DETECT_NOT["Does NOT measure: whether it can exploit or fix them"]

    PATCH["PATCH QUALITY<br/>Fix removes bug + preserves behavior?"]
    PATCH_MEAS["Measures: can the harness fix without breaking?"]
    PATCH_NOT["Does NOT measure: whether it can find them first"]

    EXPLOIT["EXPLOIT SUCCESS RATE<br/>Working PoC on forked mainnet?"]
    EXPLOIT_MEAS["Measures: can the harness build real PoCs?"]
    EXPLOIT_NOT["Does NOT measure: whether PoCs generalize to unseen bugs"]

    BENCH --> DETECT --> DETECT_MEAS --> DETECT_NOT
    BENCH --> PATCH --> PATCH_MEAS --> PATCH_NOT
    BENCH --> EXPLOIT --> EXPLOIT_MEAS --> EXPLOIT_NOT

    REPORT["Report all three together<br/>Detect-only = detection engine, not audit harness"]

    DETECT_NOT --> REPORT
    PATCH_NOT --> REPORT
    EXPLOIT_NOT --> REPORT

    style BENCH fill:#14141f,stroke:#5eead4,color:#5eead4
    style DETECT fill:#0d2818,stroke:#1e8449,color:#82e0aa
    style PATCH fill:#0d2818,stroke:#1e8449,color:#82e0aa
    style EXPLOIT fill:#0d2818,stroke:#1e8449,color:#82e0aa
    style REPORT fill:#2a1810,stroke:#a04000,color:#f0a868

Reading the diagram: EVMbench produces three independent scores. Detect recall measures whether the harness finds known bugs — but not whether it can exploit or fix them. Patch quality measures whether fixes work without breaking behavior — but not whether the harness can find the bugs in the first place. Exploit success rate measures whether the harness builds working PoCs — but not whether those PoCs generalize. All three must be reported together. A harness scoring 90% Detect / 30% Patch / 30% Exploit is a detection engine, not an audit harness.

Diagram 2 — The 92% vs 34% Gap: What Domain Specificity Buys

Type: Mermaid (flowchart) Purpose: Shows the structural explanation for why purpose-built agents outperform general LLMs by nearly 3x on DeFi-specific vulnerability classes.

flowchart LR
    subgraph GENERAL["General LLM (GPT-5.1 baseline)"]
        RAW["Raw source → LLM"]
        RESULT1["34% on DeFi classes"]
        WHY1["Misses: flash loan manipulation, oracle dependency, rebase accounting, governance execution, liquidation logic — requires domain knowledge general LLMs lack"]
    end

    subgraph PURPOSE["Purpose-built agent"]
        SCAFFOLD["Heuristic scaffolds<br/>(DeFi safety properties)"]
        TOOLS["Tool integration<br/>(Slither/Mythril/Foundry)"]
        CONTEXT["Context engineering<br/>(function-level reorganization)"]
        CASCADE["Cascaded verification<br/>(DeFi-specific FP filtering)"]
        RESULT2["92% on DeFi classes"]
    end

    GENERAL -.->|"the gap"| PURPOSE
    PURPOSE -.->|"3x improvement"| RESULT2

    style GENERAL fill:#2a0d0d,stroke:#a00000,color:#f08080
    style PURPOSE fill:#0d2818,stroke:#1e8449,color:#82e0aa
    style RESULT1 fill:#2a0d0d,stroke:#a00000,color:#f08080
    style RESULT2 fill:#0d2818,stroke:#1e8449,color:#82e0aa

Reading the diagram: The 92% vs 34% gap is not marginal — it is the difference between a reliable tool and one that misses two-thirds of DeFi bugs. The gap has a structural explanation: DeFi vulnerability classes (flash loans, oracles, rebase tokens, governance, liquidation) require domain knowledge that general LLMs lack. Purpose-built agents embed this knowledge via four mechanisms: heuristic scaffolds that encode DeFi safety properties, tool integration that lets the LLM reason over structured output, context engineering that presents the right code slice, and cascaded verification that filters DeFi-specific false positives. The gap is the quantified value of these engineering choices.

Diagram 3 — Solana's Account Model vs the EVM

Type: Mermaid (flowchart) Purpose: Shows how Solana's account-passing model creates vulnerability classes with no EVM analog, and the harness adaptations required.

flowchart TD
    EVM["EVM model<br/>Single global state tree<br/>Contract addresses are type-bound"]
    SOL["Solana model<br/>Accounts passed explicitly into each instruction<br/>Owner/type must be verified"]

    EVM_VULN["EVM vulnerability classes:<br/>reentrancy, integer overflow, access control"]
    SOL_VULN["Solana vulnerability classes:<br/>account confusion, missing signer check,<br/>integer arithmetic (Rust), PDA misuse"]

    EVM_TOOLS["EVM tools:<br/>Slither, Mythril, Foundry"]
    SOL_TOOLS["Solana tools:<br/>Anchor constraint checking,<br/>solana-security-txt, bankrun,<br/>custom Semgrep for Rust/Anchor"]

    EVM --> EVM_VULN --> EVM_TOOLS
    SOL --> SOL_VULN --> SOL_TOOLS

    ADAPT["Harness adaptations:<br/>3-mode architecture PORTS<br/>tools and heuristics DO NOT"]

    style EVM fill:#0d1b2a,stroke:#1b4f72,color:#e4e4e8
    style SOL fill:#0d1b2a,stroke:#1b4f72,color:#e4e4e8
    style SOL_VULN fill:#14141f,stroke:#5eead4,color:#5eead4
    style ADAPT fill:#2a1810,stroke:#a04000,color:#f0a868

Reading the diagram: The EVM has a single global state tree where contract addresses are type-bound — you cannot pass "the wrong contract" to a call. Solana passes accounts explicitly into each instruction, so the program must verify each account's owner and type. This creates account confusion (accepting the wrong account type) and PDA misuse (mis-deriving deterministic addresses) — classes with no EVM analog. The three-mode harness architecture (Detect/Patch/Exploit) ports to Solana, but the tools do not: Slither and Mythril do not analyze Rust/Anchor. The harness uses Anchor constraint checking, bankrun for PoCs, and custom Semgrep rules instead.

Diagram 4 — Cross-Chain Bridge Attack Surface

Type: Mermaid (flowchart) Purpose: Shows why bridges are the highest-value attack surface — the vulnerability is in the cross-chain verification protocol, not a single contract.

flowchart LR
    subgraph CHAIN_A["Chain A"]
        LOCK["Lock assets<br/>in bridge contract"]
    end

    subgraph BRIDGE["Bridge verification protocol"]
        VERIFY["How does Chain B know<br/>Chain A actually locked?"]
        SIG["Signature verification<br/>(wrong signer set? replayable?)"]
        MSG["Message passing<br/>(forgeable format?)"]
        RELAYER["Relayer<br/>(centralized? can submit fraud?)"]
    end

    subgraph CHAIN_B["Chain B"]
        MINT["Mint wrapped assets"]
    end

    LOCK --> VERIFY
    VERIFY --> SIG
    VERIFY --> MSG
    VERIFY --> RELAYER
    SIG --> MINT
    MSG --> MINT
    RELAYER --> MINT

    ATTACK["Attack: compromise verification<br/>→ mint unbacked assets"]
    SIG -.-> ATTACK
    MSG -.-> ATTACK
    RELAYER -.-> ATTACK

    CASE["Case studies:<br/>Wormhole 2022 ($325M)<br/>Nomad 2022 ($190M)<br/>Billions lost 2024-2025"]

    style CHAIN_A fill:#0d1b2a,stroke:#1b4f72,color:#e4e4e8
    style CHAIN_B fill:#0d1b2a,stroke:#1b4f72,color:#e4e4e8
    style BRIDGE fill:#2a0d0d,stroke:#a00000,color:#f08080
    style ATTACK fill:#2a0d0d,stroke:#a00000,color:#f08080
    style CASE fill:#2a1810,stroke:#a04000,color:#f0a868

Reading the diagram: A bridge locks assets on Chain A and mints wrapped representations on Chain B. The security boundary is the verification protocol — how does Chain B know Chain A actually locked the assets? This is not a single-contract vulnerability; it is a distributed-system property. The failure modes are signature verification flaws (wrong signer set, replayable signatures), message-passing manipulation (forgeable message formats), and relayer centralization (a single relayer can submit fraudulent messages). Compromising the verification lets an attacker mint unbacked assets. Bridge security requires modeling the protocol as a state machine across both chains and tracing asset flows — beyond single-contract auditing.

Diagram 5 — The Audit Report Structure

Type: Mermaid (flowchart) Purpose: The six-section structure of a client-ready audit report, matching what Trail of Bits, Consensys Diligence, and OpenZeppelin publish.

flowchart TD
    SCOPE["1. Scope<br/>Contracts audited, commit hash, dates<br/>Defines what was reviewed — and what was NOT"]
    METHOD["2. Methodology<br/>Manual review, static analysis, fuzzing, formal verification<br/>Establishes rigor and reproducibility"]
    TABLE["3. Findings table<br/>ID, title, severity, status, location<br/>The executive view — client's first stop"]
    SEVERITY["4. Severity breakdown<br/>Count by Critical/High/Medium/Low/Info<br/>Quick risk posture read"]
    DETAILED["5. Detailed findings<br/>Description, impact, PoC, recommendation, status<br/>The section remediation works from"]
    ROADMAP["6. Remediation roadmap<br/>Prioritized action items, acceptable risk, verification path"]

    SCOPE --> METHOD --> TABLE --> SEVERITY --> DETAILED --> ROADMAP

    SEV_TABLE["Critical: funds at immediate risk<br/>High: funds at risk under conditions<br/>Medium: logic error, no immediate loss<br/>Low: best-practice violation<br/>Informational: optimization/style"]
    SEVERITY -.-> SEV_TABLE

    AUTO["Harness generates from<br/>structured finding records<br/>(S11 cascaded-verification output)"]
    AUTO -.-> DETAILED

    HUMAN["Human auditor reviews,<br/>edits, confirms severity<br/>Harness severity = draft; auditor = final"]
    HUMAN -.-> DETAILED

    style SCOPE fill:#0d1b2a,stroke:#1b4f72,color:#e4e4e8
    style METHOD fill:#0d1b2a,stroke:#1b4f72,color:#e4e4e8
    style TABLE fill:#14141f,stroke:#5eead4,color:#5eead4
    style SEVERITY fill:#14141f,stroke:#5eead4,color:#5eead4
    style DETAILED fill:#0d2818,stroke:#1e8449,color:#82e0aa
    style ROADMAP fill:#0d2818,stroke:#1e8449,color:#82e0aa
    style AUTO fill:#2a1810,stroke:#a04000,color:#f0a868
    style HUMAN fill:#2a1810,stroke:#a04000,color:#f0a868

Reading the diagram: A client-ready audit report has six sections. Scope defines the boundary — what was audited and what was not. Methodology establishes rigor. The findings table is the executive summary. The severity breakdown gives a quick risk read. Detailed findings (with PoC and recommendation from S11.3 and S11.4) are what the remediation team works from. The remediation roadmap prioritizes action. The harness generates the report from structured finding records, but a human auditor reviews, edits, and confirms every severity — the harness's severity is a draft; the auditor's is final.

# Diagrams — Module S12: Advanced Smart Contract Harnesses > All Mermaid validated in Mermaid Live Editor. n8n JSON is structurally valid and importable. --- ## Diagram 1 — EVMbench: The Three Scores **Type**: Mermaid (flowchart) **Purpose**: Shows the three independent EVMbench scores and what each measures (and does not measure). A harness must report all three — Detect recall alone hides weaknesses. ```mermaid flowchart TD BENCH["EVMbench evaluation 117 vulnerabilities · 40 repositories"] DETECT["DETECT RECALL Of 117, how many found?"] DETECT_MEAS["Measures: can the harness find known bugs?"] DETECT_NOT["Does NOT measure: whether it can exploit or fix them"] PATCH["PATCH QUALITY Fix removes bug + preserves behavior?"] PATCH_MEAS["Measures: can the harness fix without breaking?"] PATCH_NOT["Does NOT measure: whether it can find them first"] EXPLOIT["EXPLOIT SUCCESS RATE Working PoC on forked mainnet?"] EXPLOIT_MEAS["Measures: can the harness build real PoCs?"] EXPLOIT_NOT["Does NOT measure: whether PoCs generalize to unseen bugs"] BENCH --> DETECT --> DETECT_MEAS --> DETECT_NOT BENCH --> PATCH --> PATCH_MEAS --> PATCH_NOT BENCH --> EXPLOIT --> EXPLOIT_MEAS --> EXPLOIT_NOT REPORT["Report all three together Detect-only = detection engine, not audit harness"] DETECT_NOT --> REPORT PATCH_NOT --> REPORT EXPLOIT_NOT --> REPORT style BENCH fill:#14141f,stroke:#5eead4,color:#5eead4 style DETECT fill:#0d2818,stroke:#1e8449,color:#82e0aa style PATCH fill:#0d2818,stroke:#1e8449,color:#82e0aa style EXPLOIT fill:#0d2818,stroke:#1e8449,color:#82e0aa style REPORT fill:#2a1810,stroke:#a04000,color:#f0a868 ``` **Reading the diagram**: EVMbench produces three independent scores. Detect recall measures whether the harness finds known bugs — but not whether it can exploit or fix them. Patch quality measures whether fixes work without breaking behavior — but not whether the harness can find the bugs in the first place. Exploit success rate measures whether the harness builds working PoCs — but not whether those PoCs generalize. All three must be reported together. A harness scoring 90% Detect / 30% Patch / 30% Exploit is a detection engine, not an audit harness. --- ## Diagram 2 — The 92% vs 34% Gap: What Domain Specificity Buys **Type**: Mermaid (flowchart) **Purpose**: Shows the structural explanation for why purpose-built agents outperform general LLMs by nearly 3x on DeFi-specific vulnerability classes. ```mermaid flowchart LR subgraph GENERAL["General LLM (GPT-5.1 baseline)"] RAW["Raw source → LLM"] RESULT1["34% on DeFi classes"] WHY1["Misses: flash loan manipulation, oracle dependency, rebase accounting, governance execution, liquidation logic — requires domain knowledge general LLMs lack"] end subgraph PURPOSE["Purpose-built agent"] SCAFFOLD["Heuristic scaffolds (DeFi safety properties)"] TOOLS["Tool integration (Slither/Mythril/Foundry)"] CONTEXT["Context engineering (function-level reorganization)"] CASCADE["Cascaded verification (DeFi-specific FP filtering)"] RESULT2["92% on DeFi classes"] end GENERAL -.->|"the gap"| PURPOSE PURPOSE -.->|"3x improvement"| RESULT2 style GENERAL fill:#2a0d0d,stroke:#a00000,color:#f08080 style PURPOSE fill:#0d2818,stroke:#1e8449,color:#82e0aa style RESULT1 fill:#2a0d0d,stroke:#a00000,color:#f08080 style RESULT2 fill:#0d2818,stroke:#1e8449,color:#82e0aa ``` **Reading the diagram**: The 92% vs 34% gap is not marginal — it is the difference between a reliable tool and one that misses two-thirds of DeFi bugs. The gap has a structural explanation: DeFi vulnerability classes (flash loans, oracles, rebase tokens, governance, liquidation) require domain knowledge that general LLMs lack. Purpose-built agents embed this knowledge via four mechanisms: heuristic scaffolds that encode DeFi safety properties, tool integration that lets the LLM reason over structured output, context engineering that presents the right code slice, and cascaded verification that filters DeFi-specific false positives. The gap is the quantified value of these engineering choices. --- ## Diagram 3 — Solana's Account Model vs the EVM **Type**: Mermaid (flowchart) **Purpose**: Shows how Solana's account-passing model creates vulnerability classes with no EVM analog, and the harness adaptations required. ```mermaid flowchart TD EVM["EVM model Single global state tree Contract addresses are type-bound"] SOL["Solana model Accounts passed explicitly into each instruction Owner/type must be verified"] EVM_VULN["EVM vulnerability classes: reentrancy, integer overflow, access control"] SOL_VULN["Solana vulnerability classes: account confusion, missing signer check, integer arithmetic (Rust), PDA misuse"] EVM_TOOLS["EVM tools: Slither, Mythril, Foundry"] SOL_TOOLS["Solana tools: Anchor constraint checking, solana-security-txt, bankrun, custom Semgrep for Rust/Anchor"] EVM --> EVM_VULN --> EVM_TOOLS SOL --> SOL_VULN --> SOL_TOOLS ADAPT["Harness adaptations: 3-mode architecture PORTS tools and heuristics DO NOT"] style EVM fill:#0d1b2a,stroke:#1b4f72,color:#e4e4e8 style SOL fill:#0d1b2a,stroke:#1b4f72,color:#e4e4e8 style SOL_VULN fill:#14141f,stroke:#5eead4,color:#5eead4 style ADAPT fill:#2a1810,stroke:#a04000,color:#f0a868 ``` **Reading the diagram**: The EVM has a single global state tree where contract addresses are type-bound — you cannot pass "the wrong contract" to a call. Solana passes accounts explicitly into each instruction, so the program must verify each account's owner and type. This creates account confusion (accepting the wrong account type) and PDA misuse (mis-deriving deterministic addresses) — classes with no EVM analog. The three-mode harness architecture (Detect/Patch/Exploit) ports to Solana, but the tools do not: Slither and Mythril do not analyze Rust/Anchor. The harness uses Anchor constraint checking, `bankrun` for PoCs, and custom Semgrep rules instead. --- ## Diagram 4 — Cross-Chain Bridge Attack Surface **Type**: Mermaid (flowchart) **Purpose**: Shows why bridges are the highest-value attack surface — the vulnerability is in the cross-chain verification protocol, not a single contract. ```mermaid flowchart LR subgraph CHAIN_A["Chain A"] LOCK["Lock assets in bridge contract"] end subgraph BRIDGE["Bridge verification protocol"] VERIFY["How does Chain B know Chain A actually locked?"] SIG["Signature verification (wrong signer set? replayable?)"] MSG["Message passing (forgeable format?)"] RELAYER["Relayer (centralized? can submit fraud?)"] end subgraph CHAIN_B["Chain B"] MINT["Mint wrapped assets"] end LOCK --> VERIFY VERIFY --> SIG VERIFY --> MSG VERIFY --> RELAYER SIG --> MINT MSG --> MINT RELAYER --> MINT ATTACK["Attack: compromise verification → mint unbacked assets"] SIG -.-> ATTACK MSG -.-> ATTACK RELAYER -.-> ATTACK CASE["Case studies: Wormhole 2022 ($325M) Nomad 2022 ($190M) Billions lost 2024-2025"] style CHAIN_A fill:#0d1b2a,stroke:#1b4f72,color:#e4e4e8 style CHAIN_B fill:#0d1b2a,stroke:#1b4f72,color:#e4e4e8 style BRIDGE fill:#2a0d0d,stroke:#a00000,color:#f08080 style ATTACK fill:#2a0d0d,stroke:#a00000,color:#f08080 style CASE fill:#2a1810,stroke:#a04000,color:#f0a868 ``` **Reading the diagram**: A bridge locks assets on Chain A and mints wrapped representations on Chain B. The security boundary is the verification protocol — how does Chain B know Chain A actually locked the assets? This is not a single-contract vulnerability; it is a distributed-system property. The failure modes are signature verification flaws (wrong signer set, replayable signatures), message-passing manipulation (forgeable message formats), and relayer centralization (a single relayer can submit fraudulent messages). Compromising the verification lets an attacker mint unbacked assets. Bridge security requires modeling the protocol as a state machine across both chains and tracing asset flows — beyond single-contract auditing. --- ## Diagram 5 — The Audit Report Structure **Type**: Mermaid (flowchart) **Purpose**: The six-section structure of a client-ready audit report, matching what Trail of Bits, Consensys Diligence, and OpenZeppelin publish. ```mermaid flowchart TD SCOPE["1. Scope Contracts audited, commit hash, dates Defines what was reviewed — and what was NOT"] METHOD["2. Methodology Manual review, static analysis, fuzzing, formal verification Establishes rigor and reproducibility"] TABLE["3. Findings table ID, title, severity, status, location The executive view — client's first stop"] SEVERITY["4. Severity breakdown Count by Critical/High/Medium/Low/Info Quick risk posture read"] DETAILED["5. Detailed findings Description, impact, PoC, recommendation, status The section remediation works from"] ROADMAP["6. Remediation roadmap Prioritized action items, acceptable risk, verification path"] SCOPE --> METHOD --> TABLE --> SEVERITY --> DETAILED --> ROADMAP SEV_TABLE["Critical: funds at immediate risk High: funds at risk under conditions Medium: logic error, no immediate loss Low: best-practice violation Informational: optimization/style"] SEVERITY -.-> SEV_TABLE AUTO["Harness generates from structured finding records (S11 cascaded-verification output)"] AUTO -.-> DETAILED HUMAN["Human auditor reviews, edits, confirms severity Harness severity = draft; auditor = final"] HUMAN -.-> DETAILED style SCOPE fill:#0d1b2a,stroke:#1b4f72,color:#e4e4e8 style METHOD fill:#0d1b2a,stroke:#1b4f72,color:#e4e4e8 style TABLE fill:#14141f,stroke:#5eead4,color:#5eead4 style SEVERITY fill:#14141f,stroke:#5eead4,color:#5eead4 style DETAILED fill:#0d2818,stroke:#1e8449,color:#82e0aa style ROADMAP fill:#0d2818,stroke:#1e8449,color:#82e0aa style AUTO fill:#2a1810,stroke:#a04000,color:#f0a868 style HUMAN fill:#2a1810,stroke:#a04000,color:#f0a868 ``` **Reading the diagram**: A client-ready audit report has six sections. Scope defines the boundary — what was audited and what was not. Methodology establishes rigor. The findings table is the executive summary. The severity breakdown gives a quick risk read. Detailed findings (with PoC and recommendation from S11.3 and S11.4) are what the remediation team works from. The remediation roadmap prioritizes action. The harness generates the report from structured finding records, but a human auditor reviews, edits, and confirms every severity — the harness's severity is a draft; the auditor's is final.