Por que algumas blockchains ocultam o que você assina

Ao aprovar uma transação cripto em uma carteira de hardware, você está fazendo uma de duas coisas: ou está lendo um resumo claro e compreensível do que vai acontecer, ou está assinando uma parede de código hexadecimal bruto, torcendo para que dê tudo certo. Blind signing é o ato de aprovar uma transação digital sem conseguir verificar todos os detalhes em um formato legível por humanos.
 

Em fevereiro de 2025, o blind signing contribuiu para o  $1.5 billion Bybit hack, o maior roubo de criptoativos da história. Os invasores não quebraram nenhuma criptografia. Eles exploraram o fato de que os usuários não conseguiam distinguir uma transferência comum de uma atualização maliciosa de contrato.
 

Se a sua carteira pode mostrar um resumo claro e legível antes de você assinar não é uma questão de qualidade do software. Isso depende de como cada blockchain foi projetada em nível de protocolo. Algumas blockchains foram criadas para que as transações se descrevam sozinhas. Outras ocultam detalhes críticos em dados binários que exigem informações externas para serem decodificados. Este artigo explica como essas decisões de design se distribuem entre as principais blockchains e o que isso significa para sua segurança.

O modelo dos três níveis

Clear Signing é um processo de segurança que permite verificar todos os detalhes de uma transação digital em um formato legível, exibido em uma tela segura antes da aprovação. 

Entre 13 grandes ecossistemas de blockchain, o suporte ao clear signing se divide em três níveis distintos, de acordo com a arquitetura do protocolo. Não se trata de quais blockchains são boas ou ruins, mas sim de escolhas de design feitas anos atrás, muitas vezes antes de se entender totalmente as implicações para a segurança.

Nível 1: construídas para transparência

Essas blockchains deixam claro que a assinatura transparente é resultado natural do seu design. O motivo principal: usam um conjunto finito de estruturas de transação tipadas, onde cada campo tem um nome, um tipo e um esquema definido. Uma carteira de hardware não precisa de informações externas para interpretar, a própria transação informa o que está sendo feito.

The XRP Ledger talvez ofereça o cenário mais forte e claro de assinatura transparente entre as grandes blockchains. Seu formato binário inclui um campo TransactionType que garante a interpretação determinística em mais de 50 tipos de transação: Payment, OfferCreate, TrustSet, EscrowCreate e outros. Cada campo tem um esquema definido. A carteira de hardware pode exibir destinatário, valor, taxa, memo e todos os parâmetros específicos sem precisar consultar nada fora da blockchain. Quase 100% das transações atuais podem ser totalmente assinadas de forma clara.

Polkadot desenvolveu a solução tecnicamente mais sofisticada do setor para clear signing, com seu  sistema de metadados de runtime (MetadataV14/V15). Cada transação referencia índices de pallet e chamada, e os metadados informam exatamente o que significam e como decodificar os argumentos. O desafio é que os metadados completos passam de 200KB, grande demais para carteiras de hardware com memória limitada. 

A solução,  RFC-0078 (Merkleized Metadata), constrói uma árvore criptográfica a partir dos metadados, transmite apenas o subconjunto relevante e verifica a prova de inclusão na blockchain. O resultado é um aplicativo Ledger único que funciona em todos os parachains Polkadot sem necessidade de atualizações por chain.
 

Cosmos utiliza uma arquitetura de mensagens tipadas e o  padrão SIGN_MODE_TEXTUAL (ADR-050), introduzido no Cosmos SDK v0.50, que exibe as transações em telas legíveis, adaptadas para displays pequenos. Os valores das moedas aparecem como "2 ATOM" em vez de "2000000uatom". O NEAR Protocol vai além, com  nomes de contas legíveis como "alice.near" e argumentos de função serializados em JSON, permitindo que a carteira mostre tudo em texto simples.
 

Nível 2: funciona para o básico, falha no avançado

Seis ecossistemas oferecem clear signing sólido para operações nativas, mas perdem transparência quando contratos inteligentes entram em cena. O caso mais didático é o do Bitcoin. O modelo UTXO faz com que transações brutas não contenham os valores de entrada; a carteira de hardware não consegue calcular a taxa sem informações extras sobre as saídas anteriores.  PSBT (BIP 174) resolve isso para pagamentos padrão, cobrindo cerca de 90% das transações típicas, mas gastos via Taproot e setups multisig complexos ainda geram opacidade.
 

Stellar mostra o contraste do nível 2 de forma clara. Suas 26 operações clássicas (Payment, ManageSellOffer, ChangeTrust) têm esquemas fixos e aparecem perfeitamente em carteiras de hardware. Mas os contratos inteligentes Soroban, lançados em 2024, reintroduzem a opacidade ao estilo EVM: os parâmetros chegam como tipos binários codificados que exigem conhecimento específico do contrato para decodificar, reduzindo a cobertura de cerca de 95% para operações clássicas a quase zero para interações Soroban brutas. Algorand, Cardano, Aptos e Tezos seguem padrões semelhantes: cobertura forte para operações nativas, mas grandes lacunas para lógicas programáveis mais complexas.
 

Nível 3: opacidade faz parte do design

Três ecossistemas fizeram escolhas arquiteturais que tornam o clear signing um grande desafio, independentemente da qualidade do software da carteira. Entender isso ajuda a explicar por que avisos de blind signing aparecem em praticamente todas as interfaces DeFi.
 

Ethereum e todas as chains compatíveis com EVM compartilham o mesmo problema central: a codificação ABI não é autoexplicativa. Ao interagir com um contrato inteligente, o campo de dados da transação traz um seletor de função de 4 bytes — os quatro primeiros bytes do hash do nome da função — seguido dos parâmetros codificados em blocos de 32 bytes. Sem o ABI JSON do contrato, isso é puro hexadecimal sem sentido. Esse ABI não é armazenado na blockchain. A carteira de hardware não tem como saber que 0xa9059cbb... significa "transferir 1.000 USDC para 0xABC..." sem metadados externos. 
Contratos proxy, que direcionam a execução para contratos de implementação cujos endereços podem mudar, agravam o problema — foi exatamente assim que ocorreu o Bybit hack.
 

A resposta do setor para isso é o  ERC-7730, um padrão de metadados criado em 2024 que fornece arquivos JSON descrevendo como decodificar e exibir interações específicas de contratos. Funciona, mas exige que alguém escreva e mantenha esses metadados para cada contrato com o qual você possa interagir. É, no fim das contas, um remendo aplicado a uma arquitetura que não foi feita para transparência.
 

Solana é, talvez, ainda mais desafiadora. As instruções das transações contêm um ID de programa e um array de bytes opaco, sem ABI padronizado — cada programa define seu próprio formato de serialização. O framework Anchor fornece uma abordagem semi-padrão com discriminadores de 8 bytes, mas muitos programas não usam Anchor nem publicam suas interfaces. Para interações DeFi, a maior parte do volume de transações de Solana exige blind signing. 

TON adiciona ainda mais complexidade com execução assíncrona: você assina apenas a mensagem inicial, e tudo que acontece depois em blocos subsequentes fica invisível no momento da assinatura.

 Principais pontos

A dica mais prática: saiba em qual nível sua blockchain se encaixa antes de usar uma carteira de hardware para DeFi. Para blockchains do Nível 1, o clear signing funciona como deveria. No Nível 2, transferências simples são seguras para assinar, mas vale pausar e pesquisar antes de qualquer interação complexa com contratos inteligentes. No Nível 3, trate toda transação em protocolos DeFi com máxima cautela e confira se o dApp e a carteira suportam metadados ERC-7730 antes de aprovar qualquer operação relevante.
 

Fabricantes de carteiras de hardware estão trabalhando ativamente nesse problema. O Generic Parser da Ledger lê arquivos de metadados ERC-7730 e exibe detalhes da transação na tela segura. 

A abordagem de Metadados Merkleizados do Polkadot é, talvez, a solução mais elegante do setor: sem confiança, verificada criptograficamente e nativa do protocolo. O setor está avançando para padrões melhores, mas as limitações de protocolo das blockchains do Nível 3 não vão desaparecer.
 

A regra mais simples: se sua carteira mostrar um hash ou uma sequência de bytes hexadecimais e pedir para assinar, encare isso como um alerta vermelho.

Recursos e leituras recomendadas

Os recursos a seguir trazem detalhes técnicos sobre os protocolos e padrões discutidos neste artigo.