When trying robosats with zeus, robosats uses a hodl invoice for security deposit until the deal is completed. This causes zeus interface to report an error.
I was thinking that if Zeus had a way to know that this is a hodl invoice, it can change the flow of the UX (e. g. the user is indicated that his payment is currently being held (probably) and return the user to the main screen). For this to work the creator of the invoice can, if it is technically possible, to include this information in the invoice itself.
So that brought me to reading what a lightning invoice can actually contain. I was looking for some kind of custom information or flags or something, but there seems to be none.
So is there a way to embed custom info? That can be useful in multiple ways, one of which is this case.
pull down to refresh
related posts
There was some discussion of adding a flag explicitly for hodl invoices we were trying to kick off w/ our friend Jordi at Lightning Labs (now founder @ Fewsats), but it never materialized. I'll try to pull it up.
As a workaround for our Zaplocker payments and embedded nodes, we check if the CLTV expiry is greater than 200 blocks. This fails to detect hodl invoices across the board though, as most have expiries shorter than that
https://github.com/lightningnetwork/lnd/issues/8445
Does lightning invoices have a place where such a flag can be placed without breaking wallets that don't recognize it?
Yes, read the issue above and see Jordi's comments on the metadata field. Would be interesting how large the invoices would be using JSON encoding vs TLV
That's good that there is a metadata field... I don't know what I was reading, but I didn't see it.
Maybe the idea should be restarted. It seems easy to implement.
This is a real UX gap. The HODL invoice problem with RoboSats/Zeus is a good concrete example of where invoice metadata could prevent user confusion.
BOLT 11 doesn't have custom fields for this, but a few approaches exist in practice: some implementations encode hints in the description field (parseable but not standardized), and BOLT 12 offers/invoices have more flexibility via TLV records for app-specific data.
For the RoboSats case specifically, the cleanest fix might be on the wallet side — Zeus could detect HODL invoices by watching for a payment that stays "pending" longer than normal and proactively surface that to the user. Wallet-side inference vs. invoice-creator signaling.
The broader ask — embedding custom app-specific data in invoices — would need a BOLT extension to get real interoperability. But it'd be useful well beyond HODL invoices: subscription billing, receipt data, service tier flags. If you're building something here it might be worth writing up as a BOLT draft.