docs: add Stellar chain support RPC methods by jakubuid · Pull Request #154 · WalletConnectFoundation/docs

jakubuid · 2026-08-06T10:23:10Z

Summary

Adds a Stellar chain-support page to the Wallet SDK docs, documenting the JSON-RPC methods wallets should implement to transact over the WalletConnect network on Stellar. Content is based on the Stellar Specs — WalletConnect Network (Proposal) and follows the same format as the existing chain-support pages (EVM, Solana, Canton, Tron, etc.).

Methods documented

stellar_signXDR — sign a TransactionEnvelope without broadcasting (primary method for fee-abstracted / fee-bump flows)
stellar_signAndSubmitXDR — sign and submit in one step
stellar_signMessage — domain-separated Ed25519 message signing (SEP-10 style sign-in)
stellar_signAuthEntry — Soroban SorobanAuthorizationEntry signing

Also included

CAIP-2 / CAIP-10 / CAIP-19 identifiers, account (StrKey) format, and base64-XDR encoding convention
Session proposal example and events (accountsChanged, chainChanged)
Signing semantics: network-passphrase binding, fee-bump envelope handling, and tx-hash / explorer discoverability
Registered the page in docs.json navigation and the chain-support overview

Marked as draft — the underlying spec is a proposal still under review; a <Warning> reflects this on the page.

🤖 Generated with Claude Code

Add Stellar JSON-RPC method reference to Wallet SDK chain support, based on the Stellar Specs — WalletConnect Network proposal. Covers stellar_signXDR, stellar_signAndSubmitXDR, stellar_signMessage, and stellar_signAuthEntry (Soroban), plus CAIP identifiers, account/XDR conventions, events, and signing semantics. Registers the page in docs.json navigation and the chain-support overview. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

mintlify · 2026-08-06T10:23:13Z

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
walletconnect-docs	🟢 Ready	View Preview	Aug 6, 2026, 10:23 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

ignaciosantise · 2026-08-10T19:33:05Z

+| CAIP-10 | `stellar:pubnet:G…` — base32 StrKey account ID (56 chars, version byte `0x30`)                           |
+| CAIP-19 | `stellar:pubnet/slip44:148` (XLM) or `stellar:pubnet/asset:{code}-{issuer}` (issued assets)              |
+
+The CAIP-2 reference `pubnet` matches the [Stellar CAIP-2 namespace draft](https://github.com/ChainAgnostic/namespaces/blob/main/stellar/caip2.md). The network passphrase (`"Public Global Stellar Network ; September 2015"` for mainnet, `"Test SDF Network ; September 2015"` for testnet) is **not** the CAIP-2 reference — it is a separate signing-domain constant that wallets MUST bind into every signature (see [Signing semantics](#signing-semantics)).


what's this note? is this useful?

Trimmed. Kept just the CAIP-2-reference-vs-network-passphrase distinction — it's a real implementer footgun (the signature binds the passphrase, derived from the chain, not the CAIP-2 reference) — and left the full detail to the Signing semantics section.

ignaciosantise · 2026-08-10T19:35:45Z

+- The envelope's discriminant determines tx version: `ENVELOPE_TYPE_TX_V0`, `ENVELOPE_TYPE_TX`, or `ENVELOPE_TYPE_TX_FEE_BUMP`.
+- Wallets MUST accept all three; wallets MAY emit signatures only on V1 and fee-bump envelopes (V0 is deprecated).
+
+## Session Properties


why is this section called Session Properties? it only shows the session proposal, i dont see properties here

Good catch — renamed to Session Proposal. It shows the proposal (optionalNamespaces), not sessionProperties.

ignaciosantise · 2026-08-10T19:36:33Z

+
+### stellar_signXDR
+
+Asks the wallet to attach a signature to a Stellar `TransactionEnvelope` and return the resulting envelope **without broadcasting it**. The dApp (or a relayer it trusts — e.g. pay-core's fee-payer) is responsible for submission.


Suggested change

Asks the wallet to attach a signature to a Stellar `TransactionEnvelope` and return the resulting envelope **without broadcasting it**. The dApp (or a relayer it trusts — e.g. pay-core's fee-payer) is responsible for submission.

Asks the wallet to attach a signature to a Stellar `TransactionEnvelope` and return the resulting envelope **without broadcasting it**. The dApp (or a relayer it trusts) is responsible for submission.

ignaciosantise · 2026-08-10T19:39:40Z

+sign(Ed25519, sha256("StellarMessage" || 0x00 || message))
+```
+
+The literal byte string `"StellarMessage"` (14 bytes) followed by a `0x00` separator MUST be hashed alongside the message bytes. This matches the SEP-53 (in-draft) convention and ensures cross-context replay is impossible — a SEP-10 challenge transaction would never collide with a `stellar_signMessage` payload.


Suggested change

The literal byte string `"StellarMessage"` (14 bytes) followed by a `0x00` separator MUST be hashed alongside the message bytes. This matches the SEP-53 (in-draft) convention and ensures cross-context replay is impossible — a SEP-10 challenge transaction would never collide with a `stellar_signMessage` payload.

The literal byte string `"StellarMessage"` (14 bytes) followed by a `0x00` separator MUST be hashed alongside the message bytes. This matches the [SEP-53](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0053.md) convention and ensures cross-context replay is impossible — a SEP-10 challenge transaction would never collide with a `stellar_signMessage` payload.

Applied the finalized SEP-53 algorithm here instead of the inline suggestion (per your general comment, which supersedes it): prefix is "Stellar Signed Message:\n" concatenated directly, no 0x00 separator and no length prefix.

ignaciosantise · 2026-08-10T19:42:08Z

+| Event             | Payload                              | Notes                                                                                        |
+| ----------------- | ------------------------------------ | -------------------------------------------------------------------------------------------- |
+| `accountsChanged` | `{ accounts: string[] }` (CAIP-10)   | Emitted when the user changes the active account in their wallet, or revokes access for an account. |
+| `chainChanged`    | `{ chainId: string }` (CAIP-2)       | Reserved for future testnet support. Today, only `stellar:pubnet` is emitted.                |


what does "Reserved for future testnet support" mean?

Reworded. Both networks are supported (stellar:pubnet and stellar:testnet), so chainChanged now describes switching the active network rather than "reserved for future testnet support".

ignaciosantise · 2026-08-10T19:45:14Z

+
+## Additional Resources
+
+- [WalletConnect Wallet SDK — Ethereum chain support](/wallet-sdk/chain-support/evm) — structural template for this document.


do we need this one?

Removed — it was an authoring-meta note ("structural template for this document"), not a reader resource.

ignaciosantise · 2026-08-10T19:45:19Z

+## Additional Resources
+
+- [WalletConnect Wallet SDK — Ethereum chain support](/wallet-sdk/chain-support/evm) — structural template for this document.
+- [WalletConnect Wallet SDK — Solana chain support](/wallet-sdk/chain-support/solana) — closest precedent for an Ed25519-based chain.


do we need this one?

Removed for the same reason (the chain-support overview page already links all chains).

ignaciosantise · 2026-08-10T19:45:43Z

+- [WalletConnect Wallet SDK — Solana chain support](/wallet-sdk/chain-support/solana) — closest precedent for an Ed25519-based chain.
+- [CAIP-2](https://chainagnostic.org/CAIPs/caip-2) and [CAIP-10](https://chainagnostic.org/CAIPs/caip-10) — chain and account identifiers.
+- [Stellar CAIP-2 namespace draft](https://github.com/ChainAgnostic/namespaces/blob/main/stellar/caip2.md).
+- [Stellar SEP-7](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0007.md), [SEP-10](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0010.md).


Added SEP-53 to the references.

ignaciosantise · 2026-08-10T19:46:08Z

+- [CAIP-2](https://chainagnostic.org/CAIPs/caip-2) and [CAIP-10](https://chainagnostic.org/CAIPs/caip-10) — chain and account identifiers.
+- [Stellar CAIP-2 namespace draft](https://github.com/ChainAgnostic/namespaces/blob/main/stellar/caip2.md).
+- [Stellar SEP-7](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0007.md), [SEP-10](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0010.md).
+- [Freighter API reference](https://docs.freighter.app/docs/guide/usingFreighterWebApp).


what's this?

should we point here?

Repointed to the Freighter WalletConnect mobile docs you linked, and dropped the generic web-app API reference.

ignaciosantise · 2026-08-12T18:23:51Z

stellar_signMessage documents a superseded algorithm. The doc specifies sha256("StellarMessage" || 0x00 || message) as "the SEP-53 (in-draft) convention" — but finalized SEP-53 replaced the prefix:

sign(Ed25519, sha256("Stellar Signed Message:\n" || message))

The fixed UTF-8 string "Stellar Signed Message:\n" (trailing newline) is concatenated directly with the message bytes — no 0x00 separator, no length prefix (mirrors Bitcoin/Ethereum signed messages). As written, wallets following this doc produce signatures no compliant Stellar wallet/SDK can verify, and a dApp verifier mirroring it only round-trips against the same wrong prefix — a false positive that hides the incompatibility.

Verifiable against SEP-53's official vectors (seed SAKICEVQLYWGSOJS4WW7HZJWAHZVEEBS527LHK5V4MLJALYKICQCJXMW):

Message	Expected signature (base64)
`Hello, World!`	`fO5dbYhXUhBMhe6kId/cuVq/AfEnHRHEvsP8vXh03M1uLpi5e46yO2Q8rEBzu3feXQewcQE5GArp88u6ePK6BA==`
`2zZDP1sa1BVBfLP7TeeMk3sUbaxAkUhBhDiNdrksaFo=` (base64 bytes)	`VA1+7hefNwv2NKScH6n+Sljj15kLAge+M2wE7fzFOf+L0MMbssA1mwfJZRyyrhBORQRle10X1Dxpx+UOI4EbDQ==`

The "StellarMessage" || 0x00 scheme produces neither; the finalized prefix reproduces both. Replay protection is unchanged — the prefix still domain-separates messages from tx bodies. (The other three methods match the impl and need no change.)

- stellar_signMessage: use finalized SEP-53 preimage sha256("Stellar Signed Message:\n" || message) — corrected prefix, no 0x00 separator, no length prefix; link SEP-53 - rename "Session Properties" -> "Session Proposal" (it shows the proposal) - signXDR: drop pay-core-specific relayer mention from the public spec - chainChanged: describe network switching (pubnet <-> testnet) instead of "reserved for future testnet support" (both networks are supported) - tighten the CAIP-2 reference vs network-passphrase note - Additional Resources: drop the EVM/Solana authoring-meta links, add SEP-53, point Freighter link at its WalletConnect mobile docs Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

jakubuid · 2026-08-17T08:42:29Z

Fixed in e0b0d38 — thanks, this was spot on.

stellar_signMessage now documents the finalized SEP-53 preimage:

sign(Ed25519, sha256("Stellar Signed Message:\n" || message))

Corrected prefix, no 0x00 separator, no length prefix, and the SEP-53 link is added to the references.

For what it's worth, the reference implementation in web-examples (react-wallet-v2 StellarLib.signMessage + the react-dapp-v2 verifier) is now on this exact algorithm and pinned against SEP-53's official vectors — the Hello, World! and binary signatures reproduce byte-for-byte, so the doc and impl agree. The other three methods were already correct and are unchanged.

mintlify Bot deployed to staging August 6, 2026 10:23 View deployment

jakubuid marked this pull request as ready for review August 6, 2026 14:16

yesgou471 approved these changes Aug 8, 2026

View reviewed changes

jakubuid requested review from ganchoradkov and ignaciosantise August 10, 2026 06:14

ignaciosantise reviewed Aug 10, 2026

View reviewed changes

mintlify Bot deployed to staging August 17, 2026 08:42 View deployment

ganchoradkov approved these changes Aug 17, 2026

View reviewed changes


		### stellar_signXDR

		Asks the wallet to attach a signature to a Stellar `TransactionEnvelope` and return the resulting envelope without broadcasting it. The dApp (or a relayer it trusts — e.g. pay-core's fee-payer) is responsible for submission.

	The literal byte string `"StellarMessage"` (14 bytes) followed by a `0x00` separator MUST be hashed alongside the message bytes. This matches the SEP-53 (in-draft) convention and ensures cross-context replay is impossible — a SEP-10 challenge transaction would never collide with a `stellar_signMessage` payload.
	The literal byte string `"StellarMessage"` (14 bytes) followed by a `0x00` separator MUST be hashed alongside the message bytes. This matches the [SEP-53](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0053.md) convention and ensures cross-context replay is impossible — a SEP-10 challenge transaction would never collide with a `stellar_signMessage` payload.


		## Additional Resources

		- [WalletConnect Wallet SDK — Ethereum chain support](/wallet-sdk/chain-support/evm) — structural template for this document.

Uh oh!

Conversation

jakubuid commented Aug 6, 2026

Summary

Methods documented

Also included

Uh oh!

mintlify Bot commented Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ignaciosantise Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ignaciosantise commented Aug 12, 2026

Uh oh!

jakubuid commented Aug 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mintlify Bot commented Aug 6, 2026 •

edited

Loading

ignaciosantise Aug 10, 2026 •

edited

Loading