The recent wave of incidents has affected ecosystems like Bitcoin, Klever, Zcash, Syscoin, Solana, Ethereum, Cosmos and BNB Chain, the protocols that bridge them, and — most recently — the Coldcard hardware wallets. It has brought an important discussion back to the surface: we are entering a new era of cybersecurity, and artificial intelligence is driving it.
But there is a detail that often goes unnoticed.
In most of these cases, blockchain consensus was never compromised.
We did not see successful attacks against the fundamentals that guarantee network integrity — cryptography, distributed consensus, or the economic security of validators. Those remain among the most resilient computing systems ever built.
What we saw were vulnerabilities in the layers above: DeFi protocols, NFT marketplaces, bridges, staking systems, business rules, and the complex integrations that make up modern ecosystems. And, as the Coldcard incident made painfully clear, in the wallet firmware that generates the keys long before a transaction is ever signed.
That distinction matters.
When a vulnerability is found in a protocol or an application built on a blockchain, it does not necessarily mean the blockchain itself failed. More often, it means a piece of code reached a state its creators never imagined was possible.
The history of technology is full of similar examples. A flaw in a banking app does not mean the Internet was compromised. In the same way, a vulnerability in a DeFi protocol does not imply a failure in the base protocol it was built on.
The Coldcard seeds: five years of a quiet mistake
The clearest illustration of all arrived while I was writing this, and it did not involve a smart contract at all.
On 30 July 2026, attackers drained 1,196 Bitcoin addresses in 41 minutes — roughly 1,082 BTC, about $70 million at the time. Galaxy Research later traced two further waves, bringing the total to around 1,367 BTC, close to $89 million, across more than 4,500 addresses. The victims were not users of some experimental protocol. They were people who had done what the entire industry tells them to do: buy a respected hardware wallet and hold their own keys offline.
The cause, documented by Block’s engineering team and confirmed in Coinkite’s own advisory, is worth stating precisely, because the precision is the lesson.
A firmware build check asked whether a configuration macro existed, when it should have asked whether it was enabled. Coldcard defines that macro as zero — it uses its own hardware random number generator wrapper — so the macro existed, the check passed, the build succeeded, and the library silently fell back to a deterministic software generator. That fallback was initialized from the chip’s UID, a timer counter and a real-time clock register: values that are, in Block’s words, “fixed or timing-derived rather than randomly sampled” and “correlated rather than independent.”
Wallet seeds that were supposed to carry 128 bits of entropy were generated with an effective ceiling of roughly 40 bits on the older Mk2 and Mk3 devices, and about 72 bits on the Mk4, Mk5 and Q. For current devices the practical search collapses to around two billion candidates — a number you can exhaust on rented hardware. Anyone holding a public address could work backwards to the private key offline, with no network access and no trace.
The flaw shipped in firmware v4.0.0 on 17 March 2021. It was discovered on 30 July 2026 — not by an audit, but because someone was already spending the money.
Notice what did not fail here, because this gets misreported constantly. This was not a cryptographic failure. It was a software defect.
Nothing was broken in secp256k1, in the key derivation, or in the signing. Bitcoin’s consensus produced blocks the entire time, and every algorithm involved did exactly what it promises to do. But what those algorithms promise is conditional: their strength assumes the key was drawn uniformly at random. That assumption is an input, not a property of the mathematics. Starve it and no cipher, curve or hash function anywhere in the stack can compensate — a perfect algorithm over a predictable secret is a predictable secret. The math was never the weak link, and strengthening it would have changed nothing.
The actual failure was one preprocessor directive in the firmware of a device sitting one layer above the protocol — an ordinary build-configuration mistake, of the kind that lives in every codebase in this industry, in the most security-conscious corner of it, inside a product whose entire purpose is to be the careful choice.
That is the whole argument of this article, compressed into a single line of C.
The shift nobody announced
What strikes me about these recent incidents is not the existence of vulnerabilities. It is the change in the pattern of the attacks.
A few years ago, most incidents were concentrated in relatively isolated smart contract bugs. Today we increasingly see attacks that exploit trust relationships between systems, complex integrations, cross-chain bridges, operational infrastructure and human processes.
In other words: the attack surface is no longer just the code. It is the entire ecosystem.
The interesting question stopped being “is there a bug in this contract?” and became “where do these systems trust each other, and what happens when one of them lies?”
This is not opinion — it is measured
It is precisely in this context that artificial intelligence starts to play a transformative role — and this is where I want to be careful to separate what I believe from what has actually been documented.
In March 2026, the Malanta Research Team published a technical report titled AI.Attackers, analyzing the shift from automated to autonomous, AI-orchestrated cyber operations. Its central argument is not that AI makes individual attacks more sophisticated. It is that AI is industrializing the production of offensive infrastructure itself.
The numbers are worth sitting with.
Malicious repositories on GitHub grew from 6,498 in 2022 to roughly 110,000 in 2024 — about 1,592% growth, or nearly seventeen times, with a parallel acceleration of 285–340% across GitLab and Bitbucket in 2023 and 2024.
The report also examined 33 attack infrastructure clusters. On average, each one held 61 domains, 88 subdomains, 35 SSL certificates and 11 social media accounts. Roughly 82% of the domains associated with those clusters had not triggered a single security vendor detection. The average window between registering a domain and using it for overtly malicious purposes was 72 days. The mean estimated cost of building one of these clusters was about $9,223.
Read those last two figures together, because that is where the story lives. An adversary can assemble a complete, largely undetected attack infrastructure for the price of a used car, and then sit on it for over two months before anyone has a reason to look.
That is not a smarter attacker. That is a production line.
The most striking single data point comes from a campaign Anthropic disclosed in November 2025, tracked as GTG-1002, in which a state-linked operator turned an agentic coding assistant into an autonomous intrusion platform against roughly thirty global targets. The AI performed an estimated 80–90% of the campaign — reconnaissance, exploitation, credential harvesting, lateral movement and exfiltration — with human operators intervening at only four to six strategic decision points.
Google’s Threat Intelligence Group reached compatible conclusions from an entirely different vantage point. In its AI Threat Tracker published in May 2026, GTIG documented the first case it had seen of a threat actor deploying an AI-generated zero-day exploit, malware families that call a model at runtime to rewrite their own code, and an Android backdoor that serializes a phone’s interface into structured text, asks a model what to tap, and translates the answer back into gestures. It also described threat actors building account-pooling and anti-detection middleware to keep high-volume access to premium model tiers — what the report calls “effectively industrializing their adversarial workflows.”
Three independent sources, three different methods, one direction of travel.
The defender’s inbox changed too
Here is where the honest version of this story gets uncomfortable, because the same wave landed on the defensive side — and it did not arrive as a clean win.
In January 2026, the curl project ended its bug bounty program after six years, 78 confirmed vulnerabilities and roughly $86,000 paid out. The reason was not budget. It was a sustained flood of AI-generated reports that consumed maintainer attention without producing findings. Triage itself became the denial of service.
And yet, in the same period, autonomous agents began finding real bugs that humans had missed. Google’s Big Sleep agent identified a live SQLite vulnerability, CVE-2025-6965, that was known to threat actors, and Google has since described using the same capability to prevent an imminent exploitation.
Signal and noise both went up. That is the actual shape of this technology, and anyone selling you only one half of it is selling you something.
A new clock: Mean Time to Preempt
The sharpest idea in the Malanta report is not a statistic. It is a metric.
The numbers we manage security by — MTTD, mean time to detect, and MTTR, mean time to remediate — share a hidden assumption. Both start counting after the attacker has already reached you. They measure how gracefully you lose the race, not whether you were ever in it.
The report proposes a third: MTTP, mean time to preempt — the interval between observing an adversary preparing and taking action against that preparation. Given those 72 days between domain registration and hostile use, and the 82% of that infrastructure that no vendor had flagged, the preparation phase is not a theoretical window. It is the longest, quietest and least contested part of the entire attack.
Go back to the Coldcard numbers with that lens. The exposure lasted five years. The offline key search left no trace anywhere. The theft itself took 41 minutes. There was no detection window worth the name — by the time anything was observable on-chain, the outcome was already settled. Mean time to detect is a meaningless metric against an attack shaped like that, and remediation had nothing left to remediate.
Malanta has since extended the idea into what it calls an Indicator of Pre-Attack, or IoPA — the pre-attack counterpart to the indicator of compromise every security team already lives by. The distinction the authors draw is a good one: an indicator of compromise is high confidence about the past, while an indicator of pre-attack is probabilistic about the future. A security operations center running only on indicators of compromise is, by construction, one that only ever moves second.
Defense has to move left, into the attacker’s preparation phase. That is the real argument for treating AI as infrastructure rather than as a tool — because nothing else operates at the scale that phase requires.
Not whether, but how
The same capability that strengthens defenders strengthens adversaries, at the same time and at the same scale. Everything that helps us read an enormous codebase helps someone else read ours. There is no version of this technology that only helps one side.
Which is why AI has stopped being seen purely as a productivity tool. It is gradually being treated as strategic infrastructure. The recent debates around frontier models, access controls, regulatory limits and national security concerns show that governments and companies already view certain AI capabilities through a very different lens than they did just a few years ago.
The reason is simple. Modern models can analyze large codebases, identify suspicious patterns, accelerate audits, assist security research and significantly increase the productivity of technical teams. But those same capabilities can be used to discover vulnerabilities, automate offensive analysis and lower the barrier to entry for attackers.
That shift cuts across everything. The same autonomous agents that I have argued will become economic actors in their own right are, in the security domain, already operating as adversaries. It is one technology, arriving everywhere at once.
So the question is no longer whether we should use AI in software and security engineering.
The question is how to use it responsibly, efficiently and safely.
How we are building for this
At Klever, we have invested heavily in this direction, building on work we have described before on AI-assisted smart contract development and on the security posture behind the chain itself. We are building a full stack of AI-assisted engineering, composed of specialized models, MCPs, guardrails, automated review flows and agents focused on different areas of analysis.
We built an internal environment we call the AI War Room, where multiple agents analyze the same code through distinct perspectives: security, quality, architecture, protocol consistency, adversarial analysis and operational risk. They do not take orders. They ask the questions a single reviewer would not think to ask.
We also developed AgentForge, an internal adversarial review framework for changes that touch financial assets, cryptographic keys, critical consensus state or sensitive infrastructure components.
One agent tries to build the exploit.
Another tries to prove it does not work.
The results are crossed, compared and validated before anything moves forward.
Nothing here is pattern matching. The disagreement between the two agents is the signal.
A build-configuration change that quietly redirects where key material comes from is exactly the class of change this is meant for. I want to be careful here: I am not claiming we would have caught the Coldcard bug. Nobody gets to make that claim about a defect that survived five years and every eye that looked at that firmware. The point is narrower — a review pass that asks “prove this key is actually unpredictable” is a different question from “does this build compile and behave,” and only the first one has any chance of failing loudly.
And still, we were hit
Even so, we were recently affected by a vulnerability.
And perhaps that is the most important lesson of all.
Security is not a final state.
There is no perfect software. There is no perfect protocol. There is no perfect audit. There is only a continuous process of learning, adapting and improving.
The blockchain industry is maturing. Artificial intelligence is accelerating that transformation. And all of us — developers, researchers, companies and communities — are learning together how to navigate this new reality.
The goal is not to achieve perfection.
The goal is to evolve faster than the threats.
