Storage, retention and recovery

RocksDB stores execution state and authenticated history. Consensus votes/locks and other safety records use separate exclusively owned durability boundaries.

Retention is part of the API

Historical state/log queries depend on retained floors. Publish joltzu_getProofRetention, and distinguish state history, logs, receipt witnesses and block metadata. An old head lookup can succeed when state at that height is no longer retained.

Local proof leases are opt-in bounded retention promises. Funded retention obligations preserve their specific answer windows and have separate retirement rules. A peer acknowledgement is not payment authority or cryptographic proof of continued remote availability.

Space limits

Logical scratch quotas bound admission to maintenance work. They do not cap physical RocksDB WAL, SST, compaction, filesystem or whole-node space. Disk headroom sampling is an operational check rather than a hard physical reservation.

Check retention obligations before reclamation. Preserve receipt paths and authenticated history required by the active profile. Use documented node maintenance commands; copying one store or deleting safety records is not a recovery strategy.

Recovery after failure

Storage corruption or ambiguous durable writes cause the service/coordinator to fail closed. Diagnose and reopen through the documented recovery flow. Do not blindly retry an ambiguous commit or initialize an empty safety store for a validator that already voted.

Back up execution, safety, authenticated checkpoints and configuration with a consistent operational boundary. Keep signing keys separate and private. Verify recoverability in a controlled deployment.

Storage capacity and recovery behavior need validation under the intended workload. This guide establishes no production throughput or recovery-time guarantee.