BRC-100 is a public unified wallet-to-application specification.
Wallets & standardsSourced answer
Is BRC-100 real interoperability or one vendor's interface?
“A published document and one implementation are not interoperability. Show independent wallets, shared vectors, and compatibility results.”
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
BRC-100 specifies wallet actions, signatures, encryption, certificates, permissions, baskets, and discovery. The current TypeScript monorepo includes wallet tooling and a growing language-neutral conformance corpus. That is more than a private API, but it does not settle vendor neutrality. Credible interoperability requires independent implementations, published coverage, negative tests, version handling, and a compatibility matrix.
Mechanism and practical meaning
A shared interface enables comparison and replacement
A public wallet interface lets applications request a common set of operations and gives independent implementers something testable to target. That is the affirmative interoperability mechanism. Meaningful evidence then needs version handling, compatible semantics, permission policies and complete application workflows.
The October 4 Zanaadu exchange shows why an interface check can pass while a user reports a failed task. A maintainer acknowledged an overly restrictive change and missing communication. This is a bounded reported case, not universal failure, and no successful current repair is established here.
What is true
The objection's strongest ground
- BRC-100 is publicly readable and defined as a unified vendor-neutral wallet-to-application interface.
- The TypeScript stack publishes language-neutral conformance vectors and runners with an explicit coverage surface.
- A single successful application-wallet pairing does not prove cross-vendor compatibility.
What remains unresolved
Do not claim more than the evidence
- The presence of a conformance directory does not mean every BRC-100 method, edge case, and language is covered.
- Wallet API interoperability does not remove rail, governance, liquidity, or license dependencies.
Inspect it yourself
What to inspect next
- Read the current conformance coverage and parity matrices before making an interoperability claim.
- Run the same positive and negative request vectors against at least two independently maintained wallets.
- Publish version, unsupported behavior, permission differences, failures, and data-export results.
Open to better evidence
What would change this answer?
Multiple independent implementations passing broad shared tests would materially strengthen the claim. Interface drift, uncovered methods, or vendor-only behavior would weaken it.
Evidence behind the answer
What the cited sources establish
The current TypeScript stack contains a language-neutral conformance corpus.
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-05CodeBRC source repositoryVersion history, proposals, and contribution surface for the BRC corpus.BSV Association contributors · Source access 2026-10-05CodeBSV TypeScript conformance corpusLanguage-neutral vectors and runners. Inspect current coverage and parity before calling the whole interface interoperable.BSV Association contributors · Source access 2026-10-05