Say where you want it.
The receiver lists supported destinations in preference order. Arkade and Bark stay distinct, with an explicit Bitcoin network.
Bitcoin payments · Hackathon prototypeOne code.
One code.
More ways to pay.
One reusable Bitcoin payment QR. Your receiving preferences. The payer’s choice of route.
Built into Rate with Bark, BOLT12 and LDK over Nostr Wallet Connect. Save where you want to receive, then share one code.
ONE REUSABLE PAYMENT REQUESTConcept preview
Your payment offer
lno1…1ArkadeFirst preference
2BarkNext preference
3LightningFallback
Illustration only · No payable code or connected wallet
The idea
A better payment handshake.
The useful part is the coordination: one request describes the receiver’s preferences, while the payer keeps control of the route and cost.
Find a route that fits.
The wallet checks its capabilities. A direct route may work; another destination may need a quoted swap or Lightning fallback.
Review before paying.
The payer checks the destination, amount and fees. Receiver preference helps rank options; it never authorizes spending.
Interactive walkthrough
Same idea. Different routes.
Choose a scenario to see what changes. These are explanations, not live quotes or automatic capability detection.
Illustrative matching only. A real wallet also verifies the address, server, network, liquidity and fees.
Honest progress
What works. What comes next.
This web app explains the design and decodes offers locally. It does not connect a wallet or move funds.
Understand the payment request
Decode BOLT12 offers, inspect their fields, show the receiver's ordered rails, including Bark and Arkade addresses, check the metadata format and preview Lightning fallback.
Rank explicit capabilities
Recipient-first ordering is available as an option. Existing callers keep direct-first behavior. This is route planning, not proof that a payment will succeed.
Create a real enriched offer
Rate saves receiving preferences and requests an offer through NWC. The updated LDK issuer embeds the ordered rails; the bridge and app reject changed or missing preferences. Amountless issuance and receipt lookup passed an encrypted regtest test.
From preferences to a payment
The receiver imports connected Ark wallet addresses, saves their order and shares a reusable QR. An on-chain destination is carried through BIP321. Real demonstrations need the updated issuer deployment and supported, fee-quoted payer routes. Arkade execution still depends on fee estimation support.
bitcoin++ Berlin 2026
KaleidoPay, in two minutes.
A payment coordination layer inside Rate: receivers express their preferences once; payers choose a supported route without asking for another address.
Receive your way.
Add Bark, Arkade, Lightning or Bitcoin on-chain. Reorder destinations, save defaults and create the reusable QR through an LDK node connected over NWC.
Choose how to pay.
Scan the request in Rate. Review supported direct routes or on-chain swap providers discovered through Electrum’s Nostr protocol. The payer confirms the amount and total fees.
Keep the evidence clear.
The enriched-offer issuance test ran on regtest. Separate Bark ↔ Arkade SDK transfer tests ran on mainnet. They do not yet prove a complete mainnet payment through the enriched-QR flow.
What is new, and what is experimental?
We combine a reusable BOLT12 offer with ordered receiving rails, persistent receiver preferences and wallet-aware route selection. Bark can fund a Lightning payment; a compatible wallet on the receiver’s Bark server can instead use its direct address. Those are distinct routes.
The address-bearing ssps_rails format is an experimental project extension, not an adopted Bitcoin standard. It preserves opaque issuer metadata. Static addresses are not signed per-payment SSPS locks. On-chain receipt uses an address in BIP321.
Award focus: Best use of Bark and Most Based Payment Protocol. This page is an explainer and local decoder; it does not send payments.
Try it locally
See inside an offer.
Paste a public offer or load the synthetic example. Decoding stays in your browser, with no uploads or automatic storage.
Accepts lno1 offers, lightning: links and BIP321 links containing lno. Invoices and invoice requests are not supported.
The example is synthetic and cannot be paid: a reusable offer in the shape Rate issues, ordered Arkade, Bark, on-chain, Lightning, with the real public mainnet server keys of arkade.computer and ark.second.tech and placeholder addresses. Only paste public payment codes, never wallet secrets.
Your offer, explained.
Load the example to explore its rails and fields.
Load the example to explore its rails and fields.
Under the hood: metadata, SSPS and compatibility
offer_metadata is opaque data owned by the issuer. We leave it untouched.
ssps_rails (experimental field 1000000385, SSPS §5.3) is the receiver's ordered list of rails. An entry is a rail id such as btc:mainnet, or a Bark/Arkade rail with the receiver's address, which a wallet on the same server pays directly. Lightning is always accepted. A wallet that ignores the field still pays a normal Lightning offer.
BOLT12 and BIP321: an offer lets a payer request a fresh invoice. A BIP321 payment link can carry that offer alongside an on-chain address. Reuse applies to the offer, not to paying the same invoice twice.