Skip to content
barcoder

Standards/stellar-sep-7

Stellar SEP-7

TypeQR Data Format
Completeness75%high

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 (Cardano URI), 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
source · content/standards/stellar-sep-7/index.md