There has been a lot posted about AI breaking crypto these past days. Let me attempt to sort the good from the bad. It started with OpenAI solving a whole bunch of math problems: xitter.cf/OpenAI/status/21075967… Maybe if we had poured the same amount of money into university math departments, humans would have solved all this a long time ago. But nonetheless, really impressive, solid work. So, if AI can do all that, maybe it can break the crypto systems we are using now. That is a reasonable question, and every serious cryptographer is thinking it. What is not reasonable is Justin Drake’s post about it, where he suggests that ECDSA might be vulnerable to AI and we should consider going into “bunker mode” by moving funds to accounts where the public key hasn’t been revealed: xitter.cf/drakefjustin/status/21… Of all the different cryptographic schemes he could have picked on for such a post, why choose ECDSA? There is no evidence that AI is making any progress towards breaking elliptic curve cryptography (on which ECDSA is built). There are so many other more fragile cryptographic schemes that would have made for a more reasonable post. But let’s get a little paranoid for a minute, and assume that AI is about to break elliptic curves. Then going into bunker mode on a chain like Ethereum is bizarre at best, because the whole consensus is built on elliptic curves. If AI can break elliptic curves, there is no more consensus, and therefore no more Ethereum. The consensus layer needs to be upgraded before AI breaks elliptic curves; otherwise the bunker is pointless. Drake’s post might have been semi-reasonable coming from a paranoid Bitcoin maxi, because Bitcoin’s proof-of-work will most likely not be broken by AI (or quantum computers; that is why @QMSNetwork is also building on proof-of-(useful-)work. Sorry for the self-promotion. Back to the topic.) So if we take Drake’s reasoning to the end, we should all leave Ethereum and go to Bitcoin to hide our tokens there. But he is an Ethereum researcher; he can’t be advising people to migrate to Bitcoin. He really gives the impression of not having thought this through. So, back to the claim that AI could soon break ECDSA. I recommend reading the series of posts from Yehuda Lindell, who explains really well why this isn’t reasonable: xitter.cf/LindellYehuda/status/2… Some other reactions are funny, like Jacob Creech from Solana talking about future upgrade paths, which is beside the point: xitter.cf/jacobvcreech/status/21… The point of bunker mode is to hide your funds while waiting for chains to deploy upgrade paths. Since Solana doesn’t have an upgrade path ready yet, that is an argument for going into bunker mode, not against. Not sure how he arrived at the opposite conclusion from where the argument was taking him. So back to the AI threat. It seems unlikely that AI breaks elliptic curves before quantum computers do. But whichever comes first, the real discussion is about what post-quantum schemes we should use, and which of them are also post-AI. And this is what Vitalik’s post is about: xitter.cf/vitalikbuterin/status/… It is fairly reasonable, but it is a promotion of Ethereum's chosen PQ path forward. If Vitalik had posted this out of the blue, it might have raised a few eyebrows, because the AI threat to PQ schemes like ML-DSA is unsubstantiated as far as I know (though more plausible than for ECDSA). But straight after Drake’s post, Vitalik’s sounds so much more reasonable.

We’re releasing a broad range of new mathematical results produced by an internal frontier model. We’ve been consulting with the independent Advisory Group on Mathematics and Artificial Intelligence at the Institute for Advanced Study, and we have drawn on their advice and public recommendations to inform how we release these results. github.com/openai/math

QMS Testnet is now live. Our first public release. The EVM-compatible execution layer is open: → Add QMS Testnet to your wallet → Claim free test tokens from the faucet → Swaps and LP on @QWAP_xyz → View transactions on the block explorer qms.finance/news/welcome-to-…

The QMS white paper is now live. It outlines the network we’re building: a layer 1 for the post-quantum era, featuring proof-of-useful-work consensus, no public-key signatures in block production, a separate post-quantum finality layer, EVM-compatible execution, and a path for quantum hardware to join the miner network. The final section covers how we plan to roll these pieces out progressively over time. Full white paper: docs.qms.finance/whitepaper

The QMS white paper is now live. It outlines the network we’re building: a layer 1 for the post-quantum era, featuring proof-of-useful-work consensus, no public-key signatures in block production, a separate post-quantum finality layer, EVM-compatible execution, and a path for quantum hardware to join the miner network. The final section covers how we plan to roll these pieces out progressively over time. Full white paper: docs.qms.finance/whitepaper

A proof-of-useful-work (PoUW) protocol is a proof-of-work (PoW) protocol with the added bonus that clients pay miners for good solutions. We understand very well the underlying PoW protocol: miners perform work to generate a block, if they really did the work, the other miners accept their block and build on top. The verification here doesn’t depend on solution quality, this is crucial to the security proof. Miners find solutions (even bad solutions, e.g., a long routing path or a bad portfolio), hash them, and if the hash result starts with enough 0, they get to build a block. The verifiers only need to check the few solutions that win the block lottery. They check that the correct algorithm was executed with the correct randomness. This is a tiny step which takes a few ms, very efficient. The security of the chain is guaranteed. Miners are now forced to run the correct algorithm to build blocks, and when they find great solutions, the client pays them extra (regardless of whether this solution allowed them to build a block). We would recommend reading the CRYPTO 2022 paper, “Ofelimos” by Fitzi et al., to understand better how PoUW works.

Before QMS produces its first block, prove you were here. We're building a Layer 1 for the post-quantum era. The Quantum Early Access Pass is now live. Claim yours for beta testnet access and share it on X: qms.finance/#waitlist

The community has spoken. Congratulations to Viktor Ihnatiuk, Christopher Portmann, and Jareau van den Heuvel on being elected to the 2026 Concordium Governance Committee. Thank you to everyone who voted, every candidate who took part, and the outgoing Governance Committee members for their service and contributions. 🔗 Read more: concordium.com/article/2026-…

$450B in Bitcoin sits in addresses a quantum computer could crack. We made a video on it — full breakdown below.

Two weeks ago, Ethereum researchers met in Berlin to continue charting the protocol's long-term trajectory, following along discussions with client teams in Svalbard in April. The updated strawmap is at strawmap.org, and I attached a picture of it to this post. My own high-level takeaways: * "Lean Ethereum" is not a single one-shot upgrade, it is a collection of improvements that will come online to the Ethereum network over the course of three or four years. But make no mistake, this IS the third major iteration of Ethereum in the same way that the Merge was the second. Almost every major piece of the protocol will be replaced: - Verification through recursive STARKs, rather than direct re-execution. Recursive STARKs become an enshrined first-class core component of the protocol - Replacing everything quantum-vulnerable with quantum-safe alternatives - Consensus: decoupled available chain and finality, one or two-round finality. Theoretically optimal security properties, simpler than today, and faster than today - Multidimensional gas - State: not just tree structure, but what *types* of state are available - Changes to client architecture ... At the same time, simplification, cleanup and future-proofing. And this will all be done in a way that minimizes disruption to existing application. We've done this before (the Merge), we can do it again. * H-star (aka Hegota) is probably Ethereum's last thematically "pre-Lean" fork. Starting from I-star, most of everything we do will have a very strong "Lean" feel to it in one way or another. * Privacy is no longer an afterthought, it is a first class goal. When designing Frames, the mempool, additions to the state tree, we explicitly ask the question "okay, how do quantum-safe, intermediary-free privacy protocol transactions go through this, and what is the overhead?" * Formal verification of everything for security. * FV also makes us much more comfortable with canonicalization (having pieces of the protocol that are directly defined as a piece of bytecode expressed in some language). evm-asm is being written in part to become a canonical proof system for the EVM. * Quantum safety has shifted up a LOT in priority. This adds a lot of work (eg. finalizing a quantum-safe blobs design has become urgent; this work has already been ongoing for months) * Probably the single most disruptive part of the plan is the changes to state. There is growing consensus around leaving present-day-style "dynamic state" mostly unchanged, but scaling it only a medium amount, and adding new types of state that are more scalability-friendly (eg. no need for builders to sync/store all of it) but more restrictive, and that will scale a large amount. eg. possible Ethereum in 2030: 2 TB of present-day-style (dynamic) state, and 100 TB of new-style (scalable but restrictive) state This "new-style" state would work very well for ERC20s, NFTs, many defi use cases, but not eg. highly "central" objects like Uniswap contracts, or onchain order books, or other complex things (which are crucial for Ethereum but which only take up a small percentage of state) Hence, it will not be *necessary* to rewrite any apps, but it will be *very cost-effective* to eg. rewrite an ERC20 token into a newer design that uses a new type of UTXO storage that is currently being explored, so that it will have >10x lower txfees. Design of these new state types (current ideas: keyed nonces, ring buffers, UTXOs, statically accessible state, temp state) is an area where we will need a lot of feedback from application developers (incl. privacy-friendly application developers) and probably several rounds of rethinking and iteration. * In the context of a much larger total state size, we need to figure out the incentive issues around who stores this state and what motivates them to. Even saying "each node stores 1%" is not good enough - why do they store that 1% and why are they willing to serve it? This is being elevated as a first-class research area. * Ethereum will need to have a "VM" other than EVM in one form or another - at the very least, we need something like leanISA for recursive STARKs - and the gains are large in exposing it to users so that we support programmable privacy and better scalability. Right now, the most likely contenders are leanISA and RISC-V. My own ideal is that in this world, we adjust the protocol so that the EVM becomes a high-level-language compiler-level feature, and the protocol only "sees" RISC-V / leanISA directly. But this is still far away. * Gas limit increases, blob increases and slot time decreases will happen many times over the next ~5 years. We expect a large gas limit increase with Glasterdam. Each step of increased scale or decreased slot time is a matter of getting to the point where it is safe to do it, which comes from a combination of client optimization and protocol changes. Ethereum is CROPS. Ethereum is scaling. Ethereum is reinventing itself. Onward.