Watermarked interactive demo of the future BTC/ETH top-up rail — no keys, no funds · content/wallets-demo.md
Demo Wallets (BTC/ETH)
STATUS: DEMO — presentation layer only. This page describes an interactive, watermarked demo of the future BTC/ETH top-up rail. It generates no keys, no transactions, no funds. The rail itself is pre-launch: no BTC payments are accepted today. See Paying with Bitcoin for the founder-approved policy this demo illustrates.
Open the demo: ui-codex/wallets-demo.html — every
surface on it is stamped DEMO, corner to card to receipt.
What the demo shows
- Demo wallet cards for BTC and ETH: visibly fake addresses (each one is
prefixed
DEMO-on screen and inside its QR code), static demo balances, and a demo-labelled copy button. No private key material exists anywhere — the "addresses" are hash-shaped strings built from documented fixed seed strings (see the page source comments). - A demo top-up walkthrough: choose BTC or ETH → generate a demo invoice (15-minute countdown, amount in Qals plus demo-coin at a stated fake demo rate, spread line disclosed) → "I paid (simulate)" → confirmation stages (0-conf detection, then 1-conf credit — or 2-conf above the stated threshold) → the credited-Qals animation → an anchored receipt card, watermarked.
- The five policy statements, quoted verbatim from Paying with Bitcoin, on the same page as the thing they will govern.
Qals amounts read 1 Qal = AU$1 of service credit = 1,000,000 doofs (ground truth F6). The demo's invoice math is real arithmetic over fake inputs: the rate is a frozen fake number labelled as such, and the spread is the real rail's disclosed floor (1.5%) so the shape of the invoice is honest even though the money is not.
The five policy statements — verbatim
These are the policy, verbatim. The service is built to enforce them, and when the rail is live they are also served by its policy endpoint.
- BTC payments are a convenience. We do not guarantee 100% uptime of BTC transfer capabilities.
- QALS is not a Bitcoin transfer service. Do not use QALS to move BTC. BTC in is only for buying credit; BTC out is only for refunds of failed purchases.
- Refunds are paid at the AUD value of the failed purchase, converted to BTC at the time of refund at the then-current rate minus our spread. If BTC's price changed since purchase, the BTC amount you receive may be lower than what you paid in.
- Chain fees come out of the spread/refund, disclosed before you confirm the refund.
- Daily BTC refund caps may delay refunds; we'll always communicate status (anchored receipts each step).
Demo vs real — the honest table
| Surface | In the demo | With the real rail (coming) |
|---|---|---|
| Addresses | DEMO--prefixed fake patterns from fixed seed strings; QR codes contain the fake text |
Invoice addresses generated by a self-hosted BTCPay Server from a watch-only xpub |
| Balances | Static numbers, labelled demo | Your Qals credit balance in the wallet, 1:1 with AUD value |
| Rate | One frozen fake number, badged "DEMO RATE — not a market feed" | Median of 3 rate sources, locked at invoice time |
| Spread | 1.5% shown on every invoice (demo floor) | Disclosed 1.5–2%, stated before you confirm |
| Payment | A "simulate" button you press yourself | Payment detected at 0-conf; credit at 1-conf (2-conf above the stated threshold) |
| Receipt | Watermarked demo receipt card | Anchored on-chain receipt recording the BTC txid — the audit trail forever |
| Refunds | Not demoed (nothing to refund) | Failed purchases only, AUD value guaranteed, 14-day window, daily caps |
What the real implementation uses — coming with the rail
- BTCPay Server, self-hosted — invoice generation and payment detection on infrastructure we own, not a third-party processor.
- Watch-only xpub — the server can see inbound payments but holds no key material; nothing to steal from the invoice layer.
- Rate oracle, median-of-3 — no single feed can skew an invoice rate.
- Disclosed 1.5–2% spread — stated on the invoice before you confirm; chain fees come out of it (policy #4).
- Refunds = failed purchases only — never a cash-out rail; general redemption stays services-only (Fees).
- Cold sweeps + intake caps — per-invoice and daily caps starting small, enforced in the payment bridge, with periodic sweeps to cold storage.
None of this is live. No real dollars have moved (ground truth F21) and no BTC invoice has ever existed. The demo exists so the shape of the future rail can be inspected before the first satoshi moves — the same reason the policy was published first.
Source: the founder-approved rail design (Part 4, 11_system_audit/FACT_DISPLAY_AUDIT_2026-09-12.md) and Paying with Bitcoin. Demo page built 2026-09-12. See also: Ground Truth · Fees.