Sovereignty Tools — Technical and Safety Appendix

This shared public reference explains the safety boundaries and technical identities behind Sovereign Keys 1.0 and the three Sovereign Pay editions. Ordinary users should begin with the exact edition guide. Public Preview.

What “self-contained” means

Each application is one HTML file with its runtime code, styles, and required cryptographic components embedded. It does not load external runtime scripts, fonts, stylesheets, or images.

Sovereign Keys 1.0 has no application network-call or browser-storage feature. Sovereign Pay signs locally but uses configured independent network providers only after explicit actions to find public UTXOs or submit an already-signed transaction. Loading the current public HTML files produces no automatic external request.

Self-contained does not mean invulnerable. A modified file, compromised device, malicious extension, unsafe clipboard, camera, printer, or operating system can still expose information or alter what the user sees.

Direct private-key handling

Sovereign Keys and Sovereign Pay deliberately support direct WIF workflows. This gives an expert user a standalone signer without a wallet service, but it also concentrates key exposure in the page and device.

BRC-100 describes a wallet-to-application architecture in which wallet capabilities, permissions, and keys are separated from ordinary applications. Sovereign Pay's direct-WIF mode is not a BRC-100 wallet interface. Direct WIF handling is an expert, offline-first workflow. Less-experienced users should not use it unless they understand the key-exposure risks and can operate on a trusted offline device.

Fee and change transparency

Sovereign Pay adds one basis point—0.01%—of the amount sent as a separate tool-fee output, rounded upward to a whole satoshi. A positive payment therefore has a minimum tool fee of one satoshi. The separate miner fee is estimated from transaction size and the selected rate.

The interface shows payments, the tool fee, change, and miner fee before signing and decodes them again from the signed bytes. Users must verify the change address. Input value not assigned to another output becomes miner fee.

The source-visible licence requires the product identity, attribution, and fee mechanism to be preserved in licensed copies. That is a licence boundary, not a claim that source code is technically impossible to edit. Modified bytes have a different SHA-256 and are not the reviewed release.

Address and package integrity are not identity

A Base58Check address checksum detects many transcription errors; it does not prove the address belongs to the intended recipient.

An SPPK1 package uses an unkeyed SHA-256 checksum over its normalized public plan. It detects accidental corruption but does not authenticate the package creator. A malicious author can change the destination and calculate a new checksum. Verify critical payment details through a trusted channel on the offline signer.

Notes and journals

Embed notes on-chain is off by default in the current Pay applications. When deliberately enabled before signing, note text is included in OP_RETURN outputs; if the transaction is mined, that content may be public and permanent. Leave the option off unless public, permanent disclosure is intentional.

Downloaded journal CSV files apostrophe-prefix cells beginning with =, +, -, @, tab, or carriage return before ordinary CSV quoting. This prevents common spreadsheet formula/DDE interpretation of attacker-influenced text. It does not make an untrusted CSV file generally safe or remove the privacy risk of storing transaction records.

Coin selection and network submission

Online lookup includes only confirmed outputs not reported as already being spent by a pending transaction. Duplicate outpoints and unsafe or uncertain results are excluded. Pending incoming and outgoing amounts are reported separately.

For a transaction produced in the active page, the built-in send action checks every input immediately before submission and rejects a provider-returned transaction ID that differs from the locally computed ID. These checks do not guarantee miner acceptance or confirmation.

Copying signed hex to an external submission service bypasses the tool's built-in submission checks. Standard and QR 1.0 also lack QR 1.2's returned-transaction exact-plan verification.

Transaction construction and verification

The Pay tools produce version-1 P2PKH transactions using deterministic ECDSA signatures over secp256k1. Signatures use canonical low-S DER form and BSV sighash ALL|FORKID (0x41). Each new input signature is verified before a signed result is displayed.

The result preview is decoded from the signed transaction bytes. A changed destination, source, payment, note, change, or fee setting invalidates the visible signed result. Clearing the WIF field after signing intentionally does not discard the verified transaction, so the key can be removed promptly.

QR Edition 1.2 additionally verifies a returned signed transaction against the original loaded plan and every input signature before enabling its returned-transaction send action.

QR transport boundaries

QR Edition 1.0 accepts one validated mainnet address per scan into approved address fields only.

QR Edition 1.2 can accept additional structured content, but every scan is reviewed before application. A single WIF QR is accepted only through an explicit warning and review. Plaintext private keys reconstructed from multipart TKQR1 are rejected.

BRC-225 TKQR1 is an animated/multipart transport for arbitrary bytes. Its payload tag supports set consistency and corruption detection but is truncated and unkeyed. TKQR1 provides neither authentication nor confidentiality; sensitive payloads require protection at the payload layer. The current tool caps collection at 200 frames and 160,000 payload bytes and refuses to emit until all parts and the final payload tag agree.

Live camera access for locally stored HTML files

The QR editions use the browser's live-camera interface only after the user presses Use camera. The browser decides whether the current page is allowed to request the camera. A downloaded HTML file opened directly from local storage may be treated differently from a page opened from an HTTPS website. Chrome, Edge, and other browsers may therefore withhold live camera access on some phones even when the browser application itself has camera permission.

This restriction does not mean that the Sovereign Pay QR decoder or the phone's camera is broken. The same verified HTML file may receive live camera access when opened by a trusted local application that provides a suitable page context. Browser and application behaviour can vary by device and version.

If the live camera is unavailable:

1. Confirm that Android or the device operating system permits the browser application to use the camera, and that camera requests are enabled in the browser's site settings.
2. Use Choose QR image to read an existing raster image, or enter the information manually.
3. Alternatively, open the exact verified HTML file with a trusted local application that permits live camera access.

Do not weaken browser security settings or rely on experimental flags to work around the restriction. Do not photograph or retain a private-key QR merely to create an importable image: photographs can remain in the gallery, backups, deleted-items storage, or cloud services. For a private-key QR, prefer a trusted offline page context that supports a live scan, or use deliberate manual entry on a trusted offline device.

Sovereign Keys format notes

• Bitcoin SV mainnet P2PKH addresses use version 0x00 and normally begin with 1.
• WIF uses mainnet version 0x80; compressed and uncompressed forms can derive different-looking addresses from the same private scalar.
• The default BIP39/BIP32 path shown by Sovereign Keys uses BSV coin type 236. Recovery depends on the same mnemonic, optional passphrase, and path.
• Supported BIP38 handling is passphrase-dependent; weak passphrases can be attacked offline.
• Dice input expects 99 base-6 digits: rolls 1–5 as written and roll 6 recorded as 0.
• Shamir shares must be tested with non-funded material before being trusted for recovery.

File identity, versions, and inscription

An application or manual can retain a familiar filename and appearance after its contents have been changed accidentally or deliberately. A modified application may not operate as designed, developed, or tested by BSVSearch.com. A modified manual may contain altered, incorrect, misleading, or unverified instructions. Either falls outside the recorded release evidence and may produce unexpected, unintended, or unwanted results.

SHA-256 identifies exact bytes. Recompute it after download and compare it with the published release record. A different byte means a different artifact and falls outside the recorded tests. The byte count is a useful additional check, but it is not a substitute for SHA-256.

The verification chain has three distinct parts:

1. The SHA-256 identifies the exact local bytes.
2. The transaction ID identifies the immutable inscribed artifact.
3. https://bsvsearch.com/sovereigntytools.web3 identifies the filename, version, SHA-256, byte count, and TXID that BSVSearch.com currently recommends.

An exact match confirms byte-for-byte identity with that recorded release; it does not prove that the software is flawless, that every possible situation has been tested, or that the device is secure. A tool cannot reliably authenticate itself because a modified copy could also modify or falsify its own self-check. Calculate the hash externally before opening an application, entering a private key, or using funds.

An ordinal inscription is public and permanent. Its transaction ID identifies the inscribed artifact; it does not by itself prove that the file is the current recommended version or that the software is safe for every use.

After inscription, each artifact still requires verification of its downloaded bytes, SHA-256, content type, resolver response, route, and transaction ID through more than one gateway.

See Verify the file before trusting it for the user procedure and current Windows and macOS commands.

Evidence and limits

At the current checkpoint, the rebuilt release candidates passed a 550-check local release gate and the six public documents passed 212 source/render checks. Earlier accepted behavior received an independent peer retest. A later focused pointer, network-load, hash, copy, and manifest reconciliation check covered the prior post-B1 candidate; it predates the approved note-default and documentation/package rebuild and is not an independent exact-current check.

This is independent peer-review evidence, not a formal security-audit certification. The current evidence does not cover every browser, device, camera, network condition, recovery procedure, or payment situation. QR Edition 1.2 has less behavioral and vector coverage than QR Edition 1.0, and the evidence does not include post-inscription MIME, route, resolver, gateway, hash, or transaction-ID verification.

Components, services, and marks

The applications contain separately licensed embedded components where applicable: BIP-0039 material, a Project Nayuki-derived QR encoder, and jsQR 1.4.0. Their notices remain with the exact application and guide. WhatsOnChain and Bitails are independent network services with no affiliation implied. QR Code is a registered trademark of DENSO WAVE INCORPORATED.

Current versions and advisories: https://bsvsearch.com/sovereigntytools.web3.