Why Some Blockchains Show You What You're Signing (And Others Don't)

Tier 1: Architecturally transparent — transaction intent is readable by design

Four ecosystems stand out for making clear signing a natural consequence of their protocol design rather than an afterthought requiring external tooling.

XRP Ledger

XRP Ledger offers the strongest clear signing story of any major blockchain. Its architecture uses a finite set of ~50+ enumerated transaction types (Payment, OfferCreate, TrustSet, EscrowCreate, NFTokenMint, etc.), each with a fully defined schema of named, typed fields. 

The binary format is self-describing — a TransactionType field makes parsing completely deterministic, and the full field schema is maintained in the rippled source code's definitions file. 

A hardware wallet can display every field of every known transaction type: recipient, amount (with currency and issuer for tokens), fee, memos, and type-specific parameters. The account-based model means amounts are explicit (no UTXO complexity), and fees are a simple field rather than an implicit calculation. 

Nearly 100% of current mainnet transactions can be fully clear-signed. The only risk is that new transaction types added via protocol amendments (like recent Vault and Loan operations) require hardware wallet app updates; unknown types would fall back to blind signing.
 

Polkadot / Substrate

Polkadot has developed the most technically sophisticated clear signing solution in the industry. Its runtime metadata system (MetadataV14/V15) provides a complete, self-describing type registry for every pallet (module), call, and data type in the runtime. 

Every transaction (extrinsic) is structured as pallet_index || call_index || encoded_arguments, and the metadata tells you exactly what those indices mean and how to decode the arguments. 

The core challenge was that full metadata exceeds 200KB — far too large for hardware wallets with ~64KB RAM. The solution, RFC-0078 (Merkleized Metadata), builds a Merkle tree from the metadata and transmits only the relevant subset (types needed for the specific transaction) plus a cryptographic proof of inclusion. 

The metadata hash is verified on-chain via the CheckMetadataHash signed extension, making the system trustless. This enables a single generic Ledger application that works across all Polkadot parachains and relay chains without per-chain updates.

The approach handles runtime upgrades elegantly, even when call indices change, fresh metadata and proofs keep signing accurate.

Cosmos / Tendermint

Cosmos/Tendermint chains benefit from a typed message architecture where each transaction contains one or more sdk.Msg objects wrapped in Protobuf's google.protobuf.Any, which includes a field type_url that identifies the message type.
Standard messages like MsgSend, MsgDelegate, and MsgVote have well-known schemas. 

The ecosystem's dedicated clear signing solution is SIGN_MODE_TEXTUAL (ADR-050), introduced in Cosmos SDK v0.50. It renders transactions as a sequence of screens sized for small devices (~40 characters), with value renderers that convert raw data into human-readable formats: coins display as "2 ATOM" instead of "2000000uatom," addresses use bech32, timestamps use RFC3339. 

Developers can provide custom renderers for their message types (with the constraint that format and parse functions must be perfectly invertible). The signed payload includes both the textual representation and a hash of the raw bytes, preserving security guarantees.

NEAR Protocol

NEAR Protocol achieves clear signing through several architectural choices that prioritize human readability. Account identifiers are human-readable names, such as "alice.near", rather than hex addresses. 

Transactions contain typed Action enums (Transfer, Stake, FunctionCall, AddKey, etc.) that are always identifiable. Most critically, the FunctionCall action includes a method_name as a plain string (e.g., "transfer", "set_greeting") and arguments that are JSON-serialized by default. 

A hardware wallet can display: "Call method 'swap' on app.defi.near with args: {amount: 1000, token: 'usdc.near'}." This is dramatically more readable than any selector-based system. The main limitation is that some contracts opt for Borsh-serialized arguments for gas efficiency, which are opaque without the schema.

Tier 2: Conditionally Clear — Native Operations Work, Smart Contracts Break Things

Good clear signing for base-layer operations. Significant degradation when general-purpose programmability enters the picture.

Bitcoin

Bitcoin occupies a unique position: its transaction model creates clear signing challenges even without smart contracts. The UTXO model means raw transactions don't contain input amounts, i.e., inputs reference prior outputs by transaction hash and index, but omit how much those outputs were worth. 

Without this information, a hardware wallet cannot calculate the fee (which equals total inputs minus total outputs) or verify it isn't being tricked into overpaying. PSBT (BIP 174) solves this by wrapping unsigned transactions with UTXO metadata and BIP32 derivation paths for identifying change addresses. 

With PSBT, hardware wallets can clearly display recipient addresses, amounts, and fees for standard payments, covering roughly 90% of typical transactions. Complexity rises with multisig setups, timelocked scripts, and Taproot script-path spends—P2SH and P2WSH hide arbitrary scripts behind hashes, and Taproot's MAST structure makes alternative spending conditions invisible until used.

Aptos

Aptos benefits from Move's strong type system and the availability of onchain ABIs. Transaction payloads contain fully qualified function identifiers, like 0x1::aptos_account::transfer, module address, module name, and function name are all visible. 

The SDK can query onchain ABIs to deserialize BCS-encoded arguments. This means a hardware wallet with ABI access could display: "Call 0x1::aptos_account::transfer(recipient: 0xABC..., amount: 1000)." 

However, BCS (Binary Canonical Serialization) is not self-describing; without the ABI schema, raw BCS bytes are meaningless. Script payloads (arbitrary Move bytecode) bypass the structured-entry-function format entirely. The Ledger Aptos app includes an explicit "Enable Blind Signing" setting for complex transactions, confirming the gap between simple and complex operations.

Stellar

The tier-2 pattern in its purest form. Its 26 classic operation types (Payment, ChangeTrust, ManageSellOffer, etc.) have fixed schemas and are fully parseable — the Ledger app displays operation type, amount, destination, asset, memo, and fee in a step-by-step review. ~95% coverage for classic operations.

• Soroban smart contracts (launched 2024) reintroduce the exact opacity problem found on Ethereum. Calls arrive as InvokeHostFunction operations with contract addresses in an opaque format and parameters encoded as ScVal types that require contract-specific knowledge to decode. Near 0% clear signing for raw Soroban interactions without external metadata.

Algorand

Seven typed transaction types (Payment, Asset Transfer, Asset Configuration, Key Registration, Application Call, Asset Freeze, State Proof) — all fully parseable from their MessagePack encoding. The ARC-4 ABI standard provides method signatures, parameter names, and descriptions for compliant smart contracts.

• Non-ARC-4 contracts have opaque arguments.
• All smart contracts can generate up to 256 inner transactions — including nested calls 8 levels deep — that are completely invisible at signing time.

Cardano & Tezos

Cardano's eUTXO model allows clear display of inputs, outputs, fees, and multi-asset values for simple transactions. But Plutus script interactions involve datums and redeemers that are arbitrary CBOR-encoded data structures with no standard schema for human interpretation. CIP-21 explicitly notes that Plutus mode "aims for maximum flexibility at the cost of users being potentially misled."

Tezos has a structural advantage — contract parameter types are stored on-chain and entrypoints use string names rather than hash-based selectors, eliminating the collision problem. But Micheline binary encoding still requires the contract's type schema for full decoding, and the Ledger Tezos app acknowledges limited display of complex parameters.

❌ Architecturally Opaque — Clear Signing Is an Uphill Battle

Fundamental design choices — not tooling gaps — make clear signing inherently difficult here. External metadata layers help at the margins but can't fix the underlying architecture.

Ethereum / EVM Chains

The most prominent and most studied case. When a user interacts with a smart contract, the transaction's data field contains a 4-byte function selector (the first 4 bytes of keccak256 of the function signature) followed by ABI-encoded parameters in 32-byte words. Without the contract's ABI JSON — which is not stored on-chain — this is pure hexadecimal noise. A hardware wallet seeing 0xa9059cbb000...03e8 cannot know it means "Transfer 1000 tokens to 0xABC..." unless it has external metadata.

The challenges compound with patterns endemic to EVM:

• Function selector collisions: The 4byte.directory database holds close to 1 million signatures — well past the birthday-problem threshold for a 32-bit space. Different functions can produce identical selectors.
• Proxy contracts: Route execution through delegatecall to implementation contracts whose addresses can change at any time. The Bybit hack exploited exactly this gap.
• Multicall patterns: Nest ABI-encoded calldata inside parameters, requiring recursive decoding.
• EIP-712: Improves readability for off-chain messages (permits, orders) but doesn't touch on-chain transaction opacity.

Solana

Arguably the most challenging architecture for clear signing. Transaction instructions contain a program_id, an account list, and an opaque byte array of instruction data. There is no standardized ABI — each program defines its own serialization format. The Anchor framework provides a semi-standard approach (8-byte discriminators from SHA-256 of the instruction name), but it's a framework convention, not a protocol requirement. Many programs don't use Anchor and don't publish IDLs.

• Address Lookup Tables in versioned transactions compress 32-byte addresses into 1-byte indices — hardware wallets cannot verify the lookup table contents because they lack on-chain access. Solana's own documentation explicitly acknowledges this.
• Cross-Program Invocation chains are invisible at signing time.
• Simple SOL transfers and SPL token operations — Ledger can parse those. DeFi interactions, which represent the vast majority of Solana's transaction volume — blind signing is essentially required.

TON

Combines multiple architectural features that independently resist clear signing, let alone in combination:

• Cell-based data structure: All data represented as trees of cells (each holding up to 1023 bits with up to 4 references), requiring recursive tree traversal to parse messages that exceed a single cell.
• TL-B encoding: Operates at the bit level with complex constructors and recursive references — significantly harder to parse on constrained hardware than byte-aligned formats.
• No universal ABI: 32-bit op codes are convention, not protocol-enforced.
• Asynchronous execution: A single user action can trigger cascading internal messages across multiple contracts and shards in subsequent blocks. The user signs only the initial external message — everything downstream is invisible and unpredictable at signing time.

Sui (Honorable Mention)

Shares Move's strong type system with Aptos, which helps at the instruction level. But Sui's Programmable Transaction Blocks can contain up to 1,024 commands that chain results between operations — split a coin, deposit into a DeFi protocol, borrow against collateral, transfer the proceeds, all in one atomic transaction. While individual commands are well-typed, displaying a multi-step PTB on a hardware wallet screen in a way that's genuinely meaningful is an extreme UX challenge. Understanding the full transaction requires analyzing the entire command sequence with its inter-command data dependencies.