Wallet Listing Guidelines

To maintain a list of secure, high-quality wallets for interacting with the Stellar network on our website, the Stellar Development Foundation (SDF) has created the following list of guidelines to determine whether a wallet will be listed on Stellar’s wallets page.

A listing is not an endorsement or a partnership, but rather an acknowledgement that the wallet exists and has passed our criteria for being published on our site. We also reserve the right to reject any wallet that we don’t believe meets our quality bar to ensure that we highlight highly usable wallets for usage within the ecosystem.

Given the extent of review that is necessary, it is the developer’s responsibility to send over the checklist to the review team at Stellar with an explanation showing proof of how each guideline has been met. While we will conduct our own review, having the checklist filled out will greatly expedite the process in which we can add your wallet to the website. In addition, meeting optional functionality greatly increases the likelihood that a wallet will be considered high quality in order to be listed.

If you have any questions, you can reach out to [email protected]

1. Wallet meets strong security requirements (see complete list).
2. Wallet meets a high standard of quality in terms of user experience, as determined by SDF.
3. Wallet clearly states prior to user signup or install whether it is custodial or non-custodial, and satisfies its respective requirements (see complete list).
4. Wallet organization or developer leadership must be publicly available (ideally via organization or developer website).
5. Wallet developer must have no active or upcoming token (ICO) sales.
6. Wallet must not use Stellar, Lumens, or anything that would violate SDF’s brand policy in the application name.
7. Wallet must support Federation lookup (SEP-0002).
8. Wallet should guard against sending funds to exchanges without memos.
9. Wallet must indicate you are not an official wallet, i.e. one that is created, sponsored, endorsed, etc. by SDF.
10. Wallet must be maintained and kept up-to-date. Applications that no longer have developer support will be removed.
11. Wallet clearly communicates errors and provides a channel for support and feedback for users.
12. Wallet contains sufficient documentation and tutorials to help users utilize the wallet.

1. Wallet supports pathfinding payments.
2. Wallet supports SEP-0005.
3. Wallet supports SEP-0006.
4. Wallet supports SEP-0007.
5. Wallet supports Multi-Factor Authentication (MFA) via TOTP, FIDO2 (WebAuthn), FIDO U2F, or hardware wallet support.
6. Wallet contains support for QR codes.
7. Wallet provides a method for account recovery if it uses credentials that aren’t a user’s secret key, e.g. a passphrase for securing a user’s account.
8. Wallet clearly communicates the network reserve to users, including any XLM set aside for trustlines and open orders.
9. Wallet allows users to toggle viewing and hiding transaction memos.
10. Wallet presents the link to the home domain of the issuing account for any asset that is displayed by the wallet (SEP-0001).
11. Wallet presents information to the user based on the issuing account’s TOML file (SEP-0001).
12. Wallet supports multiple accounts.
13. Wallet allows users to close (merge) accounts.

Wallet meets strong security requirements.

All wallets must adhere to the following criteria:

• Independent security audit is available (especially for closed source wallets), or sufficient users and/or developer feedback can be found without any major problematic issues.
• The wallet must be publicly announced and released for at least three months.
• There should be no history of the wallet maintainers concealing or ignoring security issues in the past, and the maintainers must show care towards maintaining their user’s security.
• There should be no history of users being harmed by the wallet through malice or negligence.
• If the wallet is open source, the public code repository must be sent over for testing and review.
• The wallet must never store its keys locally (cache, cookies, disk, etc.) or on any server unencrypted. In addition, the website of the wallet must:
• Pass the Qualys SSL Labs SSL Test (A or A+).
• Must support HTTPS and 301 redirects for traffic over unencrypted HTTP.

Wallet meets a high standard of quality in terms of user experience, as determined by SDF.

Wallets should emphasize a great user experience for their respective users, whether the wallet’s user interface is via the command-line or a single page web application. SDF reserves the right to not list wallets that we believe increase confusion and difficulty for users to utilize the Stellar Network, especially for new users.

Wallet clearly states prior to user signup or install whether it is custodial or non-custodial, and satisfies its respective requirements.

A non-custodial wallet is a wallet that gives full control of a user’s keys to the user and does not store or transmit a user’s secret keys to any server (all signing is done locally).

A custodial wallet is defined as a wallet in which the user’s secret key (or a decryption key based on a passphrase) is stored on any third-party server, usually a server operated or managed by the wallet developers.

Wallets must explicitly state whether they are custodial or non-custodial, and detail what level of control users have of their keys. It must be displayed in both the Terms of Service as well as the website for the wallet.

Non Custodial Wallet Requirements

• Wallet users must be able to control their keys - they must have the ability to use their public and secret keys with other non-custodial wallets, and the ability to purge any (encrypted, of course) local storage of their key pairs.
• Wallet user keys cannot be stored on a third-party server.
• Wallet has backup functionality, e.g. via a recovery code, encrypted backup file, or other means.

Custodial Wallet Requirements

• Wallet clearly states its key storage mechanism prior to user signup or install.
• Wallet must refuse any weak passphrase.
• Wallet must lock out accounts due to multiple failed login attempts.
• Wallet must provide a strict account recovery process.

Wallet organization or developer leadership must be publicly available (ideally via organization or developer website).

Wallets must list publicly display their leadership - C-level officers (including CEO) and their respective equivalents in other organizations, or in the case of smaller projects, the primary developers to provide a stronger sense of accountability. SDF will generally not publish wallets that do not have a primary form of contact or only have anonymous contributors.

Wallet developer must have no active or upcoming token (ICO) sales.

Wallets cannot have any active or upcoming token sales, which includes any promotion on the wallet’s website or within the application. If any organization that develops a wallet is having an active or upcoming token sale, it must be completely separate and distinct from the wallet software, its signup process, or any correspondence (especially marketing) sent to wallet users.

Wallet must not use Stellar, Lumens, or anything that would violate SDF’s brand policy in the application name.

Please adhere to our brand policy. It’s important that users understand that your wallet is maintained and operated by you! Creating a unique application name will help differentiate your wallet from others, prevent confusion, and help you build a proper brand presence.

Wallet must support Federation lookup (SEP-0002).

One of the main goals of the Stellar network is to make payments as simple as email. Stellar’s federation protocol maps a federated Stellar address (such as username*example.com) to more information about a given user. It’s the way for Stellar applications to resolve ‘email-like’ addresses into Stellar accounts (public keys). These federated addresses (username*example.com) makes it much easier for users to share their payment details.

The wallet must allow payment operations to federation addresses via the Federation protocol (SEP-0002). This does not require that the wallet have its own federation server, but rather allows users to send to other Stellar federated addresses (such as username*example.com).

Wallet should guard against sending funds to exchanges without memos.

As the federation protocol continues to be adopted, it’s important to safeguard users against sending funds to exchanges that don’t utilize federation and instead use memos to determine user balances. Presenting a warning to users that don’t add memos when sending to a known exchange (or, in general) is critical for preventing users from losing funds today.

Wallet must indicate you are not an official wallet, i.e. one that is created, sponsored, endorsed, etc. by SDF.

Please clearly indicate you are not an official wallet, i.e. one that is created, sponsored, etc. by SDF on your website in a prominent location. Please adhere to our brand policy.

Wallet must be maintained and kept up-to-date. Applications that no longer have developer support will be removed.

The Stellar network is constantly evolving. With protocol updates come new features and more streamlined processes. It’s important that your wallet is maintained and kept up-to-date with the development of the network. Most importantly, an out of date wallet is a security risk, and can also cause a user to lose access to their account.

Wallet clearly communicates errors and provides a channel for support and feedback for users.

Wallet errors must be easily understood by users and should be easy to report to the wallet’s developers. The wallet should have its own channel for support (email, chat, phone, support portal), and should include at least one form of direct contact with a support team (email, chat, phone). The wallet’s support channel must be presented to the user in the case of any non-recoverable error.

We highly encourage wallet developers to present FAQ’s, documentation, and usage guides to users.

Most importantly, your wallet should not direct users to SDF for wallet support.

Wallet contains sufficient documentation and tutorials to help users utilize the wallet.

Documentation can be provided via user guides, FAQ’s, a knowledge base, in-app tutorial, and other information on how to use the wallet.

We wholeheartedly encourage and want to see wallets that support multiple languages, but at least one language should be support. Note that we have limited ability to review wallets in other languages if there are no resources in English.

Wallet supports pathfinding payments.

Wallets support utilizing path payments on the Stellar network, either through Horizon or one of the several implementations of pathfinding servers for Stellar.

Wallet supports SEP-0005.

Wallet supports SEP-0005, which outlines key derivation methods and mnemonic codes for use within the Stellar ecosystem.

Wallet supports SEP-0006.

Wallet supports SEP-0006, which outlines wallet and anchor interoperability through deposit & withdrawal, KYC, and other information through an API service.

Wallet supports SEP-0007.

Wallet supports SEP-0007, which outlines a URI scheme for delegated signing of transactions (such as when a transaction is created in one place to be passed off to another service for signing).

Wallet supports Multi-Factor Authentication (MFA) via TOTP, FIDO2 (WebAuthn), FIDO U2F, or hardware wallet support.

Wallets must support some form of Multi-Factor Authentication via TOTP, FIDO2 (WebAuthn), FIDO U2F, or a hardware wallet such as Ledger or Trezor. We do not accept SMS-only MFA and will review alternative MFA methods on a case-by-case basis, and update this list over time.

Wallet contains support for QR codes.

Wallet supports QR codes for any (ideally all) of the following use cases:

1. Converting a QR code to a payment address, such that when a user scans someone else’s QR code they don’t have to input any additional information about the recipient of a transaction.
2. Invoice QR Codes: The ability to send an invoice (request for payment) to another user via a QR code, and when a user scans it, it pre-populates an entire transaction ready for signature.
3. SEP-0007 QR Codes: QR codes that encode SEP-0007 URIs to be scanned by a user in order to sign a transaction.

Wallet provides a method for account recovery if it uses credentials that aren’t a user’s secret key, e.g. a passphrase for securing a user’s account.

Wallets must provide some means of account recovery whenever an account’s credentials are not a user’s secret key. For example, if a user logs into a wallet with a username/email and passphrase, a recovery method must be provided. This is also the case for non-custodial wallets that wish to abstract away secret keys behind a user passphrase.

Common implementations include a recovery phrase and reset links via email.

Wallet clearly communicates the network reserve to users, including any XLM set aside for trustlines and open orders.

The Stellar network reserves a small number of lumens from each account to ensure the network’s integrity. In an effort to educate users and help them understand how funds are being used, you must clearly articulate the current network reserve for a given account, and break it down into its individual components: the account’s open trustlines, the account’s open orders, the base network reserve, and any reserve necessary for the wallet.

Wallet allows users to toggle viewing and hiding transaction memos.

While memos can serve an important tool for applications or bookkeeping, many users will never need no see the memo itself. In addition, the memo field is occasionally subject to spam. Wallets must allow users to toggle whether memos are visible, which benefits users by removing spam (including potentially malicious links) or unwanted additional information while they are using the wallet.

Wallet presents the link to the home domain of the issuing account for any asset that is displayed by the wallet (SEP-0001).

For each asset a wallet displays, it must present a link to the home domain of the issuing account to the user, or otherwise state a clear and obvious warning regarding the lack of a home domain on-chain. This allows for much greater transparency around the origin of a token.

Wallet presents information to the user based on the issuing accounts TOML file (SEP-0001).

For each asset that a wallet displays that has a published home domain on-chain, the wallet must verify that the home domain has a published stellar.toml file that contains the asset in its list of [[CURRENCIES]], or otherwise state a clear and obvious warning to the user. This allows for much greater transparency around whether a token is supported by a given issuer or not.

Wallet supports multiple accounts.

Wallet maintains the ability to manage multiple Stellar accounts in one unified interface.

Wallet allows users to close (merge) accounts.

Just like any other service, users should have the ability to close an account. The Stellar Network allows the closure of Stellar accounts through an operation called Account Merge. For custodial wallets, the wallet should allow users to transfer their assets and close the account. For non-custodial wallets, the wallet should allow users to close an account through an Account Merge operation.