Kevin Hurley

I think there’s still a misunderstanding here. UUIDv7s are internal database identifiers. They are used so our own systems can look up request state, enforce ownership/authorization, retry idempotently, and debug operational issues. They are not a “surveillance UID” and are not sent to Chainalysis as a Spark user identifier. On “less privacy invasive ways”: Internally, some unique identifier is necessary for correctness: idempotency, request status lookup, authorization, retries. A UUIDv7 by itself is not meaningful to an external party unless we transmit it or expose a lookup surface for it.

@kphur @sethforprivacy @_pretyflaco @nwoodfine @spark @roy_breez @matthewvuk2 @blinkbtc @lightspark Yes, talking about UUIv7 here. I'm sure there could be some less privacy invasive ways? x.com/giacomozucco/s…

It looks like we screwed up with a tweet posted in haste without properly verifying the facts on @spark. @roy_breez and @sethforprivacy have assured us that Spark does not apply chainalysis for Spark users at the on-chain or Lightning level. The misunderstanding came about due to getting wires crossed between Lightspark and Spark products, which operate on the same infra but are distinct systems. We'd appreciate you amplifying this post, to help set the record straight. Everyone on the @secondhq team are passionate bitcoiners, the team leans toward purists and obsess over the details, for better or worse. We went too far here and got things wrong to boot. Late night on a Sunday was also completely unreasonable to post stuff like this. We'll be getting back to regular programming of positive vibes only. Rest assured that the team is heads down making the Bark SDK the best it can be.

I'm unsure what you mean by a "spark-related data-aggregating UID". We use UUIDs internally of course for most any data object - I don't know of any system that doesn't use unique IDs, it would make it very difficult for any user to query what is happening with a request if they don't have something to query (it also allows us to enforce that only the correct user can ask about that information). As an example, when you create a request, the operation creates a UUID that is universally unique that can be queried to determine what the status of the operation is. The UMA code doesn't know/care about the Spark code and vice-versa.

@kphur @sethforprivacy @_pretyflaco @nwoodfine @spark @roy_breez @matthewvuk2 @blinkbtc @lightspark So, the spark-related data-aggregating UID I described above is really there, but is never connected with UMA, even upon requests. Good to confirm. I guess it would be even better if the two didn't sit on the same server (albeit with different endpoint)? :) Thanks.

@giacomozucco @sethforprivacy @_pretyflaco @nwoodfine @spark @roy_breez @matthewvuk2 @blinkbtc @lightspark I don't believe Chainalysis even supports Spark. You're asking about a separate product (UMA) which is used to allow regulated institutions to transact over Lightning.

A follow up question (assuming my interpretation above about the UID is correct) would be...can we rest reassured that chainanal guys NEVER access that UID information, resting on the same infrastructures of their "surveillance as a service" thing...or they don't get it by default, but can sometimes access it under some condition?

In our original Lightning product, we wanted to provide flexibility to developers to fetch exactly the data they wanted and make fewer API requests with graph traversal (as well as some of the other core benefits of GraphQL). In practice, we wrapped most APIs in SDKs so the benefits weren't realized and it's become one of the more controversial decisions internally

@kphur Aside from that silly discussion, I found it interesting that Lightspark seems to use GraphQL. What would the use case be?

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.

This is honestly one of the coolest set of docs I've ever seen

Polymarket 🤝 Spark 🤝 Bitcoin

@austinvach @davidmarcus @mpp Thanks for the PR, it's merged now!

@davidmarcus Hello! Can you nudge your team to include Spark addresses when creating BOLT11 invoices for @mpp? Please and thank you 🙏

Introducing Grid Global Accounts. Your app can now be a full global financial account without becoming a bank. One API integration. Live in weeks. Your users get: > Branded dollar accounts (with your stablecoin) > Visa debit cards, virtual + physical > Instant payouts to 65+ countries, 14,000+ banks > Native Bitcoin conversion > AI agent delegation with native controls Licensing, KYC, compliance, fraud monitoring, we handle it. Sandbox is open now. lightspark.com/grid-global-ac…

The future of finance starts today

I might announce something interesting next week at @TheBitcoinConf. If you're attending, drop by main stage (Nakamoto) on Tuesday at 11:15am...

Tether wallet is the biggest launch in crypto right now - built with @spark

Proper orchestration and usage of AI is an unlock unlike anything we’ve seen before. I’ve been using a tool I built that 10x’s how quickly I can move as well as gives dramatically higher quality through things like debates between agents. Take a look and see if it helps you! lightspark.com/news/insights/…

@generalbreadco 🚀

Introducing Bread The app that will change how we all experience Bitcoin Reply with your referral code for early access

Incredible momentum on Spark with WDK, Cake Wallet, and many others recently

Swap BTC instantly to any asset on any chain in under 5 seconds. Powered by Spark. Welcome, @gardenfi

Our Latest blogpost about Spark is out: layerzwallet.com/blog/unlocking… @lightspark @flashnet

Cake Wallet, one of the largest Bitcoin wallets, just launched Lightning. Powered by Spark + Breez. Welcome, @cakewallet

⚡ Lightning-fast BTC swaps are now live on Exolix! We’re excited to introduce Bitcoin Lightning support via the @Breez_Tech SDK and @spark implementation, enabling ultra-fast, low-fee BTC swaps – fully non-custodial. Watch the demo to see how easy it is, and try it yourself 👇 🔗 Read more about how it works: exolix.com/blog/exolix-in…

I’m hiring for a senior sales role at @lightspark. The right profile brings together: - proven enterprise sales track record - deep experience in fintech and crypto - highly entrepreneurial mindset, self-directed, true hunter mentality - mission-driven, able to maintain peak intensity through long cycles - zero ego We’ve just hit an inflection point at @lightspark. The path is clear to make money move like data on the internet: open, instant, global. No better time to join and help drive this mission forward. If this sounds like you, apply via the link in the reply!