Spark

• Name: Spark
• URL: https://www.spark.money/
• Category: Bitcoin offchain payments and token-issuance infrastructure / operator-assisted 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. Keep the separate operator boundary visible too: Spark the protocol/product is analytically distinct from lightspark, the named company packaging wallet SDKs, issuer tooling, and broader rail access around it.
• 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

• Company / operator shell for wallet SDK packaging, issuer workflow, and broader payments distribution: lightspark.
• 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.

Protocol / company boundary

• Keep this note on Spark’s mechanism layer: operator-assisted transfers, unilateral exits, Lightning interoperability, wallet and issuer interfaces, and the trust-model tradeoff that comes from configurable operator signing.
• Use lightspark when the sharper question is who ships the main SDK and docs shell, chooses the easiest issuer and wallet integration path, packages Spark alongside other payment rails, and can turn operator-facing workflow into de facto distribution control.
• That split matters because how does Spark work? and which named company is most likely to shape who adopts it, how they integrate it, and what operational defaults they inherit? are related but not identical questions.

Control surface

• At the project layer, leverage sits in operator availability, signer-threshold policy, issuer admission, wallet-SDK defaults, and how Spark packages Lightning and Bitcoin ingress or exit for downstream apps.

• One layer up, lightspark matters because the company can concentrate distribution, hosted workflow, SDK ergonomics, and cross-rail product packaging around Spark even if the underlying Bitcoin exit rights remain part of the safety story.

• Read Spark as operator-assisted Bitcoin payment-and-issuance infrastructure, not as a neutral L2 baseline or general-purpose chain.

• Last reviewed: 2026-08-12 UTC