Non-custodial Lightning ↔ Onchain swaps. Routed to Electrum swap servers discovered via Nostr.
Experimental software — use small amounts first. Swaps are non-custodial; keep your swap file.
You want onchain sats but have Lightning liquidity. You generate a preimage, hash it, and give the hash to the provider along with a claim public key from your onchain wallet. The provider creates a Lightning invoice — you pay it — and then locks onchain funds in an HTLC spendable with your preimage + claim key (refundable to the provider after a timeout). You claim the onchain output with your wallet; the provider sees your preimage in the mempool and settles its side.
You want Lightning but only have onchain sats. Phase 1 gives you a lockup address, an amount, and a preimageHash. You create a hold invoice in an electrum wallet keyed to that hash (phase 2). After you send the onchain amount and it confirms, the provider pays your hold invoice and claims the lockup by revealing the preimage onchain — your wallet then settles the held payment. If the provider never claims, your key refunds the funds after the timeout block.
Simple — paste any invoice. You paste ANY Lightning invoice from ANY wallet and send onchain. That is the Boltz-style flow: Boltz itself takes the hash from your invoice, builds the lockup, pays your invoice, and claims. Our providers speak the newer Electrum protocol where the provider picks the hash and the invoice must match it — so in Simple mode the BRIDGE runs that hash-matched leg for you in its own wallet: it registers the swap-side invoice, and when the provider’s onchain claim reveals the preimage, the bridge settles its invoice and pays yours.
What Simple mode assumes: the bridge is honest. It sees your invoice (amount and payee), and after the provider claims it could in theory withhold your Lightning payment — detectable, because the provider’s claim is public onchain. What it can never do is steal your onchain coins: your refund key is generated in THIS browser, saved only to your swap file, and the lockup pays back to you alone after the timeout block (the “Refund now” button uses it). If the bridge disappears or turns malicious: worst case is a delayed or missing Lightning payment while your onchain funds sit safely in the HTLC until you refund them — never lost, only delayed.
Trustless — hold invoice. You create the hash-matched invoice yourself and the bridge only relays bytes; it learns nothing about you and is removed from the trust set entirely. The “hold” is not special magic: the payment hash is the contract. Any invoice keyed to the swap hash necessarily behaves as a hold invoice, because only the provider’s onchain claim can ever reveal the preimage your wallet would need to settle. The cost: you need tooling that can create an invoice for a hash you did not generate (Core Lightning’s hold plugin or Electrum’s add_hold_invoice — both shown in phase 2).
What NO mode removes — the provider’s pay-after-claim promise. In this protocol direction the provider generates the preimage at swap creation, so nothing cryptographically forces it to pay the registered invoice before claiming your funded lockup. That is an honesty assumption about the provider, present in both modes (it is what the operator blocklist polices, and why you should prefer funding only after the provider’s payment has parked at the invoice — a parked payment cannot be revoked, and the claim that reveals the preimage settles it in your favor; the funding banner tells you which state you are in). Your hard guarantees stay: the refund key is yours alone, so a provider that never claims loses its leverage at the timeout and you refund in full; a provider that claims without paying is publicly detectable and gets blocklisted.
Both swap types share the same Hashed Time-Lock Contract structure. It is a Bitcoin Script that releases funds conditionally — this is what makes the swap non-custodial and trust-minimized.
Swap providers announce themselves on Nostr relays using NIP-33 parameterized-replaceable events of kind:30315. Each announcement carries an Electrum server endpoint, fee schedule, and a proof-of-work commitment. This Worker queries those relays on a schedule, filters by network (signet/mainnet) and minimum PoW, and caches the sorted list in Cloudflare KV.
timeoutBlockHeight.redeemScript and timeoutBlockHeight. Decode them locally before sending funds.Experimental software. Use small amounts first. Swaps are non-custodial but the Worker itself is untested in production. No warranty; you assume all risk.