Skip to Content
Welcome to our new docs! 🎉
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 Arabica devnet, 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

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.

Arabica devnet

VersionNameMeta-CIPDate and timeUpgrade heightDelay periodParameters
v2LemongrassCIP-17 2024/08/19 14:00 UTC1751707v2 
v3GingerCIP-25 2024/11/05 21:55:13 UTC2348907v3 
v4LotusCIP-33 2025/05/16 07:51:35 UTC59752651 dayv4 
v52025/07/29 19:59:00 UTC73164641 blockv5 
v6MatchaCIP-42 2025/09/09 06:08:11 UTC8105605 1 dayv6 
v7HibiscusCIP-47 2026/02/14 02:36:26 UTC10133989 1 dayv7 
v8CIP-49 2026/04/04 17:22:12 UTC10853352 1 dayv8 

Mocha testnet

VersionNameMeta-CIPDate and timeUpgrade heightDelay periodParameters
v2LemongrassCIP-17 2024/08/28 14:00 UTC2585031v2 
v3GingerCIP-25 2024/11/14 18:31:11 UTC3140052v3 
v4LotusCIP-33 2025/07/01 11:51:58 UTC69157862 daysv4 
v52025/07/30 17:07:29 UTC74011911 blockv5 
v6MatchaCIP-42 2025/10/03 01:25:02 UTC8236886 2 daysv6 
v7HibiscusCIP-47 2026/02/23 18:21:52 UTC10209986 2 daysv7 
v8CIP-49 2026/04/16 14:26:21 UTC10941526 2 daysv8 

Mainnet Beta

VersionNameMeta-CIPDate and timeUpgrade heightDelay periodParameters
v2LemongrassCIP-17 2024/09/18 14:00 UTC2371495v2 
v3GingerCIP-25 2024/12/12 14:28:52 UTC2993219v3 
v4LotusCIP-33 2025/07/28 13:46:27 UTC66803397 daysv4 
v52025/08/01 14:30:29 UTC67488211 blockv5 
v6MatchaCIP-42 2025/11/24 12:33:12 UTC8662012 7 daysv6 
v7HibiscusCIP-47 N/A (skipped, see v8)N/A
v8CIP-49 2026/05/05 16:37:35 UTC10960599 7 daysv8 

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.

No upcoming upgrades are currently announced.

Feel stuck? Go to our Discord!

Last updated on