Wavelength Delivers Ark-Based Lightning Without Node Overhead | Roasbeef & Michael Levin SLP764

**Stephan Livera** (0:00)
Hi everyone, welcome back to Stephan Livera Podcast. Today, we're going to be talking about wavelength, and joining me today on the show, many of you already know, Laolu, aka Roast Beef. He is the CTO and co-founder of Lightning Labs, and also joining us is Michael Levin. Michael is VP of Product over at Lightning. Now, yeah, today, yeah, I saw, obviously, you guys put out this news about wavelength.
It's your own form of arc, right? So obviously, you know, long-term listeners will know, just for new people, Lightning Labs are known for creating LND, which is one of the well-known big implementations of Lightning. You have Lightning Loop and Pool, which are services that people use for swapping in and out, and you have L402, so you've got Lightning Terminal, I guess. These are tools that users can do to manage their channels and manage a Lightning node. So yeah, welcome to the show, and let's get into the why, right? So you've already got all this stuff on the Lightning side.
What's the reason behind doing wavelength, which is an arc instance, let's say, or type of arc? Yeah, absolutely.

**Michael Levin** (1:11)
I mean, first off, thanks for having us. Super excited to be here, a long time fan of the show. I think when it comes to why we prioritize wavelength, like you mentioned, we have L&D, we've been doing stuff in terms of Lightning network adoption for an extraordinarily long time. We've gotten so many exchanges and businesses on board to the Lightning network, which is exciting. But in a lot of conversations we have, the problem that comes up is the integration costs or the maintenance cost of managing a Lightning node. So you have to set up the node, you have to manage the channels, you have to manage your liquidity, you have to do that actively over time.
That is the self-sovereign path, that's a path that anybody can go down, they can spin up a node and go down that road. But we want to give people the ability to access the Lightning Network and the benefits of the Lightning Network when it comes to low-cost global transactions, without having to have that integration and maintenance overhead. So we basically wanted to think about a way to put together easy mode for self-custodial Bitcoin and eventually stablecoin payments on Lightning. And that's the goal that we started with. And we worked backwards from there when it came to, how do we build out the tech stack from a backend perspective to make this a reality?
Which is why we landed on things like the combination of our existing Lightning Loop node, which is one of the biggest, most well-capitalized nodes on the network, in combination with this batching engine, or batching engine on the backend. But Lali, I'm not sure if you have anything you want to add to that.

**Stephan Livera** (2:46)
Well, Lali, maybe it would be good if you can add to us, if you can speak to the technical choices behind going with an ARK style, as compared to something else like Spark and Liquid and whatever else. Why was ARK the way?

**Olaoluwa Osuntokun** (3:02)
I think we're looking at a number of different approaches, basically. Some of them may be required, like new ARK code and software. Obviously, you can't necessarily bank on that, because who knows what's going on? And obviously, up until maybe a few weeks ago, or like last week, there was a lot of uncertainty going on in terms of what was happening with the chain itself.
I feel like this was one of those things where, I think, ultimately, just with Bitcoin as is, you have to sort of accept the number of trade-offs, basically, right? And we were looking for some of the other trade-offs between maybe A or B or C. I think one other thing, maybe compared to making... Obviously, you can make another chain, but I think that also adds additional complexity, because then you have to worry about that other chain, exactly what it's doing, basically, versus just having a single stack on Bitcoin that can be fully unified in a particular setting. And obviously, with ARK, the main trade-off, it's just sort of some things around the way the timeouts work, basically, right? And that there's a timeout system, you have to come online, then make sure you basically hand those timeouts accordingly. Otherwise, maybe some things have to do with your friends. Lightning is similar, but it may be a little bit opposite, in that you basically need to be more reactive rather than passively doing something. Because, for example, the way you can view it is sort of like, before we actually had SegWit, people were looking at the Lightning channel, they actually had a Lightning channel that was sort of single-directional and would expire, basically, after a period of time, right? And so for a long time, people were looking at those designs, there were some very early versions of that, like BitcoinJ, Bit37, things like that as well, too. But the X-ray was something that really got people caught up, right? I think this sort of reintroduced that, but in a way where you can have additional tools to manage that effectively, basically, and you can also do things like have the client maybe wake up proactively or do something like where the server says, okay, hey, I'm going to be online at 12 p.m., 1 p.m., and 3 p.m., basically, the client can basically go around that. We also had a number of things on the client and server side, basically, around handling this more asynchronous approach to things, basically, right? Because otherwise, if you have a TCP connection, maybe on your phone, maybe you go on Wi-Fi, to 3G or 5G, maybe it would break, and that would cause additional issues around a signalicity and latency and so forth. But we have this mailbox system where rather than requiring a client to continue to be online consistently, they can come online, check a mailbox, and then go offline if they really need to. Simply, the server can just send the client a message that says, hey, check your mailbox, maybe you have something there. As Michael mentioned, we combine what we have as the gateway, a liquidity network with something like Loop, which services a large portion of the network. Today, it can do fairly large payments, it has a fairly robust inbound liquidity pool from all the other available nodes with the R component as well too. I think one key part of it is a single client basically. Single client basically does everything from the ground up. For example, it has a wallet, it can be an L and D node, it can be a Explorer, it can be a Neutrino basically, then it has the R custom on top of it, then it also has the Swap layer on top of that as well too. I think one of the unique things that we end up doing with this too is that rather than introduce yet another address because people can get confused about that and then it all happens, everything is actually just a normal Lightning invoice. We do some clever stuff with the Hopkins sets that basically, no matter if I'm sending to you across Lightning, so maybe from the wavelength into the part of Lightning, or maybe if you're actually another user that's actually on wavelength, the client can basically detect that and then either dispatch it more directly or dispatch it over the network itself. I think it has some number of advantages because, for example, this means you don't always necessarily need to route. You could route if you wanted to, basically. The client could actually do the entire thing and maybe do some modification. But this lets them do something that's a bit simpler and also more lightweight as well.