Monad v0.16.4 Adds Snapshot Format Control and Clearer Block Gas Logging

Monad v0.16.4 Adds Snapshot Format Control and Clearer Block Gas Logging

September 28, 2026.

Monad's v0.16.4 release preview focuses on two practical operator concerns: distributing snapshots that other nodes can read, and seeing gas usage alongside transaction counts in proposed-block logs.

Neither change is a headline throughput upgrade. Both address the everyday work of running infrastructure: keeping recovery tools compatible during a rollout and understanding what a node is proposing without stitching together delayed execution output.

The supplied upgrade guide describes a rolling upgrade on top of v0.16.3, with no breaking changes to node.toml. Its instructions cover mainnet and testnet, but deployment dates are to be communicated through official channels. The preview changelog lists both dates as N/A. This is therefore a release preview, not an announcement that operators should upgrade immediately.

Snapshot Compatibility Is a Deployment Concern

A snapshot is useful only if the node restoring it can read it. That becomes an issue when the publisher upgrades before every consumer does.

The preceding v0.16.3 release introduced versioned snapshot-stream headers. Those headers make the format explicit and allow incompatible inputs to fail clearly. However, binaries predating the header cannot read that layout. A snapshot publisher changing its output can therefore disrupt consumers that have not yet upgraded, even if the publisher itself is healthy.

v0.16.4 adds a way to control that boundary. The new --snapshot-format option lets monad-cli choose the layout it writes when producing a snapshot dump.

According to execution PR #2566:

• v0 is the default output format, writing records without stream headers.
• v1 includes the versioned headers.
• The updated loader accepts streams with or without those headers.
• Unsupported format selections are rejected before the dump is written.

This gives publishers a deliberate transition path: retain the older output layout while consumers catch up, then adopt v1 when the receiving tools understand it.

It is a format-compatibility measure, not a guarantee that every old binary can restore every new snapshot. Network rules, state encoding, and other version requirements still matter. Operators should test a restore with the actual consumer binary they intend to support.

Why the Default Matters

In a mixed-version fleet, changing a default can have a wider effect than adding a new command-line option.

Keeping headerless v0 output as the default lets a publisher upgrade its own tooling without automatically forcing the new stream layout on every downstream user. The publisher can choose when to change that output instead of discovering the incompatibility during somebody else's recovery.

For teams operating snapshot services, the practical takeaway is to document the output format explicitly. A successful upload and a checksum match establish that an artifact was transferred intact; they do not prove that the target node can restore it.

A representative restore test is the stronger check. It should cover the producing tool, chosen format, and intended receiving version together.

AI-generated editorial illustration. The panels summarize snapshot export choice and proposal-level logging; they are not production screenshots or benchmark results. The hero image is also illustrative.

Gas Usage Becomes Visible in Proposed-Block Logs

The second change is smaller, but useful for anyone reading node output during an incident or a load test.

monad-ledger-tail now includes gas_used in its proposed_block log event, alongside the existing num_tx. Transaction count alone does not describe a proposal's gas footprint. Two proposals with similar counts can contain transactions with very different gas limits.

The implementation detail matters here. Consensus PR #3271 calculates the field by summing the proposed transactions' gas limits. Its explanation ties that calculation to Monad's post-MONAD_ONE behavior, where unused-gas refunds are zero. The information is available directly from the proposal rather than waiting for asynchronous execution results.

Operators should read the field in that context. It is proposal-level reporting, not a measurement of CPU time and not proof that the proposal has finalized. Monitoring that needs finalized-chain accounting should continue to establish that separately.

The value is immediacy: a log reader gets transaction count and the associated gas figure together. That can help distinguish a change in transaction volume from a change in the gas profile of proposed transactions.

A Rolling Upgrade, Not a New Fork Announcement

The v0.16.4 upgrade preview specifies the following operational scope:

| Item | Documented status | | --- | --- | | Upgrade path | Rolling upgrade on top of v0.16.3 | | Configuration | No breaking changes to node.toml | | Networks covered | Mainnet and testnet | | Deployment timing | To be communicated through official channels | | Package | monad=0.16.4 | | Verification | Services running, node advancing blocks, reported tag v0.16.4 |

The guide does not announce a new hard-fork timestamp. It also does not turn the existence of installation instructions into permission to move ahead of the network rollout.

Once authorized, operators should follow the complete official procedure. It stops the Monad service stack, installs the specified package, places the package on hold, and restarts the services before verification.

The package hold is important: it prevents ordinary package upgrades from silently moving the node onto a release that has not been approved for its network. If package-signature verification fails, the guide provides a signing-key renewal step; bypassing signature verification is not the documented remedy.

Checks Worth Adding to the Handover

After installation, monad-rpc -V should report the expected release tag. That version check is necessary, but it does not replace confirming that the services are running and the node is advancing blocks.

For this release, two additional checks are relevant to teams using the affected tools:

• Snapshot publishers: confirm the selected output format and test restoration with an intended consumer binary.
• Log-pipeline owners: check that parsers and dashboards handle the new gas_used field and retain its proposal-level meaning.

These checks connect the release notes to the systems around the node. A package upgrade can succeed while an external restore workflow or log parser still needs attention.

Small Changes with Specific Operational Value

v0.16.4 does not need to be presented as a broad performance breakthrough to matter.

Snapshot-format selection gives operators control over an otherwise awkward compatibility transition. Gas reporting makes proposed-block logs more informative without waiting for execution output. Both changes make routine infrastructure work easier to reason about.

For BitCtrl readers, this report covers the release preview and its operational implications. It does not claim a completed BitCtrl upgrade or a confirmed deployment date on either network.

Sources

• Monad v0.16.4 upgrade preview
• v0.16.4 changelog in the supplied preview
• Public Monad release changelog
• Execution PR #2566: snapshot-format selection
• Consensus PR #3271: proposed-block gas logging

The public changelog retrieved during preparation had not yet exposed the v0.16.4 section. Release-specific details above were checked against the supplied preview and its linked implementation notes.