Wallet as a Service: Embedded Lightning Wallets for Platforms, Agents, and Developers

"Wallet as a Service" has become a category in fintech. Fireblocks, Circle, Coinbase, Privy, Dynamic — dozens of companies offer APIs that let you embed crypto wallets into your application. Stripe acquired Privy in 2025. Fireblocks acquired Dynamic the same year. Real money is flowing into this space.

Almost all of it is flowing toward EVM chains. Ethereum, Polygon, Base, Solana — the WaaS landscape is built around token wallets, MPC key management, social login, and gas fee abstraction. If you need a user to hold USDC in your app and sign transactions with their email address, you have fifteen vendors to choose from.

If you need a wallet that software controls — an AI agent, a platform backend, an automated service — and you want it to settle payments in milliseconds for fractions of a cent, the options thin out fast. The Bitcoin Lightning Network is the obvious payment rail for this, but Lightning providers have generally called themselves "payment APIs" rather than wallet infrastructure. They ceded the WaaS term to the EVM side.

That's a gap worth filling.

What WaaS actually means

WaaS is a simple idea under a lot of marketing: your code creates wallets, your code moves money between them. You don't build the key management, the transaction signing, or the settlement infrastructure. You call an API.

The wallet is the primitive. Not the payment, not the invoice, not the checkout — the wallet. Each entity in your system that needs to hold, send, or receive money gets one. Users, merchants, agents, services, escrow accounts — they all become wallets with balances and addresses.

This is different from a payment processor like Stripe or OpenNode, where you create charges against a single merchant account. With WaaS, every participant in your system has their own account. The platform orchestrates transfers between them.

The EVM approach

The dominant WaaS architecture today looks like this:

MPC key management. Instead of a single private key, the key is split into shares distributed across multiple parties (the user's device, the provider's servers, a backup). No single point of failure. Mathematically sound. Also complex — signing a transaction requires coordinating between parties, which adds latency.

Social login. Users authenticate with email, Google, Apple, passkeys. The wallet is created behind the scenes. They never see a seed phrase. Good UX for consumers. Irrelevant for server-side code.

Gas fee abstraction. Every EVM transaction costs gas — a fee paid in the chain's native token. WaaS providers either sponsor gas (absorb the cost) or use account abstraction (ERC-4337) to let users pay gas in stablecoins. Elegant engineering to solve a problem Lightning doesn't have.

Chain selection. Your wallet exists on a specific chain — Ethereum mainnet, Base, Polygon, Arbitrum. Bridging between chains is a separate problem. Some providers handle it; most don't.

The result: enterprise-grade infrastructure for apps where humans hold tokens on EVM chains. Fireblocks charges enterprise pricing (call sales). Circle requires business verification. Magic starts at $499/month. Privy is free to start, pay-as-you-go past 10,000 monthly active users.

What falls through the cracks

That architecture assumes a human user with an identity. An email address, a social login, a face. The wallet belongs to a person.

Consider what happens when it doesn't. A marketplace where every seller needs an instant wallet — not a user with an email, but a row in a database that needs to hold money. Creating a Fireblocks wallet for each of 10,000 sellers requires business-tier pricing and integration work measured in weeks.

Or an AI agent that pays for APIs, earns from services, transfers value to other agents. It can't complete OAuth. The entire front-end UX layer that EVM WaaS providers spent years building is wasted on it — what it needs is an API key and a balance.

Or backend wallets that aren't attached to any user at all: a treasury that collects platform revenue, an escrow that holds funds until a condition is met, a payout pool that distributes earnings on a schedule.

The EVM WaaS market built excellent consumer wallet infrastructure. It didn't build much for software.

Lightning as the payment rail

Lightning settles payments in milliseconds. Fees are fractions of a cent. There's no gas, no chain selection, no block confirmations. A wallet on Lightning can send and receive money as fast as your code can make HTTP calls.

For the use cases above — platforms, agents, services — these properties matter more than token variety or DeFi composability. You don't need ERC-20 support to give an AI agent a spending budget. You don't need NFT minting to run a marketplace payout system. You need fast, cheap money movement between isolated balances.

The tradeoff is real: Lightning is Bitcoin-only. No stablecoins (natively), no tokens, no smart contracts in the Ethereum sense. If your application requires dollar-denominated balances or ERC-20 token custody, EVM WaaS is the right tool. If it needs fast, programmable, low-cost payments between wallets your code controls — Lightning fits better than most people realize.

What Lightning-native WaaS looks like

Creating a wallet on ln.bot is a single API call. No authentication required — the call itself returns the API keys for the new wallet.

from lnbot import LnBot

ln = LnBot()  # no API key needed for wallet creation

wallet = ln.wallets.create(name="seller-wallet")
# wallet.wallet_id     → "wal_8x2k..."
# wallet.primary_key   → "key_m4n7..."
# wallet.address       → "r3k9x2@ln.bot"  (Lightning address, auto-assigned)
# wallet.recovery_passphrase → "twelve words for recovery"

One call and the wallet is live — balance at zero, Lightning address ready to receive from anywhere in the world, API keys scoped to this wallet only.

The TypeScript equivalent:

import { LnBot } from "@lnbot/sdk";

const ln = new LnBot();

const wallet = await ln.wallets.create({ name: "seller-wallet" });
// wallet.primaryKey → "key_m4n7..."
// wallet.address    → "r3k9x2@ln.bot"

From here, the wallet operates independently. Give the API key to whatever code needs to use it:

# Each wallet uses its own API key
seller = LnBot(api_key=wallet.primary_key)

# Check balance
info = seller.wallets.current()
print(f"Available: {info.available} sats")

# Create an invoice to receive payment
invoice = seller.invoices.create(amount=5000, memo="Order #1234")

# Send payment
seller.payments.create(target="buyer@ln.bot", amount=200)

The wallet is a REST resource that holds sats and moves them over Lightning. The MPC ceremony, the gas funding, the chain selection — none of it applies.

Multi-tenant platforms

This is where the single-API-call wallet creation actually matters. A marketplace that onboards 10,000 sellers doesn't need 10,000 Fireblocks integrations. It needs a loop:

from lnbot import LnBot

platform = LnBot()  # platform-level client, no auth for creation

def onboard_seller(seller_id: str):
    wallet = platform.wallets.create(name=f"seller-{seller_id}")
    # Store wallet.primary_key in your database, scoped to this seller
    # wallet.address is their Lightning address — they can receive payments immediately
    return wallet

# Each seller's operations are isolated
seller_client = LnBot(api_key=stored_primary_key)
balance = seller_client.wallets.current()

Each wallet is fully isolated. Seller A can't see Seller B's balance. The platform holds the API keys and orchestrates transfers — collecting fees, distributing payouts, holding escrow. The sellers (or the sellers' agents, or the sellers' automated systems) operate their wallets through their own keys.

Compare this to the EVM approach: provision an MPC wallet, manage key shares, fund it with gas tokens, handle chain-specific transaction encoding, wait for block confirmations. For a payment platform, that's overhead without upside.

Wallets for agents

Give an agent an API key and it can receive sats to its Lightning address, send payments to any other address or invoice, and — via L402 — pay for APIs automatically when it encounters a 402 response. The wallet turns an agent from something that asks for permission into something that handles the payment and moves on.

The MCP server exposes all of this as tools that any MCP-compatible agent discovers on its own. The agent doesn't need to know it's using Bitcoin. It found a tool called send_payment, passed the parameters, and it worked.

{
  "mcpServers": {
    "lnbot": {
      "url": "https://api.ln.bot/mcp",
      "headers": { "Authorization": "Bearer key_..." }
    }
  }
}

For agents built with SDK integration instead of MCP, the agent payments guide covers budget controls (maxPrice, budgetSats, budgetPeriod) that prevent the agent from draining the wallet. You set the guardrails; the agent operates within them.

The WaaS landscape, summarized

Neither side is wrong — they're built for different systems. If your users hold tokens and trade NFTs, the EVM stack earns its complexity. If your wallets are controlled by code and you just need money to move fast and cheap, most of that complexity is dead weight.

Getting started

pip install lnbot

from lnbot import LnBot

ln = LnBot()
wallet = ln.wallets.create(name="my-first-wallet")
print(f"Address: {wallet.address}")
print(f"API key: {wallet.primary_key}")

Or in TypeScript: npm install @lnbot/sdk. Or Go, Rust, C#.

Full API reference in the docs. Multi-tenant wallet architecture, agent integration, and L402 paywalls are all covered in the guides.