Por que algumas blockchains mostram o que você está assinando (e outras

Camada 1: Arquitetura transparente — a intenção da transação é legível por design

Quatro ecossistemas se destacam por tornar o clear signing uma consequência natural do design do protocolo, e não um recurso adicionado depois com ferramentas externas.

XRP Ledger

O XRP Ledger oferece o melhor exemplo de clear signing entre as grandes blockchains. Sua arquitetura usa um conjunto finito de mais de 50 tipos de transação enumerados (Payment, OfferCreate, TrustSet, EscrowCreate, NFTokenMint, etc.), cada um com um esquema totalmente definido de campos nomeados e tipados. 

O formato binário é autoexplicativo — um campo TransactionType torna a análise totalmente determinística, e o esquema completo dos campos está mantido no arquivo de definições do código-fonte do rippled. 

Uma carteira de hardware pode exibir todos os campos de cada tipo de transação conhecido: destinatário, valor (com moeda e emissor para tokens), taxa, memos e parâmetros específicos. O modelo baseado em contas faz com que os valores sejam explícitos (sem a complexidade do UTXO) e as taxas sejam um campo simples, não um cálculo implícito. 

Quase 100% das transações atuais do mainnet podem ser totalmente clear-signed. O único risco é que novos tipos de transação adicionados por atualizações do protocolo (como operações Vault e Loan recentes) exijam atualizações no app da carteira de hardware; tipos desconhecidos caem no blind signing.
 

Polkadot / Substrate

O Polkadot desenvolveu a solução tecnicamente mais sofisticada para clear signing do setor. Seu sistema de metadados de runtime (MetadataV14/V15) fornece um registro completo e autoexplicativo de tipos para cada pallet (módulo), chamada e tipo de dado no runtime. 

Cada transação (extrinsic) é estruturada como pallet_index || call_index || encoded_arguments, e os metadados informam exatamente o que cada índice significa e como decodificar os argumentos. 

O desafio principal é que os metadados completos ultrapassam 200KB — muito grandes para carteiras de hardware com cerca de 64KB de RAM. A solução, RFC-0078 (Merkleized Metadata), constrói uma Merkle tree a partir dos metadados e transmite apenas o subconjunto relevante (tipos necessários para a transação específica) mais uma prova criptográfica de inclusão. 

O hash dos metadados é verificado on-chain via a extensão assinada CheckMetadataHash, tornando o sistema trustless. Isso permite um único app Ledger genérico que funciona em todas as parachains e relay chains do Polkadot sem atualizações por rede.

A abordagem lida com upgrades de runtime de forma elegante, mesmo quando índices mudam, pois novos metadados e provas mantêm a assinatura precisa.

Cosmos / Tendermint

Cosmos/Tendermint se beneficia de uma arquitetura de mensagens tipadas, onde cada transação inclui um ou mais objetos sdk.Msg encapsulados em google.protobuf.Any do Protobuf, que inclui um campo type_url identificando o tipo da mensagem.
Mensagens padrão como MsgSend, MsgDelegate e MsgVote têm esquemas bem conhecidos. 

A solução dedicada de clear signing do ecossistema é o SIGN_MODE_TEXTUAL (ADR-050), introduzido no Cosmos SDK v0.50. Ela exibe as transações em telas sequenciais otimizadas para dispositivos pequenos (~40 caracteres), com value renderers que convertem dados brutos em formatos legíveis: moedas aparecem como "2 ATOM" em vez de "2000000uatom", endereços usam bech32, timestamps seguem o padrão RFC3339. 

Desenvolvedores podem criar renderizadores personalizados para seus tipos de mensagem (desde que as funções de formatação e análise sejam perfeitamente reversíveis). O payload assinado inclui tanto a representação textual quanto o hash dos bytes brutos, preservando as garantias de segurança.

NEAR Protocol

O NEAR Protocol alcança o clear signing por meio de várias escolhas arquiteturais que priorizam a legibilidade. Os identificadores de conta são nomes legíveis, como "alice.near", em vez de endereços hexadecimais. 

As transações contêm enums tipados Action (Transfer, Stake, FunctionCall, AddKey, etc.) sempre identificáveis. O mais importante: a ação FunctionCall inclui o nome do método como string (ex: "transfer", "set_greeting") e argumentos serializados em JSON por padrão. 

Uma carteira de hardware pode exibir: "Chamar método 'swap' em app.defi.near com args: {amount: 1000, token: 'usdc.near'}." Isso é muito mais legível do que qualquer sistema baseado em seletores. A principal limitação é que alguns contratos usam argumentos serializados em Borsh para eficiência de gas, o que os torna opacos sem o esquema.

Camada 2: Condicionalmente claro — operações nativas funcionam, smart contracts dificultam

Clear signing eficiente para operações básicas. Há degradação significativa quando a programabilidade de propósito geral entra em cena.

Bitcoin

O Bitcoin ocupa uma posição única: seu modelo de transação cria desafios para clear signing mesmo sem smart contracts. O modelo UTXO faz com que as transações brutas não incluam os valores de entrada, ou seja, as entradas referenciam saídas anteriores pelo hash da transação e índice, mas omitem quanto valiam essas saídas. 

Sem essa informação, a carteira de hardware não consegue calcular a taxa (que é igual ao total de entradas menos o total de saídas) nem verificar se o usuário não está sendo enganado para pagar a mais. PSBT (BIP 174) resolve isso encapsulando transações não assinadas com metadados UTXO e caminhos de derivação BIP32 para identificar endereços de troco. 

Com PSBT, carteiras de hardware podem exibir claramente endereços de destinatário, valores e taxas para pagamentos padrão, cobrindo cerca de 90% das transações típicas. A complexidade aumenta com multisig, scripts com bloqueio de tempo e gastos via Taproot — P2SH e P2WSH escondem scripts arbitrários atrás de hashes, e a estrutura MAST do Taproot torna condições alternativas de gasto invisíveis até serem usadas.

Aptos

Aptos se beneficia do sistema de tipos forte do Move e da disponibilidade de ABIs onchain. Os payloads das transações contêm identificadores de função totalmente qualificados, como 0x1::aptos_account::transfer, endereço do módulo, nome do módulo e nome da função — tudo visível. 

O SDK pode consultar ABIs onchain para desserializar argumentos codificados em BCS. Assim, uma carteira de hardware com acesso ao ABI pode exibir: "Chamar 0x1::aptos_account::transfer(destinatário: 0xABC..., valor: 1000)." 

No entanto, BCS (Binary Canonical Serialization) não é autoexplicativo; sem o esquema ABI, os bytes BCS são ininteligíveis. Payloads de script (bytecode Move arbitrário) ignoram totalmente o formato estruturado. O app Ledger Aptos inclui uma opção explícita de "Enable Blind Signing" para transações complexas, confirmando a diferença entre operações simples e complexas.

Stellar

O padrão da camada 2 em sua forma mais pura. Seus 26 tipos clássicos de operação (Payment, ChangeTrust, ManageSellOffer, etc.) têm esquemas fixos e são totalmente interpretáveis — o app Ledger exibe tipo de operação, valor, destino, ativo, memo e taxa em uma revisão passo a passo. Cobertura de ~95% para operações clássicas.

• Smart contracts Soroban (lançados em 2024) reintroduzem exatamente o problema de opacidade visto no Ethereum. As chamadas chegam como operações InvokeHostFunction com endereços de contrato em formato opaco e parâmetros codificados como tipos ScVal que exigem conhecimento específico do contrato para decodificação. Praticamente 0% de clear signing para interações Soroban brutas sem metadados externos.

Algorand

Sete tipos de transação tipados (Payment, Asset Transfer, Asset Configuration, Key Registration, Application Call, Asset Freeze, State Proof) — todos totalmente interpretáveis a partir da codificação MessagePack. O padrão ARC-4 ABI fornece assinaturas de métodos, nomes de parâmetros e descrições para smart contracts compatíveis.

• Contratos não-ARC-4 têm argumentos opacos.
• Todos os smart contracts podem gerar até 256 transações internas — incluindo chamadas aninhadas até 8 níveis — completamente invisíveis no momento da assinatura.

Cardano & Tezos

O modelo eUTXO do Cardano permite exibir entradas, saídas, taxas e valores multi-ativos para transações simples. Mas interações com scripts Plutus envolvem datums e redeemers que são estruturas de dados CBOR arbitrárias sem esquema padrão para interpretação humana. O CIP-21 observa explicitamente que o modo Plutus "visa máxima flexibilidade ao custo de potencial confusão para o usuário."

Tezos tem uma vantagem estrutural — tipos de parâmetro de contrato são armazenados on-chain e entrypoints usam nomes de string em vez de seletores baseados em hash, eliminando o problema de colisão. Mas a codificação binária Micheline ainda exige o esquema de tipos do contrato para decodificação completa, e o app Ledger Tezos reconhece exibição limitada de parâmetros complexos.

❌ Arquiteturalmente opaco — clear signing é um desafio enorme

Decisões fundamentais de design — e não apenas falta de ferramentas — tornam o clear signing inerentemente difícil aqui. Camadas externas de metadados ajudam em partes, mas não resolvem a arquitetura subjacente.

Ethereum / EVM Chains

O caso mais emblemático e estudado. Quando um usuário interage com um smart contract, o campo data da transação contém um seletor de função de 4 bytes (os 4 primeiros bytes do keccak256 da assinatura da função) seguido de parâmetros ABI-encoded em palavras de 32 bytes. Sem o ABI JSON do contrato — que não é armazenado on-chain — isso é apenas ruído hexadecimal. Uma carteira de hardware vendo 0xa9059cbb000...03e8 não tem como saber que significa "Transferir 1000 tokens para 0xABC..." sem metadados externos.

Os desafios se acumulam com padrões típicos do EVM:

• Colisões de seletores de função: O banco de dados 4byte.directory possui quase 1 milhão de assinaturas — muito além do limite do problema do aniversário para 32 bits. Funções diferentes podem gerar seletores idênticos.
• Contratos proxy: Executam via delegatecall para contratos de implementação cujos endereços podem mudar a qualquer momento. O hack da Bybit explorou exatamente essa brecha.
• Padrões multicall: Aninham calldata ABI-encoded dentro de parâmetros, exigindo decodificação recursiva.
• EIP-712: Melhora a legibilidade para mensagens off-chain (permissões, ordens), mas não resolve a opacidade das transações on-chain.

Solana

Provavelmente a arquitetura mais desafiadora para clear signing. As instruções das transações contêm um program_id, uma lista de contas e um array de bytes opaco com os dados da instrução. Não há ABI padronizado — cada programa define seu próprio formato de serialização. O framework Anchor oferece uma abordagem semi-padrão (discriminadores de 8 bytes a partir do SHA-256 do nome da instrução), mas é uma convenção de framework, não uma exigência de protocolo. Muitos programas não usam Anchor e não publicam IDLs.

• Address Lookup Tables em transações versionadas comprimem endereços de 32 bytes em índices de 1 byte — carteiras de hardware não conseguem verificar o conteúdo da lookup table porque não têm acesso on-chain. A própria documentação da Solana reconhece isso explicitamente.
• Cadeias de Cross-Program Invocation são invisíveis no momento da assinatura.
• Transferências simples de SOL e operações SPL token — a Ledger consegue interpretar. Interações DeFi, que representam a maior parte do volume de transações da Solana — blind signing é praticamente obrigatório.

TON

Combina múltiplas características arquiteturais que, individualmente, já dificultam o clear signing — e, juntas, tornam o desafio ainda maior:

• Estrutura de dados baseada em células (cell-based): Todos os dados são representados como árvores de células (cada uma com até 1023 bits e até 4 referências), exigindo travessia recursiva para interpretar mensagens maiores que uma célula.
• Codificação TL-B: Opera no nível de bits, com construtores complexos e referências recursivas — muito mais difícil de interpretar em hardware limitado do que formatos alinhados em bytes.
• Sem ABI universal: Op codes de 32 bits são convenção, não exigência do protocolo.
• Execução assíncrona: Uma única ação do usuário pode disparar mensagens internas em cascata entre múltiplos contratos e shards em blocos subsequentes. O usuário assina apenas a mensagem externa inicial — todo o resto é invisível e imprevisível no momento da assinatura.

Sui (Menção Honrosa)

Compartilha o sistema de tipos forte do Move com Aptos, o que ajuda no nível das instruções. Mas os Programmable Transaction Blocks do Sui podem conter até 1.024 comandos que encadeiam resultados entre operações — dividir uma moeda, depositar em um protocolo DeFi, tomar empréstimo com garantia, transferir os fundos, tudo em uma única transação atômica. Apesar dos comandos individuais serem bem tipados, exibir um PTB multi-etapas de forma realmente compreensível em uma tela de carteira de hardware é um desafio extremo de UX. Entender toda a transação exige analisar toda a sequência de comandos e suas dependências de dados.