Moedas, saldos e contas: por que «quanto eu tenho» tem três respostas diferentes
Abra uma carteira que suporte várias redes e, se olhar de perto, vai notar algo esquisito. O saldo de Bitcoin e o de Ethereum são ambos apenas números numa tela, mas por baixo são calculados de maneiras completamente diferentes — e na Solana existe ainda um terceiro arranjo.
Isso não é curiosidade inútil. Explica por que as taxas do Bitcoin dependem do seu histórico de transações, por que uma transação de Ethereum pode falhar e ainda assim custar dinheiro, e por que uma conta da Solana não pode simplesmente ser esvaziada até zero.
O modelo UTXO: você tem moedas, não um saldo
O Bitcoin não tem contas e não armazena saldos. O que ele armazena é um conjunto de saídas de transação não gastas — os UTXOs — cada uma sendo um pedaço discreto de valor trancado por alguma condição de gasto.
Pense em dinheiro vivo. Você não tem «47 reais» no bolso; você tem uma nota de 20, duas de 10, uma de 5 e duas moedas de 1. Para pagar 23, entrega a de 20 e a de 5 e recebe 2 de volta. Não dá para rasgar uma nota ao meio.
Os UTXOs funcionam exatamente assim. Cada um precisa ser gasto por inteiro. Para pagar 0,3 BTC de uma saída de 1 BTC, sua carteira consome o BTC inteiro e cria duas saídas novas: 0,3 para o destinatário e cerca de 0,7 de volta para você como troco. O UTXO de 1 BTC deixa de existir.
Seu «saldo» é, portanto, um número derivado: sua carteira varre a rede atrás de saídas trancadas por condições que você consegue satisfazer, e soma. Em lugar nenhum da blockchain do Bitcoin existe um registro dizendo que você tem determinada quantia.
Daí seguem três consequências, e as três são práticas:
As taxas dependem do seu histórico, não só do valor. São cobradas por byte, e cada entrada gasta acrescenta bytes. Pagar 50 reais de um único UTXO grande sai barato; pagar esses mesmos 50 juntando trinta minúsculos sai caro, porque a transação é fisicamente maior. É por isso que consolidar UTXOs quando as taxas estão baixas vale a pena.
O troco é uma saída de verdade que precisa ir para algum lugar. Toda carteira cuida disso automaticamente, mas é o mecanismo por trás das heurísticas de endereço de troco que analistas de rede usam para ligar seus endereços uns aos outros.
Gastar é naturalmente paralelo. UTXOs diferentes são independentes, então nada obriga suas transações a uma ordem estrita.
Bitcoin, Litecoin, Dogecoin, Bitcoin Cash, Zcash, Ravencoin e Flux funcionam todos assim. É o modelo mais antigo, e aquele em que «se as chaves não são suas, as moedas não são suas» é mais literalmente verdadeiro: não existe conta, só moedas com condições presas a elas.
O modelo de contas: você tem um saldo, e um contador
O Ethereum jogou isso fora e adotou algo mais parecido com o livro-razão de um banco. A rede guarda um estado: um mapeamento gigantesco de endereços para saldos (e, para contratos, para dados armazenados). Enviar 0,3 ETH subtrai 0,3 de um número e soma a outro. Sem entradas, sem saídas, sem troco.
Isso é mais simples, e é o que torna os contratos inteligentes praticáveis — um contrato precisa de armazenamento persistente que possa ler e escrever, o que é desajeitado quando o mundo é feito de moedas discretas.
Mas o modelo de contas traz um problema que os UTXOs não têm. Se uma transação é só «subtraia 0,3 da Alice», qualquer um que a veja poderia retransmiti-la repetidas vezes e drenar a conta dela. A solução é o nonce: um contador por conta, incluído em cada transação, que precisa aumentar em exatamente um. A transação número 7 só pode ser minerada depois da 6, e uma única vez.
O nonce é a razão de as redes EVM se comportarem como se comportam:
Suas transações ficam estritamente ordenadas. Uma transação travada bloqueia todas as posteriores do mesmo endereço, porque não podem ser processadas fora de sequência.
As taxas são pagas mesmo quando uma transação falha. O gás paga a computação tentada, não a computação bem-sucedida. Uma chamada de contrato revertida consumiu o trabalho dos validadores do mesmo jeito, então custa do mesmo jeito. Isso surpreende as pessoas o tempo todo, e é uma diferença real em relação ao mundo UTXO, onde uma transação inválida simplesmente nunca confirma e não custa nada.
Gerenciar nonces é infraestrutura de verdade. Para uma carteira comum isso é invisível. Para um multisig em que dois aparelhos precisam concordar antes da transmissão, o nonce tem que ser reservado, acompanhado e liberado — e por isso o manejo de nonces é tema recorrente na assinatura com dois aparelhos, em vez de um detalhe de implementação.
Ethereum, Polygon, BSC, Avalanche, Base e XDC usam todos esse modelo.
Solana: contas que pagam aluguel
A Solana também é baseada em contas, mas com uma reviravolta que pega as pessoas de surpresa.
Na Solana, praticamente tudo é uma conta — sua carteira, cada token que você guarda, os dados de cada programa. E como essas contas ocupam memória dos validadores, elas precisam manter um saldo mínimo para continuarem vivas. Isso é a isenção de aluguel: deposite o bastante e a conta persiste indefinidamente; caia abaixo disso e ela pode ser recuperada.
O efeito prático é que guardar um token SPL exige uma conta de token separada, abastecida com um pouquinho de SOL, antes que alguém sequer consiga lhe enviar esse token. Receber não é de graça. Isso é incomum e vale entender antes de precisar, porque «te mandei os tokens e não chegou nada» muitas vezes é só uma conta de token faltando.
Por que uma carteira multi-rede precisa modelar os três
Uma carteira que suporta essas redes não pode compartilhar uma única noção interna de «saldo». Ela precisa:
- Para redes UTXO: um conjunto de saídas, cada uma com valor e script, mais uma lógica de seleção decidindo quais gastar.
- Para redes EVM: um único número de saldo mais um nonce, e uma fila que respeite a ordem.
- Para a Solana: um saldo, um conjunto de contas de token associadas, e consciência dos mínimos de aluguel.
A arquitetura de segurança também precisa se adaptar. Em redes UTXO, o dois-de-dois da SSP é um script: uma saída P2WSH que exige duas assinaturas para destrancar, imposta pelas próprias regras de script da rede. Em redes EVM não existe sistema de script equivalente para contas comuns, então o multisig é implementado via abstração de conta — uma conta de contrato inteligente cuja lógica de validação exige as duas assinaturas. Na Solana é um endereço derivado de programa, controlado por um programa na rede.
Três mecanismos completamente diferentes, uma ideia só voltada ao usuário: nada se move sem os dois aparelhos. O fato de as implementações por baixo não se parecerem em nada é exatamente por que a garantia precisa ser restabelecida, e reauditada, em cada rede em vez de ser presumida herdada.
O que isso significa para você
Quando as taxas do Bitcoin parecerem altas para um pagamento pequeno, olhe suas entradas. O valor importa menos do que em quantos pedaços ele está.
Quando uma transação de Ethereum travar, as posteriores daquele mesmo endereço ficam presas atrás. Isso é o nonce, não um defeito. Resolver a primeira libera a fila.
Quando uma transação EVM que falhou cobrar mesmo assim, o modelo está funcionando como projetado. A simulação ajuda a evitar isso — motivo pelo qual simular antes de assinar vale mais em redes baseadas em contas do que nas UTXO.
Quando uma transferência de token da Solana «sumir», procure por uma conta de token. Nada se perdeu; o destino pode simplesmente ainda não existir.
Nada disso é mania de uma carteira específica. São consequências de uma decisão de projeto que cada rede tomou anos atrás e, assim que você enxerga em qual modelo está, um monte de comportamento antes desconcertante fica previsível.
