코인톡

There's been a round of misinformation about Spark going around, so for the sake of setting the record straight, I'll briefly clear up a few things.

For one, unilateral exit has been around since the early days of Spark. Many developers and users have used it. This has been demonstrated many times both here on X and during the process of integration by developers. Unilateral exit also does not require the SOs to be online when a user wishes to exit. When a transaction is received, users can save the unilateral exit information and later use those pre-signed, valid L1 Bitcoin transactions at any time on Bitcoin. There are existing Github issues to expose unilateral exits in a more intuitive way in the SDKs, but unilateral exits themselves have been functional for a very long time. Unilateral exits do require CPFP - this is used to ensure that the expected value for an attacker is negative. The typical user would perform a cooperative exit, which does not require any on-chain funds and is an atomic swap of on-chain funds in exchange for Spark funds. Unilateral exits are generally reserved for a worst-case scenario and can be sponsored by an L1 fund provider if needed.

Second, the confusion around "Sparkcore". At Lightspark, we use a monorepo for our server code. This one service is called Sparkcore - the naming of which preceded the creation of Spark. Lightspark runs an SSP within this service. Our Lightning infrastructure uses both LDK and LND - both of which we contribute code towards. Sparkcore itself is not open sourced - that would mean open sourcing our entire server-side stack for every product we have built. The Spark network code, however, has always been open source - and that's the openness that matters, because it's the code that actually enforces the rules of Spark. The SSP is an optional, replaceable convenience role.

A recent post claimed that APIs used for other products are part of the SSP. We have many products, and we have never been shy about describing UMA, which allows regulated entities to exchange information to process transactions over Lightning. This is not a Spark product. The SSP does not hold your seed phrase (that should never leave your device), the SSP cannot freeze your funds, and the SSP isn't even a required role to use Spark - it is the interop layer between Lightning and Spark and helps do swaps for exact denominations of leaves. Running an SSP is something we have talked with many partners about. The client chooses which SSP they wish to interact with (if any) - we cannot control if a client talks to a new SSP.

Finally, privacy. I've discussed this many times in the past, so won't belabor the point again. Spark allows for transactions to be hidden from external visibility. As I've spoken about at length both here and at various conferences, we care deeply about making sure that there is true privacy, and we aren't satisfied with anything short of that. It's an ongoing effort to continue to further the research in this area.

I'll leave it with this. In the network our critics operate, the default payment path is one where the operator colluding with any prior owner can double-spend the current holder - their own docs say so. Receiving over Lightning means trusting that the operator deleted a key - their own docs say so. If you don't come online every 28 days, the operator can take your funds. In their founder's own words: "In theory it could steal it." The automatic re-issuance of expired funds promised in March 2025 still hasn't shipped. Their operator's liquidity costs scale with payment volume, which by their own admission "will translate into user fees." And there is exactly one operator - their own docs tell everyone else: "Do not attempt to run an Ark server in production (yet!)." Spark has three independent operators, exits that don't expire, and no flow where a single operator can take user funds. Users can judge for themselves.

Our users and the developers building on top of Spark care about bringing Bitcoin to more people. They value the ease of use and simplicity of Spark. They care that we have 3 independent SOs. They care that we are pushing for more and better functionality. And they value that we spend all of our time thinking about how to make Spark better each and every day. Ok, now back to building because that's what we do at Spark.