DEV Community: Zak R.

Stellar AppKit: Building a Complete Application Layer for Stellar

Zak R. — Thu, 27 Aug 2026 08:47:28 +0000

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.

GitHub: https://github.com/SagantaHQ/stellar-appkit

Why I Stopped Using PM2 and Built My Own Bun Process Manager

Zak R. — Thu, 12 Feb 2026 15:11:08 +0000

I loved PM2. Then I switched to Bun.

Let me tell you a quick story. Six months ago, I migrated a handful of microservices from Node to Bun. The speed improvements were everything the benchmarks promised. Cold starts dropped dramatically. Memory usage shrank. I was thrilled.

Then I noticed something. My process manager, PM2, the tool I'd relied on for years, was now the slowest part of my stack. It was the thing consuming the most memory in some cases. The irony of running a Node-based supervisor over hyper-optimized Bun processes started to eat at me.

So I did what any reasonable developer does. I spent my weekends building a replacement.

The Breaking Point

The final straw wasn't one big thing. It was a cascade of small frustrations. PM2 would occasionally misreport memory usage for Bun processes. The TypeScript integration required extra flags and workarounds.

I had to maintain a separate ecosystem.json that felt increasingly disconnected from the rest of my Bun-native tooling. Every time I ran pm2 start, there was a visible delay as the Node-based daemon spun up, only to then launch a Bun process.

I started keeping a list of these friction points. After a few weeks, the list was long enough to justify a project.

What I Built

ProcBoss (pboss) is a process manager that does one thing: manage long-running Bun processes without any Node dependency.

No daemon running on a separate runtime. No compatibility layers. Just Bun managing Bun.

The CLI is deliberately familiar:

bun i -g pboss pboss start server.ts --name api pboss restart api pboss logs api --lines 100 pboss list

Under the hood, everything uses Bun's native APIs. Subprocess spawning uses Bun.spawn. File operations use Bun.write and Bun.file.

The internal state management uses Bun's built-in SQLite. No fs polyfills. No child_process from Node. Pure Bun.

The Results

After migrating my services from PM2 to ProcBoss (pboss), here's what I noticed.
The process manager itself starts almost instantly.

There's no daemon boot delay. The memory overhead of the manager dropped significantly because it's not running a full Node runtime alongside Bun.

TypeScript files just work — no flags, no config, no transpilation. And the whole thing feels coherent in a way that's hard to describe. My entire stack is one runtime now, top to bottom.

Should You Switch?

If you're running Node services, PM2 is still excellent. Seriously. It's mature, battle-tested, and feature-rich.

But if you've committed to Bun, consider whether your toolchain has actually caught up with that decision. Your runtime is Bun. Your package manager is Bun. Your test runner is Bun. Why is your process manager still Node?

That's the question that led me to build ProcBoss (pboss). Maybe it's the question you've been ignoring too.

Links
Repository: https://github.com/procboss/pboss

Package: https://www.npmjs.com/package/pboss

Deploying Solana Anchor Programs Easily with Rocket Anchor

Zak R. — Mon, 10 Nov 2025 23:50:06 +0000

If you're a developer working with Anchor on Solana, you know the drill. You build your powerful program, and then... you're stuck writing a tangled mess of ad-hoc scripts for deployment, upgrades, and account initialization. It's time-consuming, error-prone, and just plain frustrating.

What if you could have a smooth, repeatable, Hardhat-style workflow?

Meet Rocket Anchor, a new open-source tool designed to save you from deployment headaches and streamline your entire process. This guide will walk you through exactly what it is and how to get started.

What is Rocket Anchor?

Rocket Anchor is a CLI and programmatic tool that brings the developer-friendly experience of tools like Hardhat to the Anchor ecosystem.

Its main goal is to solve the "last mile" problem of Anchor development:

It replaces manual scripts with a clean, config-based CLI workflow.
It introduces "seeding," a powerful concept for initializing accounts, PDAs, and program state right after deployment.
It's built for teams, making it easy to manage deployments across different networks (devnet, mainnet) without changing your code.

Key Features

Hardhat-Inspired CLI: Get a familiar workflow with commands like init, deploy, and seed.
Powerful Seeding: Run scripts after deployment to initialize program state, create PDAs, or set up initial data. This is a massive time-saver.
Network Management: Easily configure different networks (like devnet, testnet, mainnet, custom-network) in a single config file, complete with RPC endpoints and keypair paths.
Programmatic API: Need to integrate Rocket Anchor into your existing TypeScript toolchain? You can import and use it directly.

Installation

You can install Rocket Anchor globally to use it as a CLI tool across all your projects, or locally as a devDependency in a specific project.

Global Install:

npm install -g rocket-anchor

Local Install:

npm install --save-dev rocket-anchor

Getting Started: Your First Deployment

Let's walk through the entire workflow from zero to a seeded deployment.

Step 1: Initialize Rocket Anchor

In the root of your Anchor project, run the init command:

npx ra init

This will create a new file named ra.config.ts in your project's root. This is where you'll define all your networks and deployment configurations.

Step 2: Configure Your Networks

Open the newly created ra.config.ts. This is where you'll tell Rocket Anchor how to connect to different Solana clusters.

A typical configuration might look something like this:

// ra.config.ts
import { RocketAnchorConfig } from 'rocket-anchor';

const config: RocketAnchorConfig = {
  networks: {
    // Local validator
    localnet: {
      url: "[http://127.0.0.1:8899](http://127.0.0.1:8899)",
      keypair: "/path/to/your/localnet/keypair.json",
    },
    // Devnet
    devnet: {
      url: "[https://api.devnet.solana.com](https://api.devnet.solana.com)",
      keypair: "/path/to/your/devnet/keypair.json",
    },
    // Mainnet
    mainnet: {
      url: "[https://api.mainnet-beta.solana.com](https://api.mainnet-beta.solana.com)",
      keypair: "/path/to/your/mainnet/keypair.json",
    }
  },
};

export default config;

Step 3: (Optional but Recommended) Create Seed Scripts

This is where the magic happens. "Seeding" is the process of initializing your program's state right after deployment.

Create a seeds/ directory and an index.ts file inside it (seeds/index.ts). Here, you'll define a SeedConfig array.

// seeds/index.ts

import { SeedConfig } from 'rocket-anchor';

export const seeds: SeedConfig[] = [
  {
    program: 'counter', // a name for your program
    initialize: {
      function: 'initialize',
      accounts: {
        counter: 'pda:counter',
        authority: 'signer',
        systemProgram: 'systemProgram',
      },
      args: [0], // initial_count
    },
    seeds: [
      {
        function: 'increment',
        accounts: {
          counter: 'pda:counter',
          authority: 'signer',
        },
        args: [],
        repeat: 5, // Run 5 times
      },
    ],
  },
];

export default seeds;

Step 4: Deploy and Seed!

You're all set. Now, to deploy your program to devnet and run the seed scripts immediately after, you just run one command:

npx ra deploy --network devnet --seed

Rocket Anchor will handle:

Connecting to the correct network (devnet).
Using the correct keypair.
Deploying your Anchor program.
Once deployed, it will run the seed scripts you defined for that program.

You're live! No more manual solana program deploy commands or separate initialize.ts scripts to run.

Conclusion

Rocket Anchor fills a much-needed gap in the Solana development workflow. By adopting a config-based and scriptable approach to deployments and seeding, it saves time, reduces errors, and lets you focus on what matters: building your program's logic.

Always remember to test thoroughly on devnet before deploying to mainnet. Happy building!

Introducing Truffle Solidity Data Seeder

Zak R. — Tue, 27 Apr 2021 02:17:12 +0000

The Truffle framework is an awesome toolkit for every solidity and dapp developer, we at LibertyPie make advanced use of the truffle framework.

During LibertyPie's P2P protocol development, we needed a simple way to seed initial data to different contracts similar to database seeding.

Truffle has great migration support but no seeding of data out of the box.

So we decided to build a simple CLI tool as an npm package for seeding initial data out of the box with 0 configurations.

Introducing Liberty Pie's Truffle Seeder, your easy way to seed initial data to any smart contract. Kindly help us improve it by giving us your feedback

Project: https://github.com/LibertyPie/truffle-seeder

Introducing LibertyPie’s Wallet Provider

Zak R. — Thu, 07 Jan 2021 23:58:17 +0000

As the team builds the protocol’s user interface, it is very important to research deeply into which external libraries to include. The user interface must have a rich user experience & also very light weighted.

Every DApp must find a way to connect to users’ wallet without compromising privacy and security. Fortunately, we found many matured and well-developed libraries such as web3modal (previously web3connect), web3-wallets-kit (by Akropolis), bnc-onboard (by BlockNative) & many more.

After a careful analysis of these existing solutions, we found reasons which discouraged us from using them. A major reason was the bloat in library size, other reasons included an incomplete library or having to pay for usage in the case of BloackNative bnc-onboard.

Our final resort was to build a library exactly how we wanted it, thankfully, the initial version of LibertyPie Wallet Provider is successfully published on npm (https://www.npmjs.com/package/@libertypie/wallet-provider).
LibertyPie Wallet Provider was built to provide extra advantages over other libraries, a detailed comparison has been given below.

Size (according to Bundlephobia.com)

LibertyPie Wallet Provider — 6.9kb minified +gzipped
Web3Modal — 195kb minified + gzipped
bnc-onboard — 65.1kb minified + gzipped
web3-wallets-kit — 784.4kb minified + gzipped

Best: LibertyPie Wallet Provider
Worst: web3-wallets-kit

Runtime Dependencies

LibertyPie Wallet Provider— 0
Web3Modal — 6
bnc-onboard — 20
web3-wallets-kit — 9

Best: LibertyPie Wallet Provider
Worst: bnc-onboard

Supported Wallets Providers

LibertyPie Wallet Provider — 9
Web3Modal — 11
bnc-onboard — 6
web3-wallets-kit — N/A

As seen from the data above, LibertyPie Wallet Provider has many merits compared to the other libraries.
NPM: https://www.npmjs.com/package/@libertypie/wallet-provider
Github Repo: https://github.com/LibertyPie/Wallet-Provider