Meu robô criou a própria wallet Bitcoin e pagou por conteúdo na internet ao vivo!

A internet está entrando na sua terceira era econômica. A primeira foi a da informação gratuita — páginas estáticas, banners, o modelo publicitário que transformou atenção em commodity. A segunda foi a das assinaturas e paywalls — SaaS, streaming, o modelo recorrente que aprisionou receita em cartões de crédito e intermediários financeiros. A terceira era é a dos pagamentos nativos de máquina para máquina: agentes de IA autônomos que não apenas consomem informação, mas pagam por ela, no ato, sem intervenção humana, usando o próprio protocolo da internet.

O código HTTP 402 — "Payment Required" — foi reservado em 1997 por Tim Berners-Lee e nunca implementado. Ficou lá, adormecido, como uma profecia esperando a infraestrutura. Três décadas depois, a infraestrutura chegou: Bitcoin, Lightning Network, e um protocolo chamado Nostr Wallet Connect (NIP-47) que permite a qualquer wallet Lightning se comunicar com aplicações através de relays Nostr. Some isso a agentes de IA com capacidade de execução autônoma e você tem a receita para a reinvenção completa de como valor é trocado na internet.

O que eu quero contar aqui não é teoria. É a história de como um dispositivo de US$ 15 rodando Linux em RISC-V — o LicheeRV Nano, batizado de Mecha Gerard — construiu sua própria wallet Lightning, recebeu seu primeiro pagamento em Bitcoin durante uma live, e depois aprendeu a pagar por APIs na internet de forma totalmente autônoma. Tudo em Python puro. Sem Node.js. Sem dependências nativas. Sem desculpas.

Recentemente eu adquiri uma placa LicheeRV Nano (RISC-V) para fazer uns testes rodando modelos locais e um agente de IA — Picoclaw, um 'clone' do Openclaw (open-source em Go compilado) que a fabricante disponibilizou, e que roda com 10mb de RAM.

Adquiri também uma câmera (GC4653) compatível para utilizar com um modelo local de análise de imagens, já que a placa conta com uma NPU de 1 TOPS.

A ideia de ter um dispositivo minúsculo, encontrado por ~15 dólares no mercado, rodando modelos e agente locais num Linux é muito interessante porque desmonta todo o hype da compra de Mac Mini "para rodar modelos baseados em APIs". O custo definitivamente valeria a experiência.

Depois de explorada a compilação de um Linux (Buildroot) para RISCV, da jornada para acessar o hardware em C++, a câmera, habilitar os encoders nativos para subir um serviço de streaming, treinar e subir um modelo na NPU para detecção de pessoas, objetos (e aves) em tempo real, e efetuar algumas brincadeiras com o agente de IA nativo para ele, resolvi dar um corpo e uma powerbank para que ele tivesse total autonomia.

Apresento a vocês o Mecha Gerard:

Eu criei diversas skills para o agente tirar fotos, habilitar o streaming e subir os modelos para identificar poses, pessoas, objetos e aves e a experiência de trabalhar num dispositivo totalmente autônomo conectado a IAs agenticas me deixou ainda mais curioso das possibilidades que eu poderia explorar.

Foi então que o chat, durante o Morning Crypto #950, reclamou que não estava conseguindo enviar sats (satoshis) e descobri que meu node da Lightning Network (estou usando Alby Hub em self-hosted) estava fora do ar.

Após o encerramento da live, entrei no servidor para ver o que havia acontecido e descobri que havia uma atualização para o Alby Hub, onde eles adicionaram a uma skill para agentes de IA efetuarem pagamentos em Bitcoin usando o protocolo nativo da internet (código HTTP 402), que vem sendo desenvolvido por algumas iniciativas do ecossistema de criptomoedas. O L402 para pagamentos nativos com Bitcoin através da Lightning Network, o x402 — promovido e desenvolvido por iniciativa da Coinbase para múltiplas criptomoedas e stablecoins (agnóstico), e o MPP — que vem sendo desenvolvido pela Stripe e seu blockchain Tempo. Já escrevi um artigo sobre esse tema no ano passado.

Como venho há tempos acompanhando o desenvolvimento desses protocolos, ao ver as instruções para executar a skill no meu node, eu achei que deveria testar porque realmente acredito que o uso do código 402 por protocolos como o L402 e x402, com pagamentos automatizados por agentes de IA é o futuro dos pagamentos digitais.

Após colocar meu node Lightning de volta em funcionamento, imaginei o quão interessante seria se o Mecha Gerard tivesse a própria wallet na Lightning e efetuasse pagamentos de maneira autônoma na internet.

Então criei uma wallet independente no meu node e comecei a saga de tentar executar a skill disponibilizada pelo Alby Hub dentro do Gerard.

O dispositivo não possui NodeJS (amplamente usado para os agentes do Openclaw). Também não possui um gerenciador de pacotes. E toda aplicação precisa ser compilada para RISC-V — o que infelizmente é um limitador. Se temos dificuldade para rodar certas aplicações no Raspberry Pi (RPi) por conta da arquitetura AARCH64 (ARM64), imagine então a escassez de recursos para um processador utilizado quase que unicamente para dispositivos embarcados. Fora que o NodeJS ainda necessitaria de uma área de armazenamento e memória que eu não tenho disponível no dispositivo.

Mas como eu já possuo um Python rodando nele, resolvi procurar por alguma aplicação que se comunicasse com a Lightning, usando o protocolo Nostr Wallet Connect (simples e fácil de integrar com o Alby Hub e outras wallets). Então esbarrei em outro problema: todos os apps em python que encontrei, importam dependências que compilam toda a parte de criptografia no próprio dispositivo no momento da instalação. O motivo é simples: códigos binários performam muito melhor que códigos interpretados. Porém, por ser um dispositivo embarcado e com muita restrição de memória e armazenamento, não havia uma toolchain para concluir a instalação da aplicação localmente.

Foi então que decidi usar o próprio agente dentro do Mecha Gerard para construir a sua própria wallet Lightning (inspirada pela skill publicada pelo Alby Hub) mas toda em python, sem dependências na parte de criptografia (reconstruindo todos os algoritmos criptográficos necessários), já considerando o ambiente restrito do dispositivo RISC-V embarcado.

Então eu busquei todas as referências necessárias para construir tudo do zero: como funcionam as primitivas criptográficas do Bitcoin (eu já havia reconstruído o RSA do zero há um tempo atrás, e também construído uma prova de conceito para usar a chave privada Bitcon e suas primitivas criptográficas para criptografar mensagens — entre outros projetos do gênero), e todas as especificações que eu precisaria.

Tendo em mãos as especificações do NIP-47 (Nostr Wallet Connect), BIP-340 (Schnorr Signatures), RFC 6979 (Deterministic Nonces), GetAlby Payment Skill GetAlby e o Python NWC SDK, eu pude preparar o projeto no Picoclaw (Agente dentro do Mecha Gerard) e iniciar a execução.

Foi muito interessante acompanhar o Gerard desenvolvendo a própria wallet ao vivo durante o Morning Crypto. Muitas tentativas e erros até que todos os testes de ponta a ponta fecharam. Com isso ele terminou a sua própria wallet totalmente em Python, que não possui dependências externas e pode ser auditada em pouquíssimo tempo.

Então pedi para o Gerard gerar um invoice de 1000 satoshis na lightning, que foi voluntariamente pago pelo DevWalker (obrigado!). Assim, logo o Gerard receberia seu primeiro pagamento em Bitcoin ainda durante a live, na wallet em que ele mesmo havia acabado de construir dentro do dispositivo.

Fizemos mais alguns testes de envio e recebimento e foi um sucesso! Então tivemos mais uma ideia: e se o Gerard pudesse navegar na internet e pagar por coisas de maneira autônoma como fazer compras, acessar conteúdos pagos, etc?

Prometi que depois da live eu iria pensar melhor em como implementar isso.

Após a live, eu baixei o código de dentro do Gerard para fazer um code review (porque até então não tínhamos nem ideia de como havia funcionado a skill). E posso dizer que, embora tenha funcionado, o código estava um desastre. O code review e o assessment de segurança são essenciais para quaisquer desenvolvimentos por IA além, obviamente, do acompanhamento e supervisão constantes — como escrevi sobre os riscos nesse artigo recente.

Então fui atrás das especificações dos protocolos L402 e do x402 e busquei referências novamente na skill de pagamentos em NodeJS da Alby Hub.

Com isso implementei os métodos de pagamento na ferramenta, permitindo que ao navegar em um link e perceber que ele solicita o pagamento, o Agente de IA efetua o pagamento e então consegue acesso ao conteúdo ou produto automaticamente.

Assim, basta pedir para o agente acessar um link que ele executará todo o processo para você, de maneira autônoma e usando os recursos da própria wallet Bitcoin configurada.

Você pode conferir tudo nos episódios 950 e 951 do Morning Crypto.

NWC Agent: A Skill Técnica

Depois daquele code review pós-live — onde o código gerado pelo Gerard funcionava mas era um desastre estrutural — o resultado é o nwc-agent: uma wallet Lightning para agentes de IA autônomos. Zero dependências nativas para a criptografia. Python puro. Roda em RISC-V, ARM, x86_64. Funciona com qualquer wallet compatível com NIP-47 (Alby Hub, CoinOS, Rizful, LNCURL).

Por que reconstruir toda a criptografia em Python?

A pergunta que todo mundo faz: por que não usar uma biblioteca pronta? Fora a óbvia questão de restrições de arquitetura, a resposta também está no supply chain.

Entre 2024 e 2026, o ecossistema de software open-source atravessou uma escalada de ataques ao supply chain sem precedentes. O backdoor no xz (CVE-2024-3094) quase comprometeu SSH em toda distribuição Linux — foi detectado porque um engenheiro da Microsoft notou 500ms de latência em logins SSH. Em março de 2025, o GitHub Action tj-actions/changed-files, usado por mais de 23.000 repositórios, foi comprometido e exfiltrou secrets de CI/CD em texto plano. A Sonatype identificou mais de 454.600 novos pacotes maliciosos só em 2025. E em março de 2026, uma onda coordenada comprometeu cinco pacotes open-source em 12 dias — incluindo o LiteLLM, o gateway de APIs LLM usado por agentes de IA para chamar OpenAI, Anthropic e outros provedores.

Cada dependência é uma superfície de ataque. Quando um agente autônomo detém poder de gasto, uma dependência comprometida não vaza dados — ela drena fundos.

O nwc-agent resolve isso com uma filosofia radical:

• 3 dependências. Só. pyaes (AES em Python puro), websocket-client, pyyaml. Nenhuma compila código nativo. Nenhuma tem C extensions.
• ~1.400 linhas de criptografia auditável. Toda a stack criptográfica — aritmética de curvas elípticas secp256k1, assinaturas Schnorr BIP-340 com nonces determinísticos RFC 6979, criptografia ChaCha20-Poly1305 para NIP-44, derivação HKDF, codificação DER para chaves EC — está em Python legível, em um único arquivo (nwc_wallet.py). Você pode ler tudo em uma sentada e verificar que não há chamadas de rede para hosts desconhecidos, blobs ofuscados, ou árvores de dependência com auto-update.

Compare isso com as alternativas:

| Solução | Dependências | Código Nativo | Superfície de Ataque |

|---------|-------------|---------------|---------------------|

| nwc-agent | 3 (Python puro) | 0 linhas | Mínima |

| @getalby/sdk (Node.js) | 200+ transitivas | secp256k1 nativo | Alta |

| python_nwc (referência) | secp256k1 + pycryptodome | C extensions | Média |

| LND (gRPC) | Toolchain Go completa | Stack LND inteira | Muito Alta |

Protocolos de Pagamento: L402, X402 e MPP

A skill suporta três protocolos baseados no HTTP 402. O comando fetch faz a detecção automática — você passa a URL e ele descobre qual protocolo usar:

python3 scripts/nwc_wallet.py fetch https://api.exemplo.com/v1/generate

L402 (Lightning Service Authentication Token): O protocolo mais comum. O servidor responde com 402 Payment Required + header WWW-Authenticate: L402 token=, invoice=. O cliente extrai o invoice Bolt11, paga via NWC, e então refaz a requisição com Authorization: L402:. O macaroon + preimage são reutilizáveis — pague uma vez e use curl com o header de autorização para todas as requisições subsequentes ao mesmo proxy.

X402: Alternativa promovida pela Coinbase. O desafio vem em um header PAYMENT-REQUIRED com JSON base64. Suporta múltiplos métodos de pagamento — o cliente localiza a entrada lightning, paga o invoice, e responde com payment-signature. Inclui verificação de valor: se o invoice não bate com o declarado no desafio, o pagamento é abortado.

MPP (Multi-Party Payments): Baseado na especificação draft-lightning-charge-00, usando credenciais JCS (JSON Canonicalization Scheme). O desafio é codificado em base64url.

A detecção é totalmente automática no dispatcher (nwc_fetch.py): primeiro verifica WWW-Authenticate com "L402", depois PAYMENT-REQUIRED (X402), depois WWW-Authenticate com "Payment" + "lightning" (MPP). Se o servidor retornar 402 sem nenhum protocolo reconhecido (ex: pagamento em USDC ou ETH), o comando reporta "no supported payment protocol" — apenas Bitcoin/Lightning são suportados.

Comandos e Interface

Toda a interface é projetada para function-calling de LLMs, não para uso humano interativo. Todo comando retorna JSON estruturado para stdout. Todo erro vai para stderr.

Operações de wallet:

| Comando | Argumentos | Retorno |

|---------|-----------|---------|

| balance | — | Saldo em satoshis |

| pay_invoice | | {"paid": true, "preimage": "..."} |

| pay_invoice_async | | Fire-and-forget (verificar depois) |

| make_invoice | [desc] | Invoice Bolt11 |

| lookup_invoice | | Status e detalhes |

| check_payment | | {"paid": true/false} |

| list_transactions | [type] [limit] [offset] | Array JSON de transações |

| get_info | — | Alias da wallet, métodos suportados |

Pagamentos HTTP 402:

python3 scripts/nwc_wallet.py fetch <url>
python3 scripts/nwc_wallet.py fetch --method POST --body '{"key":"val"}' <url>
python3 scripts/nwc_wallet.py fetch --max-amount 1000 <url>

Após o primeiro fetch bem-sucedido, guarde o macaroon e preimage e use curl diretamente — não chame fetch duas vezes para o mesmo proxy, cada chamada dispara um novo pagamento:

curl -s "https://proxy.exemplo.com/resource" \
  -H "Authorization: L402 ${MACAROON}:${PREIMAGE}"

Descoberta de serviços:

python3 scripts/nwc_wallet.py discover -q "image generation"
python3 scripts/nwc_wallet.py discover -p x402

O comando discover consulta o 402index.io e retorna apenas serviços que aceitam pagamentos via Bitcoin/Lightning.

Conversão fiat/sats (via API CoinGecko, sem necessidade de wallet):

python3 scripts/nwc_wallet.py fiat_to_sats 10 USD    # 10 USD → sats
python3 scripts/nwc_wallet.py sats_to_fiat 1000 EUR   # 1000 sats → EUR

Segurança

O modelo de segurança parte de um princípio: a URL NWC contém a chave privada da wallet. Isso significa que:

• A URL NWC nunca é logada, exibida ou transmitida. Apenas IDs de eventos e valores de saldo aparecem no output.
• O flag --debug é seguro — ele imprime estrutura JSON (keys, tipos, flags de erro), nunca valores secretos ou payloads descriptografados.
• Nonces determinísticos RFC 6979 eliminam risco de reuso em assinaturas Schnorr.
• Limites de gasto são aplicados no servidor pela wallet — você não pode sobrescrevê-los. O flag --max-amount no fetch adiciona uma guarda extra no cliente.
• NIP-44 (ChaCha20-Poly1305) disponível via flag --nip44 para wallets que suportam.
• Comparação de MAC em tempo constante na verificação Poly1305.
• Conexões WebSocket sempre fechadas (try/finally em todos os paths).

Instalação

Para agentes (Hermes, OpenClaw, Claude Code, Codex etc):

pipx install pipx-skills
pipx-skills add eddieoz/nwc-agent

Configure sua wallet NIP-47 e salve a URL de conexão. Nunca cole a URL nostr+walletconnect:// em chats ou canais compartilhados. Use o terminal diretamente.

Instalação manual:

git clone https://github.com/eddieoz/nwc-agent.git
cd nwc-agent
pip install -r requirements.txt
# Configure .env com sua NWC URL
python3 scripts/nwc_wallet.py balance

Pré-requisito único: Python 3.8+ e OpenSSL (presente em toda distribuição Linux). Sem Node.js. Sem compilação nativa. Se Python roda, a wallet roda.

Performance em RISC-V

Para referência, no LicheeRV Nano (1GHz C906):

| Operação | Tempo |

|----------|-------|

| Multiplicação de ponto secp256k1 | ~2ms |

| Assinatura Schnorr BIP-340 | ~3ms |

| ECDH (subprocesso OpenSSL) | ~15ms |

| Request de saldo NWC (end-to-end) | ~3s |

| Encrypt/decrypt NIP-44 | ~5ms |

Disponibilidade

O projeto é open-source (MIT) e está disponível em github.com/eddieoz/nwc-agent. A documentação completa — arquitetura da stack criptográfica, análise de superfície de ataque, referência dos protocolos de pagamento, e guia de testes — está no diretório docs/ do repositório.

Se o nwc-agent te ajudou a construir algo útil, considere patrocinar o projeto.

A convergência entre agentes autônomos e pagamentos nativos da internet não é mais teoria. É um dispositivo de US$ 15 com uma câmera, uma NPU de 1 TOPS, e uma wallet Lightning que ele mesmo construiu — pagando por APIs, acessando conteúdo pago, operando como um ator econômico independente na rede.

O HTTP 402 acordou. E dessa vez, ele veio com Python puro.

Send sats if you liked.

⚡️eddieoz@sats4.life