Ethereum co-founder Vitalik Buterin pushed back on September 17 against the growing consensus that AI-driven hacking makes cybersecurity a losing battle.
"It's an increasingly common take that AI hacking means cybersecurity is doomed," Buterin wrote on X.
"I disagree. I think cybersecurity is naturally defense-favoring once people get their shit together."
He added that anyone still holding cryptocurrency, including himself with roughly 90% of his net worth, is implicitly betting on that thesis.
It's an increasingly common take that AI hacking means cybersecurity is doomed.
— vitalik.eth (@VitalikButerin) September 16, 2026
I disagree. I think cybersecurity is naturally defense-favoring once people get their shit together. And anyone who continues to hold cryptocurrency (including me, ~90% of my net worth) is implicitly…
Robinhood CEO Vlad Tenev responded within hours, endorsing the core argument in five words:
"AI will prove your code is correct."
The mathematical case Buterin is making
Buterin's argument rests on a specific analogy.
"If AI can prove Navier-Stokes and FLT, then AI can prove the statement 'this program is secure' as a mathematical theorem. Even if the program is very complicated," he wrote, referencing the Navier-Stokes equations and Fermat's Last Theorem as examples of problems requiring extraordinarily complex mathematical proof.
Fermat's Last Theorem went unsolved for 358 years until Andrew Wiles published a complete proof in 1995, a proof that ran to over 100 pages and required mathematical tools that did not exist when the theorem was first proposed in 1637. The Navier-Stokes existence and smoothness problem remains one of the seven Millennium Prize Problems designated by the Clay Mathematics Institute, each carrying a $1 million reward, and it remains unsolved as of 2026. Buterin's reference point is not that AI has definitively solved either problem, but that the class of reasoning required to approach them, formal, rigorous, exhaustive logical proof, is structurally similar to what would be required to prove a piece of software free of a defined category of vulnerabilities.
Why defining "secure" is the hard part
Buterin was explicit that the word "secure" conceals significant complexity. Using Signal, the encrypted messaging app, as his example, he laid out layers of security definition that go far beyond message confidentiality: whether an adversary can forge messages, whether attackers can block message delivery, whether malformed messages can crash a client, whether the Signal server itself could be compromised, and whether metadata like sender identity, recipient identity, and timing patterns leak information regardless of encryption.
He linked to an earlier post on formal verification for more detail, noting that "even definitions can be over a thousand lines of code, and need deep careful thought to figure them out."
Formal verification is a subfield of computer science that mathematically proves a program satisfies a given specification, rather than testing the program against a finite set of cases as conventional software testing does. The seL4 microkernel, developed by Australian research group NICTA starting in 2009, was the first operating system kernel to receive a complete, machine-checked formal proof of correctness, a project that took roughly 25 person-years to complete for a kernel of just 8,700 lines of code. That effort illustrates the traditional cost barrier Buterin's argument addresses directly: formal verification has historically been so labor-intensive that it was reserved for a small number of extremely high-stakes systems. His claim is that AI collapses that cost, making exhaustive verification tractable for far more software than the handful of projects that could previously justify the investment.
Why definitions scale better than code, according to Buterin
Buterin's key structural argument is that specifications are smaller and more tractable to verify than implementations, and that they compose in ways code does not.
"Definitions are also additive: if two groups have two different definitions A and B, then, well, you can just prove that the program satisfies both A and B," he wrote. "Code is not additive in this way: if a program is A + B, a bug in A or B can sink the whole thing."
He acknowledged the approach has limits.
"Sometimes, definitions are not much smaller than the implementation - UI components might be one example. But for many of the most critical components - message-passing protocols, sandboxes, cryptography like SNARKs and FHE - the asymmetry is real."
What this means for Ethereum's roadmap
Buterin tied the argument directly to Ethereum's development priorities.
"This is the kind of direction that Ethereum is going in for the next few years," he wrote. "There is no future for blockchains - especially blockchains with scalability and privacy - without doing this. We need to make software actually secure."
He also addressed a historical failure mode in verification efforts: teams verifying only a self-declared "critical" subset of code while leaving the rest unchecked, only to discover vulnerabilities in the supposedly non-critical portions.
"The solution today: sorry, you have to verify over literally your entire program, including database, networking, any caching layers, everything. Modern AI can do it," he wrote.
The Ethereum Foundation's own priorities post from September 7 included formal verification as explicit cross-cutting tooling supporting its zkEVM, post-quantum, privacy, and state research arcs, suggesting Buterin's framing here is not a standalone opinion but reflects a direction already embedded in Ethereum's stated technical roadmap.
Matvii Diadkov
Disclaimer: All materials on this site are for informational purposes only. None of the material should be interpreted as investment advice. Please note that, despite the nature of much of the material created and hosted on this website, HODL FM operates as a media and informational platform, not a provider of financial advisory services. The opinions of authors and other contributors are their own and should not be taken as financial advice. If you require advice, HODL FM strongly recommends contacting a qualified industry professional.
