On November 21st, Cardano’s mainnet diverged into two competing histories after a single fraudulent staking delegation transaction exploited a dormant bug in the new node software.
Over the course of approximately 14 and a half hours, stake pool operators and infrastructure providers watched blocks pile up on two separate chains. One was a “tainted” branch that accepted invalid transactions, and the other was a “healthy” branch that rejected transactions.
Exchanges paused ADA flows, wallets showed inconsistent balances, and developers raced to ship patched node versions that reintegrated ledgers under a single canonical history.
The funds never disappeared and the network never completely went down. Still, for half a day, Cardano lived through the scenario that Ethereum client diversity advocates warn about: a consensus split caused by software inconsistency rather than a deliberate fork.
Cardano co-founder Charles Hoskinson said he alerted the FBI and “relevant authorities” after a former stake pool operator admitted to broadcasting fraudulent delegation transactions.
The role of law enforcement here is to investigate possible criminal interference with protected computer networks under laws such as the U.S. Computer Fraud and Abuse Act. This is because intentionally (or recklessly) pushing an exploit into a live interstate financial infrastructure, even if it is purported to be a “test,” may constitute unauthorized interference.
This incident provides a rare natural experiment in how layer 1 blockchains handle validation failures.
Cardano remained live and blocks continued to come, but at the expense of temporal uniqueness, creating two legitimate-looking chains that had to be merged back together.
In contrast, Solana has repeatedly chosen the opposite tradeoff. If a single client encounters a fatal bug, the network will be brought down completely and restarted with coordinated human intervention.
Ethereum aims to sit between these extremes by running multiple independent client implementations, betting that a single codebase cannot drag an entire set of validators onto an invalid chain.
Cardano’s split and its resolution speed test whether a monolithic architecture with version skew can approximate the safety properties of true multi-client redundancy, or if we were just lucky.
bugs and partitions
Intersect, the Cardano ecosystem governance organization, traced the failure to a legacy deserialization bug in the delegation certificate hashing code.
The flaw entered the codebase in 2022, but remained dormant until it was exposed through a new execution path in Node versions 10.3.x to 10.5.1.
Around 08:00 UTC on November 21st, when a fraudulent delegated transaction carrying a hash that was too large hit the memory pool, new nodes accepted it as valid and built blocks on top of it.
Older nodes and tools that were not migrated to the affected code path correctly rejected transactions as malformed.
A single disagreement over verification split the network. Stake pool operators running buggy versions extended tainted chains, while operators using outdated software extended healthy chains.
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 the version of the node that processed the transaction.
As a result, a live partition occurred. Both branches continued to generate blocks based on normal consensus rules, but they diverged from a common ancestor and could not be reconciled without manual intervention.
This pattern appeared on Cardano’s preview testnet the previous day and was triggered by nearly identical delegation logic.
This testnet incident alerted engineers to the bug in a low-risk environment. Yet, this fix had not yet propagated to mainnet when a former stake pool operator who later claimed to have followed the AI-generated instructions sent the same fraudulent transaction to the production network.
Within hours, the chain split, and infrastructure providers were faced with the question of which fork to treat as canonical.
Safe failure without kill switch
Cardano partitions were automatically resolved through voluntary upgrades rather than emergency adjustments. Intersect developers and core developers have shipped patched versions of Node 10.5.2 and 10.5.3. These correctly rejected the fraudulent transaction and rejoined the healthy chain.
As stake pool operators and exchanges adopted the patch, the weight of consensus gradually shifted toward a single ledger.
By the end of November 21, the network had converged and the contaminated branch was abandoned.
This incident revealed an uncomfortable gap. Although two regular ledgers existed simultaneously, several boundaries prevented it from spilling over into deep reorganization and permanent loss of finality.
First, the bug existed in the application layer validation logic, not in Cardano’s cryptographic primitives or Ouroboros’ chain selection rules. Signature checking and stake weighting continued to work properly. This disagreement centered solely on whether the delegated transactions met the ledger validity conditions.
Second, the partition was asymmetric. Many key players, including legacy stake pool operators and some exchanges, ran software that rejected fraudulent transactions, ensuring that significant stake weight remained behind a healthy chain from the beginning.
Third, Cardano had a predefined disaster recovery plan based on CIP-135 that documented the process of adjusting around the canonical chain in more extreme scenarios.
The Intersect is prepared to invoke that plan as a fallback, but a voluntary upgrade proves sufficient to restore consensus under normal Ouroboros rules.
The narrow scope of the bug was also a problem. The flaw affected a specific hash deserialization routine for delegated transactions, a limited attack surface that can be patched and closed without requiring extensive protocol changes.
Once fixed, the exploit path disappeared and no generalizable class of malformed transactions remained that could cause future splits.
| Time (UTC) / Date | step | what happened | Detection/signal | relaxation step |
|---|---|---|---|---|
| November 20, 2025 – Evening | testnet precursor | Fraudulent delegation transactions are submitted to the preview testnet, exploiting a dormant deserialization bug in the hashing code, and causing a split between the “tainted” and “healthy” testnet chains. | Engineers and SPOs see abnormal behavior in preview. Since the bug is clearly reproducible, the incident is logged and a technical response is prepared overnight. | The core team will begin developing and testing hotfixes and updated node binaries to help reject the same malicious patterns in the future. |
| November 21, 2025 – around 08:00 | Malformed TX hits mainnet (T0) | A nearly identical fraudulent delegation transaction is later broadcast on Cardano mainnet from a wallet associated with the former stake pool operator. Newer node versions will accept this. Older versions reject it and create two conflicting chains. | Block explorers and monitoring dashboards begin to diverge. Some SPOs have noticed inconsistent chip hashes and delays in block generation. | Initial containment will be carried out according to procedures. Exchange and infrastructure teams will be directed to monitor for anomalies while engineers ensure mainnet behavior is consistent with the bugs in the preview testnet. |
| November 21, 2025 – After T0 minutes | Formal detection and publishing flag | Intersect and IOG classify this situation as a “temporary chain split” between a harmful chain and a healthy chain. Teams from Intersect, IOG, Cardano Foundation, EMURGO, and key SPOs will participate in a coordinated incident bridge. | Internal alerts fan out to the SPO channel. Intersect notes that each team was “warned within minutes.” Shortly after, a “Mainnet Incident Update” post is published on X, alerting the broader ecosystem that the fraudulent transaction caused the partition. | The exchange has suspended ADA deposits and withdrawals as a precautionary measure. SPO recommends not upgrading blindly and waiting for patched binaries to converge to a healthy chain. |
| November 21, 2025 – Late morning to afternoon | Hotfix release and upgrade campaign | Core developers have confirmed that the root cause is a bug in legacy hash deserialization that exists in certain recent Node versions and not in older Node versions. | Once the cause is understood, the risk of repeat fraudulent transactions is assessed and shared with SPO, CEX, and infrastructure providers in coordination channels. | Node patched versions 10.5.2 and 10.5.3 have been released with a deserialization bug fixed. SPOs, relays, and exchanges will be instructed to upgrade their stake weights to move them to healthy chains. The CIP-135 Disaster Recovery Plan is in place as a fallback in case the upgrade is delayed. |
| November 21, 2025 – until 22:17 | network reconverges | As upgraded nodes reject tainted branches and follow the healthy chain, the consensus density of Ouroboros shifts decisively towards a healthy ledger. A tainted chain continues only on a small number of unupgraded nodes. | Monitoring shows that block generation and chip hashes are once again consistent across major pools, explorers, and exchanges. Intersect confirmed that Cardano “never went offline” and only slowed down during the partition. | Intersect reports that all nodes spontaneously joined the main chain around 22:17 UTC, and the network converged to a single healthy chain within approximately 14.5 hours of the fraudulent transaction. A coordination working group has been established to handle transactions that exist only on the tainted branch. |
| November 22-23, 2025 | Post-incident mitigation and information disclosure | Attacker “Homer J” has publicly admitted that he used AI-generated instructions to create fraudulent transactions. The FBI and other agencies will be notified. A complete “Summary of Facts” report and ongoing post-mortem review will be published by Intersect. | The community and media receive an accurate reconstruction of the event. The myths about “protocol hacks” and “total outages” have been clearly debunked. | Longer-term fixes are aimed at expanding testing coverage of legacy code, accelerating upgrade cycles, increasing oversight, and a new focus on responsible disclosure and bug bounties rather than mainnet experimentation. |
Ethereum multi-client insurance policy
Ethereum treats client diversity as a first-order resilience property. Since the merge, Ethereum runs separate execution and consensus layers, each supported by multiple independent implementations.
On the execution side, Geth, Nethermind, Erigon, etc. process transactions and compute state transitions. On the consensus side, Prysm, Lighthouse, Teku, Nimbus, and Lodestar handle validator obligations and finality.
This architecture is intentional. No single codebase can impose invalid blocks on the network, and a single client bug should result in a local penalty rather than a chain-wide failure.
The strategy was tested. In early 2024, a bug affecting Nethermind’s consensus caused validators running its clients to experience delays during block processing.
Although these validators suffered a missing reward penalty, Ethereum’s canonical chain survived with the majority of client implementations and no forks occurred.
This incident validated the core theory that the network continues even if a minority client fails. Sufficient redundancy exists to prevent erroneous chains from terminating even if a large number of clients fail.
The Cardano split provides an unintended example of comparison. Although this bug existed within a single node codebase, the version bias between patched and unpatched releases effectively created two competing clients that could not agree on effectiveness.
Both versions had enough stake weight to maintain separate chains, so the partition appeared as a live fork rather than rejecting invalid blocks outright.
Ethereum’s multi-client model attempts to make such mismatches survivable by default. If Geth misunderstands a transaction, but Lighthouse, Teku, etc. reject it, the network will have to follow a largely independent implementation rather than a 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 in many ways.
Proponents of Ethereum’s client diversity explicitly frame these concentrations as systemic risks and push for a more even distribution precisely to avoid Cardano-style splits at the majority client level.
However, the principle remains the same. Independent implementations with independent bug surfaces make it less likely that a single validation error will cascade into network-wide events.
Trade-offs between stopping and restarting Solana
Solana occupies the opposite end of the design space. The network runs a single validator binary and runtime, and if that implementation fails, consensus typically stops completely rather than being split.
In September 2021, a flood of bot traffic during the Grape Protocol token launch caused Solana to exceed 400,000 transactions per second, exhausting validator memory and halting voting transaction propagation.
Consensus collapsed, and the network remained offline for approximately 17 hours until validators orchestrated a reboot with patched binaries.
In February 2024, a bug in the Berkeley Packet Filter Loader, a core component of on-chain program execution, halted block finalization for approximately five hours.
Engineers identified the problematic upgrade path, released a patched client, and restarted the cluster.
The pattern is consistent. Solana prioritizes uniqueness over chain uptime and accepts periodic complete outages as a cost of its monoclient, high-throughput architecture.
When a client fails, the chain freezes and is restarted under human coordination. The Cardano incident illustrates the opposite trade-off. In other words, liveness persisted, but the software forked created two chains, both of which continued to produce blocks.
Ethereum’s multi-client strategy attempts to avoid both failure modes by ensuring that a single bug cannot bring down the network or split the network into competing histories.
Key points for protocol designers
Cardano’s split highlights the need for aggressive fuzzing and fault injection around serialization and deserialization code, especially for legacy functions and rarely executed validation passes.
This bug was hidden in a hash deserializer that was introduced several years ago and was triggered only by a limited class of delegated transactions. This is exactly the type of latent defect that is often missed by standard tests.
Differential testing between client versions, ideally completely separate implementations, is a more basic measure.
| chain | client diversity | DoS surface | gossip hardening | replay protection |
|---|---|---|---|---|
| Ethereum | ✅ (Multi-client in both EL/CL, diversity is an explicit goal) | ⚠️ (MEV, mempool spam, BLOB/DA attack surface expansion) | ✅ (Gossip subnet, scoring, DOS-enhanced fork selection) | ✅ (Post-DAO, Replay Mitigation Standard, Chain ID) |
| Solana | ⚠️ (effectively one dominant validator client) | ⚠️ (History of DoS / Congestion and Runtime Bugs) | ⚠️ (QUIC, local fix, but vulnerability remains due to outage) | ✅ (No simple cross-chain replay, adjusted restart) |
| cardano | ⚠️ (Single main node codebase, multiple versions) | ⚠️ (Recent malformed TX split shows sensitive path) | ⚠️ (Gossip is true, but version bias + malformed certificates are still harmful) | ✅ (No obvious cross-chain replays, partitions are resolved by consensus) |
Ethereum research now treats client diversity as measured and encouraged, not just recommended, and precisely ensures that a single bug cannot silently redefine the validity rules for the entire chain.
Cardano used a pre-written disaster recovery plan based on CIP-135, combined with public incident communication from Intersect, to prevent the partition from developing into a coordination failure.
Although this plan was never fully activated, its existence created a clear focus for stake pool operators and exchanges to work together around the same chain.
Process discipline, documented playbooks, governance testnet fire drills, and transparent post-incident analysis are perhaps the most powerful parts of your response plan.
Finally, this incident highlighted a cultural gap regarding bug disclosure. The attackers chose to run a testnet exploit on mainnet rather than submit it through Cardano’s bug bounty program.
Intersect emphasized that the same conduct on the testnet could have been rewarded rather than criminalized, and reminded that clear and well-compensated disclosure channels remain the best way to prevent “try it on mainnet and see what happens” from becoming the default researcher attitude across all layer-1 blockchains.
(Tag translation) Cardano
