Imported from midnightntwrk/midnight-expert (plugins/compact-core/skills/compact-security/SKILL.md). Install upstream with npx skills add midnightntwrk/midnight-expert --skill compact-security. Copyright stays with the author.

Compact Security Threat Model

This skill provides the threat model and adversarial methodology for reviewing Compact smart contracts. It is the "how to think like an attacker" layer. For granular, item-by-item checklists, it routes to the existing compact-core:compact-review references (see the Reuse Map) — those are the single source of truth for line-items, and are not duplicated here.

Security Model

Compact and the Midnight runtime give you five structural guarantees. Each is a backstop, not a substitute for review:

• Privacy by default — witness (private) values cannot reach public ledger state unless explicitly disclose()d. The compiler enforces this.
• Compile-time validation — type errors, illegal disclosures, and sealed-field writes are rejected at compile time.
• Zero-knowledge verification — on-chain, only the proof and disclosed public inputs are checked. The verifier never sees witness values.
• Bounded execution — circuits are finite; loops are fixed-iteration and fully unrolled.
• Immutable deployment — deployed contract logic cannot be patched. A shipped vulnerability is permanent.

The gap these do not cover is the subject of this skill: what the developer trusts that they should not.

Three Execution Contexts

Every Compact value lives in one of three contexts. The reviewer's first job is to know which.

The boundary between ZK circuit and local witness is where most authorization bugs live.

Trust Boundaries & Adversarial Methodology

Review trust-boundaries first, in this order:

1. Witness inputs are attacker-controlled. Every witness foo(): T returns a value the prover chose. The circuit must constrain it (hash it, compare it against pinned state, verify a signature) before any decision depends on it. A witness value used directly in an assert for authorization is bypassable. See references/witness-trust-boundary.md.
2. Exported-circuit parameters are attacker-controlled. Anyone can call any export circuit with any arguments. Validate every parameter.
3. ownPublicKey() is a witness, not the signer. It returns the prover-supplied Zswap coin public key — not cryptographically bound to the transaction signer. Never use it for authorization/identity gating. Its only safe use is routing shielded coins to the caller after they have passed some appropriately implemented access control gate. See references/witness-trust-boundary.md.
4. Disclosure is a one-way leak. Anything disclose()d becomes public forever. Disclose as late and as narrowly as possible.
5. Assert messages are public. A failed transaction's message is observable. Never embed private state in it.

For each circuit, ask: Which inputs are witness-supplied? What does the code trust about them? Could a malicious prover supply a different value and pass the checks?

Reuse Map (threat → detailed checklist)

Apply the threat model, then pull granular checklist items from these existing references. Read references/threat-catalog.md for the full index.

Verification Requests Protocol

A security review's Critical/High findings should be mechanically confirmed. The security-reviewer agent cannot dispatch subagents, so it does not run midnight-verify itself. Instead it appends a ## Verification Requests block to its report — one entry per Critical/High finding — for the orchestrator (the /compact-core:audit-compact command, running on the main thread) to execute.

Emit each request in this shape:

## Verification Requests

### VR-<n>  →  finding: <finding id> (<short title>)
- type: poc | target | source
- claim: "<one-sentence, mechanically-testable statement>"
- poc-sketch: |
    <for type: poc — a minimal contract the orchestrator can compile/run to
     demonstrate the issue: what it declares, what it asserts, what input
     triggers the bypass, and what the secure variant does instead>
- expected: "<what a confirming result looks like — e.g. insecure variant ACCEPTS
              the forged input; secure variant REJECTS>"
- suggested command: /midnight-verify:verify "<claim>"   # or: /midnight-verify:verify <file.compact> [<witnesses.ts>]

Rules:

• type: target — confirm against the contract under review directly.
• type: poc — a minimal claim/contract the orchestrator feeds to /midnight-verify:verify "<claim>".
• type: source — a claim best confirmed by source inspection (e.g., a stdlib signature or runtime behavior).
• If there are no Critical/High findings, emit ## Verification Requests with a single line: (none).

Severity Classification