# Threat assumptions

## In scope

- Cross-chain, cross-contract, cross-action and cross-principal replay.
- Duplicate receipts, reused nonces, selector confusion and stale sessions.
- Canonical-receipt field substitution, address-to-identity coercion, stale
  chain domains, invented grouped-reward facts, and provenance/consent hash
  preimage ambiguity.
- High-s ECDSA malleability, malformed ERC-1271 responses and callback
  reentrancy.
- Timestamp equality, creator/worker abandonment and paused-state liveness.
- Forced ETH, accounting drift, over-allocation and liability mixing.
- Compromised guardian (pause only), compromised session key (finite scope),
  and malicious issuers/verifiers within their declared trust boundary.
- Name front-running and accidental interpretation of metadata as authority.

## Assumed

- Base chain consensus/finality and EVM execution are correct.
- Governance and guardian are independently secured. Governance compromise can
  unpause but cannot change immutable caps or counterparties.
- A pinned external verifier’s runtime is non-proxy, semantically reviewed, and
  remains available. Codehash pinning does not prove correctness.
- Receipt consumers inspect issuer/actor, schema or action, subject/resource,
  validity, chain domain, consent, and provenance rather than treating
  registration as truth. Canonical receipt consumers independently interpret
  the stored identity, provenance, finality, and consent namespaces.

## Explicitly excluded / not claimed

- ML-DSA, Dilithium, post-quantum or quantum-resistant authorization.
- Legal/actuarial qualification as insurance.
- Oracle correctness, subjective work-quality arbitration, identity proof,
  Sybil resistance, or reputation truth.
- Cross-chain message transport or finality verification beyond the selected
  verifier interface.
- Cross-runtime identity proof or semantic parity merely from a matching
  commitment. The canonical Base registry supplies an explicit, lossless Base
  binding; the other runtime and adapter require separate verification.
- Upgradeability. These contracts intentionally have no proxy or mutable caps.

## Pause behavior

Pause blocks only new risk: new tasks/offers/acceptances/contributions/programs
and session registration/execution. It does not block revocation, pull withdrawals, work
submission, approvals, objective claims, expiry, default approval, cancellation
or other terminal recovery.

## Independent-audit remediation notes (2026-08-31)

- A verifier's self-reported `VERIFIER_HASH()` is not identity evidence by itself. The adapter constructor also requires an approved address, exact runtime `extcodehash`, SP1 contracts commit/release identity, final guest ELF SHA-256, exact program vkey, and proof-system identifier. It rejects runtime instruction streams containing `DELEGATECALL` and rechecks code hash before every proof call. Because the final artifact/address pins do not exist, release configuration remains fail-closed.
- The Foundry verifier doubles exercise adapter control flow only. They are not real-proof, cryptographic-equivalence, production-verifier, gas, fork, or independent-review evidence.
- Copied VNS commitments are isolated by committer, task rejection is terminal and solvent, and governance transfer requires explicit proposal/acceptance with governance cancellation and guardian emergency veto.