RP1 upgrades can change both Cosmos SDK application state and the custom consensus/runtime boundary. Treat every release as a coordinated protocol change, not just a binary replacement.
Upgrade discipline
- Read the release notes and migration handler before scheduling an upgrade.
- Verify the exact chain ID, binary, genesis, config, validator key, and peer plan.
- Back up application and consensus stores before the change.
- Schedule governance or named upgrade height according to the network plan.
- Start the new binary only after every validator has the compatible artifacts.
- Compare common-height headers, app hashes, module params, and RPC behavior after activation.
Vaults V1 example
The new vaults store is mounted through the named vaults-v1 upgrade. Existing networks must coordinate that upgrade before validators run a binary that expects the store. Vaults is intentionally excluded from generic missing-store repair so a partial rollout cannot silently mutate consensus state.
Rollback thinking
Do not roll back by deleting a store or copying an application-only home over a consensus home. If the network is not converging, preserve evidence and use the release-specific recovery procedure. A process that starts is not proof that the migration is coherent.