Settlement

Settlement compresses many off-chain economic actions into replay-protected SEEDOS batches on Base. The settlement engine collects unsettled `WardLedger` mint entries, computes canonical hashes, builds `capStateHash`, `indexerSnapshotHash`, `ueiHash`, and a batch identity, then persists a `WardSettlementBatch`. The worker submits the batch only if launch controls, GEO circuit flags, and emission caps allow it. The SEEDOS contract rejects duplicate batch IDs and enforces max supply.

Trust boundary

Trust boundary: the database ledger is the accounting input; Base minting is the settlement output; duplicate protection exists both off-chain and on-chain.

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: `SEEDOS.processedBatch`, `SEEDOS.processedEpochBatch`, `WardSettlementBatch`, `WardSettlementLineItem`.

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: settlement can lag or freeze under stress, but it must not double-mint or silently exceed cap.

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.