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]
All wallets must adhere to the following criteria:
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.
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.
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.
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.
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.
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).
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.
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.
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 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.
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.
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, which outlines key derivation methods and mnemonic codes for use within the Stellar ecosystem.
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, 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).
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 supports QR codes for any (ideally all) of the following use cases:
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.
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.
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.
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.
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 maintains the ability to manage multiple Stellar accounts in one unified interface.
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.