Developers David Burkett and Loshan led the response to severe network issues
Major mining pools collaborated with developers to mitigate attack damage
Litecoin project credited Burkett and Loshan for v0.21.5.5 release
Less than two weeks after the v0.21.5.4 emergency release that followed one of the ugliest chain reorganizations in the network’s 14-year history, the Litecoin project has pushed out Litecoin Core v0.21.5.5.
The binaries are live on the official download page, and the release notes are up on the Litecoin blog.
This is the fifth release in the 0.21.5.x series since March, a pace that tells you everything about the severity of what the network has dealt with over the past several weeks. The update hardens the MimbleWimble Extension Blocks (MWEB) privacy layer at the consensus level, fixes wallet and mining issues, improves node reliability, and plugs gaps exposed by real attacks on a live network.
The release is credited to developers David Burkett and Loshan, who have led the response through the most turbulent period MWEB has seen since its activation.
Why this release matters: The MWEB incidents in context
To understand why v0.21.5.5 is being treated as urgent, you need to understand what Litecoin has been through since March. It has not been a normal couple of months.
In March 2026, developers discovered a critical validation flaw in how MWEB inputs were checked during block connection. The bug was simple but devastating: while the mempool and block-building code properly validated MWEB input metadata against the referenced unspent output, the block connection path did not fully enforce that same check.
An attacker at block height 3,073,882 exploited this gap to fabricate an inflated peg-out of roughly 85,034 LTC from an input worth barely more than 1.2 LTC. In plain terms, someone turned one coin into eighty-five thousand by tricking the validation logic at the point where blocks get added to the chain.
The full details are laid out in the official postmortem. Developers coordinated privately with major mining pools, pushed emergency releases (v0.21.5 and v0.21.5.1), and froze the attacker’s transparent outputs. After being contacted, the attacker cooperated and signed a recovery transaction returning approximately 84,184 LTC, keeping 850 LTC as an agreed bounty.
Charlie Lee, the creator of Litecoin, personally purchased the 850 LTC shortfall so the full amount could be pegged back into MWEB at block 3,078,098 and the resulting output permanently frozen. No confirmed user funds were lost.
Then came April. A second actor attempted the same exploit path. This time, upgraded nodes correctly rejected the malformed block. But a new problem appeared: mutated MWEB block data caused certain mining RPC commands, including submitblock, to hang. The upgraded miners froze.
Meanwhile, unpatched miners kept building on an invalid chain that grew to 13 blocks before the valid chain overtook it, triggering a deep reorganization that rewound roughly 32 minutes of network history.
The April reorg caused real collateral damage beyond the Litecoin chain itself. Cross-chain bridge NEAR Intents confirmed exposure of approximately $600,000 after processing swaps of 11,000 LTC for 7.78 BTC on the invalid chain before it was orphaned. THORChain was also affected, though the amounts there were smaller.
The v0.21.5.4 release, which shipped on April 25, addressed the immediate crisis. Now, v0.21.5.5 builds on that foundation with a broader and deeper set of fixes.
MWEB consensus and validation: The core of the update
The biggest chunk of this release is focused on making the MWEB layer more resilient at every step of transaction and block validation.
The update adds new validation checks for MWEB inputs, pegins, HogEx data, kernel fees, and kernel lock heights across multiple commits. It hardens the math behind MWEB amount and fee calculations against integer overflow and invalid edge cases. This class of bug, where numbers get too large and wrap around to unexpected values, was directly involved in the March exploit.
There is also a new fallback for a rare edge case in hash-to-secret-key derivation, making sure that derived MWEB keys are always valid. Most users will never hit this, but when you are dealing with cryptographic key generation, “rare” is not the same as “acceptable to ignore.”
One of the more structurally important additions is new consensus parameters for known frozen or approved MWEB transactions and outputs. This is the mechanism that keeps the MWEB state balanced after the March recovery, where the inflated output was pegged back in and frozen. Without these parameters baked into the consensus rules, future nodes syncing from scratch would not know how to account for those historical exception blocks.
On the block-handling side, the update fixes how the node deals with mutated or invalid MWEB block data. This is a direct response to the April failure: previously, invalid data could leave stale information in memory or corrupt the cached chainstate, which is exactly what caused mining nodes to stall and opened the door for unpatched miners to build the invalid chain.
v0.21.5.5 makes sure corrupted data gets thrown out cleanly so the node can keep moving forward. It also updates MWEB chainstate handling during block replay and crash recovery, which matters for any node that needs to resync or come back from an unexpected shutdown.
Network, mining, wallet, and RPC changes
Beyond the MWEB consensus fixes, the release touches several other parts of the stack.
On the network side, the maximum P2P protocol message length has been bumped to 32 MB. This sounds like a minor tweak, but it solves a real problem: some valid MWEB blocks and messages were hitting the old cap, which could cause them to fail during propagation between nodes.
The update also now enforces standard script policy checks on pegout scripts, closing a gap where non-standard scripts could slip through during MWEB peg-outs.
For miners and pool operators, there are targeted improvements. The release avoids reading the previous block from disk when constructing HogEx transactions, instead pulling from MWEB data already stored in the block index. This cuts down on disk reads during block template construction, a small but meaningful optimization in a time-sensitive operation.
The getblocktemplate RPC also now accounts for fees and signature operations more accurately when transactions carry MWEB data. And there is a new safeguard that prevents MWEB transactions from being included in candidate blocks when their input and output commitments sum to zero, a condition that could have allowed economically empty transactions to waste block space.
On the wallet side, MWEB balance and pegout accounting have been fixed, meaning displayed balances should now correctly reflect the actual state of your MWEB transactions. MWEB view keys are now included in the dumpwallet output, which is a practical improvement for anyone who needs to back up or audit their wallet’s ability to scan the MWEB chain.
The sendrawtransaction and testmempoolaccept RPCs now support maxfeerate=0 for MWEB transactions, giving users and services the option to broadcast without a fee rate floor when the situation calls for it.
A smaller but useful quality-of-life fix: getblocktemplate now works on test chains even when the node is not connected to peers or is still doing its initial block download. This removes unnecessary friction for developers testing in isolated setups.
Bug fixes and build improvements
Several stability issues that could cause problems during exactly the kind of chain disruptions Litecoin has been experiencing have been resolved in this release.
The most significant is a fix for MWEB PMMR (Prunable Merkle Mountain Range) rewind corruption, along with better durability for MMR file writes. These are low-level data structure fixes, but they matter a lot during chain reorganizations, which is the exact scenario Litecoin has been living through.
Other fixes address a cache leaf bounds check error, a transaction index consistency issue that could surface if writing block data failed after the index was already committed, wallet loading compatibility with Boost 1.78 and newer, and a debug build logger conflict.
On the build and testing side, the release adds missing
What this change for everyday users, developers, and miners
If you are a regular Litecoin user with an MWEB-enabled wallet, this update means your balance display is more accurate, your node is better at recovering from crashes, and the MWEB layer is now running through far more validation checks before accepting any transaction as valid. In simple terms, the software is now much better at catching bad data before it can cause problems.
If you run a node, the fixes to stale block data handling and chainstate corruption are directly relevant. Node stalls during the April incident contributed to the 13-block reorg. This release closes those gaps.
If you mine or operate a pool, the getblocktemplate fixes and the HogEx construction optimization address production issues that affect block creation speed and fee accounting accuracy. The zero-commitment safeguard removes an edge case that could have been used to fill blocks with meaningless transactions.
If you are building on Litecoin, the expanded test suite and the getblocktemplate fix for isolated test environments lower the barrier to working with MWEB in development. The addition of MWEB view keys to dumpwallet makes it easier to build auditing, backup, and recovery tools.
The bigger picture
This release lands at an interesting crossroads for Litecoin.
On one hand, the MWEB incidents have been a serious test. A validation bug that allowed someone to mint 85,000 LTC out of thin air, a 13-block chain reorg, cross-chain losses, and five emergency patches in under two months is not something any project wants on its record. The episodes exposed real gaps in how MWEB validation was layered and how the network handled failure modes under adversarial conditions.
On the other hand, the response has been fast. Funds were recovered. The chain was never rolled back. The development team has been shipping fixes at a pace that shows they are treating this as an ongoing security effort, not a one-time cleanup.
And the broader Litecoin ecosystem continues to move. The LiteForge testnet for LitVM, Litecoin’s first EVM-compatible rollup, went live in mid-April and logged over 96,000 transactions within 24 hours. Spot Litecoin ETF applications from Grayscale, CoinShares, and Canary Capital remain under SEC review, with Bloomberg Intelligence analysts having previously assigned approval odds as high as 90%.
The U.S. Senate’s draft crypto market structure bill has included Litecoin among the tokens that would receive classification as a non-ancillary digital asset based on their inclusion in exchange-traded products.
All of that forward momentum, the Layer 2 expansion, the ETF pipeline, the regulatory recognition, depends on the base layer being secure and reliable. Five releases in under two months is not ideal, but it is the kind of urgency the situation demands.
Also Read: Fact Check: Charlie Lee Urges Investors to Ditch Litecoin for Bitcoin
Disclaimer: The information researched and reported by The Crypto Times is for informational purposes only and is not a substitute for professional financial advice. Investing in crypto assets involves significant risk due to market volatility. Always Do Your Own Research (DYOR) and consult with a qualified Financial Advisor before making any investment decisions.
Leave a comment