Let’s walk through a user story. I want to send $1,000 to a friend of mine in El Salvador:
* When I initiate the $1,000 payment, Strike debits my existing USD balance.
* Strike then automatically converts my $1,000 to bitcoins ready for use in its infrastructure using its real-time automated risk management and trading infrastructure.
* Strike then moves the bitcoins across the Gulf of Mexico where it arrives in our Central American infrastructure in less than a second and for no cost.
* Strike then takes the bitcoins and automatically converts them back into USDT (synthetic digital dollar known as Tether) using its real-time automated risk management and trading infrastructure.
* Strike then credits the existing user with the USDT to their Strike account.
[1] https://jimmymow.medium.com/announcing-strike-global-2392b90...
In the case of merchant/customer interactions, the LN channel blocks customer funds from their balance, but they will never receive money from the merchant. So that balance will be sent to the merchant, payment by payment.
Not only does that block funds for the customer (which wants to reduce those, to avoid blocking too much, but that reduces the number of payments that can be made off-chain), but it also blocks the merchant’s reception of those payments: the merchant wants to be able to spend it soon, but it can only spend it on-chain.
That is compounded by the fact that most merchant/customer interactions are rare one-offs in the real world. I just don’t buy stamps every day.
LN channels are only most useful when the two parties exchange money bidirectionally on average.
It’s very common on lightning to pay liquidity providers to balance your channels to you. Lightning Labs has a service called loop where you can pay them an onchain transaction and it will make a lightning network payment to your channel for that amount, thus giving you more spend liquidity. Loop is sweet cause it does this in a non custodial way, look into it.
