Let's say I have a small business like a bakery, with 2-3 employees, and I want to run my business full Bitcoin, I must use the Lightning Network because I'll receive small amounts like 2$-10$ on average.
That sounds very convenient, but then I have to pay my employees, it'll be a salary like 3k$, and for what I know, this kind of big payments are usually rejected because there is not enough liquidity in lightning nodes.
Is this a myth? Do the lightning wallet companies (Phoenix, Zeus LN, WoS) solve this in some way? Am I obligated to run my own LN node or can I rely on something?
I've made $3k payments on lightning without failure a number of times. In fact, as far as I recall, they all went through first time.
I think I had to try a couple of times when I bought ~econ, but it went through faster than if I had to figure out how to pay k00b in fiat.
LOL you never heard about to use swap out from your LN channels ?
A merchant will treat sats as cash. What is doing a shop owner at the end of the day?
That is how you "empty" the LN channels after you charge all day payments.
I wrote several guides about these procedures:
Please learn more about how to use LN. Read all my guides (over 60+)
You can pay them every day or even every hour or minute if you want. You should have enough liquidity to pay bills and employees and enough capacity to receive payments.
A business only accepting sats probably won't get much business currently.
the $3k liquidity myth gets repeated a lot but it's increasingly not the reality.
modern lsp-managed wallets (Phoenix, Zeus with LSP, Breez) dynamically source liquidity — large outbound payments go through fine. the real constraint is inbound capacity, which is a receiving problem, not a paying problem.
the smarter framing for your bakery: don't treat LN as a payroll rail. treat it as a daily cash drawer. you receive sats throughout the day, sweep periodically to cold storage or a fiat bridge, pay expenses from swept funds. the "big payment" problem solves itself when you stop trying to move large amounts within LN and use on-chain for settlement.
where this gets interesting is in emerging markets — in the Caribbean, workers often prefer more frequent smaller payments (daily covers real expenses, no bank processing delays). so the Western "pay salary monthly in one lump" assumption breaks down when you build for actual user behavior. smaller, more frequent payouts via LN work fine for both liquidity and UX.
tldr: the problem you're describing is a real one from 2021 LN. today's LSP-managed wallets are a different thing.
The k myth is largely outdated. Here's how a bakery actually runs this in practice:
Receiving daily payments (the easy part)
Phoenix Wallet or Breez behind a BTCPay Server or Swiss Bitcoin Pay terminal handles – payments seamlessly. Your LSP (ACINQ for Phoenix, Breez's LSP) manages inbound liquidity automatically — you just accept payments.
Paying employees k (the part people overthink)
Two clean options:
The actual workflow
The real gotcha isn't payment size — it's channel rebalancing. If you only receive and never spend LN, your inbound liquidity fills up. The daily sweep fixes this automatically.
Running the receiving side on a custodial wallet (WoS) is simpler to start but you'll want to graduate to self-custodial (Phoenix) once volume justifies it.