Our Lightning Journey

Those who have closely followed Cake Wallet over the past few years may remember that we launched a beta version of the app with Lightning support way back in 2024, and then… never released it to all of our users. In this post we’ll break down what went wrong, why we went back to the drawing board, and how Spark has solved Lightning in a way that fits real people’s needs without compromising on the non-negotiables.

Lightning is dead… Long live Lightning?

Giving our users Lightning network support has been a goal for many years now, with it being the last missing piece for the thousands of Bitcoiners swarming to use Cake. Silent Payments support, Payjoin v2 support, and other cutting edge privacy tech paired with our ecosystem of tools has made Cake Wallet the wallet of choice for many Bitcoiners, but Lightning has always been a glaring gap for us. When we set out to solve this problem in 2024, most wallets that were launching with Lightning support were compromising on self-custody to provide a better user experience, forcing their users (often unknowingly) to trust a custodian like Liquid with their Bitcoin to “use Lightning”.

That approach was always a non-starter for us, as self-custody is an absolute non-negotiable here at Cake. In 2024, the best alternative at the time was something by Blockstream called “Greenlight”, a solution that deployed a Lightning node in the cloud for each user, but kept their signing keys (and thus custody of their funds) local on their device. While this sounds great in theory and was supposed to solve the main hurdles with Lightning at the time (specifically the always-online requirement just to receive payments and stay in sync with the Bitcoin blockchain), in practice it fell flat. After building on the Breez SDK with Greenlight at the time, we realized quickly after launching the public beta that Greenlight itself (through no fault of Breez, I may add!) was not a workable solution for us and had far too many pain points in daily use for our real users.

It was time to go back to the drawing board.

You get an L2, you get an L2, everyone gets an L2!

2024 was a big year for new tech in the Bitcoin space, with the launch of two companies aiming to build better layer two (L2) networks on Bitcoin that would allow users to easily transfer funds, make and receive Lightning payments, and much more without sacrificing self-custody. Ark Labs launched their implementation of the Arkade OS network and Lightspark launched the Spark network, both with similar initial aims but taking very different technical approaches to the problems Bitcoin and Lightning were facing.

Lightning continues to evolve, but most of the changes we’ve witnessed over the last decade are changes in the technology. What’s happened over the last two years, however, is a change of the technology.
- Roy Sheinfeld, CEO of Breez

After hundreds of hours of research, many articles and posts written by our team, and many conversations with experts in the Lightning space like Roy, it became clear that the Spark network in particular fit our needs perfectly by offering four key things:

1. Simple self-custody with easy to understand tradeoffs
2. Near-instant payments in Spark and across the Lightning network
3. Improved privacy assumptions over on-chain Bitcoin payments
4. Native token support, specifically stablecoins (more on this in the future 👀)

When we learned that Breez would be building a cutting-edge Spark SDK to enable Lightning payments, stablecoins, and more, the path was clear.

The tl;dr on Spark

If you’ve missed out on the Spark chatter over the past year or so, while it’s technically complex under the hood, it’s extremely simple in operation. For users, making and receiving payments feels as straightforward as on-chain payments. Just scan a QR, enter an address, or type in someones @cake.cash username. Payments happen instantly, with no need to wait for lengthy block times or deal with channel management. Payments just… work, no matter if they’re native on Spark or done over the Lightning network to any Lightning wallet.

Under the hood, Spark works by leveraging established tech (called a “statechain” and in existence in Bitcoin since 2019) to allow users to essentially transfer ownership of Bitcoin off-chain without requiring on-chain transactions every time. Users are free to transfer coins as many times as they want, with pre-signed Bitcoin transactions being used to ensure that only the current owner of those coins can exit back to Bitcoin’s layer one at any time. To transfer this ownership, the sender works with the Spark Operators to change the ownership of the coin(s) to the new owner, with the sender and Spark Operators promising to throw away their old keys after signing.

When you want to make a Lightning payment, you simply sign over ownership of the right amount of Bitcoin in Spark to a Lightning service provider in an atomic swap, ensuring that either the Lightning transaction goes through or you keep the Bitcoin on Spark automatically — with no way for the Lightning service provider to confiscate or freeze coins in the transaction.

All of this happens in milliseconds, with Spark transfers and Lightning payments both happening near-instantly. No need to manage channels, no need to worry about outbound and inbound liquidity, just make the payments you want to make without the constant mental burden Lightning has historically brought for real people.

So what’s the catch? As long as any one of the Spark operators (there are several unique operators) or the previous sender delete their old key share for the coin(s), the new owner is the only one with access to them and there is no catch. However, as there is no way to prove deletion of data, it is possible that this occurs if all Spark Operators and the previous sender collude to try and double spend the funds.

However, the recipient can simply publish a pre-signed Bitcoin transaction on-chain to defeat this attack, claiming the funds for themselves in a trustless unilateral exit. As long as this pre-signed transaction is published in time, the operators and previous sender won’t be able to spend the funds, and they’ll have destroyed their reputation in the attempt. That double incentive for the operators and previous sender to act honestly all but eliminates that trust assumption in the real world. While we still call this type of system self-custodial, it’s important to understand that it is trust-minimized (as are most things in the space, even “pure” Lightning!) and not entirely trustless.

If you want to dive deeper into both Spark and Ark, check out Seth For Privacy’s long-form post for Bitcoin Magazine breaking down Spark and Ark from last year:

Spark And Ark: A Look At Our Newest Bitcoin Layer Twos

A comparison of the trust models and trade offs of Ark and Spark, the two newest entrants to Bitcoin’s collection of Layer Two protocols.

Bitcoin MagazineSeth For Privacy

Conclusion

We’re thrilled that the right solution to the problems we were facing with Lightning has become a reality through Spark, and that the implementation itself has been greatly simplified by the incredible work of the Breez team. All of our 1M+ users now get seamless access to the Lightning network at the tap of a button without the headaches that traditionally come with Lightning usage and without sacrificing custody over their coins.

Let’s make Lightning great again.