BRC-100 covers a broad wallet-to-application surface.
Developer experienceSourced answer
Is BSV too complicated to build on?
“BRC-100, BEEF, baskets, certificates, overlays, SHIP, SLAP, and GASP are too much. I should not need ecosystem lore to ship an app.”
Open evidence question · 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
The stack has many concepts because it covers keys, transactions, permissions, identity, storage, proofs, payments, and distributed application state. That breadth is not an excuse for a poor first run. A credible onboarding path should produce one wallet-mediated result with a minimal API, explain the trust boundary in plain language, and defer protocol acronyms until the builder needs them.
Mechanism and practical meaning
Progress from one task to optional depth
First understand the task: authorize a wallet operation and inspect its result. Next learn the trust boundary: what the wallet controls and what the application receives. Only then follow the relevant BRC, transaction-proof or overlay detail. The quickstart is an inspection starting point; this revision does not claim a timed clean-environment onboarding run.
If the first task fails, capture versions and safe symptoms using the compatibility template. A blocker is useful product evidence. A high-level API is successful when unfamiliar builders can finish the task, not merely when its documentation is short.
What is true
The objection's strongest ground
- BRC-100 defines a broad wallet/application interface, so a complete implementation necessarily exposes many capabilities.
- The TypeScript stack now recommends higher-level entry points such as @bsv/simple or @bsv/sdk for many applications.
- A high-level API still needs clear permission, failure, custody, and network behavior.
What remains unresolved
Do not claim more than the evidence
- One-command setup does not eliminate the operational complexity of production wallets, overlays, keys, or payments.
- Simplified language must not misstate who signs, stores data, or can change network outcomes.
Inspect it yourself
What to inspect next
- Time a clean-room builder from empty directory to one visible wallet-mediated outcome.
- Record every prerequisite, account, faucet, permission, failure, and unexplained acronym.
- Keep a progressive glossary linked at first use and test it with non-BSV developers.
Open to better evidence
What would change this answer?
Fast, repeatable completion by unaffiliated builders would weaken the complexity objection. Fragile setup, undocumented concepts, or hidden services would strengthen it.
Evidence behind the answer
What the cited sources establish
The current TypeScript stack exposes higher-level starter packages and documents package roles.
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-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