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.
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.