Skip to Content
OperateMaintenanceNetwork upgrades

Network upgrades

Blockchain networks often need to upgrade with new features which require coordination work among the community of developers, validators, and node operators prior to activating the upgrades. This process is called a network upgrade, which can be breaking or non-breaking. During planned network upgrades the community will coordinate to prepare for the upcoming upgrade. Breaking network upgrades are not backward-compatible with older versions of the network software, which is why it is important that validators upgrade their software to continue validating on the network. Non-breaking network upgrades are backward-compatible and require less coordination.

Network upgrade coordination

As of the Lemongrass upgrade in September 2024, Celestia has implemented CIP-10 , which establishes two methods for coordinating network upgrades:

  1. Pre-programmed height: Used for the Lemongrass network upgrade (v2)
  2. In-protocol signaling: Used for all subsequent upgrades (v3+)

Under the in-protocol signaling mechanism, validators submit messages to signal their readiness and preference for the next version. The upgrade activates automatically once a quorum of 5/6 of validators have signaled for the same version.

Announcement channels

Follow the latest network upgrade announcements on:

Upgrade process

The upgrade process can be broken down into a few steps:

  1. Celestia Improvement Proposals  (CIPs) are created for consensus-breaking changes and features that impact user experience. These CIPs are included in a meta-CIP, which define the scope of the upgrade.
  2. Celestia core developer teams implement the features defined in the CIPs.
  3. A new binary is released with the new features to be tested on testnets.
  4. Node operators upgrade to the new binary on Mocha testnet, and finally on Celestia Mainnet Beta.
    • Upgrades using pre-programmed height (v2) activate at a predetermined block number.
    • Upgrades using in-protocol signaling (v3+) activate one week after 5/6 of the voting power has signaled for a particular version

Configuration changes in v10

Existing configuration files

Replacing celestia-app does not add new settings or comments to existing configuration files. Missing settings use the binary’s defaults.

Starting with celestia-app v10.2.0, use config sync to add missing fields and their documentation to config/config.toml. Preview the additions first:

celestia-appd config sync --home ~/.celestia-app --dry-run celestia-appd config sync --home ~/.celestia-app

Use your node’s home directory if different. The command preserves existing values and creates a backup before writing changes. It does not run automatically on startup. Use it instead of the deprecated update-config command for v10 configuration maintenance.

RPC and storage settings

These settings apply to celestia-app consensus nodes:

Section in config/config.tomlSettingDefault
[rpc]max_concurrent_heavy_requests20
[storage]compactfalse
[storage]compaction_interval10000

The RPC setting caps concurrent heavy requests such as block_results and tx_search; public RPC providers may want to raise it. Blockstore compaction is optional and does not enable pruning. When enabled, it compacts the pruned range in the background. To compact an existing blockstore once, stop the node and run celestia-appd compact-blockstore.

See the Mocha release upgrade instructions  for details. Follow the upgrade announcement for your network before replacing its binary.

Network upgrade history

v7 (Hibiscus) was skipped on Mainnet Beta due to a bug discovered after testnet activation; v8 (defined in CIP-49 ) was activated instead.

In the Mainnet Beta table, version links point to Celenium upgrade status pages for signaling upgrades (v3+). v2 used a pre-programmed height and does not have a Celenium signaling page.

Mocha testnet

Mocha-5

App version 10 activated on mocha-5 at the height specified in the activation announcement . Bonded validators can now start and register their Fibre servers.

VersionDate and timeUpgrade heightParameters
v102026/09/24 20:20:15 UTC1082619 v10 

Mocha-4 (historical)

The upgrades below happened on the mocha-4 chain. Celenium now indexes mocha-5, so explorer pages for these historical upgrades and heights are no longer available.

VersionNameCIPDate and timeUpgrade heightDelay periodParameters
v2LemongrassCIP-17 2024/08/28 14:00 UTC2585031—v2 
v3GingerCIP-25 2024/11/14 18:31:11 UTC3140052—v3 
v4LotusCIP-33 2025/07/01 11:51:58 UTC69157862 daysv4 
v5——2025/07/30 17:07:29 UTC74011911 blockv5 
v6MatchaCIP-42 2025/10/03 01:25:02 UTC82368862 daysv6 
v7HibiscusCIP-47 2026/02/23 18:21:52 UTC102099862 daysv7 
v8—CIP-49 2026/04/16 14:26:21 UTC109415262 daysv8 
v9—CIP-50 2026/06/05 08:16:10 UTC116559912 daysv9 

Mainnet Beta

VersionNameCIPDate and timeUpgrade heightDelay periodParameters
v2LemongrassCIP-17 2024/09/18 14:00 UTC2371495 —v2 
v3 GingerCIP-25 2024/12/12 14:28:52 UTC2993219 —v3 
v4 LotusCIP-33 2025/07/28 13:46:27 UTC6680339 7 daysv4 
v5 ——2025/08/01 14:30:29 UTC6748821 1 blockv5 
v6 MatchaCIP-42 2025/11/24 12:33:12 UTC8662012 7 daysv6 
v7 HibiscusCIP-47 N/A (skipped, see v8)N/A——
v8 —CIP-49 2026/05/05 16:37:35 UTC10960599 7 daysv8 
v9 —CIP-50 2026/07/01 18:53:25 UTC11771699 7 daysv9 

Upcoming upgrades

Warning: You do not need to use a tool like cosmovisor  to upgrade the binary. Please upgrade your binary before signaling support for the new version.

Mocha has activated app version 10; see the Mocha-5 upgrade history. For upcoming upgrade schedules on each network, follow the network announcements .

Feel stuck? Go to our Discord!

Last updated on