Blind Signing on Soroban: Stellar's Smart Contract Security Gap

Stellar Got Clear Signing Right - Then Added Soroban

Ledger's Stellar application has, for years, been one of the better hardware wallet integrations in the industry. When you sign a Payment operation, your device shows the destination address, the asset, and the amount in clear human-readable form. When you add a trustline via ChangeTrust, the device shows the asset code and issuer. When you manage an offer on the DEX, the parameters are parsed and presented to you. For Stellar's native operation types, clear signing largely works.

In 2024, Stellar activated Protocol 20 and launched Soroban: a WASM-based smart contract platform that introduces a new operation type - InvokeHostFunction. This operation allows a transaction to call an arbitrary function on an arbitrary Soroban smart contract with arbitrary arguments encoded as SCVal (Smart Contract Value) types in XDR binary format. Hardware wallets, including Ledger, cannot parse arbitrary Soroban contract invocations into human-readable descriptions. When your signers approve a Soroban contract call on a hardware device today, they are, in most cases, blind signing - approving a binary payload whose content is not visible to them.

Ethereum encountered this exact problem at scale. Between 2021 and 2025, blind signing of arbitrary EVM calldata contributed to over $1.9 billion in documented theft. The Ethereum community spent years building ERC-7730 and ERC-8213 as mitigations. Soroban is at the beginning of that same curve - but the lesson has already been written. The question is whether the Stellar ecosystem reads it before a protocol of sufficient size is exploited.

How Soroban Breaks the Clear Signing Model

To understand why this is hard to fix at the wallet level, you need to understand how Soroban changed what a transaction can contain.

Stellar's classic transaction format uses XDR (External Data Representation), a binary serialisation standard. A classic transaction contains typed operations - Payment, CreateAccount, ManageSellOffer, ChangeTrust - with named, typed fields defined in the Stellar protocol specification. Because those types are fixed and bounded, your hardware wallet can implement a static parser that covers the complete operation set. That is why clear signing works for classic Stellar operations: the parameter space is known in advance.

Soroban changes this entirely. The InvokeHostFunction operation introduced in Protocol 20 carries a HostFunction payload that specifies a contract address, a function name as a SCSymbol, and a vector of SCVal arguments. SCVal is a variant type that can encode integers, addresses, byte vectors, booleans, maps, vectors, and custom user-defined types. The meaning of a specific argument at position n in a call to function f on contract C is determined entirely by that contract's source code - not by the Stellar protocol. Your hardware wallet can parse the XDR structurally (contract ID, function name, argument count) but cannot interpret what the arguments mean without external contract metadata. The function name swap with two i128 arguments tells the device nothing about which assets are being swapped, in what direction, or at what minimum output - information that is essential for informed consent.

This is structurally identical to the Ethereum calldata problem. The encoding scheme differs; the vulnerability class is the same. And the solution architecture that Ethereum built - descriptor files mapping contract interfaces to human-readable display instructions - is directly applicable to Soroban, with one important advantage: Soroban already has a better foundation for it.

What Your Hardware Wallet Actually Shows for Soroban

If you are a Soroban protocol operator using Ledger to sign administrative transactions, here is what your device currently shows you. For an InvokeHostFunction call, the device displays the contract address and the function name - information parseable from the XDR structure without any external metadata. What it cannot show you is anything else that matters: asset symbols, human-readable amounts with correct decimal scaling, recipient addresses with labelling, or a summary of what the transaction is actually doing.

For a Soroswap liquidity removal, you see a contract address and a function name. You do not see which liquidity pool, which two assets, what minimum output amounts, or what recipient address. For a Soroban lending protocol borrow call, you see a function name. You do not see the asset being borrowed, the amount, the collateral involved, or the health factor impact. For a multisig account executing an administrative Soroban contract operation, your co-signers see bytes.

This is not a criticism of Ledger's Stellar application specifically - it is a structural consequence of the architecture. Without a descriptor standard equivalent to ERC-7730, there is no mechanism by which your hardware wallet can receive and verify metadata telling it how to interpret Soroban contract arguments for a given function. The wallet cannot embed full parameter metadata for every Soroban contract - the set is unbounded and growing. Without a registry and descriptor format, clear signing for arbitrary Soroban contracts is not implementable regardless of firmware quality.

What Your Exposure Looks Like in Practice

If you are building or operating a Soroban protocol with material TVL and administrative operations executed via multisig accounts or operational wallets, your signers are approving XDR-encoded InvokeHostFunction payloads they cannot read. That is the exposure. Here is what an attacker does with it.

An attacker who compromises the web interface used by your multisig signers can substitute the contract address or function arguments in a pending transaction payload. Your hardware wallet will display the function name and contract address - but if your signers have normalised approving Soroban transactions without verifying those values against an independent source, the substitution goes undetected. Each signer approves. The attacker executes. For a Soroban contract with an upgrade function that accepts a new WASM hash as its argument, a single successful attack of this type replaces your entire contract implementation.

The Stellar multisig model adds a specific consideration. Stellar accounts have configurable signing thresholds - low, medium, and high - with different operations requiring different threshold levels. A high-threshold operation on an account with multiple signers requires collecting authorisation from a quorum. If your signers use hardware wallets and are working from a shared signing interface, that interface is a single attack surface. An attacker who compromises it can present each signer with a transaction they believe is routine while the actual XDR payload contains manipulated parameters. Because no signer can independently verify the payload content from their device, each approves the manipulated transaction on the basis of trust in the interface alone. That is the same trust model that failed at Bybit, Radiant Capital, and WazirX.

The Standard That Does Not Yet Exist

Ethereum's ERC-7730 defines a JSON-based descriptor format that maps a smart contract address and function selector to human-readable display instructions for hardware wallets. Protocol teams publish descriptors to a public registry. Hardware wallet firmware fetches, verifies, and applies them at signing time. The result: a Uniswap swap, an Aave deposit, or a Compound borrow displays as human-readable intent on your hardware wallet screen rather than as ABI-encoded hex.

Soroban has no equivalent standard. The Stellar Ecosystem Proposals (SEPs) catalogue covers authentication (SEP-10), payment paths (SEP-31), asset interoperability (SEP-1), and transaction URI schemes (SEP-7). None address the hardware wallet display problem for Soroban contract invocations. There is no community-maintained registry of Soroban contract descriptors. There is no formal proposal in progress as of this writing that addresses the clear signing gap at the hardware wallet level.

This is not because the problem is unrecognised. Soroban is young - Protocol 20 launched in early 2024 - and the ecosystem is still building. But the urgency of the clear signing gap scales with TVL. As more value flows through Soroban contracts, the cost-benefit ratio for an attacker targeting this vulnerability improves. The Ethereum ecosystem crossed that threshold long before ERC-7730 was drafted. The Soroban ecosystem is approaching it with the solution architecture already proven and available. Use that advantage.

The Technical Path to a Descriptor Standard

Soroban is actually better positioned than Ethereum was to build a clear signing descriptor standard, for one specific reason: the contract specification is already on-chain.

Soroban contracts compiled to WASM expose their interface through a contract specification (contractspec) embedded in the WASM binary as a custom section. This is a machine-readable definition of the contract's functions, their parameter names, and their types - analogous to the ABI JSON that Ethereum contracts publish, but with a critical advantage: Soroban's contractspec is embedded in the deployed artefact itself and is therefore always present, always verifiable on-chain, and co-deployed with the contract. A descriptor standard can reference contractspec entries directly rather than requiring a separately maintained ABI. That materially reduces the maintenance burden compared to the Ethereum approach.

A descriptor standard sits on top of this. It maps each function in the contractspec to human-readable display instructions: how to label each parameter, how to format each value (rendering an i128 holding a Stellar asset amount as a decimal with the correct number of decimals and the asset symbol), what intent summary to display at the top of the signing screen, and which parameters require explicit signer confirmation. On the hardware wallet side, Ledger's Stellar application would need to be extended to fetch, verify, and apply descriptors at signing time - the same architecture implemented for ERC-7730 on the EVM side. The firmware verifies that each descriptor is signed by the contract's publisher and bound to the specific contractspec hash of the deployed WASM, preventing a scenario where an attacker substitutes a legitimate descriptor for a malicious contract.

How a New SEP Would Solve This

A Stellar Ecosystem Proposal (SEP) is the Stellar community's standardisation mechanism for off-protocol conventions: wallet interoperability, federation, asset metadata, authentication, and payment flows. The clear signing gap for Soroban is precisely the kind of cross-ecosystem coordination problem that SEPs exist to solve. Here is what a new SEP for Soroban clear signing - call it SEP-CS for discussion purposes - would need to define.

The descriptor format. A JSON schema for Soroban contract call descriptors. Each descriptor file references a deployed contract by its network, contract ID, and the contractspec hash of the deployed WASM - binding the descriptor to the specific deployed implementation. For each function in the contract, the descriptor declares: a human-readable intent template (e.g., "Swap {amount_in} {asset_in} for at least {min_amount_out} {asset_out}"), the display format for each argument (decimal scaling, asset symbol resolution, address labelling, and whether the value requires confirmation), and any field-level warnings - for example, flagging an upgrade function as a high-risk administrative operation requiring explicit confirmation. The format would be versioned and extensible, with a core field set that all compliant wallets must implement.

The registry model. A community-maintained registry structure, analogous to LedgerHQ/clear-signing-erc7730-registry. Protocol teams submit descriptor files for their deployed contracts via pull request. Submitted descriptors are reviewed for technical correctness and bound to specific contract IDs and contractspec hashes. A companion CLI tool - built on top of the Stellar SDK - allows your team to validate descriptor files against deployed contracts before submission. Hardware wallet firmware and browser-extension wallets consume the registry through a standardised API endpoint.

The trust and verification model. Hardware wallets operate in an adversarial environment. A descriptor fetched at signing time must be verifiable as authentic before the wallet applies it - otherwise an attacker who compromises the registry endpoint can substitute a misleading descriptor for a malicious contract. The SEP would specify a signing requirement: each descriptor must be signed by a key associated with the contract's publisher. The firmware verifies this signature before applying any display transformation. Because the descriptor is bound to a specific contractspec hash, the firmware can also verify that the contract being invoked matches the contract the descriptor was written for - closing the descriptor substitution attack vector.

The wallet behaviour specification. The minimum required behaviour for a compliant wallet when signing a Soroban InvokeHostFunction transaction. If a valid descriptor is available: display the intent summary, all confirmation-required parameters in decoded form, and a clear signing indicator. If no descriptor is available: display an explicit "unverified contract interaction" warning, show the raw function name and contract ID, and require the user to actively dismiss a risk acknowledgement before proceeding. This requirement - making blind signing visually distinct and friction-ful - is the intervention that prevents signers from normalising approval of unreadable payloads.

The SEP process path. A proposal of this scope begins as a GitHub discussion in stellar/stellar-protocol under the Ecosystem proposals category: post the problem statement and high-level design for community input. After initial discussion, submit a draft SEP as a pull request in the standard SEP format (header metadata, motivation, specification, design rationale, security considerations). The Stellar Development Foundation's protocol team participates in the review alongside community members. For a SEP with hardware wallet implementation implications, direct engagement with Ledger's Stellar application team is essential in parallel - the firmware specification needs to be co-developed with the implementer, not handed over after the fact. Coordination with Firefly Wallet, Lobstr, and other wallets that support Soroban interactions would bring the broader ecosystem into alignment before ratification. The ERC-7730 standardisation process took approximately eighteen months in the Ethereum ecosystem. Soroban's advantage is that the model is already proven. A motivated coalition of protocol teams, hardware wallet engineers, and SDF staff could complete this path materially faster.

What Your Team Should Do Right Now

The SEP process operates on a timescale of months to years. In the interim, your team has immediate options that reduce blind signing exposure without waiting for ecosystem-level standardisation.

Publish your contract interface specifications publicly. Make your Soroban contract specifications, function signatures, and parameter semantics publicly available in a structured format - ideally one compatible with the emerging descriptor standard. Publish the contractspec JSON derived from your deployed WASM as a versioned artefact in your public repository alongside each deployment. This enables manual verification by your signers today and positions you for rapid descriptor adoption when the standard arrives.

Enforce independent transaction verification in every multisig signing workflow. Every signer in your Stellar multisig quorum should independently verify the XDR transaction hash and decoded operation content through a channel separate from the signing interface. Stellar Laboratory's XDR viewer, the Stellar Expert explorer, and the Stellar CLI all provide independent transaction decoding. Require signers to cross-check the contract ID and function name against a known-good reference before approving on the hardware device. This procedural control would have prevented the Bybit, WazirX, and Radiant Capital attacks.

Protect administrative functions with time delays and on-chain monitoring. Any Soroban contract function that upgrades the implementation, modifies critical parameters, or moves treasury funds should incorporate a time delay between authorisation and execution, combined with on-chain event emission that feeds your monitoring infrastructure. This does not prevent a blind signing attack at the point of authorisation, but it creates a detection and response window before the payload executes.

Audit your signing interface for payload substitution risk. The web interfaces, CLI scripts, and backend services through which your signers construct and approve Soroban transactions are part of your security perimeter. Assess them for supply chain risk: npm dependency integrity, subresource integrity for frontend assets, and the integrity of any service that constructs or presents XDR transaction payloads to signers. The Radiant Capital attack executed entirely through a compromised signing interface; the hardware wallets signed exactly what they were given.

Initiate or co-sponsor the SEP. If you are building significant TVL on Soroban, you have both the most to lose from a blind signing exploit and the most leverage to accelerate a community standard. A working group of three to five major Soroban protocols drafting the initial SEP discussion post, jointly engaging Ledger's Stellar application team, and coordinating with the Stellar Development Foundation is the fastest path from the current gap to a ratified standard. Waiting for the standard to arrive without participating in its development means waiting longer and with less influence over the design.