Terra Classic Proposes v4.1.1 Upgrade to Fix Stuck LUNC Transactions and Restore Vesting Accounts
Terra Classic has a new software upgrade proposal aimed at fixing a critical transaction issue that can leave accounts unable to send transactions, alongside improvements to tax processing and vesting account functionality.
Submitted on October 12, 2026, the Terra Classic Core v4.1.1 upgrade proposal schedules a coordinated mainnet upgrade from v4.0.2 to v4.1.1. The update focuses on improving network reliability, fixing existing bugs, and ensuring affected accounts can function normally again.
The proposal does not introduce new modules, change network parameters, or require changes to existing blockchain state. However, validators must upgrade at the same block height because the new version changes how certain transactions and block proposals are processed.
Terra Classic Upgrade Targets Stuck Transactions
The main objective of v4.1.1 is to resolve a problem known as a stuck or ghost transaction. Under certain conditions, a transaction could be accepted by a validator but never included in a block or removed from the network’s transaction queue.
This issue could prevent an account from sending any subsequent transactions, even when the account itself and its funds remained intact.
According to the proposal, the problem occurred on Terra Classic mainnet and affected a validator that was unable to unjail its validator after being jailed. The transaction needed to restore the validator’s status was blocked behind an earlier transaction that never completed.
The incident required manual intervention with assistance from another validator running a patched node.
The v4.1.1 upgrade addresses the underlying cause and introduces an additional safeguard designed to prevent similar transaction problems from permanently blocking accounts.
How the Ghost Transaction Problem Works
When users submit transactions on Terra Classic, those transactions typically wait in a queue called the mempool before a validator includes them in a block.
Validators maintain two related transaction lists. One is used to share pending transactions with other validators, while the other is used to assemble new blocks. Both lists are expected to remain consistent.
However, a software bug could cause a transaction to disappear from the list used to build blocks while remaining in the list shared among validators.
As a result, the transaction could continue circulating between validators without ever being confirmed or rejected.
The problem becomes more serious because blockchain accounts process transactions in sequence. If one transaction remains permanently stuck, later transactions from the same account cannot proceed because they depend on the earlier transaction being resolved.
This can effectively freeze an account’s ability to transact, even though its funds are not lost.
How v4.1.1 Fixes the Problem
The upgrade introduces two important changes.
First, it corrects a gas accounting issue involving the dynamic commission module. The module was consuming additional gas during block proposal preparation and verification, even though messages were not being executed during those stages. This could cause certain transactions to pass initial checks but fail when a validator attempted to include them in a block.
Second, the upgrade introduces a mempool consistency safeguard. Validators will check that their transaction lists remain synchronized and remove transactions from the network’s shared queue when those transactions are no longer valid in the application mempool.
Together, these changes address the root cause and help ensure that a transaction dropped by the application does not remain stuck in the network’s transaction queue indefinitely.
The relevant fix is documented in Terra Classic Core pull request #689.
Two Tax Module Fixes Improve Network Stability
The v4.1.1 upgrade also includes two fixes designed to prevent the tax module from crashing during specific conditions.
The first addresses an issue involving the reverse charge flag. Previously, the software assumed that the flag would always be present in the transaction context. If it was missing, the application could trigger a panic. The new version treats a missing flag as meaning that reverse charging is not enabled.
The second fix addresses a potential division by zero in the community tax calculation. Under a particular combination of governance parameters, a community tax rate of 1.0 and an oracle split rate of zero could cause taxable transactions to trigger a panic.
The upgrade adds a safeguard to prevent this calculation error.
According to the proposal, the change does not alter tax calculations or rounding under other parameter settings, including the current mainnet parameters.
These improvements are intended to make the network more resilient to unusual configurations without changing the normal tax behavior experienced by users.
Upgrade Restores Access to Terra Classic Vesting Accounts
Another important component of v4.1.1 is a fix for accounts using Terra Classic’s LazyGradedVestingAccount structure.
Following the move to Cosmos SDK v0.53, these accounts could no longer be decoded correctly because they were not registered for the account interface used by the updated software.
This caused certain account queries, including account information and spendable balance queries, to fail. Transactions signed by affected vesting accounts could also fail because the software could not properly load the account.
The issue affects vesting accounts originating from the network’s genesis state. Although their funds were not lost, the accounts could not be used normally through the affected functionality.
The new software registers LazyGradedVestingAccount and BaseVestingAccount with the appropriate interface, allowing the affected accounts to be read and used again.
Importantly, the fix does not require a state migration or changes to existing account data. The accounts become accessible when the updated software is activated.
More technical details are available in Terra Classic Core pull request #692.
What the v4.1.1 Upgrade Means for LUNC Holders
For ordinary Terra Classic users and LUNC holders, the proposed upgrade is primarily a network reliability improvement.
The proposal states that the upgrade does not change transaction fees, taxes, account balances, or smart contract behavior. Users are not expected to take any action.
The key expected benefits include:
- Reduced risk of transactions becoming permanently stuck in the mempool.
- Better consistency between transaction queues maintained by validators.
- Protection against specific tax module errors.
- Restored functionality for affected vesting accounts.
- Improved reliability for validators and network infrastructure.
The upgrade is not a new tokenomics proposal and does not introduce a direct change to LUNC supply, burning mechanisms, or staking parameters.
However, the network is expected to pause briefly at the scheduled upgrade height while validators switch to the new software. Exchanges, infrastructure providers, and node operators must account for this interruption.
Validators Must Upgrade at the Same Block Height
Because v4.1.1 changes how certain block proposals are accepted and how transactions from affected vesting accounts are processed, validators cannot safely treat this as a routine rolling software update.
The proposal requires validators to continue running v4.0.2 until the designated upgrade height. Switching to v4.1.1 too early could result in differences in block proposal validation between nodes running different versions.
The proposed upgrade height is 31,010,600, where the network is expected to halt and wait for validators to activate the new version.
The chain will resume once validators representing more than two thirds of the voting power are running the upgraded software.
The proposal also reports that the core fixes were tested on an in place testnet based on real mainnet state. Testing reproduced the stuck transaction issue before the upgrade and confirmed that the scenario no longer caused the same account blocking problem after the software update.
Additional tests covering banking, staking, and CosmWasm functionality also passed during the rehearsal. The vesting account fix was added afterward and tested separately against affected mainnet accounts.
Terra Classic v4.1.1 Proposal Timeline
The proposal was submitted on October 12, 2026, and has a seven day voting period.
According to the proposed schedule:
- Proposal submitted: October 12, 2026, at 12:29 UTC.
- Voting period ends: October 19, 2026, at 12:29 UTC.
- Estimated mainnet upgrade: October 26, 2026, at approximately 15:00 UTC.
- Proposed upgrade height: 31,010,600.
The estimated upgrade date and block height remain subject to adjustment when the proposal proceeds to the on chain vote. Actual block times and network conditions can affect the final schedule.
Conclusion
The Terra Classic Core v4.1.1 proposal focuses on resolving technical issues that can affect transaction processing, tax calculations, and vesting account functionality.
Its most significant change is the fix for ghost transactions, which can leave accounts unable to process new transactions when pending transaction queues become inconsistent. The additional mempool safeguard is designed to prevent similar problems from permanently blocking accounts in the future.
For LUNC holders, the proposal does not introduce changes to tokenomics, taxes, fees, or balances. Instead, it aims to strengthen the reliability of the existing Terra Classic network.
If approved, the coordinated upgrade will require validators to switch to v4.1.1 at the designated block height, with a brief network halt expected during activation.
