On Nov. 21, Cardano’s mainnet bifurcated into two competing histories after a single malformed staking-delegation transaction exploited a dormant bug in newer node software.

For roughly 14 and a half hours, stake pool operators and infrastructure providers watched as blocks piled up on two separate chains: one “poisoned” branch that accepted the invalid transaction and one “healthy” branch that rejected it.

Exchanges paused ADA flows, wallets showed conflicting balances, and developers raced to ship patched node versions that would reunify the ledger under a single canonical history.

No funds vanished, and the network never fully halted. Still, for half a day, Cardano lived the scenario Ethereum’s client-diversity advocates warn about: a consensus split triggered by software disagreement rather than an intentional fork.

Cardano co-founder Charles Hoskinson said he alerted the FBI and “relevant authorities” after a former stake-pool operator admitted broadcasting the malformed delegation transaction.

Law enforcement’s role here is to investigate possible criminal interference with a protected computer network, under statutes like the U.S. Computer Fraud and Abuse Act, since deliberately (or recklessly) pushing an exploit to a live, interstate financial infrastructure can constitute unauthorized disruption, even if framed as “testing.”

The incident offers a rare natural experiment in how layer-1 blockchains handle validation failures.
Cardano preserved liveness, blocks kept coming, but sacrificed temporary uniqueness, creating two legitimate-looking chains that had to be merged back together.

Solana, by contrast, has repeatedly chosen the opposite trade-off: when its single client hits a fatal bug, the network halts outright and restarts under coordinated human intervention.

Ethereum aims to sit between those extremes by running multiple independent client implementations, betting that no single codebase can drag the entire validator set onto an invalid chain.

Cardano’s split and the speed with which it resolved test whether a monolithic architecture with version skew can approximate the safety properties of genuine multi-client redundancy, or whether it simply got lucky.

The bug and the partition

Intersect, Cardano’s ecosystem governance body, traced the failure to a legacy deserialization bug in hash-handling code for delegation certificates.

The flaw entered the codebase in 2022 but remained dormant until new execution paths exposed it in node versions 10.3.x through 10.5.1.

When a malformed delegation transaction carrying an oversized hash hit the mempool around 08:00 UTC on Nov. 21, newer nodes accepted it as valid and built blocks on top of it.

Older nodes and tooling that had not migrated to the affected code path correctly rejected the transaction as malformed.

That single disagreement over validation split the network. Stake pool operators running buggy versions extended the poisoned chain, while operators on older software extended the healthy one.

Ouroboros, Cardano’s proof-of-stake protocol, instructs each validator to follow the heaviest valid chain it observes, but “valid” had two different definitions depending on which node version processed the transaction.

The result was a live partition: both branches continued producing blocks under normal consensus rules, but they diverged from a common ancestor and could not reconcile without manual intervention.

The pattern had appeared on Cardano’s Preview testnet the day before, triggered by nearly identical delegation logic.

That testnet incident alerted engineers to the bug in a low-stakes environment. Still, the fix had not yet propagated to mainnet when a former stake-pool operator, who later claimed he followed AI-generated instructions, submitted the same malformed transaction to the production network.

Within hours, the chain had split, and infrastructure providers faced the question of which fork to treat as canonical.

Safe failure without a kill switch

Cardano’s partition resolved itself through voluntary upgrades rather than emergency coordination. Intersect and core developers shipped patched versions of node, 10.5.2 and 10.5.3, which correctly rejected the malformed transaction and rejoined the healthy chain.

As stake pool operators and exchanges adopted the patches, the weight of consensus gradually tipped back toward a single ledger.

By the end of Nov. 21, the network had converged, and the poisoned branch was abandoned.

The incident exposed an uncomfortable gap: two canonical ledgers existed simultaneously, but several boundaries prevented it from cascading into a deep reorganization or permanent loss of finality.

First, the bug lived in application-layer validation logic, not in Cardano’s cryptographic primitives or Ouroboros’ chain-selection rules. Signature checks and stake weighting continued to operate normally. The disagreement centered solely on whether the delegation transaction met ledger validity conditions.

Second, the partition was asymmetric. Many critical actors, including older stake pool operators and some exchanges, ran software that rejected the bad transaction, ensuring substantial stake weight remained behind the healthy chain from the start.

Third, Cardano had pre-positioned a disaster-recovery plan under CIP-135, which documented a process for coordinating around a canonical chain in more extreme scenarios.

Intersect is prepared to invoke that plan as a fallback, but voluntary upgrades proved sufficient to restore consensus under normal Ouroboros rules.

The narrow scope of the bug also mattered. The flaw affected a specific hash deserialization routine for delegation transactions, a bounded attack surface that could be patched and closed without requiring broader protocol changes.

Once fixed, the exploit path disappeared, and no generalizable class of malformed transactions remained available to trigger future splits.

Ethereum’s multi-client insurance policy

Ethereum treats client diversity as a first-order resilience property. Since the Merge, Ethereum has run separate execution and consensus layers, each supported by multiple independent implementations.

On the execution side, Geth, Nethermind, Erigon, and others process transactions and compute state transitions. On the consensus side, Prysm, Lighthouse, Teku, Nimbus, and Lodestar handle validator duties and finality.

The architecture is deliberate: no single codebase should be able to impose an invalid block on the network, and bugs in one client should result in localized penalties rather than chain-wide failure.

The strategy has been tested. In early 2024, a consensus-impacting bug in Nethermind caused validators running that client to fall behind during block processing.

Those validators suffered missed-reward penalties, but Ethereum’s canonical chain persisted on majority client implementations, and no fork occurred.

The incident validated the core thesis: if a minority client fails, the network continues. If a majority of clients fail, there is enough redundancy to prevent a false chain from finalizing.

Cardano’s split offers an unintended comparative case. The bug lived inside a single node codebase, but version skew between patched and unpatched releases effectively created two competing clients that disagreed on validity.

The partition manifested as a live fork rather than a clean rejection of invalid blocks, because both versions had enough stake weight to sustain separate chains.

Ethereum’s multi-client model tries to make that kind of disagreement survivable by default: if Geth misinterprets a transaction but Lighthouse, Teku, and others reject it, the network should follow the majority of independent implementations rather than any single binary.

The model has weaknesses. Geth often accounts for more than half of Ethereum’s execution layer, and Prysm has held an uncomfortable share of the consensus layer at various points.

Ethereum’s client-diversity advocates explicitly frame these concentrations as systemic risks and push for more even distribution precisely to avoid a Cardano-style split at the majority-client level.
But the principle remains: independent implementations with independent bug surfaces reduce the likelihood that a single validation failure cascades into a network-wide event.

Solana’s halt-and-restart trade-off

Solana occupies the opposite end of the design space. The network runs a single validator binary and runtime, and when that implementation fails, consensus typically halts outright rather than splitting.

In September 2021, bot traffic flooding a Grape Protocol token launch pushed Solana past 400,000 transactions per second, exhausted validator memory, and caused vote transactions to stop propagating.

Consensus broke down, and the network remained offline for roughly 17 hours until validators coordinated a restart with a patched binary.

In February 2024, a bug in the Berkeley Packet Filter loader, a core component of on-chain program execution, caused block finalization to halt for about 5 hours.

Engineers identified the faulty upgrade path, released a patched client, and restarted the cluster.
The pattern is consistent: Solana prioritizes chain uniqueness over liveness, accepting periodic complete outages as the cost of a monoclient, high-throughput architecture.

When the client fails, the chain freezes and restarts under human coordination. Cardano’s incident demonstrates the inverse trade-off: liveness persisted, but software divergence created two chains that both kept producing blocks.

Ethereum’s multi-client strategy attempts to avoid both failure modes by ensuring that no single bug can halt the network or split it into competing histories.

Takeaways for protocol designers

Cardano’s split underscores the need for aggressive fuzzing and fault injection around serialization and deserialization code, especially for legacy features or rarely exercised validation paths.

The bug hid in a hash deserializer introduced years earlier and only triggered by a narrow class of delegation transactions, exactly the kind of dormant flaw that standard testing often misses.

Differential testing across client versions, and ideally across entirely separate implementations, is the more fundamental lever.

Chain	Client diversity	DoS surface	Gossip hardening	Replay protection
Ethereum	(multi-client on both EL/CL, diversity an explicit goal)	(MEV, mempool spam, blob/DA attack surface growing)	(gossip subnets, scoring, DOS-hardened fork choice)	(post-DAO, replay mitigations standard; chain IDs)
Solana	(effectively one dominant validator client)	(history of DoS / congestion and runtime bugs)	(QUIC, localized fixes, but outages show residual fragility)	(no simple cross-chain replay; restarts coordinated)
Cardano	(single main node codebase, multiple versions)	(recent malformed-tx split shows sensitive paths)	(gossip solid but version skew + malformed certs still hurt)	(no obvious cross-chain replay; partitions resolved by consensus)

Ethereum research now treats client diversity as something to measure and incentivize, not just recommend, precisely to ensure that no single bug can silently redefine validity rules for the entire chain.

Cardano’s use of a pre-written disaster-recovery plan under CIP-135, combined with public incident communication from Intersect, kept the partition from escalating into a coordination failure.

The plan was never fully invoked, but its existence created a clear focal point for stake pool operators and exchanges to align around the same chain.

That process discipline, documented playbooks, fire drills on governance testnets, and transparent post-incident analysis, is arguably the strongest part of the response.

Finally, the incident highlights a cultural gap around bug disclosure. The attacker chose to run a testnet exploit on mainnet rather than submit it through Cardano’s bug bounty program.

Intersect stressed that the same behavior on testnet could have been rewarded instead of criminalized, a reminder that clear, well-compensated disclosure pathways remain the best way to prevent “try it on mainnet and see what happens” from becoming the default researcher posture across all layer-1 blockchains.

In a move towards a more diversified Ethereum execution client ecosystem, AllNodes, a staking provider, has announced its complete transition from Geth to Besu. With this shift, AllNodes has eliminated the use of Geth across its entire network of 23,895 nodes, marking a milestone in the ongoing efforts to reduce the current centralization around Geth, a majority client.

AllNodes Migrates To Besu

In a post on X, the non-custodial staking provider said the decision is a testament to the growing recognition of the need for a more robust and decentralized Ethereum ecosystem. Though Geth is the most widely used execution client for Ethereum nodes, analysts are concerned about its dominance and potential security vulnerabilities should it fall prey to a bug.

The transition to Besu aligns with AllNodes’ commitment to providing its clients with the most secure and reliable staking infrastructure. Besu, developed by ConsenSys, is a highly performant and secure execution client offering several advantages over Geth. 

This development significantly boosts its decentralization efforts for Rocket Pool, an Ethereum staking protocol that utilizes mini pools. Rocket Pool’s mini pool operators are free to leverage AllNodes’ staking and node hosting services. Even if some of Rocket Pool’s mini-pool operators still use Geth, the decision by AllNodes to switch to Besu further strengthens Ethereum’s resilience against potential client-side failures.

The current landscape of Ethereum validators still heavily favors Geth. Data from Client Diversity shows that over 75% of all validators rely on this client. However, in light of the current realization that client failures can negatively impact the network’s stability, more staking providers will likely diversify their base with others following AllNodes. If more validators are spread across Nethermind, Geth, Besu, and other clients, Ethereum will become more resistant to potential forks and security issues.

No Bailouts For Ethereum Node Operators If Geth Fails

One analyst on X, Marius, explained that anyone can use any client, even gravitating to the first and popular Ethereum execution client, Geth. However, the analyst insists there will be no “bailouts” if the network forks.

A buggy Geth will inevitably expose validators to the risk of catastrophic losses, triggering a network fork since it already controls over 66% of nodes needed for finality. Validators running that client could face slashing penalties of up to 32 ETH, effectively wiping out their stake.

The Ethereum network usually “slashes” the stake of validator nodes should their reliability drop below 100%. The longer they are offline, the higher the slashing penalty. 

Feature image from Canva, chart from TradingView

The Spot Bitcoin ETFs started trading on Thursday, January 11, 2024, marking a historic moment for the crypto arena. However, all’s not well with major Wall Street investment firms. Recently, Vanguard, Merrill Lynch, Edward Jones, and Northwestern Mutual have expressed strong criticism against Bitcoin ETFs. These firms noted that investing in these assets is banned for their clients.

Why are Wall Street firms against Bitcoin ETF adoption?

The above-mentioned firms are preventing retail investors from accessing the newly approved Spot BTC ETFs, as reported by FOX Business. These financial institutions have chosen not to provide their clients with exposure to the burgeoning crypto market.

The move contradicts the Securities and Exchange Commission’s (SEC) decision to approve 11 Spot Bitcoin ETFs. The SEC’s decision marked a pivotal moment for the crypto market, which is now nearing $2 trillion.

The inclusion of Bitcoin (BTC) in a regulated investment vehicle like a Spot ETF allows retail investors to access crypto asset investments through broker-dealers. This eliminates the need for reliance on unregulated crypto exchanges. Additionally, it eradicates the requirement for investors to qualify as accredited investors, a criterion for the Bitcoin futures ETF launched in 2021.

The restriction on this new cryptocurrency investment avenue has led some clients to reconsider financial institutions that embrace the opportunity. In a recent post on X, Yuga Cohler, Senior Engineering Manager at Coinbase, revealed plans to transfer his $401,000 savings from Vanguard to Fidelity. According to the FOX report, he rebuked the investment firm’s approach. He said, “Vanguard’s paternalistic blocking of Bitcoin ETFs does not fit in with my investment philosophy.”

Bitcoin ETF issuer BlackRock‘s competitor, Vanguard, defended its stance, stating that the new ETFs don’t align with the institution’s investment ideology. Moreover, the firm emphasized its commitment to aiding investors in generating positive real returns in the long run. Hence, they noted that the crypto space’s speculative and unregulated nature would obstruct them from achieving their goals.

On the other hand, the internal communication records of Merrill Lynch and its clients highlight its current policy prohibits investment in Spot BTC ETFs. However, there is a possibility of a policy change in the future. According to FOX Journalist Eleanor Terrett’s post on X, Merrill Lynch is going to monitor how the ETFs perform to make a final decision.

Also Read: Grayscale Dominates As Spot Bitcoin ETFs Debut With Over $4 Billion Trading

Will Spot BTC ETFs be banned?

Edward Jones and Northwestern Mutual have mirrored Vanguard’s approach. These firms have informed clients of their decision to join the Bitcoin ETF ban. This indicates that Bitcoin ETFs would be banned at an institutional level, especially among the major Wall Street investment firms.

However, eradicating these ETFs from the U.S. would never be possible, considering the SEC’s decision. If it considered a nationwide Bitcoin ETF ban, the regulatory body would never have approved the proposals. The first Bitcoin ETF was proposed in 2013, marking a decade-long effort to achieve the milestone. Hence, if the SEC has decided to approve the proposals now, it is most likely to stick to its decision.

Moreover, CoinRoutes CEO Dave Weisberger expressed his views on the Wall Street firms’ decision to ban Bitcoin ETF investments. He stated that it’s common for firms to conduct due diligence on individual ETFs before offering them to clients. However, he also noted, “Vanguard’s attitude shows it may have more to do with the asset itself, rather than the performance of the ETF.”

Also Read: Spot Bitcoin ETF: Vanguard Backtracks, Vows Not to Join the Train

✓ Share:

CoinGape comprises an experienced team of native content writers and editors working round the clock to cover news globally and present news as a fact rather than an opinion. CoinGape writers and reporters contributed to this article.

The presented content may include the personal opinion of the author and is subject to market condition. Do your market research before investing in cryptocurrencies. The author or the publication does not hold any responsibility for your personal financial loss.