BTC in for credit, BTC out for failed-purchase refunds only — pre-launch policy · content/btc.md

Paying with Bitcoin

STATUS: PRE-LAUNCH — the rail is designed and approved, not yet live. No BTC payments are accepted today. This page is published early so the policy can be read and scrutinised before a single satoshi moves. This block is stamped at launch when the rail completes.

Bitcoin becomes one more way to pay for Qals credit — and, in exactly one narrow case, a way to get credit back. BTC is a payment method, not a product. We sell AU$1-backed prepaid credit; Bitcoin is one way to pay for it. We are not an exchange, not a custodian of customer Bitcoin beyond a short operational float, and not a Bitcoin remittance service.

Buying credit with BTC, in plain language

1. You ask for N Qals of credit; the payment bridge creates an invoice denominated in AUD.
2. The BTC amount is computed from a rate locked at invoice time (a median of multiple rate sources, so no single feed can skew it) plus a disclosed spread. The invoice expires in 15 minutes.
3. Payment detection is shown at 0-conf; credit lands at 1-conf for small amounts and 2-conf above a stated threshold.
4. The credit tops up 1:1 with AUD value, and the receipt — anchored on-chain like every receipt in this system — records the BTC transaction id, so the audit trail links your payment to your credit forever.
5. Per-invoice and daily BTC intake caps apply, starting small. Caps are enforced in our payment bridge, not just the invoice layer.

Refunds, in plain language

Refunds exist for failed purchases only — the job never ran, the unlock never opened, the top-up errored. This is not a cash-out rail: general redemption stays services-only by policy (Fees).

• Eligibility is checked against the anchored receipt of the failed purchase, within a refund window (14 days).
• The refund is the AUD value of the failed purchase; the BTC quantity is computed at the refund-time rate, minus our spread.
• Said plainly: if Bitcoin's price rose since you paid, the BTC amount you get back can be smaller than the amount you sent. The AUD value is what is guaranteed — not the BTC quantity. That difference is disclosed here, on purpose.
• Chain fees come out of the spread and are disclosed before you confirm the refund.
• Daily BTC refund caps may delay a refund; every step writes an anchored receipt, so status is always checkable rather than promised.

The five policy statements

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.

1. BTC payments are a convenience. We do not guarantee 100% uptime of BTC transfer capabilities.
2. 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.
3. 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.
4. Chain fees come out of the spread/refund, disclosed before you confirm the refund.
5. Daily BTC refund caps may delay refunds; we'll always communicate status (anchored receipts each step).

Why publish before launch

Because the honesty constraints are the design. The two hard rules — no uptime guarantee, and never a BTC transfer vessel — are easier to hold when they are public before the first invoice exists. The commercial reality is disclosed too: BTC is accepted as a payment convenience, and the spread/refund-time mechanics are part of how the rail pays for itself. None of it is an investment product, and QALS remains non-transferable outside the ecosystem in this phase (F2).

Status: pre-launch design copy, written 2026-09-12 from the founder-approved rail design (11_system_audit/FACT_DISPLAY_AUDIT_2026-09-12.md Part 4). See also: Fees — where money actually moves · Ground Truth · Evidence.