SEP proposal: Clear signing descriptor standard for Soroban contract invocations

[kingfavourjudah]

Problem

Stellar's classic operation types (Payment, ChangeTrust, ManageSellOffer, etc.) are fully parseable by hardware wallets — Ledger's Stellar app displays them in human-readable form. Soroban changes this. The InvokeHostFunction operation introduced in Protocol 20 carries arbitrary SCVal-encoded arguments whose meaning is determined entirely by the contract's source code, not the Stellar protocol. Hardware wallets cannot interpret these arguments without external metadata. As a result, signing Soroban contract calls on a hardware device today is, in almost all cases, blind signing — the signer approves a binary payload whose content is not visible to them.

This is structurally the same problem Ethereum encountered with ABI-encoded calldata, which contributed to over $1.9B in documented losses between 2021 and 2025. Ethereum's response was ERC-7730 (clear signing descriptors) and a community-maintained registry. Soroban has no equivalent.

Proposed solution

A new SEP defining a clear signing descriptor standard for Soroban — working title SEP-CS — that would specify:

• A JSON descriptor format mapping a deployed contract (identified by network, contract ID, and contractspec hash) to human-readable display instructions for each function
• A community-maintained registry of verified descriptors, analogous to LedgerHQ/clear-signing-erc7730-registry
• A trust and verification model requiring descriptors to be signed by the contract publisher and bound to the deployed contractspec hash
• Minimum required wallet behaviour when a descriptor is present vs. absent (explicit "unverified contract interaction" warning for blind signing flows)

Soroban has an advantage Ethereum lacked: the contractspec is embedded in the deployed WASM artefact and is therefore always present and verifiable on-chain. A descriptor standard can reference it directly rather than requiring a separately maintained ABI.

Happy to provide a full draft specification, technical design rationale, and implementation notes upon request.

[tupui]

This is a real concern but the situation is not that bad. Wallets are showing now function calls and arguments (work in progress for hardware wallets.) So it's not a blind signing. You will always have to trust a 3rd party in the context of smart contracts, there is the Stellar Registry which is proposing a solution to the having a community vetted list. Combined with SEP-55 and SEP-58, we have something compelling.

[kingfavourjudah]

Thanks for pointing this out. I agree that the situation is improving, and I should distinguish between the current wallet UX work and the underlying standardisation problem more clearly.

My concern isn't that Soroban wallets can never display function calls or arguments. The key question is whether a hardware wallet can independently establish that the human-readable representation it is showing corresponds to the exact contract invocation the signer is approving.

For arbitrary Soroban contracts, interpreting an InvokeHostFunction still depends on contract-specific semantics. That's where I think a standardised, verifiable descriptor layer could complement SEP-55, SEP-58, the Stellar Registry, and the ongoing wallet work.

In particular, I'd like to explore:

• How the displayed function and arguments are cryptographically bound to the deployed contractspec.
• How a hardware wallet can distinguish a verified descriptor from unverified metadata.
• What the signer should see when no trusted descriptor exists.
• Whether the existing proposals and registry can already provide these guarantees, or whether a dedicated SEP is still useful.

I agree that users will always have some level of trust in external metadata and contract publishers. The goal here isn't to eliminate that trust, but to make the trust assumptions explicit, verifiable, and consistent across wallets.

I'd be very interested in comparing the proposed SEP-CS model against the current SEP-55/SEP-58 + Stellar Registry approach to see where there is overlap and, importantly, whether anything is still missing.