Stellar SEP-7

Overview

SEP-0007 ("SEP-7") is a Stellar Ecosystem Proposal that defines a URI scheme to facilitate delegated signing on the Stellar network [1, 2]. It specifies a payload — typically embedded in a qr-code or a clickable link — that a requesting application (a merchant, a multisig coordinator, a website) hands to a wallet so the wallet can present a transaction or payment to the user for explicit consent and signing. The wallet, not the requester, holds the private key; SEP-7 is the wire format that carries the request to sign [1].

URIs take the form web+stellar:<operation>?<param1>=<value1>&<param2>=<value2> [1, 2]. The web+ prefix is used deliberately: per Mozilla's registerProtocolHandler rules, browser-registrable custom schemes for web pages must carry a web+ prefix, so SEP-7 links can be handled by a web wallet as well as a native app [1].

Two operations are defined: pay (request a payment to a destination) and tx (request signing of a fully-formed transaction envelope) [1, 2]. A distinguishing feature versus plain "address QR codes" is an optional signed-origin mechanism: a requester can attach origin_domain + signature, and the wallet verifies the signature against a public key published in the domain's stellar.toml, proving who built the request [1].

History

SEP-7 was authored by Nikhil Saraf (Lightyear.io / Stellar Development Foundation), created 2018-05-07, and last updated 2020-07-29 at version 2.1.0; its status is Active [1]. SEPs are the Stellar ecosystem's standards-track documents (analogous to BIPs/EIPs), maintained in the stellar/stellar-protocol repository under ecosystem/ [1, 3]. SEP-7 references SEP-0011 (Txrep) for its field-replacement syntax and SEP-0001 (stellar.toml) for publishing the request-signing key [1].

Technical specification

pay operation

Requests payment to a destination with an optional asset and amount [1, 2]:

Parameter	Required	Notes
destination	yes	Account ID or payment address that receives the payment
amount	no	Amount the destination receives; omit to let the user enter it
asset_code	no	Asset code; defaults to native XLM
asset_issuer	no	Issuer account ID; defaults to native XLM
memo	no	Memo (base64+URL-encoded for HASH/RETURN, URL-encoded for TEXT)
memo_type	no	One of MEMO_TEXT, MEMO_ID, MEMO_HASH, MEMO_RETURN
callback	no	URL-encoded callback (url: prefix) to POST the signed result to
msg	no	Informational message shown to the user (max 300 chars, never on-chain)
network_passphrase	no	For non-public networks
origin_domain	no	Fully-qualified domain of the requester
signature	no	Base64+URL-encoded signature over the request

Example [1]:

web+stellar:pay?destination=GCALNQQBXAPZ2WIRSDDBMSTAKCUH5SG6U76YBFLQLIXJTF7FE5AX7AOO&amount=120.1234567&memo=skdjfasf&memo_type=MEMO_TEXT&msg=pay%20me%20with%20lumens

tx operation

Requests signing of a specific base64-encoded XDR TransactionEnvelope [1, 2]:

Parameter	Required	Notes
xdr	yes	Base64-encoded, then URL-encoded TransactionEnvelope
replace	no	Fields to be replaced, expressed in SEP-0011 Txrep paths with hints
callback	no	URL-encoded callback (url: prefix)
pubkey	no	Public key the wallet should sign with (useful for multisig)
chain	no	URL-encoded nested SEP-7 request (max 7 levels deep)
msg, network_passphrase, origin_domain, signature	no	As in pay

The callback, when present, receives a POST with Content-Type: application/x-www-form-urlencoded carrying the signed xdr field — i.e. the wallet returns the signature to a service rather than submitting to the network directly [1].

Signed origin (request authentication)

The requester proves authorship as follows [1]:

1. Add an origin_domain parameter (the requester's FQDN).
2. Publish a URI_REQUEST_SIGNING_KEY in that domain's stellar.toml.
3. Build a payload of 35 zero bytes + the byte 4 + the ASCII string stellar.sep.7 - URI Scheme + the URI request bytes, sign it with the domain's secret key, base64-encode and URL-encode the signature, and append it as the final signature parameter.

The wallet then refuses to display origin_domain unless: the signature is present, the domain is a valid FQDN, https://<origin_domain>/.well-known/stellar.toml is reachable and contains URI_REQUEST_SIGNING_KEY, and the reconstructed payload verifies against that key. Wallets are also advised to pin the previously-seen key per domain and alert the user if it changes [1]. Any modification of the URI invalidates the signature [1].

Under no circumstance may a wallet sign without explicit user consent; the SEP requires the transaction details and msg to be shown before any signature [1, 2].

Use cases

• Merchant / point-of-sale QR: a merchant encodes a pay URI in a qr-code; the customer scans it with any SEP-7-aware wallet, which pre-fills destination/asset/amount [1, 2].
• Delegated / multisig signing: a coordinating service builds the transaction (tx) and routes it — optionally with pubkey and nested chain requests — to one or more signers, each of whom approves in their own wallet [1].
• Trusted website payment requests: origin_domain + signature let a wallet display "this request really came from example.com," mitigating spoofed payment requests [1].

Implementations

• stellar/stellar-protocol — the canonical specification repository (markdown), actively maintained by the Stellar Development Foundation [1, 3].
• stellarguard/stellar-uri — TypeScript/JavaScript library to parse, build, sign, and verify SEP-7 URIs in the browser or Node.js, including SEP-11 Txrep field replacement; small community project (~8 stars) [4, 5].
• Stellar's official wallet documentation publishes SEP-7 integration guidance for wallet builders [2].

Comparison

Versus a plain "Stellar address QR" (just an account ID), SEP-7 carries operation type, asset, amount, memo, and callback in a single scannable payload, removing manual entry by the payer [1]. Its standout property is the signed-origin scheme: unlike Bitcoin's BIP-21 or Cardano's cardano-cip-13, which carry no requester authentication, SEP-7 lets a wallet cryptographically attribute a request to a domain via stellar.toml [1]. The tx operation also goes beyond simple payment URIs — it can request signing of arbitrary transactions and even chain nested requests for multisig flows [1], a capability closer to TON's bin binary-payload deep links (ton-transfer-uri) or XRPL's payload request type (xrpl-request-uri) than to address-only schemes.

Status

Active. SEP-7 is a stable, widely-referenced ecosystem standard at version 2.1.0; the SDF's own wallet docs treat it as the recommended way to convey payment and signing requests on Stellar [1, 2].

Sources

1 SEP-0007: URI Scheme to facilitate delegated signing — Stellar Development Foundation, 2020 2 URI Scheme to facilitate delegated signing — Stellar Docs, 2026 3 Stellar Ecosystem Proposals (SEPs) — Stellar Docs, 2026 4 stellarguard/stellar-uri — GitHub, 2023 5 stellar-uri README — GitHub, 2023

Deployments

No country reports mention this standard by name.

Regions / aggregations not mapped to a single country

• Universal