
Interoperability between payment applications such as wallets and on/off ramps such as Stellar anchors has always been one of the most important pillars for Stellar. That's why the Stellar Development Foundation (SDF) started defining standards for wallets and anchors very early on to facilitate their interoperability and to maximize the adoption.
The basic consideration here is that, from the wallet developer's point of view, it should make no difference whether they integrate with one anchor or with several different ones. The power of this interoperability standard is that you code once and ideally with very little modifications you can support multiple companies and you can provide a very competitive service in terms of your wallet offering.
However, because these standards were defined very early on to maximize adoption, with very little information about the most important user cases, the consequence was that they had to be extended again and again over the last 10 years to reflect the wallet and anchor builder’s needs. But evolving the standard is not an easy thing, you don’t want to break anyone who is already compatible, so you need to create this backwards compatible evolution system that ends up becoming almost like a patchwork where you either grow by having a fixed set of endpoints with a lot of optional parameters or you have a bunch of endpoints that do slightly different things. It is probably impossible to get as close to a good API as if you had defined that from the go considering all the use cases and accommodated all of them. As a result, these standards have become very complex, extensive, and interconnected over time. See for example SEP-06 or SEP-24.
The standard API for interoperability between wallets and anchors was defined by SDF via so-called Stellar Ecosystem Proposals (SEPs). And the original recommendation for developers to become interoperable was to read the SEPs and implement them. However, since these are very complex, extensive and cover many edge cases, this led to many different interpretations during implementation.
That's why SDF came up with the idea of implementing so-called Wallet SDKs about two years ago. These are software libraries that implement the needed functionality and that developers can integrate into their program, so as not to keep reinventing the wheel over and over again.
The integration of a wallet SDK makes it very easy for the developer of a client application to become interoperable. They do not have to develop the communication with the anchor themselves, but only use the SDK. Furthermore, this helps to remain interoperable, because every time the standard evolves, a new version of the SDK is also released, and the developer only must update to use the new version of the library. It is a common, natural process for software developers. And, because the functionality is already implemented, developers can become interoperable much faster and at a much lower cost than if they were to implement the functionality from scratch themselves. This means that developers have more time to focus on implementing their business logic instead of constantly reinventing the wheel by having to implement Stellar details.
Wallet SDKs are currently offered for three different programming languages. The Stellar Development Foundation created and maintained the TypeScript and the Kotlin Wallet SDKs. And the Flutter (dart) Wallet SDK was developed and is maintained by me (Soneso). You can find their documentation on the official Stellar docs website under: Build a Wallet with the Wallet SDK.
All three SDKs offer the same functionality and the same interfaces for integration. These were defined by SDF when the TypeScript and Kotlin SDKs were implemented.
The new Swift Wallet SDK will implement all the current features of the other SDKs from the Wallet SDK family (Stellar Integration, SEP-01, SEP-10, SEP-09, SEP-12, SEP-24, SEP-06, SEP-38, SEP-30, SEP-07). As soon as new features are defined and implemented by SDF, the Swift Wallet SDK will grow with them. Like the other Wallet SDKs, the Swift Wallet SDK will be build upon the corresponding Horizon SDK, the Horizon iOS Stellar SDK, of which I am the main developer and maintainer.
If you are interested in learning more about the importance and usability of the Wallet SDKs, please check out this Meridian presentation by Alex Cordeiro (Senior Director, Engineering, SDF).
Maybe in the future, but not in this submission
$76.8K
The SDK makes it easy for developers of Stellar projects to create highly usable products.
The SDK will be listed on the official Stellar Wallet SDK Page and on the Stellar Wallet SDK docs page. Furthermore, a new section will be created for the SDK in the official Stellar Discord Channel sdk-hub, where I will be available to developers for their questions and help them with the integration.
Because the Swift Wallet SDK is a new project, I can only provide evidence of prior traction or validation via the Horizon iOS Stellar SDK, on which the Swift Wallet SDK will be build upon. The open-source Horizon iOS Stellar SDK is used by many projects including the Lobstr Wallet and has more than 100 stars on GitHub. It has also won the Stellar Build Challenge #6. You can find it here on GitHub: Horizon iOS Stellar SDK
Brief description: Implementation of the predefined features and API for communication with the Stellar Network. Most of them are described here: https://developers.stellar.org/docs/build/apps/wallet/stellar.
How to measure completion: The following features will be available: Create Account, Modify Account, Modify Assets (Trustlines), Swap Assets, Transfer (Payments), Path Pay, Manage Sell and Buy Offers, Account Merge, Fund Testnet Account, Building Advanced Transactions, Sponsoring Transactions, Fee Bump Transactions, Accessing Horizon SDK, Submit Transaction, Using XDR to Send Transaction Data. Access to these features is made possible via an API that is predefined for all Wallet SDKs. Test cases and documentation will be available.
Estimated date of completion: 20. Nov 2024
Budget: 12.800
Brief description: Wallets connect to anchors using a standard way of authentication via the Stellar network defined by the SEP-10 standard. This deliverable will contain all the components required for SEP-10 Authentication with Anchors. See also the official Wallet SDK docs here: https://developers.stellar.org/docs/build/apps/wallet/sep10.
How to measure completion: The following features will be available: Info Loader for SEP-01 (Stellar Toml) and the SEP-10 authentication process will be covered including Default Signer, Client Domain Signer, Validations, JWT tokens handling, preparation of Auth Tokens to be used for the successive SEP's to be covered. Access to these features is made possible via an API that is predefined for all Wallet SDKs. Test cases and documentation will be available.
Estimated date of completion: 10. Dec 2024
Budget: 8.400
Brief description: The SEP-24 standard defines the standard way for anchors and wallets to interact on behalf of users. Wallets use this standard to facilitate exchanges between on-chain assets (such as stablecoins) and off-chain assets (such as fiat, or other network assets such as BTC). This deliverable will cover the SEP-24 flow. See Wallet SDK docs: https://developers.stellar.org/docs/build/apps/wallet/sep24.
How to measure completion: The following features will be available: Withdrawal, Deposit, Fetching Single Transactions, Transaction History, Transactions Watcher, SEP-09 KYC fields. Access to these features is made possible via an API that is predefined for all Wallet SDKs. Test cases and documentation will be available.
Estimated date of completion: 5. Jan 2025
Budget: 10.600
Brief description: The SEP-38 standard defines a way for anchors to provide quotes for the exchange of an off-chain asset and a different on-chain asset, and vice versa. This deliverable will cover the SEP-38 flow.
How to measure completion: The following features will be available: Info, Get Prices, Get Price, Post Quote, Get Quote, Asset Identification Format. See docs: https://developers.stellar.org/docs/build/apps/wallet/sep38. Access to these features is made possible via an API that is predefined for all Wallet SDKs. Test cases and documentation will be available.
Estimated date of completion: 25. Jan 2025
Budget: 8.800
Brief description: SEP-12 defines a standard way for stellar clients to upload KYC (or other) information to anchors and other services. Our SEP-06 implementation will use this protocol, but it can serve as a stand-alone service as well. This deliverable will cover the SEP-12 flow.
How to measure completion: The following features will be available: Add customer, Get Customer, Update Customer, Delete Customer, Verify Provided fields, Upload binary data. See docs: https://developers.stellar.org/docs/build/apps/wallet/sep6#providing-kyc-info. Access to these features is made possible via an API that is predefined for all Wallet SDKs. Test cases and documentation will be available.
Estimated date of completion: 20. Feb 2025
Budget: 8.000
Brief description: The SEP-06 standard defines a way for anchors and wallets to interact on behalf of users. Wallets use this standard to facilitate exchanges between on-chain assets (such as stablecoins) and off-chain assets (such as fiat, or other network assets such as BTC). See Wallet SDK docs here: https://developers.stellar.org/docs/build/apps/wallet/sep6.
How to measure completion: The following features will be available: Get Anchor Info, Deposit, Deposit-Exchange, Providing KYC Info, Withdrawal, Withdrawal-Exchange, Get Exchange Info, Fetching Transactions, Trecking Transactions. Access to these features is made possible via an API that is predefined for all Wallet SDKs. Test cases and documentation will be available.
Estimated date of completion: 15. March 2025
Budget: 10.200
Brief description: The SEP-30 standard defines the standard way for an individual (e.g., a user or wallet) to regain access to their Stellar account after losing its private key without providing any third party control of the account. During this flow the wallet communicates with one or more recovery signer servers to register the wallet for a later recovery if it's needed. See Wallet SDK docs here: https://developers.stellar.org/docs/build/apps/wallet/sep30.
How to measure completion: The following features will be available: Create Recoverable Account, Get Account Info, Recover Wallet. Access to these features is made possible via an API that is predefined for all Wallet SDKs. Test cases and documentation will be available.
Estimated date of completion: 10. April 2025
Budget: 8.400
Brief description: The SEP-07 standard defines a way for a non-wallet application to construct a URI scheme that represents a specific transaction for an account to sign. The SDK will provide the functionality to easily parse, construct and sign SEP-07 Stellar URIs. See Wallet SDK docs here: https://developers.stellar.org/docs/build/apps/wallet/sep7.
How to measure completion: The following features will be available: construct, parse and sign Tx and Pay URIs, parse and construct replacement parameter. Access to these features is made possible via an API that is predefined for all Wallet SDKs. Test cases and documentation will be available.
Estimated date of completion: 30. April 2025
Budget: 7.600
Brief description: I will test all Stellar Network related Features on MainNet, publish a release, prepare the docs and create a pull request to the Stellar Docs repo, so that the new Swift Wallet SDK can be added to list of Wallet SDKs.
How to measure completion: all Stellar Network related features work perfectly on mainnet, a release is published and the pull request is added.
Estimated date of completion: 9. May 2025
Budget 2.000
I have been a Stellar developer since 2017 and I am the main developer and maintainer of the: Stellar iOS SDK, Stellar Flutter SDK, Stellar Flutter Wallet SDK, Stellar PHP SDK and the AssemblyScript Soroban SDK.

