A watermarked, interactive demo of the future BTC/ETH top-up rail — the presentation layer only. No private keys exist on this page, no chain is contacted, and no funds can move. The real rail is pre-launch; read the policy in Paying with Bitcoin.
Everything below is simulated: addresses are visibly fake DEMO-… strings, balances are static numbers, the rate is a frozen fake constant, and payments are a button you press yourself. Nothing here touches the real rail, and no real dollars have ever moved (ground truth F21).
Deterministically generated from documented fixed seed strings (in the page source) — they never change across reloads. The patterns mimic bech32 / hex shapes for familiarity; they are not valid network addresses and cannot hold anything, anywhere.
Pattern only: hashed from the fixed seed qals-demo-btc-2026-09-12 (+ …-m- for the legacy row). No checksum, no network, no private key — the QR encodes the fake text itself, so scanning it can only ever show DEMO-….
Pattern only: hashed from the fixed seed qals-demo-eth-2026-09-12. Not checksummed (EIP-55), not on any chain, no private key. QR holds the fake text, prefix included.
Per the approved design: invoice denominated in AUD, rate locked at invoice time plus a disclosed spread, 15-minute expiry, detection at 0-conf, credit at 1-conf (2-conf above the stated threshold), and an anchored receipt at the end. Here, all of it is a simulation inside this page.
Demo caps (mirroring “caps start small”): per-invoice AU$500 · demo-daily AU$2,000. The real rail enforces caps in the payment bridge, not just the invoice layer.
Pick a coin and an amount, then press Generate demo invoice. Nothing leaves this page — ever.
On the real rail, every receipt is anchored on-chain and records the BTC transaction id — the audit trail links payment to credit forever (policy step 4). This one anchors nothing; it is a picture of the future.
These are the policy, verbatim, from Paying with Bitcoin. The service is built to enforce them, and when the rail is live they are also served by its policy endpoint.
Quoted verbatim — content/btc.md, 2026-09-12. Refunds exist for failed purchases only; this is not a cash-out rail (fees).
From the founder-approved rail design (Part 4). Honest and clearly future: none of this is live — this page is the preview, not the product.
Invoices and payment detection run on infrastructure we own — not a third-party processor, no external custody.
The invoice layer sees inbound payments but holds no key material. There is nothing to steal from it.
The invoice rate is a median of multiple sources locked at invoice time, so no single feed can skew it. (The demo uses one frozen fake number instead — badged as such.)
Stated on the invoice before you confirm. Chain fees come out of the spread (policy #4). The demo shows the 1.5% floor.
The job never ran, the unlock never opened, the top-up errored — checked against the anchored receipt, 14-day window, AUD value guaranteed. Never a cash-out rail.
Per-invoice and daily BTC intake caps, starting small, enforced in the payment bridge — with periodic sweeps of the operational float to cold storage.