BRC-105 specifies a wallet-mediated, authenticated HTTP 402 payment flow.
Product fitSourced answer
Does anything economically need BSV?
“Low fees are not a use case. Nothing requires a public blockchain, much less BSV.”
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
Most software does not need a blockchain. BSV is worth considering only where its particular tradeoffs improve a real workflow—for example, pay-per-request APIs, independently verifiable event records, or user-authorized cross-application actions. Even then, the comparison is against ordinary databases, payment processors, and other ledgers on cost, latency, privacy, reliability, governance, and exit risk.
Mechanism and practical meaning
Choose by the job, not absolute necessity
Consider an API that charges per request. A wallet-mediated payment may avoid an account-credit relationship, but introduces funding, conversion, wallet and support costs. Compare the cost per completed request with subscriptions, conventional payments and account credit. The ledger earns its place if the complete workflow improves.
For records, ask what another party must independently verify. Shared commitments may help parties with different operators compare evidence. They do not create truthful inputs or retained bytes. A simpler database remains a successful choice when it meets the requirement.
What is true
The objection's strongest ground
- Low fees alone do not create a user need or distribution channel.
- BRC-105 specifies an authenticated HTTP 402 flow, showing a concrete pay-per-request design rather than proving market demand for it.
- Public proofs can reduce reliance on one application's database for a narrow fact while adding ledger, privacy, and governance dependencies.
What remains unresolved
Do not claim more than the evidence
- A specification and implementation demonstrate feasibility, not customer willingness to pay.
- Public-chain storage is often the wrong choice for private data; commitments or references may be more appropriate than plaintext.
Inspect it yourself
What to inspect next
- Start with the user's job, then compare database, card/subscription, account credit, and ledger designs.
- Model full cost per successful workflow, including wallets, hosting, support, conversion, and failures.
- Run a pay-per-request or proof-verification flow and ask whether the architecture materially improves the product.
Open to better evidence
What would change this answer?
Repeatable products whose economics or portability clearly depend on these capabilities would strengthen the case. If simpler architectures consistently deliver equal value at lower total risk, the use-case claim weakens.
Evidence behind the answer
What the cited sources establish
Source desk
Read the underlying material
PrimaryBRC-105 — HTTP service monetization frameworkSpecification for authenticated HTTP 402 pay-per-request flows; implementation and demand must be verified separately.BRC contributors · 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-05ReferenceProject Babbage quickstartsRunnable wallet-mediated application paths. Maintainer documentation is useful for reproduction, not independent adoption proof.Project Babbage · Source access 2026-10-05