Introducing the Matcha upgrade: towards 128MB blocks
Celestia’s v6 upgrade, Matcha, is now live on Arabica testnet and on its way to Mainnet, marking the biggest upgrade yet.
Matcha enables Celestia to scale up to 128MB blocks with a new high-throughput block propagation mechanism. This represents a big step towards the Celestia roadmap’s core objective of scaling to 1 GB/s of data throughput and beyond.
Matcha also cuts inflation from 5% to 2.5% and makes Celestia a routing layer for any asset by removing the token filter for IBC and Hyperlane. Cutting inflation in half via CIP-41 improves TIA’s monetary properties, making it more suitable as DeFi collateral and prepares for a future upgrade to Proof-of-Governance. And CIP-39 will allow users to bridge any asset to any network, enabling future use as a routing layer for chains on Celestia and beyond.
Matcha changes coming to Celestia
The CIPs included in the Matcha upgrade are specified in CIP-42. They are:
- CIP-36 Lowering trusted period to 7 days
- CIP-37 Lower unbonding period to ~14 days
- CIP-38 Increase maximum block, square and transaction size
- CIP-39 Remove token filter for Hyperlane and IBC
- CIP-40 Privval interface extension for arbitrary message signing
- CIP-41 Reduce issuance to 2.5% and increase minimum commission to 10%
Also included in Matcha are patches for two network issues: the inability to claim rewards after moving stake, and broken ICA functionality (mostly used by liquid staking protocols).
In addition, the DA network will receive an upgrade on a similar timeline. This includes two non-consensus-breaking changes:
Matcha CIPs
Lowering trusting period to 7 days
CIP-36 reduces Celestia’s trusting period, the maximum time a node can safely remain offline without eternal trust, from 14 days to 7 days. The change also shortens the sampling window to 7 days, cutting storage needs for light nodes and bridge nodes by ~77% and improving sync speed.
CIP-36 also decouples the trusting period and sampling window from the minimum pruning window, allowing node operators to set the pruning window to longer than 7 days, based on storage considerations.
Lower unbonding period to ~14 days
CIP-37 reduces Celestia’s validator unbonding period from 21 days to 14 days and 1 hour, improving capital efficiency while maintaining network security guarantees. This shortened unbonding period still exceeds the 14-day trusting period used by IBC light clients, keeping the necessary window to detect and punish validator misbehavior before funds can be withdrawn. The additional 1-hour buffer accounts for timing variations, ensuring the unbonding period is strictly longer than any trusting period in use.
CIP-37 also updates parameters to more closely reflect Celestia’s current 5-second block time. Delegations undergoing unbonding at the time of the Mainnet upgrade will continue under the previous 21-day period.
Increase maximum block, square and transaction size
CIP-38 introduces a new high-throughput block propagation mechanism that will allow Celestia to safely scale to 128MB blocks. The more efficient block propagation mechanism replaces Celestia’s existing full-replication model. In addition, CIP-38 increases the maximum block size from 8MB to 128MB, the data square size from 128 to 512, and the maximum transaction size from 2MB to 8MB. This sets the stage for Celestia’s next block size increase, coordinated later via a community governance vote.
Remove token filter for Hyperlane and IBC
CIP-39 removes the token filter that restricts users from bridging non-native assets to Celestia. This change enables users to bridge any asset to Celestia and strengthens Celestia’s role as an effective routing layer for cross-chain assets that are in-demand by Celestia-native applications.
CIP-39 modifies the WarpKeeper configuration to support synthetic tokens and removes a specific filter in the IBC implementation that blocks non-TIA transfers. Backwards compatibility is preserved for TIA users and existing bridge functionality.
Privval interface extension for arbitrary message signing
CIP-40 extends CometBFT to let validators sign arbitrary offchain messages with their consensus keys. This change enables validators to securely participate in high-throughput and low-latency offchain protocols, such as the Full Mesh Overlay (peer identity and verification) and Vacuum! (blob commitment before block inclusion) without requiring separate key management systems (KMS).
The change adds two new protobuf message types to the existing interface, with additional required fields to distinguish protocols. Existing KMS users (beyond the default file) will need to use a fork that supports singing offchain messages.
Reduce issuance to 2.5% and increase minimum commission to 10%
CIP-41 reduces Celestia’s inflation rate from 5% to 2.5% and raises the minimum validator commission from 5% to 10%. Lower inflation improves TIAs monetary properties, making it more suitable as DeFi collateral while also preparing for a future upgrade to Proof-of-Governance. The annual disinflation rate remains unchanged, so inflation will continue to decline until the long-term 1.5% target is reached.
To maintain validator incentives despite reduced issuance, CIP-41 doubles the minimum commission rate, ensuring validators retain comparable revenue before and after the upgrade.
Matcha node upgrade
See the Matcha upgrade docs for more details on timing and how to update your Celestia nodes to run the Matcha upgrade.
DA network CIPs
Set pruning window to 7 days + 1 hour
CIP-34 reduces Celestia’s minimum data pruning window from 30 days to 7 days + 1 hour, dramatically reducing storage costs for bridge nodes from 30TB down to 7TB at projected throughput levels.
This change is designed to align with CIP-36, which sets the light node sampling window at 7 days, ensuring that pruned nodes can still serve all the required data during that period. The extra 1-hour buffer helps guarantee coverage for serving data throughout the full sampling window.
Header pruning for light nodes
CIP-35 introduces a pruning mechanism for Celestia light nodes, allowing them to retain only a fixed window of recent headers rather than the entire chain history. This change significantly reduces light node storage requirements to ~10GB.
Pruning is opt-in and fully backwards compatible. Operators who prefer can still initialize from genesis, or from any chosen point in the past by specifying a block height or hash. However, pruned nodes will not be able to retrieve historical headers older than their configured window.