Sovereign Pay — QR Edition 1.3 — User Guide

QR Edition 1.3 provides reviewed QR input for structured payment and offline-signing workflows. It supports ordinary addresses, lists, bitcoin: payment requests, a deliberate single-WIF scan, key-free signing packages, returned signed transactions, and non-secret multipart TKQR1 transfer. Public Preview.

Choose the appearance you prefer. Light, Obsidian Vault, and Aurora Glass have identical payment, signing, network, and QR behaviour. Only their visual themes differ. Light is the recommended default for general reading conditions.

Prefer the original compact interface? QR Edition 1.2 remains an active expanded-QR release with the same payment and signing QR capabilities. Open QR Edition 1.2 or read its exact-edition manual.

Read Choose Your Tool and Work Safely. Use QR Edition 1.0 or Standard Edition when the expanded features are unnecessary.

Know where your copy came from. If you opened this manual through the official Sovereignty Tools page at BSVSearch.com, you are using our recommended current entry point. Extra verification is most important when an application or manual was received through another person, email, messaging, phone transfer, cloud storage, a USB drive, another website, or a similar channel. In that situation, open a fresh copy through the official page, retrieve the published document from the BSV Blockchain using the TXID listed there, or compare the received file's SHA-256 with the published value before entering a private key or using funds. See When to verify a received file for Windows and macOS instructions.

The ordinary payment flow

1. Enter or scan source addresses and find confirmed, currently spendable coins. Pending incoming, already-moving, duplicate, and uncertain outputs are excluded.
2. Enter or scan the destination and amount. A bitcoin: request may suggest an amount and note; review each value before applying it. Unsupported required parameters, schemes, or addresses are rejected.
3. Confirm change, the separate 0.01% Sovereign Pay fee, and the network miner fee.
4. Decide whether notes should be public. Embed notes on-chain is off by default. Leave it off unless public, permanent disclosure is intentional; tick it only before signing a transaction whose note you want embedded.
5. Enter keys only on a trusted device, accept the applicable risk and privacy notices, and sign.
6. Review every field decoded from the signed bytes. Editing a plan/source field invalidates the affected result and requires another review and signature.
7. Send only when correct. The built-in sender rechecks inputs and compares the provider-returned ID with the locally computed transaction ID.

Scan review is mandatory

QR content is parsed, validated, summarized, and shown for confirmation before a field changes. A checksum or valid address proves structural consistency, not who created the content or who owns the destination.

Live camera access and locally stored files

The camera starts only after a camera action. Chrome, Edge, and other browsers may withhold live camera access when a downloaded HTML file is opened directly from a phone's local storage. This is a browser or page-context restriction; it does not disable image-based QR reading. If it occurs, choose a QR image, enter the information manually, or open the exact verified file with a trusted application that permits live camera access. See Live camera access for locally stored HTML files.

An imported image remains sensitive. Do not photograph or retain a private-key QR merely to work around a camera restriction: the image may remain in the gallery, device backups, or cloud storage.

Private-key QR boundary

A WIF QR is the private key. Any camera, screenshot, photo, printout, screen recorder, or observer that captures it may gain control of the coins.

This release accepts a private key only through a deliberate single-QR review on a trusted offline device. It rejects a private key reconstructed from multipart TKQR1 frames, including a key hidden inside a larger multipart list. Multipart plaintext-WIF transport is not supported in this edition.

Delete or physically destroy temporary key images and printouts. Do not scan a WIF QR on a networked or observed device.

Key-free offline signing package (SPPK1)

1. Online device: create a signing package containing the intended public inputs, payments, change address, fee settings, and note setting. It contains no private key.
2. Offline device: import the package, review every destination, amount, note, change address, and fee, then enter the WIFs and sign.
3. Online device: import the returned signed transaction into the copy that holds the original plan. Verify it before sending.

The package's SHA-256 checksum detects accidental corruption. It does not authenticate the creator or recipient. An attacker who can change the package can create a new checksum. Confirm destination and amount through a trusted channel on the offline device.

Returned signed-transaction verification

QR Edition 1.3 requires the original plan and compares the returned transaction with it before enabling its send action. It verifies the expected inputs, ordered outputs, amounts, notes, change, tool-fee destination, miner fee, transaction structure, and every input signature.

This verification protects the online/offline round trip only when the original plan is still loaded and the user carefully reviews that plan. It does not prove the recipient's real-world identity or make a compromised device trustworthy.

Multipart TKQR1 transfer

Large non-secret payloads can be split into BRC-225 TKQR1 frames and scanned in any order. The collector rejects inconsistent sets, waits for every part, and checks the reconstructed payload tag before use.

TKQR1 provides transport framing and corruption/mixed-set detection. It provides neither origin authentication nor confidentiality. Do not use it for plaintext private keys, mnemonics, credentials, or other secrets.

The current application enforces a maximum of 200 parts and 160,000 payload bytes. These are implementation safety limits, not a reason to transfer more information than needed.

Journal, Pay Page, and external submission

The CSV journal neutralizes spreadsheet-formula prefixes but still exposes sensitive transaction records. Store it accordingly.

Configured Pay Pages use client-side guardrails rather than cryptographic locks. Payers must verify the decoded transaction.

If signed hex is submitted outside the built-in returned-transaction workflow, the external path does not automatically inherit QR Edition 1.3's original-plan verification or pre-submission provider checks.

Status, licence, and credits

Provided as-is without warranty. This source-visible Public Preview was originally developed by BSVSearch.com. Embedded Project Nayuki-derived QR encoder material and jsQR 1.4.0 retain their respective licences; WhatsOnChain and Bitails are independent services. “QR Code” is a registered trademark of DENSO WAVE Incorporated.

See the shared Technical and Safety Appendix. Current versions, hashes, transaction IDs, and advisories: https://bsvsearch.com/sovereigntytools.web3.