Como desenvolver em chains UTXO: Bitcoin, Litecoin, Dogecoin e Bitcoin Cash

Bitcoin não tem saldos de conta. Nunca teve. Litecoin, Dogecoin e Bitcoin Cash também não. Essas quatro chains compartilham um design de 2009 chamado modelo UTXO, que substitui a máquina de estados "uma linha por endereço" que todo desenvolvedor Ethereum e Solana considera natural. O modelo funciona no nível de protocolo. Ele quebra na camada de aplicação, onde toda consulta básica que seu app precisa fazer ou não existe, ou precisa ser remontada por um indexador externo.

É por isso que times que constroem em chains UTXO passaram anos costurando infraestrutura: um provedor para RPC, outro para leituras indexadas, um terceiro para webhooks, código customizado para as lacunas. Nosso pacote UTXO reúne tudo isso em uma única plataforma nas quatro chains, no mesmo dashboard, com as mesmas API keys e o mesmo sistema de medição que você usa para EVM e Solana.

O que é diferente nas chains UTXO?

UTXO significa "unspent transaction output" (saída de transação não gasta). Toda transação Bitcoin consome uma ou mais saídas como entradas e cria novas saídas. O "saldo" de uma carteira não é armazenado em nenhum lugar na chain. Ele é calculado somando todas as saídas que a carteira controla e que ainda não foram gastas. O guia do desenvolvedor Bitcoin é explícito: "quando sua carteira Bitcoin informa que você tem um saldo de 10.000 satoshis, na verdade significa que você tem 10.000 satoshis esperando em uma ou mais UTXOs."

Um exemplo concreto. Alice controla três UTXOs: 0,4 BTC, 0,3 BTC e 0,2 BTC. Ela envia 0,5 BTC para Bob. A transação consome integralmente suas saídas de 0,4 e 0,3 BTC, cria uma saída de 0,5 BTC para Bob, retorna ~0,1999 BTC como troco para um novo endereço controlado por Alice, e deixa ~0,0001 BTC como taxa de mineração. A UTXO de 0,2 BTC permanece intocada. UTXOs são atômicas. Não é possível gastar uma parcialmente.

O contraste com chains baseadas em conta é nítido:

Litecoin, Dogecoin e Bitcoin Cash herdam todos esse modelo. Eles forkaram o código-base do Bitcoin, ajustaram tempos de bloco e alguns parâmetros, e lançaram. O mesmo modelo mental e a mesma classe de infraestrutura atendem às quatro chains.

Por que isso importa para os devs?

As diferenças não são filosóficas. Elas aparecem em pontos concretos onde a maioria dos times subestima o trabalho envolvido.

Você não consegue pedir a um node o saldo de um endereço

O Bitcoin Core armazena blocos e transações. Ele não mantém um índice de endereço para transação. Os desenvolvedores do Core têm resistido explicitamente a adicionar um, porque, como colocou um mantenedor, "índices de endereço são inerentemente inescaláveis, já que crescem linearmente com o tamanho da blockchain." A posição deles é que a indexação de endereços pertence a serviços externos. Então todo app Bitcoin que precisa exibir um saldo, listar as transações de um usuário ou monitorar pagamentos recebidos depende de um indexador: um serviço que observa a chain e mantém um banco de dados consultável de endereços, transações e UTXOs. A única questão é quem opera esse indexador. A maioria dos times usa um provedor de node blockchain hospedado em vez de montar sua própria infraestrutura.

Carteiras não têm um endereço, têm milhares

Reutilizar um endereço vincula todas as entradas e saídas sob uma única identidade. Por isso a convenção é um endereço por recebimento, derivado de uma única seed por meio de chaves determinísticas hierárquicas (HD) definidas na BIP 32. Uma exchange que mantém uma única xpub corporativa (uma chave pública estendida capaz de derivar uma árvore de endereços de recebimento a partir de uma única raiz, sem expor as chaves privadas que gastam esses fundos) pode mostrar a cada cliente um endereço de depósito recém-derivado. Uma carteira auto-custodiada pode recalcular todas as UTXOs que controla a partir de uma seed de 12 palavras. A pegadinha: um indexador precisa derivar endereços sequencialmente e monitorar todos eles, com o gap limit de 20 endereços da BIP 44 determinando quando parar. Pule 20 endereços e o indexador acha que terminou, o que é uma causa real de tickets do tipo "para onde foi meu dinheiro".

Taxas são pagas por tamanho, não por valor

A unidade é satoshis por byte virtual. Uma carteira que consolida 100 UTXOs pequenas em uma única saída paga uma taxa proporcional a essas 100 entradas, independentemente do valor movimentado. A estimativa depende do mempool e varia minuto a minuto. Transações travadas são aceleradas com replace-by-fee (BIP 125) ou child-pays-for-parent. Nada disso é conceitualmente difícil. Tudo isso é código de produção real que você teria de escrever de qualquer jeito.

A finalidade é probabilística

Um bloco Bitcoin pode ser reorganizado para fora da chain por um bloco concorrente. Quando isso acontece, toda transação nos blocos descartados volta para o mempool. Saídas que estavam "gastas" voltam a ser não gastas. Seu indexador precisa desfazer isso de forma limpa, senão entrega ao seu app o saldo errado. Apps se protegem com limiares de confirmação: 1 confirmação para pagamentos de baixo valor, 6 como padrão histórico, 30+ para depósitos grandes em exchanges. Litecoin e Dogecoin têm tempos de bloco mais curtos (2,5 minutos para LTC, 1 minuto para DOGE), então o mesmo número de confirmações compra menos segurança em tempo real.

Os formatos de endereço continuam mudando

O Bitcoin já lançou três atualizações de formato de endereço sem aposentar as anteriores: P2SH em 2012, SegWit em 2017 e Taproot em 2021. Quatro famílias coexistem na rede hoje: legacy P2PKH (1...), SegWit aninhado P2SH (3...), SegWit nativo P2WPKH (bc1q...) e Taproot P2TR (bc1p...). Uma transação P2WPKH com 1 entrada e 2 saídas tem aproximadamente 141 bytes virtuais contra ~226 vB para a transação P2PKH equivalente, então a escolha do formato tem consequências diretas nas taxas. Carteiras e exploradores em produção precisam suportar os quatro.

Todo time que constrói sobre Bitcoin gasta boa parte do primeiro trimestre nesta lista. A maior parte disso não tem nada a ver com o produto que estão desenvolvendo.

Como a Alchemy dá suporte a chains UTXO?

Damos suporte a Bitcoin, Litecoin, Dogecoin e Bitcoin Cash na mesma plataforma que Ethereum, Solana e o restante do diretório de chains. Mesmas API keys. Mesmo dashboard. Mesmo modelo de medição. Mesmos webhooks. Todo recurso disponível em todos os planos.

O que já está disponível no lançamento:

• Passthrough raw JSON-RPC para full nodes rodando com -txindex=1, para todo método padrão do Bitcoin Core (getblock, getrawtransaction, estimatesmartfee, sendrawtransaction e os demais).
• APIs REST indexadas para saldos de endereço, consultas de UTXO, histórico de transações paginado, detalhes de transação enriquecidos e status de gasto. As consultas que o Bitcoin Core não consegue responder nativamente, respondidas em milissegundos.
• Rastreamento de xpub e descriptor nas quatro chains. Output descriptors especificam como derivar endereços a partir de uma chave; nós tratamos a derivação nas árvores BIP 44, 49, 84 e 86 e o gap limit padrão de 20 endereços. Consultas de saldo, UTXO e histórico rodam sobre todo o conjunto de endereços derivado, não apenas sobre o primeiro endereço enviado.
• Assinaturas WebSocket para transações confirmadas, atividade de endereço, novos blocos e notificações de reorg, com limiares de confirmação configuráveis por stream.
• Operações de transação além do broadcast puro: estimativa de taxa em níveis rápido, médio e lento (com base no mempool), construção de transação não assinada, compilação, verificação e broadcast.
• Wrappers de compatibilidade para métodos no estilo Blockbook bb_* (o formato da QuickNode) e no estilo Blockdaemon bd_*, para que integrações existentes migrem apenas com mudanças na chamada HTTP.

No código, isso se traduz assim. Raw JSON-RPC para qualquer coisa que um node suporte:

REST para as consultas que o Bitcoin Core não consegue responder nativamente:

Conexões persistentes para atualizações ao vivo:

A referência completa, incluindo todo endpoint e a lista de métodos dos wrappers de migração, está em nosso quickstart da API Bitcoin e na referência JSON-RPC do Bitcoin. Para uma leitura mais aprofundada sobre como o estado UTXO difere do estado de conta, nossa documentação sobre o modelo UTXO vs. conta cobre a mecânica no nível de protocolo.

Como isso é diferente do que já existe?

Se você já constrói sobre Bitcoin hoje, provavelmente usa um de três provedores, cada um com lacunas:

Três coisas mudam para quem constrói.

Um fornecedor, uma integração, uma fatura

Se você já usa Alchemy para Ethereum, Base, Polygon ou Solana, adicionar Bitcoin não é um projeto de procurement. É uma chain que você liga. Mesmas API keys, mesma medição, mesmo modelo de entrega de webhooks, mesmo dashboard. As configurações multi-fornecedor que foram padrão em chains UTXO por anos se reduzem a uma única integração.

As quatro chains, um único conjunto de recursos

Todo provedor existente cobre alguma combinação dessas chains e recursos, mas a cobertura é desigual. A QuickNode oferece leituras indexadas Blockbook e rastreamento de xpub em BTC, LTC e BCH; o Blockbook para Dogecoin é um add-on pago separado. A Blockcypher oferece HD Wallets em BTC, LTC e DOGE via wallets/hd. A Wallet Transact API da Blockdaemon cobre construção de transação nas quatro chains. Os times acabam combinando cada caso de uso ao provedor que suporta a funcionalidade e a chain específicas de que precisam, e depois costurando o resto em código customizado. Nós entregamos rastreamento de xpub, leituras indexadas, operações de transação e assinaturas WebSocket em Bitcoin, Litecoin, Dogecoin e Bitcoin Cash em um único pacote, sem add-ons por chain nem divisão de recursos.

Migrações são mudanças de chamada HTTP, não rearquiteturas

Wrappers de compatibilidade para métodos no estilo Blockbook bb_* (o formato da QuickNode) e métodos no estilo Blockdaemon bd_* significam que suas integrações existentes mantêm o formato da requisição. Você muda o host. Não reescreve o ponto de chamada. Para times na superfície REST legada da Blockcypher, o formato da requisição muda sim (usamos REST GET com um formato diferente), mas o modelo de dados subjacente é o mesmo. Disponibilizamos um guia consolidado de migração UTXO no lançamento, com seções para Blockcypher, QuickNode Blockbook e Blockdaemon.

O benefício para o dev, em uma linha: menos infraestrutura para juntar, menos provedores para gerenciar e um caminho mais rápido de "precisamos de suporte a Bitcoin" até colocar isso em produção.

Construa sobre Bitcoin com a Alchemy

Bitcoin, Litecoin, Dogecoin e Bitcoin Cash estão disponíveis na Alchemy ao lado de Ethereum, Solana e mais de 100 outras chains. Desenvolvedores PAYG adicionam chains pelo dashboard no primeiro dia. Sem contratos, sem lista de espera, sem compromisso mínimo. Clientes Enterprise recebem as chains UTXO dentro da alocação de compute units já existente. Leia o anúncio de lançamento do suporte a Bitcoin para o detalhamento completo dos recursos.

Crie um endpoint no dashboard da Alchemy e comece a consultar, ou fale com o time de vendas para suporte à integração enterprise e preços personalizados.