Building a Stellar application shouldn't require developers to assemble a dozen different pieces before they can get to the product itself.
Wallet connectivity is only the beginning.
A production-grade Stellar application needs to handle wallet integration, responsive wallet UX, authentication, session management, Soroban transactions, transaction simulation, error handling, localization, and increasingly, compliance and user onboarding.
That is the problem we're trying to solve with Stellar AppKit.
Stellar AppKit is an application SDK designed to provide a unified layer between your application, your users, wallets, and the Stellar network.
The easiest way to think about it is:
Wallet connectivity gets a user into your application. AppKit is focused on everything that happens around that connection.
What is Stellar AppKit?
Stellar AppKit started as a wallet connectivity library, but the project has evolved into something broader.
The goal is to provide developers with reusable infrastructure for the application layer of Stellar:
Your Application
│
▼
┌──────────────────────┐
│ Stellar AppKit │
├──────────────────────┤
│ Wallet Connectivity │
│ Authentication │
│ Session Management │
│ Transaction UX │
│ Soroban Infrastructure│
│ Risk Detection │
│ Localization │
│ Compliance │
└──────────┬───────────┘
│
▼
Stellar Ecosystem
Instead of every application independently implementing these primitives, AppKit aims to provide them through one consistent developer experience.
Wallet connectivity is only the starting point
There are already good wallet connectivity solutions in the Stellar ecosystem.
Stellar Wallets Kit, for example, solves an important problem: connecting applications to multiple Stellar wallets through a common interface.
We don't see that problem as the entire application stack.
A developer building a real application eventually has to answer questions like:
- How should the wallet selector behave on mobile?
- How do I support multiple frontend frameworks?
- How do I localize the wallet experience?
- How do I authenticate a user with their wallet?
- How do I maintain their session?
- How do I validate that authentication on the server?
- How do I simulate a Soroban transaction before signing?
- How do I show the user what they're actually signing?
- How do I detect potentially dangerous transactions?
- How do I onboard users who don't already have a wallet?
- How do I handle compliance requirements?
AppKit is intended to address that larger set of problems.
A better wallet UX
Wallet connectivity APIs are useful, but the user experience surrounding a wallet connection matters just as much.
A desktop application and a mobile application shouldn't necessarily present wallet selection in the same way.
AppKit supports different UI presentation patterns, including:
- Desktop modal
- Mobile bottom sheet
- Inline and UI-agnostic flows
This allows applications to use AppKit's ready-made experience or build their own interface around the underlying SDK.
The objective isn't to force a specific design.
It is to give developers a good default experience while keeping the underlying functionality flexible.
25 languages out of the box
Stellar is a global ecosystem, so localization shouldn't become another project developers have to maintain themselves.
AppKit currently supports 25 languages, including Chinese and other major languages.
That means wallet-related interfaces, authentication flows, and other AppKit components can be presented to users in their preferred language without every application having to implement the translation infrastructure independently.
Localization is treated as part of the application experience rather than an afterthought.
Multi-framework support
Another important design decision is keeping AppKit independent from a single frontend framework.
The core SDK is framework-agnostic, while UI integrations are available for:
- React
- Vue
- Svelte
We're also working toward support for:
- React Native
- LynxJS
- Flutter
The objective is to make AppKit useful across both web and mobile applications while maintaining the same underlying concepts and developer experience.
A developer shouldn't have to completely rethink wallet and authentication infrastructure just because their frontend stack changed.
Transaction UX: don't make users sign blind XDR
One of the areas we're particularly interested in is transaction understanding.
Traditionally, an application builds a transaction, produces XDR, and asks a wallet to sign it.
From the user's perspective, that can be extremely opaque.
The user may be asked to approve a transaction without having a clear understanding of:
- Which operations are being executed
- Which assets are moving
- How balances will change
- What fees are involved
- Which contracts are being called
- Whether there are potential risks
AppKit is designed to put an interpretation layer around transactions.
The vision is:
Transaction
│
▼
Decode
│
▼
Simulate
│
▼
Explain
│
▼
Assess Risk
│
▼
User Approval
This includes capabilities around transaction previews, operation decoding, simulation, balance and fee information, contract information, and risk detection.
The goal is simple:
Users should have a much better understanding of what they are signing.
Soroban application infrastructure
Soroban introduces another layer of complexity.
A typical transaction flow isn't simply:
Create → Sign → Submit
Applications often need to:
Build
↓
Simulate
↓
Prepare
↓
Sign
↓
Submit
↓
Track
AppKit provides abstractions around this lifecycle so developers can work with higher-level APIs instead of rebuilding the same workflow in every project.
We're also working on capabilities such as:
- Typed contract clients
- Transaction helpers
- RPC failover
- Simulation-aware execution
The goal is to make interacting with Soroban feel more like using an application SDK and less like manually orchestrating every transaction step.
Authentication shouldn't stop at "Connect Wallet"
A wallet connection does not necessarily mean the user is authenticated in your application.
Modern applications usually need a proper authentication lifecycle.
AppKit is building Stellar authentication and session management inspired by Sign In with Ethereum (SIWE).
The system is designed around concepts such as:
Connect Wallet
↓
Request Nonce
↓
Sign Authentication Message
↓
Server Validation
↓
Create Session
↓
Authenticated Application
This includes:
- Nonce-based authentication
- Signed authentication messages
- Session creation
- Session persistence
- Re-authentication
- Sign-out
- Server-side signature and session validation
The goal is to make a Stellar wallet usable as an application identity rather than treating wallet connection as the authentication mechanism itself.
Walletless onboarding
One of the bigger areas on our roadmap is walletless connectivity.
Crypto onboarding can be a significant barrier for users who have never interacted with a wallet before.
We're working toward allowing applications to onboard users through more familiar authentication methods.
Social login
Applications will be able to offer familiar social authentication flows so users can get started without first installing and configuring a traditional crypto wallet.
Passkeys
We're also working toward passkey-based authentication, allowing users to authenticate using device-native credentials and biometrics.
The broader goal is to make Stellar applications accessible to users who don't already identify themselves as "crypto users."
Instead of:
Install wallet
↓
Create account
↓
Find recovery phrase
↓
Connect wallet
↓
Start application
the experience can move closer to:
Authenticate
↓
Start using the application
while still allowing applications to interact with Stellar underneath.
Compliance and KYC
Another area we're exploring is making compliance infrastructure available directly at the application layer.
For many Stellar applications, particularly those involving regulated assets, real-world assets, financial services, or restricted jurisdictions, compliance can't simply be an external concern.
Developers may need to know whether a user:
- Has completed KYC
- Is eligible to use a particular application
- Is from an allowed jurisdiction
- Meets an age requirement
- Satisfies another compliance policy
Today, developers often have to assemble separate identity and compliance systems to handle these requirements.
We're working toward allowing developers to request and manage KYC directly through AppKit.
A zero-knowledge compliance layer
The longer-term vision is to combine compliance verification with zero-knowledge technology.
Instead of putting sensitive personal information on-chain, applications could verify specific properties about a user.
For example:
KYC completed → ✓
Allowed jurisdiction → ✓
Age requirement → ✓
Restricted status → ✗
without exposing the underlying personal information directly on-chain.
The objective is to make compliance:
Verifiable + Privacy-preserving + Reusable
This is still an area we're actively developing, but we believe it could become increasingly important as Stellar applications move into regulated and real-world use cases.
Why not just use a wallet SDK?
This is probably the most important distinction.
If your application only needs to connect to a Stellar wallet, a wallet-focused SDK may be exactly what you need.
AppKit is intended for applications that need more.
The difference can be summarized like this:
| Wallet Connectivity | Application Layer |
|---|---|
| Connect wallet | Connect wallet |
| Sign transaction | Sign transaction |
| Wallet selection | Wallet UX |
| Wallet abstraction | Authentication |
| Session management | |
| Server-side validation | |
| Transaction preview | |
| Simulation | |
| Risk detection | |
| Soroban lifecycle | |
| Localization | |
| Cross-framework UI | |
| Walletless onboarding | |
| Compliance infrastructure |
We don't think developers need yet another abstraction simply for the sake of having one.
The goal is to reduce the amount of application infrastructure they have to build repeatedly.
The bigger vision
The long-term vision for AppKit is a single application layer that helps developers move through the entire user and transaction lifecycle:
┌───────────────┐
│ User │
└───────┬───────┘
│
▼
┌──────────────────┐
│ Authentication │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Session │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Wallet / Identity│
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Transaction │
│ Preview / Risk │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Soroban │
│ Execution │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Stellar │
└──────────────────┘
And eventually, developers should be able to choose between traditional wallets, smart wallets, social authentication, passkeys, and compliant identity flows without having to completely rewrite their application.
What's next?
We're continuing to build AppKit around the needs of Stellar developers.
Some of the areas we're working on include:
Walletless authentication
- Social login
- Passkeys
Cross-platform
- React Native
- LynxJS
- Flutter
Compliance
- Integrated KYC flows
- Zero-knowledge-based compliance verification
Application infrastructure
- More transaction intelligence
- More Soroban abstractions
- More wallet integrations
- Improved developer tooling
The goal isn't to build the biggest SDK possible.
It's to make building a Stellar application significantly easier.
Conclusion
Stellar already has strong infrastructure for wallets, assets, payments, and smart contracts.
What we're building with Stellar AppKit is the layer around those primitives.
A developer shouldn't have to independently solve wallet UX, authentication, session management, transaction interpretation, Soroban execution, localization, and eventually compliance every time they start a new Stellar application.
The vision is straightforward:
Connect → Authenticate → Understand → Sign → Execute → Verify
That's what we're building with Stellar AppKit.
The project is open source, and we're actively looking for feedback from developers building on Stellar.
