State movement in RP1 has two coupled domains: the Cosmos SDK application state and the custom consensus store. A node is not ready merely because one domain opened successfully.
State-sync choices
- Fresh managed testnet — initialize homes from the release’s topology and genesis workflow.
- Coordinated validator snapshot — restore application and consensus state from a verified snapshot with matching chain ID and validator identity.
- Observer catch-up — use the supported state-sync/runbook path and verify the first complete retained header.
Recovery invariants
- Durable consensus data is synchronized before in-memory floors or ordering state advance.
- A pending durability failure blocks ordinary mutations and recovery reads until it is retried successfully.
- A header can be durable while transaction bodies or block sidecars are unavailable; the RPC should say so explicitly.
- A nonzero application with an empty consensus recovery database is not an ordinary fresh start.
- Historical data below the retained floor is unavailable unless a supported archive or snapshot provides it.
Operator checklist
- Stop the node with the bounded shutdown workflow.
- Preserve the original home and capture logs, status, and store metadata.
- Verify chain ID, application height/hash, consensus retention, and validator key identity.
- Restore only from a release-matched, integrity-checked artifact.
- Start without exposing public RPC until the canonical header and validator readiness checks pass.
Do not copy generic Cosmos state-sync parameters into an RP1 node: the current chain couples application state to a custom consensus store and retained-header recovery. Use the release-pinned operator runbook shipped with the exact rp1d binary, and keep the original home available until both domains pass the release’s readiness checks.