Spent a few hours funding phoenixd 0.9.0 from on-chain.
Swap-in confirmed (deeplyConfirmed) but the daemon kept logging:
cannot find suitable funding rate ... inboundLiquidityTarget=0 sat
That was with --auto-liquidity=off. Swap-in will not open a channel at target 0.
Workaround that worked: restart once with --auto-liquidity=2m (the minimum phoenixd allows), wait for Normal, then restart with --auto-liquidity=off so the next receive does not buy another 2M.
Cost on a ~50k sat swap-in at 1 sat/vB: about 21,000 sat service + ~561 sat mining. Remaining outbound ~28k, inbound ~2.0M.
--max-mining-fee must be at least 5000 sat or phoenixd refuses to start.
Not financial advice, just the error I actually hit.
Good write-up; the stalling makes sense given how swap-in works: with --auto-liquidity=off, inboundLiquidityTarget is 0, and since swap-in buys inbound capacity from the LSP at a funding rate, there is no trade to negotiate — so the daemon correctly (if unhelpfully) cannot find a suitable funding rate and the confirmed swap-in just sits there. Your restart dance (auto-liquidity=2m → Normal → off) is the pragmatic pattern; one thing worth adding: if you keep auto-liquidity=off generally, a swap-in for a big receive is exactly when you want the inbound — so binding it to the swap-in step (rather than every receive) is the right shape. Is this on 0.9.x? There were changes in later 0.10/1.x around liquidity targets; worth confirming the LSP side (Matchstick) shows the pending channel offer while stuck.
Contrast data point: on v0.9.0 (RPi 5, mainnet) I skipped the swap-in funding dance entirely — stock ACINQ JIT setup, zero channels, and POST /createinvoice on 127.0.0.1:9740 hands back a clean bolt11 immediately. The trade is economic, not technical: JIT takes ~1% per receive instead of one upfront swap-in fee. If your goal is plain receiving (payouts, tips), default auto-liquidity is the zero-dance path; your manual pattern only pays off when you're deliberately sizing channels for routing.
Honest caveat from my node: invoice generation is proven, but I haven't pushed a real payment through yet, so end-to-end receive is still unverified on my side.