This is a concept of a non-custodial Lightning Address provider that directs incoming payments to a predefined Liquid address.
It can function independently as a standalone service or serve as a backup for other Lightning address providers. This is particularly useful for services directing incoming payments to mobile nodes that may not always be online.
The service operates as a Lightning Address provider, following these steps when a request for an invoice is received:
- the service initiates a swap on the exchange
- it sends the invoice to the payer, who begins the payment process
- the service awaits the appearance of the swap transaction in the mempool
- upon detecting the transaction, it signs and broadcasts a claim transaction
- the exchange detects the claim transaction, settles the invoice
- the payer observes the successful completion of the payment
All trustless and within a matter of seconds due to the use of zero-conf swaps (refer to security considerations below).
The exchange charges a 0.25% fee for the service, plus approximately 40 sats in on-chain fees.
The exchange imposes limits on the minimum and maximum amounts that can be swapped. Currently, the range is set at 1,000–25,000,000 sats (~0.50–12,000.00 EUR as of February 2024).
During a swap, the service determines the Liquid address to swap to. While it has the potential to replace the user’s address with its own, the impact is minimal as the service can always return an invoice to its own node.
The service employs a zero-conf swap, meaning that once the swap transaction enters the mempool, it promptly signs and broadcasts a claiming transaction. While this opens up the possibility of the exchange attempting a double spend, the service can counteract this by providing proof of the initial swap transaction, what would result in significant reputational damage for the exchange.
Although it is feasible to wait for one confirmation before broadcasting the claim transaction, doing so would introduce additional delays (up to one minute). Additionally, there is the flexibility to choose between a zero-conf swap or not based on the payment amount.
The current implementation reuses the Liquid address, enabling the exchange to learn the amounts and destinations of all payments. Additionally, common ownership of transactions is visible on the Liquid blockchain, but amounts are blinded. The issue can be addressed by utilizing an xpub and generating unique addresses for individual swaps, although if the recipient sweeps all UTXOs in one transaction, common ownership becomes obvious.
- npub.cash: A Lightning-Address powered by eCash and nostr
- Hermes: A Lightning Address Messenger with Fedimint
@startuml
actor "Payer" as payer
participant "Lipa Server" as server
participant "Boltz Exchange" as boltz
participant "Liquid Network" as liquid
activate payer
payer -> server ++: request invoice
server -> server: generate **preimage**,\nhash it to **hash**
server -> boltz ++: init swap with **hash**
return **swap_id**
server -> payer: **invoice**
payer -> boltz ++: send **HTLC**
boltz --> liquid: publish **swap** tx
liquid --> server: observe **swap** tx
server --> liquid --: publish **claim** tx\nwith **preimage**
liquid --> boltz: observe **claim** tx
boltz -> boltz: extract **preimage**
boltz -> payer --: settle **HTLC**
deactivate payer
@enduml