Stellar Ecosystem Proposals (SEPs)

Each SEP is a distinct blueprint meant to help users build a product or service that interoperates with other products and services on the Stellar network. When you build on Stellar, you generally use the Stellar RPC API to interact with the network. However, anytime you want your product or service to interoperate with other products or services in the ecosystem, you must create additional infrastructure to handle those components of an interaction. SEPs define standards for building that infrastructure on top of the Stellar network. They are designed to help different entities, such as asset issuers, wallets, exchanges, and other service providers interoperate using a single common integration. Generally, they define two sides of an interaction — often a server-side and a client-side — and using them as a blueprint allows you to connect to multiple counterparties without starting from scratch every time. SEPs are publicly-created, open-source documents that live in the GitHub repository and have a lightweight approval process. New SEPs and upgrades are discussed constantly. We encourage participation in these discussions to help build new standards and make Stellar services more accessible.

​

Notable SEPs

There are many SEPs, and they cover a wide variety of standards for interoperation (see the full list of active SEPs below). Whatever you’re building, you may want to take a look at the complete list to see if there’s a standard for your use case. This section will cover a few notable SEPs that define the standards for some common Stellar use cases.

​

SEP-1 - Stellar Info File

Defines how to create and host a stellar.toml file: a common place where the Internet can find information about your Stellar integration. You can store a lot of information in your stellar.toml file including organization information, currency information, and contact information. TOML is a simple and commonly used configuration file format designed to be readable by both humans and machines. Using the set_options operation, you can link your Stellar account to the domain that hosts your stellar.toml, creating an on-chain connection between this information and that account. Used by anchors, issuers, and validators. Link to GitHub

​

SEP-5 - Key Derivation Methods for Stellar Accounts

Describes methods for key derivation for Stellar, improving key storage and moving keys between wallets and applications. Guidance in this SEP improves the Stellar ecosystem by:

• Making key derivation the same across wallets and applications
• Allowing users to hold keys in hardware wallets
• Allowing users to hold keys in cold storage more reliably (using mnemonic codes)
• Allowing users to generate multiple keys from a single seed (for example, first for storing funds and second as a signer for a shared account)

Used by wallets and other applications. Link to GitHub

​

SEP-6 - Deposit and Withdrawal API

Defines the standard way for anchors and wallets to interact on behalf of users. With this SEP’s guidance, wallets and other clients can interact with anchors directly without the user needing to leave the wallet to go to the anchor’s site. This SEP defines a standard protocol enabling the following features within a wallet or other Stellar client:

• Deposit external assets with an anchor
• Withdraw assets from an anchor
• Execute deposit/withdrawal between non-equivalent assets
• Communicate deposit & withdrawal fee structure for an anchor to the user
• Handle anchor KYC needs, including transmitting KYC information about the user to the anchor via SEP-12
• Check the status of ongoing deposits or withdrawals involving the user
• View history of deposits and withdrawals involving the user

SEP-24 is the alternative to SEP-6 which supports hosted deposits and withdrawals. Used by anchors, wallets, and other applications. Link to GitHub

​

SEP-7 - URI Scheme to Facilitate Delegated Signing

Defines the standard URI scheme that can be used to generate a URI that will serve as a request to sign a transaction. With this SEP’s guidance, non-wallet applications can have their their users sign a transaction without seeing the wallet user’s secret key in any form since the URI (request) will typically be signed by the user’s trusted wallet where the secret keys are stored. This SEP defines a standard protocol enabling the following features within a wallet or other Stellar client:

• Deeplinks payments (online)
• QR code payments (online and offline)
• Point of sale transactions (offline)
• Peer to peer payments (online and offline)

Used by wallets and other applications. Link to GitHub

​

SEP-10 - Stellar Authentication

Defines a standard way for clients (such as wallets or exchanges) to create authenticated web sessions for users holding a Stellar account. This SEP also supports authenticating users of shared or pooled Stellar accounts. Clients can use muxed accounts to distinguish users or sub-accounts of shared accounts. Proves that the user has a Stellar account and that they control the account with a single master key or sufficient signers needed. Used by wallets and exchanges. Link to GitHub

​

SEP-12 - KYC API

Allows for sharing of KYC data and defines a standard way for Stellar clients to upload KYC and other information to anchors and other services. This SEP was made with these goals in mind:

• Allow a customer to enter their KYC information into their wallet once and use it across many services without re-entering information manually
• Handle image and binary data
• Support the set of fields defined in SEP-9
• Support authentication via SEP-10
• Support the provision of data for SEP-6, SEP-24, SEP-31, and others
• Give customers control over their data by supporting complete data erasure

Used by anchors, wallets, and other applications. Link to GitHub

​

SEP-20 - Self-Verification of Validator Nodes

Defines how validators self-verify by setting the home domain of their Stellar account to their website, where they publish information on-chain about their node and organization in a stellar.toml file. This allows other participants to discover other nodes and add them to their quorum sets without needing a centralized database. Used by validators. Link to GitHub

​

SEP-24 - Hosted Deposit and Withdrawal

Defines the standard way for anchors and wallets to interact on behalf of users interactively. This means that the user’s application must open a webview hosted by a third-party anchor for the user to provide the information necessary to complete the transaction. Users use applications that implement SEP-24 to connect to businesses that will accept off-chain value (such as USD) in exchange for on-chain value (such as USDC) and vice-versa. SEP-6 is the alternative to SEP-24 that supports an API-style solution for the same use case. Used by anchors, wallets, and other applications. Link to GitHub

​

SEP-30 - Account Recovery: Multi-Party Recovery of Stellar Accounts

Defines the standard API that enables an individual (e.g., a user or wallet) to regain access to a Stellar account that it owns after the individual has lost its private key without providing any third-party control of the account. Using this protocol, the user or wallet will preregister the account and a phone number, email, or other form of authentication with one or more servers implementing the protocol and add those servers as signers of the account. If two or more servers are used with appropriate signer configuration no individual server will have control of the account, but collectively, they may help the individual recover access to the account. The protocol also enables individuals to pass control of a Stellar account to another individual. This SEP enables the following use cases for a user:

• Recover: Recover access to Stellar accounts for which they may have lost keys.
• Share: Gain access to Stellar accounts that another user intends to share with them.

Used by wallets and other applications. Link to GitHub

​

SEP-31 - Cross-Border Payment API

Defines the protocol for two financial accounts that exist outside the Stellar network (anchors) to interact with each other. Used by anchors. Link to GitHub

​

Complete list of active proposals