Blogs & Articles: Building on Lightning: How Satimoto Is Beating Fiat with the Breez SDK 🔗 33 weeks ago

We’ve told you about the Breez SDK and why it’s necessary for Lightning to grow and to make bitcoin into a currency. But maybe that’s all a little abstract? Examples help to illustrate arguments, and as ever more developers use the SDK in their apps to provide Lightning functionality, examples are popping up all around.

Let me introduce you to one in particular — Satimoto — because it provides a really clear case study of how the SDK can solve real-world Lightning problems and how, implemented cleverly, Lightning can do things fiat can’t.

Satimoto uses Lightning to solve fiat’s problem

Ross is Satimoto’s experienced lead developer. When Ross’s young family opted to buy an electric car for day trips and such, he discovered that finding available charging stations required about six different apps for a single metropolitan area. And each of those apps required him to submit a range of personal and payment information to obtain their card.

Whatever you think about the privacy implications of submitting all that data to a range of corporations, this is just a UX nightmare. Six different apps, each with its own map?? Six different cards?? For a single service?? No wonder most of us are still burning Mesozoic corpses in our cars.

Then the pandemic hit, and Ross had some spare time, which is the most valuable resource in any development project. Satimoto became his second most important pandemic project (after his toddler).

Ross designed Satimoto to solve the UX problems he discovered in the charging-station apps. With Satimoto, users can see nearby charging stations from a whole range of operators on a single map, and they can pay to charge at any of those stations with a single app and without divulging their personal information.

Satimoto looks like Candy Crush if Candy Crush were, like, useful (and gosh those “Send” and “Receive” buttons look familiar).

The first, fundamental choice he faced — fiat or Lightning — was made for him. After some research, he found that processing payments in Europe with any method that takes custody of customers’ funds “basically requires a banking license.” Researching regulations in offshore jurisdictions was slow and cumbersome. His conclusion: Satimoto had to be non-custodial Lightning for mundane, practical reasons of feasibility.

Incidentally, Lightning made good business sense too. Ross found that using Lightning allowed him to undercut the competition’s commission fees by about 30%. And operators can receive their payments immediately rather than having to wait up to 12 weeks for fiat payment processors. Banks and credit card companies are slow and expensive, and the customer always ends up footing the bill. Ideology and orange pilling are unlikely to convert the masses. A better UX and paying less will get them every time.

The catch: a built-in node wouldn’t work

Ross knew a thing or two about Lightning because he had previously been playing around with a Lightning payment app. Yes, it was Breez. He found it worked pretty well — so well, in fact, that he copied some of our design. In particular, he put a full lnd node in the Satimoto app, just like the Breez app.

Thinking like a user, Ross realized an lnd node would solve his problem as a developer but would cause problems for users down the road. Each node needs precious processor cycles, power, the user’s attention, and other scarce resources on a mobile device. If every app with payment functionality on a phone required its own built-in node, the hardware would become unusable. But if we or Ross tried to pile a dozen apps on top of a single node in a single, universal app, the software would be unusable.

Call it the Swiss-Army-knife problem.

Designing a universal tool — whether hardware or software — is a fool’s errand. (Image: Jim Sheely)

The Breez SDK (dis)solved the problem

The paradox, then, was how to build Satimoto around non-custodial Lightning payments without putting a node on the user’s phone. It’s like asking how to propel a vehicle without installing any kind of motor (solution: maglev) or how to cook food without heat (solution: curing).

The Breez SDK is the solution. Instead of local nodes, it leverages Greenlight nodes. They’re non-custodial nodes in the cloud that any app can access for Lightning payments. Multiple apps, one node, no custody. But a universal node is only universal in theory until users and their apps can access it, and they can only access it once developers write the code.

And that’s where the Breez SDK really cooks. It allows developers like Ross to add non-custodial Lightning to their apps within a matter of hours or even minutes. Receiving payments? No prob. Making payments. Piece of cake. Swapping on and off chain? Easy. Connecting to the network and balancing channels? Stop trolling me with child’s play, you casual.

The Breez SDK doesn’t solve the Swiss-Army-Knife problem as much as dissolve it. Makes it invisible. Annihilates it from existence. The Breez SDK makes Lightning work in the backend over a range of apps, so that apps like Satimoto can focus on the frontend business of serving users in any jurisdiction. Now Satimoto’s only geographical constraint is the reach of the charging station operators. Our SDK dissolves borders.

There used to be tradeoffs between Lightning and fiat: UX vs. sovereignty; UX vs. speed; UX vs. cost; off-the-shelf fiat payment widgets vs. coding a node into an app. With the Breez SDK, Lightning beats fiat across the board. It’s faster to implement (as Ross says, “It’s like one or two API calls to set up a node, one to send a payment and one to receive payment”), cheaper to use, legally less complicated (check your jurisdiction), more private, and the UX is on par with fiat for the user and even better for the developers.

Ross noticed immediate UX improvements with the SDK relative to a local node. Because of the node, the old Satimoto took about 30 seconds to boot up and be ready to use. With the SDK, that has dropped to < 3 seconds. And thanks to the LSP operating invisibly in the background, Ross and his users can ignore issues like how they’re connected to the rest of the Lightning Network and whether they have sufficient inbound liquidity for refunds and other incoming payments.

As Ross has said from his experience in building Satimoto, “The puzzle of making all the pieces fit together in building a service is now much easier than it used to be because the SDK removes many pieces.” While not yet publicly available, a Satimoto version running on the Breez SDK is all coded, tested, and ready to drop imminently, so you’ll soon be able to experience the difference yourselves.

Here’s the puzzle to solve if you want to implement Lightning in your app with the Breez SDK. You got this. (Image: gratuit)

What to build next

In the startup world, there’s the trope of the “Idea Guy” — someone with no clue about engineering or business, but thinks he’d be the next Edison if he could only find the right co-founder to realize his many visions. Everybody knows an Idea Guy, but nobody takes them seriously. Whenever they call, we’re always just about to rush out the door. Coincidence.

But the Breez SDK is so easy that even Idea Guys can build their own apps. There’s no reason to be intimidated by the technology anymore. A good idea is now worth a lot more because executing it has become so much easier.

Ross mentioned three ripe areas for new apps with SDK-enabled Lightning:

• dynamic content (i.e. streaming sats for streaming content)
• making more intelligent energy grids with real-time pricing (e.g. imagine getting paid by the electric company to wash a load of laundry or charge your car because you’re taking load off the grid)
• social micropayments on the order of children's allowances and splitting bar tabs.

Look at us! We got ideas! We’re all Idea Guys (and Gals and Whatevers). But thanks to the Breez SDK, we’re all builders now too. So let’s go build.

Building on Lightning: How Satimoto Is Beating Fiat with the Breez SDK was originally published in Breez Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.