Wallet Listing Guidelines

Below you’ll find the guidelines for listing your application.

Introduction

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.

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.

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

Required Wallet Listing Checklist

  1. Wallet meets strong security requirements (see complete list)
  2. Wallet clearly states prior to user signup or install whether it is custodial or non-custodial, and satisfies its respective requirements (see complete list).
  3. Wallet must support every Stellar asset, or only lumens (XLM).
  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 supports Multi-Factor Authentication (MFA) via TOTP, FIDO2 (WebAuthn), FIDO U2F, or hardware wallet support.
  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 errors and provides a channel for support and feedback for users.
  9. Wallet clearly communicates the network reserve to users, including any XLM set aside for trustlines and open orders.
  10. Wallet allows users to close (merge) accounts.
  11. Wallet allows users to toggle viewing and hiding transaction memos.
  12. Wallet must present the link to the home domain of the issuing account for any asset that is displayed by the wallet (SEP-0001).
  13. Wallet must verify and present information to the user based on the issuing accounts TOML file (SEP-0001).
  14. Wallet must support Federation lookup (SEP-0002).
  15. Wallet must indicate you are not an official wallet, i.e. one that is created, sponsored, endorsed, etc. by SDF.
  16. Wallet must not use Stellar, Lumens, or anything that would violate SDF’s brand policy in the application name.
  17. Wallet must be maintained and kept up-to-date. Applications that no longer have developer support will be removed.
  18. Wallet has sufficient documentation provided in English.

Optional Checklist

  1. Wallet supports hardware wallets such as Ledger and Trezor.
  2. Wallet supports multiple languages in addition to English.
  3. Wallet supports SEP-0005, SEP-0006, and SEP-0007.
  4. Wallet supports pathfinding payments.

Complete Requirements

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:

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.
  • Wallet is open source.

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 must support every Stellar asset, or only lumens (XLM).

Wallets must either strictly service the transactions of lumens (XLM) or allow for transactions of every asset on the Stellar network. Wallets should not impose any bias towards limiting assets available on the wallet, as this removes control from the user to manage their account.

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 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 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 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 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 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.

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 must present 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 must verify and present 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 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 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 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 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 has sufficient documentation provided in English.

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 we use English as our baseline given our limited ability to review wallets in other languages.

Ready to submit your application?

Apply now