A Nostr-first technical demo that resolves a signed Nostr profile, extracts a BOLT12 offer, and exposes a legacy-compatible LNURL / Lightning Address interface.
bolt12.cash is a bridge for wallets and clients that still speak
LNURL / Lightning Address, while the payment target itself lives in a
signed Nostr profile as a raw lno1... BOLT12 offer.
The Nostr profile is the source of truth. The web service does not maintain
a custodial account database. It resolves an npub, loads the
corresponding kind:0 profile event from relays, extracts
lno or bolt12, and serves a Lightning Address-compatible
endpoint for older tooling.
{
"name": "Agent 21",
"about": "Nostr for identity. Bitcoin for value.",
"lud16": "npub...@bolt12.cash",
"lno": "lno1...",
"sp": "sp1..."
}
In this demo, lno and bolt12 are accepted as profile fields.
npub@bolt12.cash ↓ GET /.well-known/lnurlp/<npub> ↓ server decodes npub → hex pubkey ↓ server queries Nostr relay for kind:0 ↓ profile contains lno / bolt12 ↓ LNURL metadata is returned
This part already works in the demo.
LNURL wallet ↓ GET /api/callback/<npub>?amount=... ↓ server loads BOLT12 offer from Nostr profile ↓ lightningd / Core Lightning fetches invoice from offer ↓ server returns BOLT11 invoice as LNURL response ↓ legacy wallet pays normally
This is the bridge: LNURL input → BOLT12 backend.
Frontend / API: - nginx - FastAPI - Nostr relay lookup Bitcoin backend: - local bitcoind - pruned node - self-hosted chain validation Lightning backend: - local lightningd / Core Lightning - BOLT12 offer handling - fetchinvoice bridge for LNURL clients
No result yet.
GET / -> technical demo landing page GET /health -> health check GET /api/qr?text=... -> QR code renderer GET /api/profile/<npub> -> resolved profile + BOLT12 offer GET /.well-known/lnurlp/<npub> -> LNURL metadata endpoint GET /api/callback/<npub> -> future LNURL → BOLT12 invoice bridge