FBI called as Cardano split in two by a single transaction: Lessons for ETH and SOL client diversity

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.

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.