How this site works

Trust is a process, not a tone of voice.

BSV is a contested system with technical capability, institutional baggage, real governance choices, and an adoption proof gap. This site is designed to survive contact with all four.

01

State the concern fairly

We begin with the strongest recognizable version, including the concern underneath the insult. Weak caricatures are not answered.

02

Use a source hierarchy

Primary legal records, operative rules, code, standards, and live measurements come first. Official claims are labeled as official claims. Secondary summaries are discovery aids.

03

Separate capability from adoption

A standard can exist without interoperability. A repository can run without users. A benchmark can be impressive without independent replication.

04

Name dependencies

Governance, licensing, liquidity, hosted services, rail assumptions, and institutional concentration belong in the answer when they can change the product decision.

05

Say what could change the answer

Every brief states what new evidence would strengthen, weaken, or overturn its conclusion.

06

Review unstable facts

Market access, software versions, network conditions, policies, and availability must be checked again before a consequential decision.

Explain the mechanism and its conditions together

Answer the actual property at issue, name who acts and explain why the design could help. Keep the conditions beside the benefit. A misconception, a real tradeoff and an unanswered empirical question need different treatments.

Documented describes what a source specifies. Reported attributes someone’s account. Interpretation makes our reasoning explicit. Proposed marks an unproved design or safeguard. Tested requires versions, method, observed result and scope; reaching a URL is not such a test.

Content update, source access and product-test dates are separate. Review dates prompt a recheck and do not certify today’s availability. A related author’s opinion is not independent corroboration. We correct supportive overstatements by the same standard as criticism and retain material changes in the revision log.

Short answers, mechanism guides, decision aids, case studies and references share this evidence contract without requiring an identical article structure. The public library export preserves scope and links for reuse.

What carries the most weight?

  1. Primary recordJudgments, contracts, operative rules, protocol specifications, signed releases.
  2. Inspectable implementationSource, tests, reproducible builds, live transaction proofs, incident records.
  3. Independent measurementMethods, time windows, raw data, and limitations must be visible.
  4. Official explanationUseful for intent and claims; not independent proof of the claim.
  5. CommentaryUseful for finding objections; insufficient for settling them.

No institution gets a credibility shortcut.

BSV.place is maintained as a builder resource. Project Babbage and its contributors work on BSV-related software, so that proximity is a perspective and a potential bias—not a substitute for evidence.

Material corrections should identify the exact sentence, the best available source, and why the current wording is wrong or incomplete. Use the structured correction form; accepted changes are summarized in the public revision log.

This site does not provide financial or legal advice, does not use advertising identifiers, and does not require agreement with a Satoshi identity claim.