Spark

• Name: Spark
• URL: https://www.spark.money/
• Category: Bitcoin Layer 2 / payments and token-issuance infrastructure / Lightning-compatible settlement layer
• Tags: bitcoin-ecosystem
• Summary: Spark is payments-and-asset infrastructure on top of Bitcoin, not a general-purpose smart-contract chain. The note should stay on the actual shape: an off-chain, statechain-derived system with operator-assisted signing, unilateral exits back to Bitcoin L1, Lightning interoperability, and explicit trust-model tradeoffs instead of a VM, rollup, or separate blockchain.
• What it does:
  • Provides a Bitcoin-native off-chain transaction layer for instant Spark-to-Spark transfers with near-zero or zero-fee internal payments
  • Lets developers build self-custodial wallets with TypeScript and React Native SDKs plus CLI-based quickstarts
  • Supports Lightning send/receive flows without requiring end users to manage channels or liquidity directly
  • Offers Bitcoin L1 deposit, withdrawal, and 0-conf deposit flows for faster wallet and payments UX
  • Exposes an Issuer SDK and BTKN token standard for creating and managing Bitcoin-native tokens and stablecoins on Spark
  • Documents fiat-ramp, wallet, explorer, and stablecoin integrations that position Spark as a broader Bitcoin payments control plane rather than only a protocol primitive
• Key claims:
  • Spark’s homepage and docs describe it as the fastest, cheapest, and most UX-friendly way to build financial apps and launch assets natively on Bitcoin, though that framing remains a project claim
  • The docs explicitly say Spark is not a rollup, not a blockchain, and has no smart contracts or VM; instead it is a payments-focused off-chain system built on shared signing and statechain-style mechanics
  • The llms.txt index emphasizes self-custody, sub-second finality, Lightning compatibility, native stablecoin issuance, and 0-conf deposits as the key differentiators
  • The technical docs and research pages say users retain unilateral exit rights to Bitcoin L1 and that Spark’s safety model depends on a 1-of-n or configurable-threshold operator assumption at transaction time
  • The trust-model docs are unusually clear that Spark’s main tradeoff is operator behavior and availability during transfers rather than simple “fully trustless” marketing
  • The Issuer SDK and BTKN materials show Spark is trying to become a real token-and-stablecoin issuance environment on Bitcoin, not just a payments wallet rail
• Whitepaper: No single canonical Spark whitepaper or litepaper was surfaced in this pass. The clearest primary sources were Spark’s official site, docs, llms.txt index, issuer documentation, and first-party research explainers; see ../whitepapers/spark-primary-sources-2026-04-27.md.
• Sources:
  • https://www.spark.money/
  • https://docs.spark.money/
  • https://docs.spark.money/llms.txt
  • https://docs.spark.money/start/overview
  • https://docs.spark.money/learn/tldr
  • https://docs.spark.money/learn/trust-model
  • https://docs.spark.money/quickstart/create-wallet
  • https://docs.spark.money/issuance/overview
  • https://www.spark.money/research/what-is-spark-bitcoin-layer-2

Internal linkages

• Closest operator-assisted Bitcoin transfer cousin: mercury-layer.

• Shared Bitcoin offchain-transfer branch worth keeping nearby: ark.

• Strongest contrast when the question is richer client-side state and proof machinery instead of operator-availability tradeoffs: rgb.

• Last reviewed: 2026-05-31 UTC