Entre usuários de criptomoedas, há uma crença amplamente difundida: se você inserir o endereço correto, escolher a rede certa e tiver tokens nativos suficientes para cobrir a taxa, a transação será concluída. Na grande maioria dos casos, essa crença se confirma.
Mas cada blockchain tem suas próprias regras ocultas — regras que só aparecem em situações muito específicas. E quando surgem, uma transação pode falhar mesmo que, do seu ponto de vista, tudo tenha sido feito corretamente.
Isso foi exatamente o que aconteceu conosco quando um cliente do nosso serviço de swap, Rabbit.io, trocou LTC por SOL. O valor era ínfimo — menos de 0,0003 SOL, que aos preços atuais fica abaixo de três centavos. Em muitos dos meus artigos anteriores, mencionei que não impomos limites mínimos para swaps. Sim, frequentemente processamos quantias extremamente pequenas também.
Quando tentamos enviar o SOL solicitado, nos deparamos com um problema. O endereço estava correto. A rede era a Solana Mainnet. Nosso saldo era suficiente. A taxa foi considerada. Ainda assim, a transação continuava a falhar, vez após vez.
A explicação acabou sendo inesperada — até para nós. E quando a compartilhamos com o cliente, ele também não acreditou à primeira vista. O incidente me fez pensar: quantas armadilhas ocultas semelhantes existem em diferentes blockchains?
Decidi investigar e compilar os exemplos mais interessantes — casos que poderiam até me pegar de surpresa, apesar de eu processar uma ampla variedade de trocas de criptomoedas diariamente.
1. Solana. Pagando "aluguel" — Mesmo pelo SOL nativo
Por que isso surpreende
Muita gente já ouviu dizer que na Solana, para receber tokens SPL — como USDT, USDC e outros — em um endereço que nunca recebeu esses tokens antes, o endereço precisa ter uma pequena quantidade de SOL. Estritamente falando, isso não é totalmente preciso, mas há alguma verdade nisso.
Cada token é armazenado em uma Associated Token Account (ATA) separada, e criar essa conta custa cerca de 0,002 SOL. No entanto, mesmo se o destinatário não tiver SOL, os tokens ainda podem ser recebidos — porque é o remetente quem paga pela criação da ATA, não o destinatário.
O que é muito menos conhecido é que um requisito semelhante às vezes pode se aplicar a transferências do próprio SOL nativo. Foi exatamente isso que aconteceu conosco quando tentamos enviar a quantia mínima solicitada pelo nosso cliente.
Como o mecanismo funciona
Na Solana, uma conta não é apenas uma sequência de caracteres que representa um endereço. É um registro real armazenado no estado corrente da blockchain. Esse registro ocupa espaço em disco nos nós validadores — e armazenamento não é gratuito.
Esse mecanismo é conhecido como isenção de aluguel (rent exemption). Para que uma conta exista, seu saldo deve exceder um certo mínimo — efetivamente o custo de dois anos de aluguel de armazenamento.
Esse valor não é fixo para sempre, mas no momento, para uma conta de sistema básica (uma carteira regular), o mínimo é 890.880 lamports, ou 0,00089088 SOL.
Se um endereço ainda não existe on-chain (isto é, seu saldo é zero), a primeira transação que tentar criar a conta com um valor abaixo desse limite será rejeitada.
Foi exatamente isso que estava acontecendo no nosso caso. Estávamos enviando um pouco menos de 0,0003 SOL para um endereço recém-criado — aproximadamente três vezes abaixo do limite exigido. Nosso cliente recusou-se a acreditar que tal regra existisse. E, para ser justo, tivemos dificuldade em encontrar qualquer declaração clara sobre isso na documentação oficial da Solana. A única confirmação indireta que encontramos estava na descrição do método RPC getMinimumBalanceForRentExemption, que implica essa regra — embora não a explicite diretamente.
Há uma nuance importante aqui. Já havíamos enviado quantias tão pequenas para clientes muitas vezes sem problemas. Pela experiência prática, sabíamos que a Solana permite transferências de somas arbitrariamente pequenas.
E isso é verdade — mas somente se a conta do destinatário já existir. Se for a segunda, terceira ou centésima transação recebida, o endereço pode receber até 1 lamport. Mas quando uma conta está sendo criada pela primeira vez, a verificação de isenção de aluguel se aplica.
2. XRP Ledger e Stellar. O endereço existe — mas a conta não
O problema que encontramos na Solana é, na verdade, um caso específico de um padrão mais amplo. Em várias redes, um endereço como objeto criptográfico e uma conta como uma entrada no livro-razão distribuído são duas coisas diferentes. Sem um saldo inicial mínimo, a conta simplesmente não existe.
No XRP Ledger, toda nova conta deve receber uma reserva mínima de 1 XRP. Nos primeiros dias da rede, esse requisito era bem maior — 200 XRP no lançamento, depois reduzido para 50 XRP, depois 20 XRP, depois 10 XRP. Conforme o preço do XRP aumentou ao longo do tempo, a reserva foi gradualmente reduzida para o atual 1 XRP.
Essa reserva permanece permanentemente bloqueada na conta. Ela não pode ser gasta. Não pode ser usada para pagar taxas de transação. Alguns exploradores do XRP Ledger até exibem o saldo total e a reserva bloqueada separadamente, para que os proprietários de carteiras possam ver claramente quanto XRP está realmente disponível para gasto.
A rede Stellar segue lógica semelhante. Um endereço não existe no livro-razão até que receba um saldo mínimo. Uma conta Stellar requer pelo menos 1 XLM para ser ativada e permanecer operacional.
Você deve se lembrar que já escrevi sobre um erro que transformou 1.000 USDC em 1 XLM. A situação descrita naquele artigo foi precisamente um exemplo desse mecanismo em ação: uma transação de token, mesmo que assinada corretamente pelo remetente, não pode ser creditada ao destinatário a menos que certos pré-requisitos sejam atendidos.
Uma característica distintiva tanto do XRP Ledger quanto do Stellar é que uma conta não pode receber tokens a menos que ela tenha optado explicitamente por interagir com aquele ativo específico. Essa é uma decisão deliberada dos desenvolvedores, e tem suas vantagens.
Em outras redes, endereços de whales e celebridades frequentemente são inundados com tokens spam recém-criados, criando a ilusão de que o dono do endereço os comprou. No XRP Ledger e no Stellar, esse spam é impossível — porque receber um ativo requer autorização prévia.
3. Lightning Network. Liquidez existe — mas não há rota
A Lightning Network é uma rede de canais de pagamento projetada para enviar bitcoin sem registrar cada transferência na blockchain. Ao contrário das transações on-chain regulares, um pagamento Lightning não é validado por todos os nós da rede e não é confirmado por mineradores em um bloco. Em vez disso, ele viaja através de uma cadeia de nós intermediários.
E é aí que surge toda uma classe de erros não óbvios.
Como o roteamento funciona
Para que um pagamento viaje de Alice a David através dos nós intermediários Bob e Carol, cada segmento da rota deve ter liquidez suficiente na direção necessária.
A rede conhece a capacidade total de cada canal, mas não sabe como o saldo está distribuído entre as duas partes. Isso pode levar a situações como a seguinte:
- David tem liquidez de entrada suficiente em seu canal com Carol.
- Mas no canal entre Bob e Carol, quase todo o saldo está, por acaso, do lado da Carol. Bob não consegue encaminhar o pagamento na direção dela.
Como resultado, o pagamento de Alice para David falha com um erro de "rota não encontrada" — mesmo que Alice tenha fundos suficientes, David tenha um canal ativo capaz de receber o pagamento e uma rota exista formalmente no grafo da rede.
A armadilha oculta do limite de taxa
Há outra nuance particularmente traiçoeira. No LND, uma das implementações de nó Lightning mais usadas, o limite padrão de taxa de roteamento é definido para 0 satoshis.
Isso significa que o nó só tentará encontrar rotas completamente gratuitas — que, em uma rede real, praticamente não existem. Usuários que nunca mudaram essa configuração padrão podem ver repetidamente um erro de "rota não encontrada", mesmo que o pagamento fosse bem-sucedido se permitissem uma pequena taxa de roteamento.
Isso não é uma falha. Pelo contrário, os desenvolvedores do LND deliberadamente escolheram não decidir em nome dos usuários qual taxa máxima eles estariam dispostos a pagar. Se um limite positivo fosse definido por padrão, os usuários poderiam depois descobrir que taxas de roteamento foram deduzidas sem que percebessem.
Outras razões para um erro de "rota não encontrada":
- O nó do destinatário está offline e seus canais estão inativos.
- A fatura expirou. Faturas Lightning têm um período de validade limitado, frequentemente em torno de uma hora.
- O valor é muito grande. Pagamentos grandes são mais difíceis de rotear do que pequenos.
- Uma tentativa anterior "prendeu" a liquidez. Contratos HTLC com bloqueios de tempo podem bloquear temporariamente a capacidade do canal até expirarem.
Encontramos todas essas questões ao trocar bitcoin via Lightning Network. Elas podem parecer incomuns em comparação com transações tradicionais em blockchains, mas cada um desses problemas tem solução. Por isso, no Rabbit.io, você pode enviar e receber bitcoin pela Lightning Network sem se preocupar com essas armadilhas.
4. USDT e USDC. Listas negras com arquiteturas diferentes
USDT e USDC são stablecoins gerenciadas de forma centralizada. Seus contratos inteligentes incluem funções de blacklist: os emissores — Tether e Circle — podem adicionar um endereço a uma lista negra a qualquer momento, após o que operações envolvendo os tokens naquele endereço se tornam impossíveis.
Isso é um fato conhecido. O que é menos compreendido é que os mecanismos de restrição no USDT e no USDC são fundamentalmente diferentes — e essa diferença tem consequências práticas importantes.
USDC (Circle): ambas as direções bloqueadas
No contrato do USDC, a verificação da blacklist se aplica tanto ao remetente quanto ao destinatário. Se o endereço do destinatário estiver na lista negra, a transação será rejeitada pelo contrato inteligente. O remetente simplesmente perde uma pequena quantidade de gas, enquanto os USDC permanecem na sua carteira.
Do ponto de vista do remetente, esse é um modelo mais seguro: os fundos não desaparecem em um endereço congelado.
USDT (Tether): apenas o remetente é bloqueado
No contrato do USDT (TetherToken), a função transfer contém a seguinte verificação: require(!isBlackListed[msg.sender]). Isso significa que somente o remetente é verificado em relação à blacklist. O endereço do destinatário não é validado durante a transferência.
Na prática, isso leva às seguintes consequências:
- Você pode enviar USDT com sucesso para um endereço em lista negra.
- A transação será concluída sem erros.
- A blockchain registrará a transferência.
- Mas os fundos ficarão congelados como resultado.
Nem o destinatário nem ninguém mais poderá movimentar esses tokens posteriormente — transações de saída de um endereço em lista negra são proibidas. Somente o emissor, a Tether, pode intervir, usando a função destroyBlackFunds para efetivamente apagar os tokens do endereço em lista negra.
Nesse caso particular, pode-se argumentar que é melhor que uma transação corretamente construída falhe imediatamente. A abordagem implementada no contrato do USDC parece mais transparente e justa do que o modelo do USDT, onde a transação tem sucesso — apenas para depois ficar claro que a transferência foi, na prática, inútil.
Minhas recomendações:
- Ao trabalhar com USDT, verifique o endereço da contraparte em relação a sanções ou dados de blacklist antes de enviar. Um endereço que estava "limpo" ontem pode não estar limpo hoje — seu status pode mudar no pior momento.
- Se possível, considere usar USDT na blockchain Liquid, onde a Tether não tem a capacidade de congelar endereços individuais.
Dito isso, mesmo transferências de USDT às vezes podem falhar imediatamente — mesmo quando todos os dados da transação parecem corretos. Na Parte II deste artigo, cobrirei tais casos, junto com restrições de transação menos conhecidas nas redes Bitcoin, Ethereum e Tron.
Será publicado aqui exatamente em uma semana.
