The Reth bug
According to Konstantopoulos, the flaw originated in Reth’s legacy state-root calculation system, which could return an incorrect result when processing certain smart contract storage configurations.
A state root is a cryptographic fingerprint representing a blockchain’s current state, including account balances and smart contract data. An incorrect calculation can cause nodes to disagree about the validity of a block, potentially disrupting transaction processing or network synchronization.
“Reth’s legacy state root code had an edge case,” Konstantopoulos explained, adding that a carefully crafted transaction could trigger the error under specific conditions.
Reth’s block-building software used the vulnerable calculation method on lower-end hardware and in networks built with Optimism’s OP Stack, extending the potential exposure beyond Ethereum’s mainnet infrastructure.
The Tempo development team discovered the issue through automated security testing. The testing technique, known as fuzzing, involves feeding software unusual or unexpected inputs to uncover errors that ordinary testing might miss.
Konstantopoulos said Tempo had also been patched, while Reth developers released version 2.10.0, Optimism published OP Reth v2.8.1, and Base issued version 1.5.3.
The Reth release classified the update as high priority for node operators, including those responsible for building blocks.
The coordinated response highlights a vulnerability in Ethereum’s increasingly interconnected software ecosystem: multiple blockchain networks can inherit the same underlying defect when they rely on shared execution software.
However, Konstantopoulos said the affected code did not expose users of Base and other OP Stack networks to faulty withdrawals.
He explained that these networks’ withdrawal systems were not vulnerable to the error, while ecosystem bridges generally rely on transaction receipt roots or multisignature authorization rather than the affected state-root calculations.
He also apologized for the disruption, emphasizing Paradigm’s responsibility for maintaining infrastructure used across the Ethereum ecosystem.
Base confirms user funds safe as LayerZero restricts cross-chain activity
Base separately confirmed that the vulnerability had not affected its users, providing additional details about how its security systems prevented the error from threatening the network’s integrity.
In a Nov. 5 status update, the Coinbase-backed network said it discovered the Reth issue on Nov. 4 and immediately patched its block builders.
The team also independently recalculated the blockchain’s state root to verify its accuracy.
Base said its proof system uses a separate implementation to verify state roots, providing an additional check capable of detecting discrepancies in calculations produced by Reth.
The network said:
“We’ve verified the current state root is correct and users were not affected.”
The version 1.5.3 release also addresses a separate operational consequence of the defect, preventing Base validators from halting when encountering invalid state roots.
Node operators were encouraged to upgrade, although Base said they would not need to resynchronize their nodes or take additional recovery steps.
Nevertheless, concerns about the software flaw prompted precautionary measures across parts of the decentralized finance ecosystem.
Frax Finance reported on Nov. 5 that cross-chain messaging protocol LayerZero had temporarily suspended certain transfer routes while developers assessed the situation.
Frax said its assets and smart contracts continued operating normally and that user funds remained safe.
The restrictions did not establish that LayerZero’s bridge contracts were vulnerable to the Reth defect. Instead, they demonstrated how concerns about shared blockchain infrastructure can prompt other services to restrict activity while assessing operational risks.
There were no confirmed reports of funds being stolen through the state-root calculation flaw.
Konstantopoulos said the coordinated patching effort had secured Reth-based infrastructure, including systems that depend on blockchain state proofs.
However, the availability of corrected software does not mean every independently operated node has installed it.
The remaining priority is for infrastructure providers and node operators to deploy the patched releases, while services that restricted activity determine when they can resume normal operations.
