Security - Wardenseed

Security

Security is a product surface: roles, pausing, replay protection, circuit breakers, and incident response must be legible. Wardenseed's security model prioritizes role separation, max-supply enforcement, duplicate batch rejection, signed marketplace order replay protection, authorized anchors, pause controls, and treasury delay. The system is not audit-complete just because it has contracts; it becomes credible when roles, tests, docs, and runbooks are visible.

Trust boundary

Trust boundary: hot keys can operate defined surfaces, but upgrade, treasury, and policy authority should sit behind multisig/timelock.

Gameplay mutation remains in USK/Postgres unless explicitly settled.
On-chain state is used for ownership, receipts, governance execution, or proof.
Public copy must describe the boundary honestly, including what is not decentralized yet.

Contract surfaces

Contract surfaces: `PAUSER_ROLE`, `UPGRADER_ROLE`, `ENGINE_ROLE`, `MINTER_ROLE`, `ROUTER_ROLE`, nonce maps, batch maps, timelock roles.

Every surface should emit enough events for analytics and incident reconstruction.
Privileged functions should be role-gated, timelocked, or emergency-scoped depending on blast radius.
Batch, nonce, and root identifiers must remain replay-resistant across upgrades.

Operational assumptions

Operational assumption: emergency mode may pause mint, settlement, marketplace, LP, or governance execution while the team reconciles evidence.

Failure modes must degrade visibly rather than pretending the world is healthy.
Security posture takes priority over feature velocity when settlement or treasury risk is involved.
Docs, tests, and live proof widgets should evolve together with contract changes.