In the v6.3.0 mainnet release, the team explicitly tells operators not to upgrade until an official announcement goes live via the usual channels. The warning is paired with a clear reason: this is a high-impact release and node operators are expected to verify performance, update KMS tooling, and update configs for stability. All of that is spelled out in the GitHub release notes.
For a network like Celestia, a “don’t upgrade yet” line is effectively an ops coordination signal. It implies there is a planned activation moment and a narrow tolerance for partial upgrades.
The same release notes frame v6 as paving the way for “32MB/6s blocks,” which is a direct step up in throughput expectations for the consensus layer and the data propagation path.
At peak capacity, the math looks like this:
| Target | Throughput | Rough Data per Day |
|---|---|---|
| 32MB every 6s | ~5.3 MB/s | ~450 GB/day |
These are back-of-the-envelope numbers at max fill. Real usage is usually lower, but the point is operational: bigger blocks compress more data into the same time window, which increases bandwidth pressure and can expose weak links in networking, disk I/O, and signing latency.
Celestia’s scale-up story here is not just a binary upgrade. It is a two-step progression:
That sequencing is made explicit in a governance-tracking issue that notes: after v6 activates, governance parameters still restrict blocks to 8 MiB, so a proposal is needed to raise the cap to 32 MiB. See the governance issue.
That is also why L2 monitoring is useful here. L2beat tracks a milestone for a “block size increase to 32MB,” framing it as an onchain governance vote to raise the cap from 8MB to 32MB. See the L2beat milestone entry.
Operator takeaway: the v6 binary upgrade and the onchain parameter change are related, but they are not the same event. Treat them as separate risk moments.
The scaling headline is fun. The operational requirements are what bite.
The v6.3.0 release notes call out several items that are easy to underestimate until you miss blocks:
The broader hardware picture in Celestia’s docs also reinforces that the network is planning for sustained high throughput. The official hardware requirements table sets expectations like 1 Gbps bandwidth for consensus nodes and high storage requirements for bridge and archival roles, with sizing assumptions tied to maximum throughput scenarios.
Celestia’s value proposition is modular scale, but scale is never free.
Bigger blocks and faster throughput can:
At the same time, the network must manage decentralization pressure:
Celestia’s architecture helps in one important way: light nodes can still verify data availability through sampling, which lowers the verification burden for many participants. But validators and full nodes remain the ones who must keep up with peak propagation and execution realities.
If you operate infrastructure, treat this as an upgrade you prepare for, then execute on the announced schedule.
Celestia’s v6 mainnet release is notable for two reasons: it tells operators to wait for the official announcement before upgrading, and it sets the foundation for higher throughput with 32MB blocks on a 6-second cadence.
The deeper story is the ops bar rising. As Celestia pushes scale, bandwidth, signing tooling, and node performance become stricter requirements, not optimizations.
That is where the scaling vs decentralization tension lives: bigger blocks can unlock real adoption, but only if the network can keep a broad, healthy operator set that can meet the new baseline.
The post Celestia v6 Mainnet: “Don’t Upgrade Yet” and the Road to 32MB Blocks appeared first on Crypto Adventure.
