# How does loop work?

Lightning loop is a great non-custodial way to do submarine swaps in both directions. However I would like to clarify some questions about how it actually works.

There is a closed source server side of the loop, controlled by lightning labs. Which lightning nodes is the server side running on? Does that mean that I will only ever be able to rebalance the channels that are a part of the path from my node to theirs?

Second question is more about the software architecture. Why do I need a daemon loopd to always be running in the background? Seems like the server side should be of course always online, but why ask the clients to do that?

1. Lightning Labs manages the lnd node(s) running on the private (closed source) server you are correct. Your node receiving Loop payments on LN will need a route to their node, however part of the service Loop is providing (and charges for) requires them to keep channels balanced to pay your invoices or accept payments on demand.

The closed source functionality could include proprietary channel balancing techniques that give Loop's node(s) an edge in their service over competitors.

In any case to find their node you can take an invoice from Loop and parse out the destination pubkey.

1. The loopd implementation itself is a daemon that is tightly coupled with lnd and the private server discussed above. It is responsible for facilitating all parts of the submarine swap functionality Loop offers. It is intended for loopd to be running alongside lnd for automated submarine swap workflows (ie. rebalancing).

I played around with loop and got some of the answers. Posting here as it can also be useful to others.

1. I did multiple loop out operations, and every time my counterparty was a node 03fb2a0ca79c005f493f1faa83071d3a937cf220d4051dc48b8fe3a087879cf14a. I assume this is the loop server node. It does not necessarily mean that loop only has one server node, but so far it looks like it.

03fb2a... is a private node though, so it also gave my node routing hints, which point out to the last public node on the path to the server. And the last public node is 021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d - a pre-server node.

So most probably it is only possible to balance the channels that have a path with sufficient liquidity to the node 021c97...

2. It seems like loopd needs to be running in the background purely for user experience reasons. Something needs to be running while a swap is being completed, and the swap takes a long time to complete (two transactions need to be confirmed on-chain, so it can easily take half an hour).

So running loopd in the background makes sense simply not to block the terminal window for a long time. I also checked that when no swap was being executed - loopd was simply idle.

I wasn't aware until now that their server is closed source. But it appears to be like that indeed. Interesting and understandable choice, I guess they do want to earn money after all. Let's hope it'll be open sourced/reconstructed eventually.

With regards to your more technical questions, I don't know what nodes their servers run on, but the idea of the lightning network is that as a user you shouldn't have to know. As long as you are connected to the LN, there should always be a path from your node to theirs. The question could only be if there is a path with enough capacity from/to their nodes. However, the advantage of this seeming to be their business is that they have an incentive to maintain good in- and outgoing capacity to everywhere in the network, so it should just work.

As to why there needs to be a loopd running, that makes sense while a swap is running, since it needs to watch and act both upon LN and the bitcoin blockchain, because loops are really just submarine swaps. I'm pretty sure you can kill that loopd once your swap is done.

• That is essentially the question: there will be all sorts of routing/inbound capacity issues if they only have one node, so I would like to analyze it. But maybe they have multiple nodes, which would improve the situation, but still the issues will remain... Also of course you can kill loopd, but that is clearly not their intended design decision, and I wonder why? – Dmitry Laptev Jul 12 '19 at 15:38