I've been working on BOLT12 Pay.
It’s a self-hosted Lightning payment and identity server designed for Umbrel.
Features:
- BOLT12 offers (via LNDK)
- Lightning Address (BIP353 + LNURL)
- BOLT11 fallback
- Nostr identity (NIP-05) + zaps
- Mobile-friendly payment pages
The goal is to make modern Lightning standards usable today while keeping everything self-hosted.
Would love feedback or ideas for improving interoperability.
Thoughts on making an additional geyser goal for adding the project to Start9/StartOS? With StartOS v0.4.0 allegedly making it easier to expose certain services to clearnet, it might be a good match for BOLT12 Pay
Start9 app is on the roadmap and will be shipped soon!
Bolt12 is just Tor slop pushed by the irrelevant implementations that went full retard on mobile nodes, shame that Lightning Labs might be capitulating to that nonsense... It's inherently unusable, no one is going to deploy wasm to web pages just to transport invoices slowly and unreliably
Use CLINK instead, does everything Bolt12 does and more, but over Nostr so it actually works where it's needed
I am curious to see LND 0.21 that supposedly will support bolt12 natively.
Yes then i will switch Bolt12pay to nativ support and get rid of lndk server integration. Nevertheless you will remain to have a very powerful bundle.
It will be a revolution as LND has around 90% of the market, think about many folks mining and using not their own nodes to receive sats when using pools like ocean. And also many folks on nostrs not using their own nodes to zap because of not having bolt12 integrated.
You perfectly can receive zaps in a non custodial way and create numerous lightning addresses for mining et cetera. Also use alby hub for nwc for sending zaps...until I will integrate nwc soon.
but always using another server, or alby that asks for an email address afaik
you can run alby hub without an alby account! There also in an nwc app in the alby umbrel community app store. So no, you don't need kyc.
ok, that's new to me. Anyway native bolt12 will make thing simpler for IQ 80 like me.
Yes I am hoping to get into the official app store on umbrel as well.
deleted by author
not to be rude, but from my admittedly slender knowledge of LN tech, what you are doing has been largely solved by the shocknet boys
https://github.com/shocknet
this thing does not even install on my umbrel...
Curious how people see BOLT12 adoption evolving — still too early or already usable?
BOLT12 is just a useless marketing campaign, run by few people pushing this useless bolt.
BOLT12 is totally useless, you are not going to pay a merchant to a BOLT12 offer... cmon, any merchant is a PUBLIC FACE FFS!
What is more necessary are blinded path routing. but seems that people have no idea what is that... #1461422
Let's stop this bullshit madness with BOLT12, it doesn't serve to anything.
And all you describe is just a... BOLT11 fallback and LN address. So all for nothing.
try it and you will see that it actually creates real offers and uses blinded paths.
I think you're mixing two things here.
A lot of BOLT12 discussion is indeed theoretical — agreed.
But this project is explicitly about testing real-world usage using LNDK, including actual offers and blinded paths, not just wrapping BOLT11 behind LNURL.
Also, merchants don't have to expose a static public invoice endpoint — that’s exactly where offers + blinded paths can change UX and privacy assumptions.
Totally fair to be skeptical, but dismissing it as “useless” ignores what’s actually being implemented and tested here.
Happy to go into specifics if you're interested.
Hosted like a parasite teehee
GitHub repo for those interested in the technical details:
https://github.com/Alex71btc/lndk-pay
https://github.com/Alex71btc/umbrel-community-store.git
Happy to answer technical questions about LNDK, BOLT12 or Lightning Address implementation.
this is the stack i'd actually want to build on. the combo of BOLT12 offers + LN Address + NIP-05 in one self-hosted package removes the biggest friction: "how do i receive payments and prove who i am without a custodian in the middle?"
i run a NIP-05 identity and Lightning address through flashapp.me, so i can receive zaps and payments — but i'm dependent on that infrastructure staying alive. a self-hosted equivalent where i control the keys and the routing is the real endgame.
curious about the blinded path / BOLT12 receive side specifically: when you issue a BOLT12 offer through LNDK, what's your fallback strategy if the payer's wallet only speaks BOLT11? the BOLT11 fallback you mention — is that automatic offer-to-invoice negotiation or does it require the sender to explicitly request it?