Auditor Guide¶

What To Understand First¶

1. Source References
2. Generated Solidity Inventory
3. Permission Matrix
4. Upgradeability Model
5. Evidence Status

What You Are Allowed To Do¶

Auditors may challenge assumptions, request evidence, map source to docs, review threat models, and identify missing tests. Production actions still require assigned governance or operations roles.

What You Must Never Do¶

• Treat generated inventory as a full parser or proof.
• Accept “Evidence required” as production evidence.
• Rely on old false-freeze deposit docs.
• Ignore key custody when reviewing upgradeability.
• Review only happy-path state transitions.

Responsibilities¶

Verify implementation behavior, access control, state transitions, funds movement, upgrade lifecycle, and evidence claims. Separate confirmed findings from hardening suggestions and missing evidence.

Failure Modes To Recognize¶

Policy assertion gaps, privileged role colocation, unsafe public claim paths, source id replay, reserve accounting drift, settlement ordering bugs, proxy selector collisions, and stale docs.

Escalation¶

Escalate high-impact issues with direct source references, attack path, affected functions, required authority, and recommended immediate operational containment.

Role Operating Guide¶

What This Person Must Understand First¶

The Auditor must understand source manifest, permission matrix, state machines, threat model, and evidence gaps. The four questions must stay separate: Upgrade governance asks which code is official, Deposit permissioning asks who may deposit, Custody/readiness asks whether the deposit route is safe, and Economic/claim safety asks whether funds can later leave safely.

Allowed To Do¶

This role may challenge claims and request stronger proof when the relevant runbook, permission matrix, and reviewer approval support the action.

Must Never Do¶

This role must never accept generated inventory as a compiler or formal proof.

Pages To Read In Order¶

1. System Map
2. Permissioned vs Permissionless Deposits
3. Permission Matrix
4. Source Manifest
5. The runbook for the exact action being performed.

Routine Responsibilities¶

Keep evidence current, record decisions, reconcile action tickets to onchain events, and raise drift quickly. Do not rely on memory when a source manifest, event log, or contract read can answer the question.

Incident Responsibilities¶

Stop routine automation for the affected layer, preserve evidence, notify the correct owner, and avoid broad remediation until the failing layer is identified.

Escalation Triggers¶

Escalate on unknown governance actions, mismatched implementation metadata, unexpected allowlist-admin transfer, stale oracle data, slashing/exit anomalies, failed custody readiness, or any claim that cannot be tied to current source and onchain evidence.