Spark, in case you didn't know, is not fully open source. The Lightspark Spark Service Provider (SSP) does not seem to be open source. The SSP is the thing that actually makes a lightning payment when you pay a lightning invoice using a balance held on Spark.
Back in 2025, Megalithic noted that there was no way to run a SSP without a business relationship with Spark
More recently, here is @calle asking Spark to set up a public SSP on signet for testing:
Calle kept asking, and then @benthecarman made this comment:
And a day later, that's exactly what he did:
Pretty cool!
open-sspis a self-hosted Spark Service Provider written in Rust. One process provides the SSP GraphQL API, owns the Spark liquidity wallet, fills Swap V3 requests, and settles Lightning payments throughldk-server.
The service uses the Breez Spark Rust SDK for its embedded wallet. Spark Operators remain separate services and use the existing Spark protocol. The operator build must expose the authenticated counter-swap RPC used by the SSP.
Supported flows
Static-deposit quotes are test-only on regtest. Cooperative exits, instant static deposits, receive quotes, request history pagination, and wallet webhooks are not production-complete. See SSP API coverage for the exact operation status.
- Wallet challenge authentication and durable 24-hour sessions.
- Partial Spark transfers through atomic Swap V3 counter transfers.
- BOLT11 Lightning sends backed by a verified Spark preimage-swap transfer.
- BOLT11 Lightning receives with wallet-created preimage shares, an atomic operator swap, and a Spark payout before the Lightning claim.
- BOLT12 Lightning sends with a completed Spark prepayment and an idempotent refund after a final Lightning failure.
- BOLT12 Lightning receives with an SSP-created offer and a Spark payout after the Lightning payment completes.
- Durable payment state, event-stream reconnect, and payment reconciliation.
- Authenticated Spark liquidity deposits and leaf funding.
Lol, probably came quicker that lightshpark expected.
Might be worth a dig to see if it's actually useful as a replacement to boltz exchange
Stupid but genuine question: what’s the impact/value of this? Is it mostly for testing or could this turn into a Spark competition in case they turn evil?
In my ignorance, I see it as a testing thing. I believe the Spark Operators would need to accept the SSP for it to work with Lightspark's Spark.
Maybe if there was an entirely different Spark entity (in the same way that you can have two entirely different ecash mints or two different bitcoin blockchains) this could be useful in building out the lightning gateway part.
Does that answer your question?
haha super clever @benthecarman 🙌
Good question — I don't think it's about Spark turning evil so much as the difference between using a protocol through one hosted company versus running the infrastructure yourself. The SSP is the operational trust point: it holds the liquidity wallet, executes swaps, and sees preimages. Spark's enforced unilateral exit keeps it trust-minimized, but a hosted-only SSP still makes you a customer of one business — exactly the gap Megalithic flagged in 2025. open-ssp closes that: one process, embedded wallet + ldk-server, so a competent self-hoster can run their own SSP with no commercial relationship. The residual catch is operational — running an SSP that stays liquid and available is real work, which is why most people will still pay Lightspark. But now it's a choice, not a requirement, and devs finally have a local/regtest SSP to build against instead of asking a company for a public signet instance.