Terra Classic v4.1.0 Released With Mempool and Tax Safety Fixes

Terra Classic developers have released Core v4.1.0 with several fixes focused on transaction reliability and protection against panic conditions in the tax module.

The release was published on October 4, 2026, and includes four listed changes: an app and CometBFT mempool parity fix, a reverse-charge panic fix, a tax division-by-zero safeguard, and an updated Terra REST API demo endpoint. GitHub currently marks v4.1.0 as a pre-release.

What Is Terra Classic v4.1.0?

Terra Classic v4.1.0 is a software release for the Terra Classic blockchain. Unlike a feature release that introduces major user-facing products, this version is mainly focused on fixing edge cases that could affect transaction processing and preventing certain parts of the tax system from entering a panic state.

The most important change is the fix for a mismatch between two mempools used by a Terra Classic node. The release also adds two safeguards to the tax module.

1. App and CometBFT Mempool Parity Fix

To understand this fix, it helps to know what a mempool is.

When a user sends a transaction, it does not immediately become part of a blockchain block. The transaction first waits in a temporary queue called a mempool. Validators use pending transactions from the mempool when building blocks.

Terra Classic uses the CometBFT mempool for transaction propagation, while the application also maintains its own view of pending transactions. These two views are supposed to remain synchronized.

According to the v4.1.0 upgrade proposal, a rare bug could cause the two lists to become different. A transaction could disappear from the application mempool while remaining in the CometBFT mempool.

That created a serious problem. Validators could continue receiving and sharing the transaction, but the transaction could no longer be included in a block. It could therefore remain stuck instead of being confirmed or rejected.

Because transactions from the same account must normally be processed in sequence, a stuck transaction could also prevent later transactions from being processed. The upgrade proposal describes a real mainnet incident involving a validator that was unable to complete an unjail transaction because of this type of stuck transaction.

How v4.1.0 fixes it

The fix has two important parts.

First, the dynamic commission handler no longer charges gas during block proposal preparation and verification, where messages are not actually executed. This removes the condition that could cause the two mempools to disagree.

Second, v4.1.0 adds a mempool parity check. After a block, the node checks the two mempools and removes a transaction from CometBFT if it is no longer present in the application mempool. Transactions that fail application admission are also removed from the application mempool.

In simple terms, the goal is to make sure a transaction cannot remain stuck between the two systems indefinitely. If a transaction is dropped, it can be sent again.

2. Reverse-Charge Panic Fix

The second major fix concerns the tax module and the IsReverseCharge check.

The previous logic assumed that a reverse-charge flag would always be available in the transaction context. If the flag was missing, the code could enter a panic.

With v4.1.0, a missing reverse-charge flag is treated as meaning that reverse charge is not enabled. This prevents the missing flag from triggering a panic.

For normal users, this is mainly a reliability improvement happening underneath the transaction-processing system.

3. Tax Division-by-Zero Safeguard

The third fix also addresses a potential panic in Terra Classic’s tax calculations.

Under a specific combination of governance-controlled parameters, the community-tax split calculation could attempt to divide by zero. The upgrade proposal identifies the combination as a community tax of 1.0 and an oracle split rate of 0.

v4.1.0 adds a safeguard around the divisor so that this situation cannot trigger the same division-by-zero panic.

The proposal also states that for other parameter values, including the current mainnet parameters, the calculation and its rounding remain unchanged.

4. Terra REST API Demo Endpoint Update

The release also includes an update to the Terra REST API demo endpoint in the project’s documentation. This is a documentation-related change rather than a major change to how LUNC transactions work.

Does v4.1.0 Change LUNC Fees, Taxes or Balances?

Based on the upgrade proposal, v4.1.0 does not introduce changes to user balances, fees, staking or the current tax calculation under normal parameter values.

The proposal states that there are no state migrations, no new modules and no parameter changes. It also says that the existing calculation and rounding remain unchanged for current mainnet tax parameters.

When Will Terra Classic Upgrade to v4.1.0?

This is an important point because the release of the software and the activation of the upgrade are two different events.

The v4.1.0 software has already been released. However, the mainnet upgrade timing should not yet be presented as finalized.

The upgrade proposal lists the proposal submission and voting dates as TBD. It gives block height 31,010,600 and approximately October 26, 2026 at 15:00 UTC as an estimate, but explicitly says the height can be corrected and the timing can shift because of block times and network load.

Therefore, the October 26 date should currently be described as an estimate in the proposal, not a confirmed upgrade date.

Validators and node operators are also instructed not to switch to v4.1.0 early because the new version changes how certain block proposals are accepted. The coordinated upgrade requires validators to move to the new version at the upgrade height.

What Does v4.1.0 Mean for LUNC Users?

For ordinary LUNC users, v4.1.0 is mainly a reliability and safety update rather than a change to the way Terra Classic is used.

The most important improvement is protection against transactions becoming permanently stuck because the node’s two mempool systems disagree. The two tax fixes also reduce the possibility of unexpected software panics under specific conditions.

Testing described in the upgrade proposal reproduced the stuck-transaction scenario on v4.0.2. After applying v4.1.0, the transaction was either included or properly removed, allowing subsequent transactions from the account to proceed. Additional bank, staking and CosmWasm smoke tests also passed.

Bottom Line

Terra Classic v4.1.0 is primarily a stability-focused release.

Its most significant fix addresses a mempool mismatch that could leave transactions stuck and block later transactions from the same account. Two additional changes protect the tax module from panic conditions involving a missing reverse-charge flag and a possible division by zero.

The software release is confirmed, but the mainnet activation schedule remains subject to the governance process. Any estimated upgrade date should therefore be treated as provisional until an official on-chain schedule is confirmed.