signerd: reserve daily-cap before signing + durable rollback-resistant accounting (C3)

[hellno]

Severity: MEDIUM (durability/correctness; a testnet-confined security side-benefit). Source: ADR 0003 (#105), decoupled by ADR 0004 (#119). Reviewed + re-scoped via /autoplan (2026-06-20).

Problem

The signer daily spend cap is not durable: spent_today_wei is in-memory and force-zeroed on every daemon load (policy_store.rs:63), incremented only post-broadcast (daemon.rs:1166, after the broadcast at :1148). So any restart — crash, OOM, app update, sleep — silently zeroes the day's accounting. That is a plain correctness bug that hits honest users on every restart.

It also removes a (now testnet-confined) drain: a same-uid attacker could crash-loop the auto-respawning daemon (supervise.rs) to reset the cap and spend in within-cap chunks. This is bounded — the daemon boots Locked and needs a fresh passphrase per restart (daemon.rs:262), and #76's guardrail already downgrades every real-chain auto-allow to a human card (daemon.rs:635, guardrail_active :1392), so the hands-free within-cap path only exists on testnets/forks or under an explicit autonomy override. The same-uid attacker can also just delete the counter file (accepted residual, ADR 0004), so the durable counter's value is primarily honest-restart durability, not a security guarantee. The security story completes when #72 authenticates the cap values in policy.json.

Re-scoped by review: dropped the nonce-keyed RPC reconciliation from the earlier draft (it restructures the frozen broadcast path and defends a sub-second window the file-delete attacker bypasses). Conservative count-on-reboot gives the same safety, errs tighter, and needs no chain query.

Acceptance criteria (Option A)

• Durable counter file (spend.json in config_dir) holding {chain_id, account, day, committed_wei, reserved_wei}, written atomically via a new deckard_core::atomic_write(path, &[u8]) extracted from Vault::write_atomic (temp@0600 + fsync + rename + dir-sync). (F1 — write_atomic is a Vault method, not a byte-writer; the extraction is a prerequisite.)
• Reserve-before-sign: in execute, after the cap re-check (daemon.rs:1116) and before the broadcast (:1140), durably record reserved_wei += value (skip when value == 0 — shields/approves/contract-calls). A reserve-write failure denies fail-closed with a new reserve_failed deny tag. (F3, F5)
• Effective spend = committed_wei + reserved_wei. On reboot any leftover reserved_wei (a crash between reserve and commit) is counted as spent — never released by a chain query. (conservative count-on-reboot)
• Broadcast outcome: success → commit (reserved→committed); clean RPC rejection → release the reserve; timeout → KEEP it counted (a timed-out tx may have landed — must not re-open the double-spend). (F4)
• Forward-only rollover: one effective_day = max(current_utc_day(), stored_day); reset spend only when the day advances. A backward wall-clock does not reset (fail closed). Replaces the bidirectional rollover() (daemon.rs:1397). (F8)
• Binding: validate chain_id at boot (mismatch → discard — a different chain is a different cap); validate account at unlock (mismatch → reset window). Missing file → fresh window; corrupt file → fully-spent + loud log until rollover (mirror the policy loader's missing/invalid split). Clamp recovered spend ≤ daily cap. (F9, F10, F6)
• Supervisor crash-budget (Option D): a non-resetting N-crashes-in-M-minutes budget in monitor_loop stops respawning and surfaces a loud error (the per-spawn backoff resets every 200ms today — supervise.rs:590 — so a crash-loop respawns at the floor forever). Counter-load failures are non-fatal so a single bad file can't feed the budget into a lockout. (F11)
• Tests: unit (round-trip; missing→fresh / corrupt→fully-spent; forward-only rollover incl. clock-rewind; value==0 skips reserve; chain/account binding; reserve-error fail-closed; clamp) + anvil e2e (happy; fault-injected crash-restart; clean-Err release; timeout keep; honest-restart durability) + supervisor budget + isolated DECKARD_CONFIG_DIR per test (cross-test counter bleed). (F12)

Deferred

• Nonce-keyed exact reconciliation / dropped-tx headroom release → a post-Spike: make policy.json tamper-evident + define a secure edit/maintenance path (not in the vault) #72 issue (conservative count-on-reboot covers the gap and errs tighter).
• policy.json authentication (Spike: make policy.json tamper-evident + define a secure edit/maintenance path (not in the vault) #72) — sequences with this; the cap value is unauthenticated until it lands.
• Anti-rollback anchor ([Deferred] Spike: rollback-protect the vault with a monotonic epoch (→ ADR 0004) #71, ADR 0004); spawn_blocking off-lock fsync (fast-follow if the two reserve/commit fsyncs on the STOP-blocking critical section bite — accepted for v1, anvil-instant, matching the existing "lock held across broadcast" precedent); forward-clock-jump reset (needs root, above the same-uid boundary).

[hellno]

Build on the keystone primitive from ADR 0004 (#119)

The rollback-resistant store spike (#71) landed as ADR 0004 with an unwired reference StateAnchor (crates/deckard-signerd/src/state_anchor.rs). The cap is the high-frequency consumer, so the ADR specifies a two-tier split and — importantly — its adversarial pass found three holes you must close, not just "persist the counter."

The two tiers

• Tier 1 (slow durable anchor): StateAnchor holds a coarse cap_generation bound to chain + account + policy_version + UTC-day. Bump it on a UTC-day roll / policy change / detected rollback via advance(Namespace::Cap, …). Don't write the keychain per spend (slow / can prompt).
• Tier 2 (fast local file): per-spend reserved_wei, written with the same atomic write_atomic recipe (keystore.rs), reserved before the signature is released (closes the post-broadcast crash window at daemon.rs:1166). Accept the fast file only if its embedded generation == the anchor's.

Three corrections the ADR makes mandatory (each was a landed adversarial finding)

1. The generation fence does NOT catch an intra-generation rollback. Within a UTC day at fixed policy, cap_generation is constant, so swapping in an earlier same-day fast file (lower reserved_wei, same generation) passes the fence and resets the counter — the C3 crash-loop drain is only partially closed. Add intra-generation monotonic protection (a high-water sequence the slow tier checkpoints), or scope the fence honestly to cross-generation only and say so.
2. A backward wall-clock jump must not re-open the window. current_utc_day() (policy_store.rs:98) is naive and rollover() (daemon.rs:1397) resets the spend bidirectionally today. Derive the window from effective_day = max(current_utc_day(), anchor.last_seen_day) (persist last_seen_day in the anchor) and make rollover() forward-only. A backward jump then mismatches → fail closed, not reset-to-zero.
3. Reconcile a pre-broadcast crash deterministically. Reserve-before-sign over-counts if the daemon crashes after reserving but before broadcasting. The reservation must carry a deterministic tx identity (chain + from + nonce) so that on reboot the daemon queries the chain and commits-or-releases, rather than permanently consuming the cap.

Performance note: an fsync per signature lands under the daemon mutex held across the broadcast (the documented STOP-latency window). Measure it; consider one combined journal entry per spend.

Sequencing: cap_generation binds to policy_version, which #72 must add first (it doesn't exist on contract::Policy yet). So: #72's versioned policy record → then #108's generation fence.

[hellno]

Supersedes my earlier comment. Scratch the two-tier / anchor / keystone design — deferred (ADR 0004), and this never needed it. Build the local durable fix:

• Persist the spent counter; reserve-before-sign (decrement durably before broadcast; reconcile by chain + from + nonce on reboot).
• Survive restart; forward-only day rollover (a backward clock can't reset the window).

This is the highest-value item in the set: the crash-loop drain is really a durability gap in our own design — any restart (crash, OOM, update) resets the in-memory cap, attacker or not — so persisting it is just correct engineering, and it also removes the trivial drain. Same-uid rollback/deletion of the counter file is the accepted residual (deferred with #71). Body updated accordingly.

[hellno]

/autoplan review — re-scoped to Option A (2026-06-20)

Ran the full CEO + Eng dual-voice pipeline (Codex was usage-limited, so this was Claude primary + independent subagent, with the two load-bearing facts verified against source). Decision at the premise gate: ship-smaller + sequence with #72, severity reframed HIGH → durability.

Why the reframe: the crash-loop drain is capability-gated (daemon boots Locked, needs a fresh passphrase per restart) and now testnet-confined (#76's guardrail downgrades every real-chain auto-allow to a human card — the old "worse off mainnet" line was stale/inverted). The same-uid attacker can also just delete the counter file (the "accepted residual" is their capability), so the durable counter's real value is honest-restart durability, and the security value is #72-gated.

Dropped from the earlier draft: nonce-keyed RPC reconciliation (AC#2). It restructures the frozen broadcast_intent (the nonce is filled inside alloy's send_transaction) and adds an RPC-dependent boot path to defend a sub-second window the file-delete attacker bypasses. Conservative count-on-reboot (treat any reserved-but-unconfirmed spend as spent) gives identical safety, errs tighter, needs no chain query — deferred exact reconciliation to a post-#72 issue.

Eng review caught a blocker (F1): write_atomic is a Vault method that serializes self.to_bytes(), not a generic byte-writer — so it must be extracted to deckard_core::atomic_write first. Plus F4 (timeout must KEEP the reserve), F8 (single forward-only effective_day), F9/F10 (missing vs corrupt + chain/account binding), and the supervisor crash-budget (the per-spawn backoff resets every 200ms, so a crash-loop respawns forever).

Implementation in progress on hellno/provo → PR to follow.