# Stellar SEP-7
> Source: https://docs.barcoder.ai/docs/standards/stellar-sep-7
> research date 2026-06-04 · extracted at 2026-10-03
> Publisher: Barcoder — encyclopedia of QR, barcode and payment-code standards
Specifications:
- [SEP-0007: URI Scheme to facilitate delegated signing — stellar-protocol](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0007.md)
- [URI Scheme to facilitate delegated signing — Stellar Docs](https://developers.stellar.org/docs/build/apps/wallet/sep7)
## Overview
**SEP-0007** ("SEP-7") is a **Stellar Ecosystem Proposal** that defines a **URI scheme to facilitate delegated signing** on the [Stellar](https://stellar.org) network [1][1], [2][2]. It specifies a payload — typically embedded in a [QR Code](https://docs.barcoder.ai/docs/standards/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][1].
URIs take the form `web+stellar:?=&=` [1][1], [2][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][1].
Two operations are defined: **`pay`** (request a payment to a destination) and **`tx`** (request signing of a fully-formed transaction envelope) [1][1], [2][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][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][1]. SEPs are the Stellar ecosystem's standards-track documents (analogous to BIPs/EIPs), maintained in the `stellar/stellar-protocol` repository under `ecosystem/` [1][1], [3][3]. SEP-7 references **SEP-0011 (Txrep)** for its field-replacement syntax and **SEP-0001 (`stellar.toml`)** for publishing the request-signing key [1][1].
## Technical specification
### `pay` operation
Requests payment to a destination with an optional asset and amount [1][1], [2][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][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][1], [2][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][1].
### Signed origin (request authentication)
The requester proves authorship as follows [1][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:///.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][1]. Any modification of the URI invalidates the signature [1][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][1], [2][2].
## Use cases
- **Merchant / point-of-sale QR**: a merchant encodes a `pay` URI in a [QR Code](https://docs.barcoder.ai/docs/standards/qr-code); the customer scans it with any SEP-7-aware wallet, which pre-fills destination/asset/amount [1][1], [2][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][1].
- **Trusted website payment requests**: `origin_domain` + `signature` let a wallet display "this request really came from `example.com`," mitigating spoofed payment requests [1][1].
## Implementations
- **`stellar/stellar-protocol`** — the canonical specification repository (markdown), actively maintained by the Stellar Development Foundation [1][1], [3][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][4], [5][5].
- Stellar's official **wallet documentation** publishes SEP-7 integration guidance for wallet builders [2][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][1]. Its standout property is the **signed-origin** scheme: unlike Bitcoin's BIP-21 or Cardano's [Cardano CIP-13 (Cardano URI)](https://docs.barcoder.ai/docs/standards/cardano-cip-13), which carry no requester authentication, SEP-7 lets a wallet cryptographically attribute a request to a domain via `stellar.toml` [1][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][1], a capability closer to TON's `bin` binary-payload deep links ([TON Transfer URI](https://docs.barcoder.ai/docs/standards/ton-transfer-uri)) or XRPL's `payload` request type ([XRPL Request URI](https://docs.barcoder.ai/docs/standards/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][1], [2][2].
## Sources
[1]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0007.md
[2]: https://developers.stellar.org/docs/build/apps/wallet/sep7
[3]: https://developers.stellar.org/docs/learn/fundamentals/stellar-ecosystem-proposals
[4]: https://github.com/stellarguard/stellar-uri
[5]: https://github.com/stellarguard/stellar-uri/blob/master/README.md
[1] [SEP-0007: URI Scheme to facilitate delegated signing](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0007.md) — Stellar Development Foundation, 2020
[2] [URI Scheme to facilitate delegated signing](https://developers.stellar.org/docs/build/apps/wallet/sep7) — Stellar Docs, 2026
[3] [Stellar Ecosystem Proposals (SEPs)](https://developers.stellar.org/docs/learn/fundamentals/stellar-ecosystem-proposals) — Stellar Docs, 2026
[4] [stellarguard/stellar-uri](https://github.com/stellarguard/stellar-uri) — GitHub, 2023
[5] [stellar-uri README](https://github.com/stellarguard/stellar-uri/blob/master/README.md) — GitHub, 2023
## Deployments
_No country reports mention this standard by name._
## Regions / aggregations not mapped to a single country
- Universal