Lightspark

• Name: Lightspark
• URL: https://www.lightspark.com/
• Category: cross-rail payments-infrastructure company / Bitcoin-and-stablecoin money-movement operator / Spark-adjacent wallet-and-issuer tooling company
• Summary: Lightspark belongs as an entity note because the important control surface is not a neutral protocol. The company operates the quote, account-mapping, compliance, webhook-truth, and execution stack that sits between customers and multiple payment rails. The practical authority lives in the operator-managed control plane around Grid, UMA-style address handling, internal-versus-external routing, and the company’s growing Spark-adjacent wallet and issuer stack.
• What it does:
  • Operates Grid, a payments API for sending and receiving global payments across internal accounts, external accounts, and UMA addresses, with customer management, KYC/KYB-related surfaces, exchange-rate and quote generation, transfer execution, and webhook-driven status delivery
  • Supports cross-currency transfers that move across fiat, stablecoin, and Bitcoin-adjacent endpoints instead of exposing Lightning as the whole product boundary
  • Develops Spark-adjacent wallet SDKs and issuer tooling for moving Bitcoin and Bitcoin-native assets, including stablecoins, through its broader house stack
  • Publishes Lightning SDK surfaces, open-source tooling, OpenAPI specs, a CLI, and example implementations through its GitHub organization
  • Sells hosted money-movement infrastructure where policy, routing, customer-state gating, and execution defaults remain company-run surfaces
• Key claims:
  • Homepage and Grid docs show Lightspark presenting itself as a global-payments infrastructure company rather than as a narrow Lightning API vendor
  • Grid API materials make quote generation, account mapping, compliance handling, transfer execution, and webhook state first-class product surfaces, which means the useful risk question is who operates those layers
  • Cross-currency transfer docs show Lightspark packaging addressability and execution across fiat, stablecoins, Bitcoin-adjacent endpoints, and UMA-style flows under one operator-managed interface
  • Spark docs broaden the stack further with wallet and issuer tooling, but they do not erase the company boundary; they reinforce that Lightspark is building and operating a bundled money-movement control plane
  • The public GitHub organization and SDK surfaces matter because downstream integrators can become dependent on Lightspark-authored clients, schemas, and execution assumptions in addition to the hosted APIs themselves
• Whitepaper: No classic standalone company whitepaper is the important artifact here. The strongest primary-source snapshot is ../whitepapers/lightspark-primary-sources-2026-04-25.md.
• Sources:
  • https://www.lightspark.com/
  • https://github.com/lightsparkdev
  • https://grid.lightspark.com/llms.txt
  • https://grid.lightspark.com/api-reference/authentication
  • https://grid.lightspark.com/api-reference/cross-currency-transfers/create-a-transfer-quote
  • https://docs.spark.money/start/overview
  • https://docs.spark.money/wallets/overview
  • https://docs.spark.money/issuance/overview

Internal linkages

• Legacy project-layer alias preserved for old links: lightspark.
• Structural protocol/product child: spark.
• Strongest hosted-payments comparison: bridge-xyz.
• Useful standards contrast: open-payments.

Protocol / company boundary

• There is no especially clean standalone Lightspark protocol boundary doing the analytical work here.
• The important surface is the company-run stack that prices routes, maps accounts and counterparties, handles compliance and customer state, decides how UMA-style addressing resolves in practice, and publishes webhook truth back to integrators.
• Spark may matter as a protocol and product family, but Lightspark the company is still the operator boundary that packages rail access, wallet tooling, issuer tooling, and execution policy together.
• That is why Lightspark belongs in companies/: the practical control question is who runs the money-movement stack and chooses the defaults, not whether one underlying rail is nominally open.

Control surface

• Practical leverage sits in quote policy, corridor and asset support, compliance and account-state gating, internal-versus-external routing defaults, webhook truth, API and SDK evolution, and the customer-facing abstractions that determine how counterparties reach fiat, stablecoin, Bitcoin, Lightning, UMA, and Spark-connected flows.

• If customers treat Lightspark as the default path-selection and settlement-orchestration layer, authority accumulates in the company’s routing logic and operational policy even when some underlying rails remain open.

• Read Lightspark as an operator control plane for cross-rail money movement, not as a neutral payments primitive.

• Last reviewed: 2026-08-05 UTC