Follow the official c8ntinuum GitHub organization or repository for release-specific upgrade announcements. Each scheduled network upgrade should publish the upgrade name, target height, binary version, checksums or signatures, and operator deadline before validators replace binaries.

Current upgrade status

ItemCurrent documented value
Upgrade modulePresent
Active genesis upgrade planNone documented
Existing app upgrade handlerv0.5.0-to-v0.6.0
Plan queryctmd query upgrade plan

Release-specific runbook

PhaseOperator action
AnnouncementRecord the upgrade name, target height, binary version, checksums or signatures, and deadline from the official release notice.
PreparationBack up configs and keys, confirm disk headroom, check service health, and download the release binary.
VerificationVerify binary checksums or signatures when provided, then confirm ctmd version and ctmd version --long.
ExecutionFollow the release-specific stop height, binary replacement, config migration, and restart instructions.
Post-upgradeConfirm height progression, peer count, logs, RPC health, and application version.
RollbackRoll back only when the release instructions say it is allowed for the observed failure mode.

Operator reminders

  • Take backups before replacing binaries or changing configs.
  • Verify binary checksums or signatures when provided.
  • Watch logs and peer health through the upgrade window.
  • Coordinate validator-specific steps separately from full-node steps.
  • Do not use --unsafe-skip-upgrades except under explicit emergency coordination.
  • Security reports go to [email protected]; do not open public issues for vulnerabilities.
For operator coordination channels (Discord incident channel, status page, pager rotation, validator coordination room), see Node Operations.