[olaams-tech]

Closes #187.

Context

Two of the three acceptance items were already satisfied on main: escrow-contract and dao-governance-contract each have a SECURITY.md following greenpay-contract's methodology, and the findings those audits surfaced are tracked and fixed with regression tests (escrow H-01 CEI reorder and H-02 dispute-timeout recovery; dao H-01 snapshot voting-power inflation and H-02 proportional quorum). The remaining gap was the third item: a documented process for re-running the audit when either contract changes.

What this adds

• contracts/SECURITY_AUDIT_PROCESS.md — the repeatable process:
  • Scope table mapping each contract to its audit record.
  • Triggers for a re-run (new/changed entrypoint, external call, arithmetic, access control, storage keys/tier, toolchain bump, upgrade path, or a prior finding's fix).
  • Seven-point checklist (CEI/reentrancy, checked arithmetic, access control, front-running/MEV, event safety, edge cases, storage lifecycle).
  • Procedure (inventory → check → classify → fix or document → regression test → record → run tests/lint → date + reference).
  • Severity scale, a finding-record template, complementary checks (make audit, make lint, property tests), and sign-off.
• Links from each audit record (greenpay-contract, escrow-contract, dao-governance-contract) to the process via a new Re-running this audit section.

No contract code changed.

Acceptance criteria → evidence

Criterion	Where
escrow & dao SECURITY.md follow the documented methodology	existing contracts/escrow-contract/SECURITY.md, contracts/dao-governance-contract/SECURITY.md
Findings tracked and fixed (CEI ordering, voting-power inflation, others)	H-01/H-02 in each audit record plus their regression tests
Process documented for re-running the audit	contracts/SECURITY_AUDIT_PROCESS.md + the Re-running this audit links

Notes

make audit remains the dependency-vulnerability check (cargo audit); the process above is the contract-level audit methodology and is complementary to it.