CIP-50 - Celestia Improvement Proposals (CIPs)

cip	50
title	v9 Network Upgrade
description	Reference CIPs and parameter settings included in the v9 Network Upgrade
author	@jcstein
discussions-to	https://github.com/celestiaorg/CIPs/pull/399
status	Draft
type	Meta
created	2026-06-18
requires	CIP-48, CIP-38

Abstract

This Meta CIP lists the protocol changes included in the v9 network upgrade for Celestia Mainnet Beta. The primary change is CIP-48, which reduces the target block time from 6 seconds to approximately 3 seconds. The upgrade also applies the v9 upgrade handler parameter settings required to support the faster block cadence and updated Mainnet Beta operating envelope.

Specification

Included CIPs

CIP-48: Lower block time to 3 seconds

CIP-48 is state breaking and thus requires a breaking network upgrade.

Upgrade handler parameter settings

The v9 upgrade handler MUST set the following target values at the upgrade height. Some governance-modifiable parameters may already match these values before activation; the handler reaffirms the v9 release envelope.

Parameter	v9 value	Description
`consensus.Version.AppVersion`	9	Application version used to determine protocol rules for a given height
`consensus.block.MaxBytes`	32 MiB	Maximum protobuf encoded block size accepted by consensus
`blob.GovMaxSquareSize`	256	Governance parameter for the maximum original data square size
`consensus.evidence.MaxAgeNumBlocks`	559,940	Evidence age window in blocks, scaled to preserve the same wall-clock duration under faster block times
`ibc.ConnectionGenesis.Params.MaxExpectedTimePerBlock`	13 seconds	Maximum expected time per block used by IBC connection verification

The timeout, upgrade-delay, evidence-window, and IBC changes are specified in CIP-48. The consensus.block.MaxBytes and blob.GovMaxSquareSize values set the Mainnet Beta capacity envelope for the v9 release while remaining within the hard protocol limits introduced by CIP-38.

Operator configuration

The v9 release also changes node behavior around min-retain-blocks: non-zero values enable pruning, and archival nodes must keep min-retain-blocks = 0. This is operational guidance for node configuration and is not an additional protocol CIP included in the v9 network upgrade.

Rationale

This CIP provides a complete list of the CIPs and upgrade-handler parameter settings included in the v9 network upgrade. A separate Meta CIP makes the upgrade record easy to audit without duplicating the detailed block-time specification already maintained in CIP-48.

The v9 release is primarily about reducing confirmation latency by moving Celestia from 6-second blocks to approximately 3-second blocks. The upgrade-handler parameter settings preserve safety-relevant wall-clock windows after the block cadence changes and set the Mainnet Beta block and square-size parameters used by the release.

Backwards Compatibility

This upgrade is not backwards compatible. Consensus nodes must upgrade to a v9-compatible celestia-app release before the activation height. Nodes that continue running older software will not follow the post-upgrade chain.

Client applications and tooling that assume a 6-second block time SHOULD be updated to use the v9 block-time assumptions from CIP-48.

Reference Implementation

The reference implementation is celestia-app v9.0.4.

Security Considerations

This CIP does not have additional security concerns beyond those discussed in CIP-48 and CIP-38.

Validators and node operators should still account for the operational impact of the v9 release. Faster block times increase sensitivity to validator latency and node performance. Operators using non-zero min-retain-blocks should also be aware that pruning may run on startup and can take time on nodes with a large historical backlog.