Request
Please consider adding BOLT12 offer support to Mostro as an additional buyer payment destination format.
Why
Today Mostro appears to rely on:
- BOLT11
- Lightning Address / LNURL
- LND + hold invoice architecture
That works, but it makes compatibility dependent on invoice generation or LNURL HTTP reachability. Supporting BOLT12 would improve interoperability with newer Lightning tooling and BIP353-style payment identity.
Suggested scope
- keep existing BOLT11 / Lightning Address / LNURL behavior
- add BOLT12 offer parsing/validation
- allow BOLT12 as a buyer payout destination
- document backend/node requirements and limitations
Key question
Since Mostro currently appears to be built around LND gRPC + hold invoices, is the main blocker that the current backend does not support the needed BOLT12 flow?
I’d be interested in this feature because it would make Mostro easier to use with newer wallets which utilize Breez Liquid SDK (which uses BOLT12) and less dependent on classic LNURL flows.
Request
Please consider adding BOLT12 offer support to Mostro as an additional buyer payment destination format.
Why
Today Mostro appears to rely on:
That works, but it makes compatibility dependent on invoice generation or LNURL HTTP reachability. Supporting BOLT12 would improve interoperability with newer Lightning tooling and BIP353-style payment identity.
Suggested scope
Key question
Since Mostro currently appears to be built around LND gRPC + hold invoices, is the main blocker that the current backend does not support the needed BOLT12 flow?
I’d be interested in this feature because it would make Mostro easier to use with newer wallets which utilize Breez Liquid SDK (which uses BOLT12) and less dependent on classic LNURL flows.