BRC-100 specifies wallet-mediated actions, signatures, encryption, certificates, and permissions.
Wallet trust modelSourced answer
Can miners, the chain, or an app sign as me or read my private data?
“If BSV can recover coins and apps use identity keys, miners or the Association can impersonate me, decrypt my data, or approve wallet permissions.”
Answer with conditions · Updated 2026-10-05 · Next review 2026-11-05
By BSV.place / Project Babbage. Editorial review; source access dates below. No independent product retest is implied.
Short answer
The short answer
Under the published wallet model, applications request operations from a wallet; the wallet holds or controls user key material and permissions. Miners validate transactions and order accepted history. The NAR can affect UTXO treatment at the network layer. None of those facts, by itself, gives a miner or Association the private keys needed to produce a user's application signature or decrypt properly protected data. Implementation bugs, wallet compromise, and poor permission design remain real risks.
Mechanism and practical meaning
Name the authority boundary
The key distinction preserves a real capability: users can authorize application signatures and encryption operations through a wallet boundary. A rule changing accepted coin treatment does not automatically confer those cryptographic powers. Key compromise, wallet bugs, excessive permissions and misleading prompts can still undermine the practical boundary.
A valid signature also does not make the signed statement factually true. Read relevant public security information for the exact affected component and version; the existence of a policy or unrelated advisory is not evidence of a particular fix.
| Boundary | What to inspect |
|---|---|
| User key and wallet | Custody, derivation, signing and decryption authority |
| Application request | Permissions, prompts, denial and revocation |
| Network acceptance | UTXO treatment, chain policy and directives |
| Real-world assertion | Issuer, device or other evidence beyond the signature |
What is true
The objection's strongest ground
- BRC-100 defines wallet-mediated operations rather than handing arbitrary private keys to an application.
- BRC-103 uses identity keys and signed messages for peer authentication and selective certificate exchange.
- Network-level UTXO reassignment can change accepted ownership without creating the former holder's signature.
What remains unresolved
Do not claim more than the evidence
- A vulnerable or malicious wallet can mishandle keys, permissions, data, or signatures.
- Encrypted content can still leak metadata, and recovery of coins can have identity or financial consequences without key disclosure.
- This page describes intended protocol boundaries, not a security audit of every wallet.
Inspect it yourself
What to inspect next
- Draw the exact keys, data, permissions, messages, and network decisions involved in the user action.
- Inspect the wallet prompt and source path for every requested signature, encryption, certificate, and transaction operation.
- Test denial, revocation, export, compromised-app, and unavailable-wallet scenarios.
Open to better evidence
What would change this answer?
Evidence that a network directive or ordinary app can obtain user key operations outside published wallet authorization would invalidate this boundary. Independent audits and cross-wallet permission tests would strengthen it.
Evidence behind the answer
What the cited sources establish
BRC-103 specifies peer authentication using identity keys, signed messages, and certificate exchange.
Source desk
Read the underlying material
PrimaryBRC-100 — Unified wallet-to-application interfaceThe current unified interface covering wallet actions, signatures, encryption, certificates, permissions, and discovery.BRC contributors · Source access 2026-10-05PrimaryBRC-56 — Abstract wallet-to-application messaging layerEarlier interface rationale and permission-oriented wallet/application boundary.BRC contributors · Source access 2026-10-05PrimaryBRC-103 — Mutual authentication and certificate exchangePeer-to-peer authentication, message signatures, and selective certificate exchange protocol.BRC contributors · Source access 2026-10-05PrimaryNetwork Access Rules — Part III, Enforcement RulesDirective events, restrictions, and permitted steps including freezes, reassignment, peer controls, and block invalidation.BSV Association · Source access 2026-10-05CodeBSV TypeScript stackCurrent monorepo for SDK, wallet, overlay, messaging, middleware, helpers, infrastructure, documentation, and conformance vectors.BSV Association contributors · Source access 2026-10-05