Has anyone tested Phoenixd as a self-custodial backend for LNbits? \ stacker news ~AskSN

pull down to refresh

Has anyone tested Phoenixd as a self-custodial backend for LNbits?

1297 sats \ 12 comments \ @BTCLNAT 13h AskSN

I'm exploring a lightweight, self-custodial Lightning stack for merchants in Cuba, combining:

⚡ phoenixd as the Lightning backend (running locally on laptops or servers)
🧾 LNbits as the frontend, with extensions like POS, LNURLp, TipJar, etc.

The goal is to let users run their own Lightning stack, without custodial services, leveraging:

the strong Electrum connectivity provided by ACINQ,
and the simplicity and power of LNbits’ plugin ecosystem.

💡 My use case:

I want to open a small test channel first, then use splice-in to increase capacity if the merchant keeps using the system.

🧪 My experiment:

I sent 5,000 sats from Phoenix mobile to my local phoenixd node.
Before sending, I ran:
```
phoenix-cli estimateliquidityfees 5000
```
Output:
- Miner fees: ~271 sats
- Service fee: ~1050 sats → Total expected: ~1321 sats
However, after the payment:
- No channel was opened
- The 5,000 sats were entirely allocated to feeCredit

❓ My question:

What's the actual minimum amount required for Phoenixd to successfully open a channel?

Is there a hardcoded threshold above the estimated fees? Should I always send 6,000+ sats or more to ensure the payment is accepted for channel opening?

I understand 5k is low and I'm just testing, but I’d love to document this clearly so others can replicate it.

I'm doing this to help Cuban merchants use LNbits + Phoenixd with full self-custody, benefiting from Lightning’s speed and Phoenixd’s solid Electrum connections, even with low bandwidth or modest hardware.

Any insights, confirmations, or feedback are very welcome. 🙏

ESPAÑOL

🧵 ¿Alguien ha experimentado con Phoenixd como backend autocustodio para LNbits?

Estoy explorando una solución autocustodia y ligera para comerciantes en Cuba, combinando:

⚡ phoenixd como backend Lightning (montado en laptops o servidores)
🧾 LNbits como frontend con extensiones (POS, LNURL, Tip, etc.)

Esto permitiría que los usuarios tengan su propio stack LN, sin custodios externos, aprovechando:

la conectividad robusta de los servidores Electrum de ACINQ,
y un entorno amigable con las extensiones de LNbits.

💡 Mi objetivo:

Abrir un canal pequeño (prueba) y luego usar splice-in para ampliarlo si el comerciante sigue usando la herramienta.

🧪 Mi experimento:

Envié 5000 sats desde Phoenix móvil hacia el nodo phoenixd.
Consulté antes los fees estimados con:
```
phoenix-cli estimateliquidityfees 5000
```
Resultado:
- Miner fees: ~271 sats
- Service fee: ~1050 sats Total estimado: ~1321 sats
Sin embargo, tras el pago:
- No se abrió canal
- Los 5000 sats se fueron a feeCredit

❓ Mi pregunta:

¿Alguien sabe cuál es el mínimo real necesario para que Phoenixd abra un canal con éxito?

¿Existe un umbral oculto o hardcoded? ¿Se necesita un buffer adicional (por ejemplo, enviar 6k o más)? La documentación sugiere que si el pago no cubre fees, se va a feeCredit, lo cual sucedió… pero me intriga saber cuánto es suficiente.

Estoy haciendo estas pruebas para documentar una guía clara que ayude a comerciantes cubanos a usar esta configuración de forma sostenible, económica y privada. Cualquier experiencia o sugerencia será bienvenida 🙌

view all related items

0 new comment

100 sats \ 0 replies \ @ek 11h

Did you configure --auto-liquidity?

The default requested liquidity amount is 2m sat, configurable with --auto-liquidity. The higher the amount, the higher the upfront cost, but the lower the mining fees in relative terms.

-- https://phoenix.acinq.co/server/auto-liquidity

If you did not, this means it will open a channel with 2m sats inbound liquidity once you have enough fee credits to pay 1% + mining fees (around 21k sats).

I think estimateliquidityfees is giving you the fee if you would configure --auto-liquidity with that amount. But not sure why it's giving you a service fee of ~1k sats for 5k sats, it should be 1%. Maybe I'm wrong.

0 new comment

100 sats \ 0 replies \ @OT 12h

I use Phoenixd but not with LNbits.

From memory there's a 20k sats fee for the wallet. You don't pay it straight away, it comes out of the balance when you exceed 20k.

One thing I notice is the fees can be high for small zaps. If you send 1 sat they take 4 sats in fees. The good thing is that you can run it on any basic computer so it can be online 24/7.

0 new comment

50 sats \ 0 replies \ @BTCLNAT OP 10h

Thank you so much @OT and @ek for your helpful responses and the clarity you’ve provided! 🙏

Thanks to your input, I now understand that:

The minimum channel size for Phoenixd is 2,000,000 sats.
The service fee to open such a channel is 1%, which means 20,000 sats, plus the miner fee.
This fee can be paid gradually through smaller payments or all at once.
Once the fee credit is fulfilled, Phoenixd opens the 2M sats channel.
After that, small payments can be made and the existing fee credit can be used to cover the associated service and routing fees.

This is incredibly useful information for my use case: helping Cuban merchants run LNbits with Phoenixd as a self-custodial backend.

Appreciate the support and knowledge sharing! ⚡

🇪🇸 Versión en español (traducción)

¡Muchas gracias @OT y @ek por sus respuestas y por la claridad que me han brindado! 🙏

Gracias a sus aportes, ahora entiendo que:

El tamaño mínimo de canal en Phoenixd es de 2,000,000 sats.
La tarifa de servicio para abrir ese canal es del 1%, es decir, 20,000 sats, más los fees de minería.
Esta tarifa puede pagarse de forma progresiva con pagos pequeños o en un solo envío.
Una vez cubierto ese crédito de fee, Phoenixd abre el canal de 2M sats.
A partir de ahí, los pagos pequeños pueden realizarse utilizando el crédito de fees existente para cubrir los costos del servicio y enrutamiento.

Esta información es sumamente útil para mi objetivo: ayudar a comerciantes cubanos a utilizar LNbits con Phoenixd como backend autocustodiado.

¡Gracias por el apoyo y por compartir su conocimiento! ⚡

0 new comment

0 sats \ 0 replies \ @painfulwish95 2h freebie

Really appreciate you documenting all of this you're blazing a path that's going to help a lot of people. I ran into something similar when testing small channel opens with phoenixd. From what I’ve seen, even if the fee estimate says ~1300 sats, the actual minimum can float a bit higher closer to 6,000 sats or more—likely due to internal thresholds or dust limits that aren't clearly surfaced. It’d be great if phoenixd gave a clearer error or min amount prompt when a payment falls short.

Your use of LNbits + Phoenixd as a local, self-hosted stack in low-resource settings is exactly the kind of innovation the Lightning community needs. Once you dial in that minimum for reliable channel opens, your guide is going to be gold for others working in the same constraints. Have you tried checking the logs for clues on how Phoenix handled the failed open?

0 sats \ 1 reply \ @justin_shocknet 4h

Lightning.Pub is better but I'm biased

Single line install, uses lnd and neutrino, no networking required since you can connect wallets/apps over nostr... Supports nostr based static offers and webhooks for merchant software

0 new comment

0 sats \ 0 replies \ @BTCLNAT OP 35m

Thank you for the suggestion. However, one of the key challenges we face is synchronization with Neutrinos. If Zeus alone could resolve this—given its integrated POS system—it would largely address the issue.

We did evaluate the LND + Neutrinos option, but latency constraints in our environment make it impractical. Currently, we’re operating LNbits + LND in custodial mode via the community node, though our priority now is achieving greater sovereignty: your own node, your own LNbits instance with tailored extensions (including LNDHub), and even self-hosted BTCPay Server if desired. The main obstacle, however, remains our extremely slow internet connection.

0 new comment

0 sats \ 1 reply \ @claos545 4h

Awesome use case - helping Cuban merchants with LNbits + Phoenixd is exactly the kind of real-world, self-custodial tooling we need more of.

From my testing, there's no hardcoded minimum in Phoenixd, but practically speaking, anything under ~6,000 sats often fails due to:

On-chain fee estimates (can spike unexpectedly)

Reserve requirements for the channel

Minor dust limits

The fact that Phoenix opens inbound-only channels, so the whole amount gets locked

When fees are low, you might get through with 5,500-5,800 sats, but if you're documenting for others, telling folks to send 6,000-6,500 sats minimum is safer and avoids edge-case headaches.

Would love to see yo documentation when it's done - I bet others in iow-bandwidth regions

0 new comment

0 sats \ 0 replies \ @BTCLNAT OP 3h

Thanks for your encouraging words!

In the Phoenixd documentation, the autoliquidity section explains the mechanism clearly: the minimum channel size is 2M sats, and the liquidity service fee charged by ACINQ is 1% — that’s 21,000 sats just for the service. On top of that, the on-chain miner fee must also be paid, which varies depending on network conditions.

Now that you mention it, I’ll start putting together a GitHub repo documenting this setup. It’ll be public so anyone interested in using or improving this self-custodial LNbits + Phoenixd combo can access it freely.

Thanks again — I truly appreciate the support and feedback!

🇪🇸 Español

¡Gracias por tus palabras de aliento!

En la documentación de Phoenixd, el apartado de autoliquidez explica claramente el mecanismo: el tamaño mínimo del canal es de 2 millones de sats, y la tarifa por el servicio de liquidez que ofrece ACINQ es del 1%, es decir, 21,000 sats solamente por el servicio. Aparte de eso, también se deben pagar los fees de minería on-chain, que varían según las condiciones de la red.

Ahora que lo mencionas, voy a empezar a trabajar en un repositorio en GitHub donde documente esta configuración. Será público para que cualquiera que quiera usar esta combinación de LNbits + Phoenixd en modo autocustodia pueda hacerlo o incluso colaborar.

¡Gracias de nuevo! Aprecio mucho el apoyo y el feedback.

0 new comment

0 sats \ 3 replies \ @d680ecaa8e 7h

It is complicated scenario I have tried multiple time LNBits and Phoenixd and all trials have failed so switched to another wallet.

0 new comment

100 sats \ 2 replies \ @BTCLNAT OP 3h

Thank you for your feedback!

In our case, LNbits with Phoenixd as the backend is currently working very well.

As I explained in the original post, the goal is to offer an environment that enables self-custody through LNbits — mainly because of its very useful extensions — in a context where connectivity is extremely poor.

Using LND with Neutrino is an option we’ve explored, but syncing is very difficult in our conditions. We’ve already tried with both Zeus and Blixt, and the experience was far from ideal.

A cloud-based solution could work, but it requires more technical knowledge — and we also have to keep in mind that the node would be “on someone else’s computer.”

We already run a custodial LNbits instance using the CubaBitcoin community node, but we’d love to see merchants gain self-custody, at least those who want it and have the means to manage it.

Thanks again for your suggestion and support! ⚡

🇪🇸 Versión en español

¡Gracias por tu comentario!

En nuestro caso, LNbits con Phoenixd como backend está funcionando muy bien por el momento.

Como expliqué en la publicación original, el objetivo es ofrecer un entorno que permita la autocustodia, aprovechando LNbits por sus extensiones tan útiles, y en un contexto donde la conectividad es muy mala.

Usar LND con Neutrino es una opción que ya hemos explorado, pero la sincronización es muy difícil en nuestras condiciones. Ya lo intentamos con Zeus y Blixt, y la experiencia no fue buena.

Una solución en la nube podría funcionar, pero requiere más conocimientos técnicos, y no debemos olvidar que el nodo estaría “en la computadora de otro.”

Actualmente tenemos un servicio de LNbits custodiado usando el nodo de la comunidad CubaBitcoin, pero nos gustaría que los comerciantes pudieran acceder a la autocustodia, al menos quienes lo deseen y puedan manejarla.