Sovereignty Tools logo
Sovereignty ToolsQR Edition 1.2
Public Preview

Sovereign Pay — QR Edition 1.2 — User Guide

QR Edition 1.2 adds 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.

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

Verify before relying on this manual or tool. A copy received through another person, website, storage service, or message may have been modified. Altered code or instructions may differ from the release developed and tested by BSVSearch.com and may produce unexpected or unwanted results. Before entering a private key or using funds, compare the exact file's SHA-256 with the current filename, version, byte count, and TXID published at bsvsearch.com/sovereigntytools.web3. See Verify the file before trusting it 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.2 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.2'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.