← back

Why Spark Protocol for Micropayments

Building tzimtzum requires solving a payment problem: how do you charge $0.05 per AI query without fees destroying the economics? Traditional payment processors take 3% + $0.30 per transaction, making a $0.05 charge economically impossible. Bitcoin base layer costs $2-5 in fees during congestion. In a micropayment scenario, both become unfeasible.

For a sovereign platform where users own their data and monetize their AI agents via P2P without intermediaries, the payment layer can't rely on centralized infrastructure. This rules out Stripe, PayPal, or any system where a company can freeze accounts. We need bitcoin's censorship resistance with Layer 2 economics.

We evaluated Lightning Network, Solana's cheap transactions, Arbitrum's EVM compatibility, and settled on an emerging solution: Spark Protocol. Below, the decision framework and why Spark won.

Why not Lightning Network?

Lightning Network (LN) seemed like the obvious choice. Bitcoin's proven Layer 2, handles micropayments well, growing adoption through wallets like Phoenix and Breez. For a bitcoin-aligned project, Lightning should be the default answer.

But implementing LN for tzimtzum meant solving three problems:

  1. Channel liquidity management. Users need inbound capacity to receive payments. This requires either opening channels with upfront capital, using Lightning Service Providers (LSPs) who provide liquidity for fees, or submarine swaps to balance channels. We intend the platform to be adopted by both technical and non-technical users. For the latter, this complexity could become a conversion killer.

  2. Always-online requirements. Lightning nodes must monitor channels to prevent old states being broadcast. Solutions exist (watchtower services, LSP-hosted channels), but they add trust assumptions or ongoing costs.

  3. UX friction. Explaining "you need to open a channel with 100,000 sats to receive payments" to a non-fiction writer trying to monetize their essay corpus would create a lost user.

These problems aren't insurmountable. Projects like Breez and Phoenix have dramatically improved Lightning UX. But for tzimtzum's use case, creators who aren't crypto-native receiving micropayments from AI queries, every bit of friction matters. We need something simpler for recipients while maintaining bitcoin's security model.

Why Spark Protocol?

In Spark, instead of payment channels between peers, it uses statechains, a method of transferring bitcoin ownership off-chain through a coordinated service provider. While LN locks funds in channels between specific peers and routes payments through the network, Spark lets you transfer ownership of bitcoin UTXOs directly through a service provider. Similar to an on-chain transaction but instant and nearly free.

This enables:

Native stablecoin support

Another critical advantage is native stablecoin (USDT) support. For a knowledge monetization platform, this solves a real problem: users who want to price their services in stable terms. "$0.05 per query" reads differently from "120 sats per query (which might be $0.03 or $0.08 tomorrow)." Bitcoin's volatility creates pricing friction. Spark's native USDT support means creators can denominate in dollars while maintaining the censorship resistance and low fees of bitcoin infrastructure.

Architectural alignment

Spark integrates with Tether's Wallet Development Kit (WDK), a non-custodial toolkit designed for programmatic use. Built for applications, not for humans clicking around in a browser extension. WDK runs headless, meaning AI agents in tzimtzum can generate keys, sign transactions, and manage payments without user intervention. It runs on Bare.js (same runtime as Pear/Hypercore), so the wallet embeds directly in the tzimtzum binary.

This architectural alignment, Pear for data layer, WDK for payment layer, both running on Bare.js, keeps the stack lean and integrated.

The trust tradeoff

Spark's design introduces a trust assumption that LN avoids: service providers coordinate the statechain transfers. This is Spark's main critique, that we're trusting a provider to stay online and behave honestly.

The critique is addressed by a security model that makes Spark trust-minimized rather than trustless. When receiving funds via Spark, you hold pre-signed transactions that can be broadcast to bitcoin mainnet at any time. If the Spark provider goes offline, censors your transaction, attempts to steal funds, or operates maliciously in any way, you can execute a unilateral exit: broadcasting the pre-signed transaction to reclaim ownership on the bitcoin base layer. The provider facilitates speed and low fees but cannot confiscate funds.

This aligns with tzimtzum's sovereignty requirement: optimize for speed and user experience, but always maintain an escape hatch to base layer security. Users trust the provider to facilitate efficient transfers while retaining the ability to exit to bitcoin mainnet anytime.

For micropayments where you're receiving $5-50 frequently (rather than storing $50,000 long-term), this security model is appropriate. Larger balances can always be moved to cold storage.

Why not alternatives?

Every alternative either was too expensive, had reliability issues, or centralized trust. Spark offered the right tradeoff: bitcoin-level security with L2 economics and user-friendly UX.

Conclusion

The choice for Spark Protocol as tzimtzum's payment layer was less about the perfect solution and more about accepting the right tradeoffs. LN is more decentralized but adds UX friction. Solana is cheaper but less reliable. Spark optimizes for the creator economy use case: fast, cheap payments with bitcoin security and stablecoin support.

For knowledge workers monetizing their expertise, the payment layer must be invisible. Spark gets closer to that ideal than any alternative we evaluated. The infrastructure for micropayments in creator economies exists, now it's for us to execute.