V2-SC-144 — Create Mutation Testing for Security Assertions

[dDevAhmed]

V2-SC-144 — Create Mutation Testing for Security Assertions

Overview

Introduce controlled contract mutations and demonstrate that authorization, invariant, fuzz, event, and upgrade tests fail when critical protections are removed.

Problem Context

This issue closes a distinct assurance gap in the canonical modular V2 protocol. It must be delivered as an independently reviewable change and must not absorb unrelated implementation, deployment, API, or frontend work.

Technical Scope

• Define the authoritative behavior, assumptions, failure modes, and module boundaries for this scope.
• Implement the minimum production Solidity, libraries, scripts, fixtures, or documentation required by the objective.
• Map affected interfaces, storage, events, roles, configuration versions, and deployment artifacts.
• Preserve bounded execution, pull-based value transfer, deterministic rounding, and replayable event semantics.
• Document migration impact and compatibility with active claims and released artifacts.

Security and Architecture Requirements

• Optimism/EVM contracts remain authoritative for protocol mutation and settlement.
• No API, indexer, frontend, guardian, deployer, or test harness may gain settlement or treasury authority.
• Reject zero-address dependencies, unsafe token assumptions, unbounded loops, replay paths, and fail-open authorization.
• Preserve asset conservation, single settlement, no double claim, immutable active-claim parameters, and timelocked governance.
• Do not add Stellar, Soroban, Freighter, production secrets, placeholder addresses, generated drift, or mock production dependencies.

Required Tests

• Positive, negative, boundary, authorization, replay, and failure-path unit tests.
• Stateful fuzz or invariant coverage for every affected protocol property.
• Regression tests for each legacy or audit defect displaced by this work.
• Event/storage reconciliation and ABI/artifact drift validation where applicable.
• Full Foundry build, unit, fuzz, invariant, gas, lint, and configured static-analysis suites.

Acceptance Criteria

• The objective is implemented without unrelated scope.
• Every affected protocol invariant and trust boundary is documented and tested.
• Events and storage remain sufficient for deterministic projection and reconciliation.
• No backend-authoritative mutation or privileged shortcut is introduced.
• All required exact-head checks pass without ignored security findings.
• The PR maps evidence to every acceptance criterion and identifies residual risk.
• Independent exact-head human maintainer approval is recorded.

Dependencies

• V2-SC-091 through V2-SC-140

This issue must remain unassigned until every dependency is verified complete and compatible.

Non-Goals

• Unrelated protocol redesign or legacy V1 compatibility work.
• API, frontend, or off-chain settlement implementation.
• Production secrets, addresses, or launch-value selection unless explicitly required.
• Applying the external Stellar Wave label before maintainer activation.

Complexity and Review

• Complexity: high
• Points: 200
• Risk: protocol-critical
• Candidate state: wave-candidate
• Required review: independent human maintainer approval; automatic merge prohibited

---

🏷 Labels

• contracts
• security
• protocol-critical
• web3
• complexity-high
• wave-candidate

---