{"schemaVersion":"1.0.0","canonicalOrigin":"https://bsv.place","updatedAt":"2026-10-05","maintainer":"BSV.place / Project Babbage","reuse":"Link to canonical pages. Preserve qualifications, evidence states and source dates. A reported or documented claim is not a tested result. External authors retain rights in their work.","items":[{"id":"guide:mining-acceptance","path":"/guides/mining-incentives-and-economic-acceptance/","title":"Mining incentives and economic acceptance","format":"Mechanism guide","topic":"Mining and settlement","depth":"Full explanation","shortAnswer":"Producing a block, checking it and accepting a payment are different decisions. Hashpower makes production possible and competing histories costly. Credible, coordinated rejection can reduce a profit-seeking attacker’s realizable payoff. That depends on actual enforcement, compatible settlement policies and continued accepted mining; one participant’s refusal cannot guarantee agreement.","description":"Who produces, verifies and accepts a payment; how credible rejection can deter an attack; and why coordination and continued mining still matter.","modifiedAt":"2026-10-05","evidenceScope":"Editorial synthesis of published rules, implementation documentation and the October 5 exchange. No current miner-control measurement, attack-resilience test or deployment audit was performed.","aliases":["non-mining node","nonmining validator","51%","majority attack","honest nodes","who decides honest","hashpower","minority refusal"],"sections":[{"id":"three-jobs","title":"Start with a merchant payment","kind":"interpretation","paragraphs":["A merchant hands over a product only after deciding that a payment meets its acceptance policy. A miner may include the transaction in a block. A verifier may check the transaction and relevant history. A payment service may do some of those checks for the merchant. These are related jobs, but the person doing one need not do all of them.","A non-mining validator therefore has a useful role: it can independently inspect the evidence and refuse to recognize a result. Its refusal contributes no hashpower and creates no replacement blocks. The merchant can also delegate checking to a wallet or payment service, gaining convenience while depending on that provider’s implementation, information and policy.","The relevant question is not just whether a block was produced. It is whether the businesses and services involved will treat its result as settling their obligations. Each participant’s choice matters within its own scope; neither the merchant nor the miner can unilaterally make every other participant agree."],"sources":["whitepaper","js","question"],"diagram":{"title":"Different jobs in one settlement process","nodes":[{"title":"Produce","text":"Miners supply work and continuing blocks."},{"title":"Verify","text":"Operators check rules and evidence themselves or through services."},{"title":"Accept","text":"Businesses and users decide which result settles their exchange."},{"title":"Coordinate","text":"Participants communicate and apply compatible policies."}],"conclusion":"Verification can justify local refusal. Successful convergence also requires compatible acceptance and continuing accepted block production."}},{"id":"rules-and-histories","title":"Validity and competing histories are different questions","kind":"documented","paragraphs":["More work does not make a transaction pass a rule it violates. The original network description has nodes check blocks before accepting and extending them. But a conflict can also involve alternative histories whose individual transactions otherwise satisfy the relevant checks. Resolving that dispute requires a chain-selection and settlement policy; calling one participant dishonest supplies neither the policy nor its evidence.","Be explicit about which rules are being applied. Transaction validity, a software implementation’s protective behavior, and an institutionally issued directive are different inputs. A repeatable technical check does not by itself establish the legitimacy of an external decision. Readers should be able to identify the rule version, actor, evidence and decision being relied on."],"sources":["whitepaper","nar"]},{"id":"documented-mechanisms","title":"What the BSV mechanisms establish","kind":"documented","paragraphs":["SV Node’s Safe Mode documentation describes detection and protective behavior, together with operator intervention. It provides a basis for saying an operator can withhold acceptance locally. It does not establish that every service is running that software, that detection is infallible, or that all participants will choose the same response. Do not silently transfer an SV Node behavior to every Teranode installation.","The published Network Access Rules assign the Association directive functions, including specified block treatment under defined events. The alert system is a channel for signed information and directives. Authenticating a message helps establish its origin under the signing-key assumptions; it does not independently establish the truth of an allegation or make the response unanimous.","Those powers belong in the explanation, alongside operator and business decisions. Treating coordination as automatic hides operational risk. Treating every response as a purely informal choice hides the documented institutional layer. Both make it harder to evaluate what an actual settlement policy depends on."],"sources":["safe","nar","alert"]},{"id":"economic-mechanism","title":"Why credible rejection can change incentives","kind":"interpretation","paragraphs":["A profit-seeking attack needs more than a history on disk: it needs a realizable benefit. Suppose an attacker’s intended gain depends on a merchant, exchange or other counterparty recognizing an attack branch. If those parties effectively reject the result, the intended payoff may disappear. If the target economy also refuses that branch’s mining rewards, producing additional work does not by itself make those rewards spendable there.","That is the affirmative deterrence argument. A credible response known in advance can make accepted mining more attractive than an attempted attack. The word credible carries substantial work: participants need usable rules, timely evidence, the ability to act, compatible policies and enough continuing accepted production to serve the economy they are protecting.","This does not imply an attack branch has zero value everywhere. Another economy could accept it. A position elsewhere, a political objective or a desire to cause disruption could also make an attack worthwhile to its sponsor. There is no verified estimate here of holdings, outside exposure, response probabilities or miner concentration from which to calculate a numerical safety margin.","The position is strongest as a conditional economic argument: effective rejection can remove a particular payoff, changing incentives. It is weaker when compressed into ‘attacks will always be orphaned’ or ‘hashpower no longer matters.’ Even when a defense prevents the intended theft, delayed service and disputed settlement can still hurt users."],"sources":["js","whitepaper"],"table":{"caption":"Illustrative scenarios, not forecasts","columns":["Conditions","Economic consequence","What remains"],"rows":[["Compatible policies; effective response; continuing accepted mining","The targeted payoff may be denied; accepted mining remains an alternative","Operational cost and disruption still need measurement"],["Services disagree or respond too slowly","Some counterparties may realize or recognize a conflicting result","Split settlement, loss and recovery risk"],["Sabotage or significant outside incentives","Foregone local rewards may not deter the sponsor","Sustained disruption and a need for an explicit service policy"]]}},{"id":"convergence","title":"Local refusal is not network convergence","kind":"interpretation","paragraphs":["One business can refuse a payment without forcing another business to refuse it. One operator can reject a branch without forcing other operators to produce a replacement. Convergence means the participants whose agreement matters actually resume compatible settlement. It is an outcome to demonstrate, not a synonym for having a rejection mechanism.","During a disagreement, users need to know which operations are paused, what evidence is available, which counterparties share a policy and what unresolved obligations remain. A transparent incident record should include dissent and unsuccessful coordination, not only the eventual preferred result. If accepted block production stops, local conviction cannot supply the missing service.","Hashpower remains essential to production and the cost of competing histories. Economic acceptance explains what gives those histories relevance to particular transactions. Their interaction is the useful model; erasing either side makes the account less complete."],"sources":["js","whitepaper"]},{"id":"historical-comparison","title":"What the 2013 fork does and does not show","kind":"documented","paragraphs":["BIP 50 records a chain split caused by incompatible software behavior. Coordination mattered: participants selected a compatible path and mining pools downgraded, moving hashpower. The incident also involved disruption and a documented double spend. It is evidence that software choices, human communication and mining all matter to the outcome.","It is not evidence that a minority’s refusal alone necessarily defeats a sustained majority, nor a blanket endorsement of BSV’s present governance. A historical analogy becomes useful when its differences are retained. Ask what changed the outcome in that incident, and what corresponding capability is actually available in the case now being considered."],"sources":["bip50"]},{"id":"acceptance-policy","title":"Make the acceptance policy inspectable","kind":"proposed","paragraphs":["Before a high-consequence workflow depends on settlement, document what will be accepted, who checks it and who can change that decision. The worksheet is a design and review aid; completing it is not certification. A low-value receipt and an irreversible high-value delivery can reasonably require different controls.","The accompanying incident template separates observations from reports and decisions. It helps preserve an explanation after a social conversation has disappeared, without publishing private logs, keys or operational details that users do not need. Use public references and sanitized evidence. An unknown is a legitimate result; an unrecorded assumption is much harder to challenge."],"steps":["Name the workflow, value at risk and irreversible consequence.","Name the rules, implementation version, verifier and delegated providers.","Document accepted-history, delay and disagreement policies, including who authorizes changes.","Identify required coordination and continuing production; record untested assumptions.","Retain the public evidence, decisions, affected outcomes and unresolved disagreements."],"sources":["safe","nar","js"]}],"sources":[{"id":"whitepaper","title":"Bitcoin whitepaper · sections 5, 6 and 8","url":"https://bitcoin.org/bitcoin.pdf","kind":"documented","checkedAt":"2026-10-05","note":"The original network, incentive and verification model. It does not document later BSV institutions."},{"id":"safe","title":"SV Node Safe Mode","url":"https://docs.bsvblockchain.org/network-topology/nodes/sv-node/frequently-asked-questions/safe-mode","kind":"documented","checkedAt":"2026-10-05","note":"Documents protective detection and operator intervention for SV Node. Not a deployment or convergence test."},{"id":"nar","title":"Network Access Rules · Part III","url":"https://docs.bsvblockchain.org/network-access-rules/network-access-rules/part-iii-enforcement-rules","kind":"documented","checkedAt":"2026-10-05","note":"Published Association directive powers and event categories. Read the operative text for scope and conditions."},{"id":"alert","title":"SV Node alert system","url":"https://docs.bsvblockchain.org/network-topology/nodes/sv-node/alert-system","kind":"documented","checkedAt":"2026-10-05","note":"Documents signed information and directive messages. Message authentication is not a judgment on the merits, and documentation is not a deployment audit."},{"id":"js","title":"Project Babbage’s answer on mining and economic acceptance","url":"https://x.com/ProjectBabbage/status/2107167307097342049","kind":"reported","checkedAt":"2026-10-05","publishedAt":"2026-10-05T17:53:29Z","note":"The published argument that prompted this guide, verified against its live body. An authored position, not empirical proof of deterrence."},{"id":"question","title":"JS’s question about rejecting miners without mining","url":"https://x.com/jionny112/status/2107129424135225455","kind":"reported","checkedAt":"2026-10-05","publishedAt":"2026-10-05T15:22:57Z","note":"The direct question answered by the October 5 reply. The guide answers the substance independently of access to X."},{"id":"bip50","title":"BIP 50 · March 2013 chain fork post-mortem","url":"https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki","kind":"documented","checkedAt":"2026-10-05","note":"Records software incompatibility, coordinated downgrade and movement of mining hashpower, disruption and a double spend."}],"related":[{"title":"Stewardship and authority","href":"/guides/stewardship-and-authority/","purpose":"Identify who is empowered to decide and how a decision can be challenged."},{"title":"Hashpower and reorganizations","href":"/answers/security-hashpower-and-reorgs/","purpose":"Put the mechanism alongside the settlement risks."},{"title":"Proof and preservation","href":"/proof/merkle-proof-not-backup/","purpose":"Distinguish retained inclusion evidence from current accepted history."}],"downloads":[{"file":"mining-acceptance-origin.json","label":"Original published argument","note":"Project Babbage’s October 5 reply, with publication time and its limits.","path":"/assets/guides/mining-acceptance-origin.json"},{"file":"acceptance-policy.md","label":"Acceptance-policy worksheet","note":"Blank, reusable review template.","path":"/assets/guides/acceptance-policy.md"},{"file":"incident-evidence.json","label":"Incident evidence template","note":"Empty fields; no incident or result is implied.","path":"/assets/guides/incident-evidence.json"}],"changesConclusion":"Observed coordination failures, inconsistent acceptance or inability to sustain accepted production weaken the deterrence case. Transparent incident outcomes and independent review can strengthen confidence. Neither establishes an unconditional guarantee."},{"id":"guide:stewardship-authority","path":"/guides/stewardship-and-authority/","title":"Stewardship and authority in an open system","format":"Mechanism guide","topic":"Governance and responsibility","depth":"Full explanation","shortAnswer":"A shared system needs maintainers and coordination. Those responsibilities can be distributed across institutions with different scopes. The useful test is whether another competent participant can understand the rules, inspect a decision and continue the relevant work. BSV’s published Association powers remain real dependencies; plural stewardship is a standard to demonstrate, not evidence that concentration has disappeared.","description":"A practical account of transferable competence, institutional correction and independent stewards, with BSV’s current authority boundaries made explicit.","modifiedAt":"2026-10-05","evidenceScope":"BRC-187 is an authored framework, read alongside published operational rules. This article is not an independent control audit or a legal opinion about replacement rights.","aliases":["BRC-187","BRC187","who decides honest","capture","centralization","independent stewards","Association"],"sections":[{"id":"three-responsibilities","title":"Three responsibilities that make stewardship useful","kind":"interpretation","paragraphs":["Maintaining a shared system is work. Someone must preserve the rules, implement them, explain their application and repair mistakes. Denying that work exists does not remove power; it can make the people doing it less visible. The constructive question is how responsibilities can be bounded, checked and continued by others.","BRC-187, an opinion authored by Ty Everett, supplies a framework for this discussion. We interpret its practical demands as transferable competence, correction within institutions, and cooperation among independent stewards. Because this site is maintained by Project Babbage, the related authorship is material. The essay explains a position; it is not outside verification that BSV already meets it."],"sources":["brc187"],"diagram":{"title":"Three tests of a stewardship arrangement","nodes":[{"title":"Transfer competence","text":"Another qualified participant can understand the work and its evidence."},{"title":"Correct institutions","text":"A mistake can be acknowledged, challenged and repaired."},{"title":"Cooperate independently","text":"Different stewards can coordinate within explicit scopes."}],"conclusion":"Evidence of these capabilities must accompany the principle. A commitment alone does not demonstrate replaceability."}},{"id":"transferable-competence","title":"Can another competent person continue the work?","kind":"proposed","paragraphs":["For a software maintainer, this means more than publishing a repository. A successor needs build instructions, tests, release provenance, supported behavior and an intelligible account of design choices. A public interface helps separate applications from a particular implementation, but compatibility and licensing still determine whether a substitute is practical.","For a service, continuity also requires usable data. A replacement overlay cannot reconstruct absent records from a name or endpoint. The records, schema, indexing rules and authorization model must be available to the party that needs them. A documented export becomes much stronger evidence after a restore in an independent environment.","Transferable competence is therefore a useful affirmative goal: preserve enough knowledge for another responsible person to act. It does not imply that all production infrastructure must be public, that every operator shares private data, or that a formally assigned institutional authority can be replaced simply by copying its software."],"sources":["brc187","brc100"]},{"id":"correctable-institutions","title":"Can an institution correct itself?","kind":"proposed","paragraphs":["A correction path needs an accountable owner, a way to supply evidence, a record of the decision and a means to revisit it. It should work when the challenger is unfamiliar or critical. A formal complaint channel with no observable handling history provides less assurance than a process whose corrections can actually be inspected.","Scope matters. A maintainer can correct code or documentation without determining a legal dispute. A business can change a payment policy without rewriting a standard for everyone. A coordinator can communicate evidence without making the communication itself proof of the evidence. An explanation should name the act and the authority for it rather than group everything under ‘governance.’","Apply this standard to our own work. A mistake in a supportive argument deserves the same correction as a mistake in a criticism. The October mining guide consequently preserves the acceptance mechanism while retiring the inference that rejection must always succeed. Correctability makes a position more reliable because readers can see what survives scrutiny."],"sources":["brc187","js"]},{"id":"rules-and-custodians","title":"Identify the system apart from its custodian","kind":"interpretation","paragraphs":["The strongest part of the stewardship argument is that a rule can be stated independently of the person applying it. Two competent stewards using the same complete rules and relevant evidence should obtain the same validation result. Where the selection conditions uniquely determine a history, they should also identify the same resulting state. The premises must be exposed: different evidence, incomplete rules or unresolved selection conditions can prevent that conclusion.","This makes replacement without redesign conceivable. A new maintainer can preserve an interface; another service can apply an existing application rule. Responsibility for maintaining a system does not, by itself, justify changing its underlying undertaking. BSV’s stated preference for a stable core is a stewardship commitment to examine against actual rules and conduct, not a license to skip that examination.","For example, two warehouse-receipt services could recognize the same issuers, use the same admission rules and inspect the same available evidence. They could produce compatible results without one owning all interpretation. They still need sufficient records, consistent implementations and an explicit way to handle missing or conflicting evidence. A public query interface alone would not prove those conditions.","If the complete rule set includes an external directive, both stewards must identify that input. Reproducing its technical consequences is different from independently justifying the directive. Plural stewardship is strongest when this dependency is visible, rather than concealed inside the word ‘objective.’"],"sources":["brc187","nar"]},{"id":"authority-matrix","title":"Keep current powers separate from desired safeguards","kind":"documented","paragraphs":["The following matrix separates documented roles from the evidence still needed to assess their operation. It is a starting map, not a complete audit of the ecosystem. In particular, an external directive remains an input: reproducing its technical effect differs from independently deriving or endorsing the decision.","The Network Access Rules describe Association functions that cannot be erased by calling the ecosystem plural. The framework proposed here asks for clearer boundaries and accountability around such power. It does not amend the operative rules, establish an appeal outcome or confer a legal right to replace an assigned authority."],"sources":["nar","alert","brc100","brc187"],"table":{"caption":"Authority and dependency matrix · documented roles; proposed checks","columns":["Role","Current scope and input","Inspectable output","Challenge or replacement question","Evidence state"],"rows":[["Association directive function","Published Part III event and directive provisions; external decisions may be inputs","Specified instruction and its declared basis","Use applicable dispute process; technical substitution alone does not establish authority","Rules documented; complete operation audit not supplied"],["Node operator","Implementation, accepted rules and relevant directive inputs","Locally applied policy and resulting accepted history","Can another operator reproduce the technical treatment?","SV Node documentation; deployment and convergence untested"],["Wallet implementer","Interface, permission policy and user key operations","Versioned behavior, prompts and safe workflow results","Can an independent wallet support the required behavior and migration?","Interface documented; end-to-end compatibility must be tested"],["Application or overlay operator","Application schema, retained records and service policy","Usable exports and verifiable application results","Can another service interpret, restore and serve the required records?","Design requirement; product-specific evidence needed"],["Business accepting payment","Workflow risk, verifier/service evidence and counterparties","Published acceptance and dispute policy","Who can revise it, and who must agree for settlement?","Proposed accountability record; no universal merchant policy"]]}},{"id":"worked-disagreement","title":"A disagreement between two operators","kind":"interpretation","paragraphs":["Consider two operators reaching different conclusions about the same event. First they compare the actual inputs: transaction or record, rule version, implementation version and any external instruction. If their inputs differ, the useful work is to identify the difference. If the same input produces different technical results, a reproducible implementation discrepancy may explain it.","If they agree on the technical effect but disagree about an instruction’s legitimacy, rerunning the same code will not resolve that disagreement. They need the applicable authority and challenge process, and an account of what services do while the disagreement persists. A signed message establishes an attributed instruction, subject to key assumptions; it does not resolve the merits by itself.","Independent stewards cooperate by making these boundaries legible. Agreement can be an outcome of shared rules and evidence, but agreement with our preferred conclusion cannot be the definition of honesty. An unresolved disagreement must remain visible. The miner, wallet, business and user may also face different immediate consequences."],"sources":["brc187","nar","alert"],"steps":["Compare inputs and rule versions.","Compare the technical result.","Separate implementation differences from disputes over authority or judgment.","Use the relevant challenge process and record interim service policy.","Publish the reasoned outcome, remaining dissent and resulting correction where appropriate."]},{"id":"responsibility-record","title":"Make a responsibility statement portable","kind":"proposed","paragraphs":["Every critical dependency should have a short responsibility statement: what it controls, why, who can change it, what evidence it exposes and what continuity requires. The downloadable template also asks who handles a challenge and what has actually been tested. These questions are useful for an independent builder as well as a large institution.","Do not infer independence from separate names alone. Shared hosting, funding, administrators, licenses or signing keys may constrain real choices. Equally, institutional concentration is not proof that every independent builder is controlled by one sponsor. Record supported relationships and unknowns rather than making either sweeping assertion.","The strongest argument for plural stewardship is a demonstrated ability to preserve competence, correct errors and cooperate across independent scopes. It improves as replacement and challenge paths become practical. It weakens when undocumented discretion expands, important records disappear or a supposed alternative cannot perform the promised job."],"sources":["brc187"]}],"sources":[{"id":"brc187","title":"BRC-187 · stewardship opinion","url":"https://github.com/bsv-blockchain/BRCs/blob/7c0ba5f2208e06525303ad4ac429dcbf379229d4/opinions/0187.md","kind":"interpretation","checkedAt":"2026-10-05","note":"Ty Everett’s authored stewardship framework. BSV.place is maintained by Project Babbage; this is a related author’s position, not independent corroboration or a deployed governance specification."},{"id":"nar","title":"Network Access Rules · Part III","url":"https://docs.bsvblockchain.org/network-access-rules/network-access-rules/part-iii-enforcement-rules","kind":"documented","checkedAt":"2026-10-05","note":"Published Association directive powers and event categories. Read the operative text for scope and conditions."},{"id":"alert","title":"SV Node alert system","url":"https://docs.bsvblockchain.org/network-topology/nodes/sv-node/alert-system","kind":"documented","checkedAt":"2026-10-05","note":"Documents signed information and directive messages. Message authentication is not a judgment on the merits, and documentation is not a deployment audit."},{"id":"safe","title":"SV Node Safe Mode","url":"https://docs.bsvblockchain.org/network-topology/nodes/sv-node/frequently-asked-questions/safe-mode","kind":"documented","checkedAt":"2026-10-05","note":"Documents protective detection and operator intervention for SV Node. Not a deployment or convergence test."},{"id":"brc100","title":"BRC-100 · wallet to application interface","url":"https://bsv.brc.dev/wallet/0100","kind":"documented","checkedAt":"2026-10-05","note":"The interface specification; implementation, policy and workflow outcomes need their own evidence. No new compatibility test is implied by this guide."},{"id":"js","title":"Project Babbage’s answer on mining and economic acceptance","url":"https://x.com/ProjectBabbage/status/2107167307097342049","kind":"reported","checkedAt":"2026-10-05","publishedAt":"2026-10-05T17:53:29Z","note":"The published argument that prompted this guide, verified against its live body. An authored position, not empirical proof of deterrence."}],"related":[{"title":"Mining and economic acceptance","href":"/guides/mining-incentives-and-economic-acceptance/","purpose":"See how authority and coordination enter settlement."},{"title":"Association governance","href":"/answers/bsv-association-governance/","purpose":"Inspect the formal institutional layer."},{"title":"Metanet overlay recovery","href":"https://metanet.fyi/overlays/recovery","purpose":"Turn service replaceability into a recovery checklist."}],"downloads":[{"file":"authority-matrix.csv","label":"Authority and dependency matrix","note":"The HTML matrix as CSV, with sources and evidence states.","path":"/assets/guides/authority-matrix.csv"},{"file":"responsibility-statement.md","label":"Responsibility statement template","note":"For a maintainer, service, business or institution.","path":"/assets/guides/responsibility-statement.md"}],"changesConclusion":"Independent continuation, reproducible decisions and meaningful correction histories strengthen the framework’s practical case. Opaque discretion, unavailable evidence or unusable replacement paths weaken it. The framework never substitutes for the actual authority record."},{"id":"guide:wallet-compatibility","path":"/guides/wallet-compatibility-and-safe-changes/","title":"When a conforming wallet still breaks an application","format":"Case study","topic":"Wallets and compatibility","depth":"Full explanation","shortAnswer":"A common wallet interface gives applications a shared way to request operations. It does not guarantee that every wallet policy, version and user workflow works together. The October 4 Zanaadu report and maintainer acknowledgment expose that gap. A repair needs an identified release and a successful workflow retest; neither an interface pass nor a constructive exchange proves resolution.","description":"The October 4 Zanaadu exchange explains why interface checks, wallet policy, release communication and successful user workflows need separate evidence.","modifiedAt":"2026-10-05","evidenceScope":"Case based on public October 4 reports and acknowledgments reviewed October 5. No independent reproduction, current release verification or successful Zanaadu retest is claimed.","aliases":["app broke","Zanaadu","BRC29","BRC-29","regression","conformance","security disclosure","bug bounty","release notes"],"sections":[{"id":"why-the-interface-matters","title":"The affirmative case for a common interface","kind":"interpretation","paragraphs":["A wallet interface lets an application request actions without implementing every wallet’s private API. It can make user permissions more consistent, allow reusable test vectors and make alternative implementations easier to compare. That shared boundary is valuable precisely because the wallet and application are different components with different responsibilities.","The user still needs the complete task to work. An operation may exist in the interface while an implementation rejects a particular request, asks for an unexpected permission or returns behavior the application cannot handle. A passing test only establishes the behavior covered by that test under its recorded conditions. It does not certify all combinations of wallet, app, platform and version."],"sources":["brc100"]},{"id":"the-public-record","title":"What the October 4 exchange establishes","kind":"reported","paragraphs":["A Zanaadu user reported a broken mobile posting workflow and an unexpected signing restriction. A maintainer subsequently described an overly restrictive change, acknowledged missing prompt and release communication, and said the interface check had passed. Project Babbage accepted a code-quality and testing gap. The reporter’s later constructive response is useful context, but it is not a verification of repair.","These are attributed public reports. They do not establish an independently reproduced diagnosis, a fixed version or a successful current test. This case records the support and compatibility lesson without asking readers to accept a claim about an unobserved outcome. A later update should name the release, conditions and evidence that change this status."],"sources":["report","maintainer","ownership","userResponse"],"table":{"caption":"Evidence status at the October 5 review","columns":["Item","State","What remains"],"rows":[["Mobile posting failure","User-reported","Exact app/wallet builds and a safe independent reproduction"],["Overly restrictive change and communication gap","Maintainer-reported","Release-specific implementation evidence"],["Interface test pass","Maintainer-reported","Published test coverage for the affected workflow"],["Repair and successful user workflow","Not verified","Named release, retest conditions, outcome and preferably reporter confirmation"]]}},{"id":"four-layers","title":"Four layers to inspect before assigning the fix","kind":"interpretation","paragraphs":["The specification defines what a request means and which behavior is promised. Wallet policy defines permission and risk decisions inside that boundary. The implementation carries those decisions out. The application then composes operations into a user workflow, including its handling of denials, errors and changes.","Calling a problem an implementation issue can help assign work, but should not end the investigation. A standard may leave important semantics ambiguous. A policy change may be legitimate yet poorly communicated. An application may rely on undocumented behavior. More than one of these can be true at once. The useful result is a precise supported behavior and a tested path forward.","A compatibility matrix should therefore name app, wallet, versions, platform, workflow, expectation, observed result, date and tester. Distinguish pass, fail and not tested. Keep a reported failure separate from an independently reproduced failure; otherwise the table silently upgrades the evidence."],"sources":["brc100","maintainer"],"diagram":{"title":"From an interface to a usable product","nodes":[{"title":"Specification","text":"What operation and semantics are promised?"},{"title":"Policy","text":"What permission or restriction applies?"},{"title":"Implementation","text":"What does this version actually do?"},{"title":"Workflow","text":"Can this user complete the intended task?"}],"conclusion":"A pass at one layer is evidence about that layer. Record the complete workflow separately."}},{"id":"safe-reporting","title":"Public compatibility support and security reporting","kind":"proposed","paragraphs":["Ordinary compatibility questions benefit from public symptoms, supported behavior, release notes and migration instructions. Developers should not need a private relationship to learn that a supported operation changed. A public report can be constructive even when its first explanation of the cause turns out to be incomplete.","If a report includes a suspected exploitable weakness, use the affected project’s designated confidential reporting process for sensitive details. A safe public status can still explain affected functionality, mitigations that do not create new risk, supported versions and where updates will appear. Do not publish credentials, private records or exploit instructions in a compatibility ticket.","The TypeScript stack has a public security policy. That fact establishes a reporting route, not an independent audit or a paid bounty promise. It also does not establish that any existing advisory describes this particular incident. Match identifiers and affected versions before linking an advisory as its resolution."],"sources":["security"],"steps":["Ordinary unexpected behavior: provide safe symptoms, versions, expected behavior and a public issue or support route.","Potential exploitable weakness: send sensitive detail through the project’s designated process; keep public updates safe and useful.","Unclear category: ask the maintainer to route it without requiring secrets or a public reproduction of a weakness.","Resolution: name the release and retest the original user task before marking it fixed."]},{"id":"change-notices","title":"Communicate a behavior change before users discover it","kind":"proposed","paragraphs":["A useful change notice states what changed, who is affected, which versions contain it and what applications should do. If a restriction changes, describe the user-visible behavior and supported migration path. Do not turn a security improvement into an undocumented compatibility surprise when safe advance communication is possible.","The notice should also distinguish intentional behavior from a regression and identify the owner of follow-through. An apology or acknowledgment matters, but users still need a release and a working task. Preserve failed tests and unexpected results as part of the record; they explain why a later claim of compatibility is credible.","For maintainers, shared interface tests and application workflow tests serve different purposes. Add coverage for the behavior that mattered to the user, including ordinary denial and recovery behavior, while keeping security-sensitive investigation in the appropriate process. A versioned result is more useful than a general badge saying ‘compatible.’"],"sources":["maintainer","ownership"]},{"id":"compatibility-matrix","title":"A matrix ready for real results","kind":"proposed","paragraphs":["The downloadable CSV begins with the reported Zanaadu case and a blank test row. Its test status is not-tested because this article did not reproduce the workflow. The reported symptom remains in a separate field. Fill unknown versions only from evidence; do not infer them from a publication date.","Use the same workflow against the relevant released app and wallet versions, retain a non-sensitive result and record who performed the test. A successful retest supports that combination on that platform. It cannot establish universal compatibility or resolve unrelated reports. Link the evidence back into the article so the original conversation becomes a durable, revisable record."],"sources":["report","userResponse"]}],"sources":[{"id":"brc100","title":"BRC-100 · wallet to application interface","url":"https://bsv.brc.dev/wallet/0100","kind":"documented","checkedAt":"2026-10-05","note":"The interface specification; implementation, policy and workflow outcomes need their own evidence. No new compatibility test is implied by this guide."},{"id":"report","title":"Zanaadu mobile workflow report","url":"https://x.com/johncalhooon/status/2106787458138378251","kind":"reported","checkedAt":"2026-10-05","note":"October 4 user report of failed posting and an unexpected signing restriction. Not independently reproduced for this article."},{"id":"maintainer","title":"Maintainer’s explanation and acknowledgment","url":"https://x.com/deggen/status/2106810017915580802","kind":"reported","checkedAt":"2026-10-05","note":"Describes an overly restrictive change and missing prompt/release communication, despite a passing interface check. Does not establish a released repair."},{"id":"ownership","title":"Project Babbage’s acknowledgment of the testing gap","url":"https://x.com/ProjectBabbage/status/2106822131413872713","kind":"reported","checkedAt":"2026-10-05","note":"Public acceptance of responsibility for code quality and workflow coverage. An acknowledgment is not a fix."},{"id":"userResponse","title":"Reporter’s constructive follow-up","url":"https://x.com/johncalhooon/status/2106824255992451579","kind":"reported","checkedAt":"2026-10-05","note":"Acknowledges shared responsibility. It does not confirm a successful retest."},{"id":"security","title":"TypeScript stack security policy","url":"https://github.com/bsv-blockchain/ts-stack/security","kind":"documented","checkedAt":"2026-10-05","note":"Project-specific reporting policy. A policy is not an audit, a promised bounty, or evidence that this compatibility incident matches an advisory."}],"related":[{"title":"BRC-100 interoperability","href":"/answers/brc100-interoperability-and-portability/","purpose":"Read the short answer on standards and independent implementations."},{"title":"Data and service portability","href":"/answers/user-data-and-service-portability/","purpose":"Check what a successful migration must retain."},{"title":"Metanet","href":"https://metanet.fyi/","purpose":"Start with the app and wallet model in plain language."}],"downloads":[{"file":"compatibility-matrix.csv","label":"Versioned compatibility matrix","note":"Reported symptom and independent test status are separate.","path":"/assets/guides/compatibility-matrix.csv"},{"file":"change-notice.md","label":"Behavior-change notice template","note":"Versions, supported behavior, migration and retest evidence.","path":"/assets/guides/change-notice.md"}],"changesConclusion":"A named release and successful workflow retest can establish a repair for that combination. Repeated unexplained regressions or unclear semantics would justify revising implementation practices, compatibility commitments or the specification itself."},{"id":"guide:iot-evidence","path":"/guides/iot-records-and-shared-evidence/","title":"When a shared ledger helps an IoT record","format":"Decision guide","topic":"Applications and evidence","depth":"Full explanation","shortAnswer":"A shared ledger can help independent parties inspect a common commitment and accepted ordering without relying only on the original application’s database. It cannot make a sensor truthful or preserve missing records. Use it when that verification benefit justifies its costs and dependencies; a signed database log or transparency service may be the better design.","description":"A sensor example separates signatures, truth, retention, ordering and settlement, then compares database logs, transparency services and ledger anchors.","modifiedAt":"2026-10-05","evidenceScope":"A hypothetical design comparison motivated by the October 4 question. The example and export are synthetic. No device, benchmark, customer deployment or recovery test is represented as measured.","aliases":["IoT","database","sensor","spam","shared evidence","signed false data","throughput","timestamp"],"sections":[{"id":"one-reading-three-parties","title":"One reading, three parties","kind":"interpretation","paragraphs":["Imagine a refrigerated shipment producing an overheating record. The customer wants to know whether the goods were kept within bounds, the supplier wants to understand a disputed delivery, and an auditor wants an inspectable account. They may need a shared reference even after the application that first displayed the event is gone.","The strongest ledger case is specific: a compact commitment can let parties compare retained records against a common reference and inspect their inclusion and ordering under an explicit acceptance policy. That can reduce reliance on one party’s editable database as the only account. It does not eliminate reliance on devices, keys, retention providers or settlement rules.","Start by naming the fact to verify. ‘These bytes match the earlier commitment’ is different from ‘this device signed them,’ ‘the temperature was accurate,’ or ‘the supplier is liable.’ A design that answers the first question has not automatically answered the others."],"sources":["iot","whitepaper"]},{"id":"evidence-layers","title":"Keep the evidence layers separate","kind":"interpretation","paragraphs":["A signature can support attribution to a key and integrity of the signed message under its cryptographic assumptions. It does not establish sensor calibration, secure installation, correct location or an honest measurement. A signed false reading remains false; device provenance and independent observations need their own evidence.","A retained record can be compared with a commitment. A Merkle proof can link it to a particular block. The block’s place in currently accepted history and the practical finality of settlement require additional checks. None of those operations reconstruct missing bytes, a missing schema or an unavailable decryption key.","The useful architecture assigns each job an owner and a test. Preserve the record and schema, explain the device’s trust assumptions, and state what a third party can check without the original frontend. If a legal or operational decision relies on more than the ledger establishes, name that additional evidence."],"sources":["signatures","whitepaper"],"diagram":{"title":"What each evidence layer can establish","nodes":[{"title":"Observation","text":"Calibration, provenance and context concern the real-world reading."},{"title":"Signature","text":"An attributable message under key and cryptographic assumptions."},{"title":"Retention","text":"Bytes, schema and permissions remain available."},{"title":"Commitment","text":"Retained bytes match a common reference and inclusion proof."},{"title":"Acceptance","text":"Participants check current history and settlement policy."}],"conclusion":"Evidence at a later layer cannot repair missing evidence at an earlier one."}},{"id":"compare-the-same-job","title":"Compare three ways to do the same job","kind":"interpretation","paragraphs":["A signed database log can be enough when one accountable operator is acceptable and parties can retain copies. A transparency design can help expose inconsistent histories when appropriate monitoring and consistency checks exist. A public ledger anchor may help when independent parties need a common accepted reference and can justify its additional operating model.","These are design families, not interchangeable products. RFC 9162 supplies a concrete transparency example from certificate infrastructure; it is not an off-the-shelf IoT solution. Compare implemented designs for the actual task, including outages, retention, operator misconduct, correction handling and full cost."],"sources":["transparency","whitepaper"],"table":{"caption":"Design comparison · illustrative, not a product benchmark","columns":["Design","Useful property","Remaining dependency","Good reason to choose it"],"rows":[["Signed database log","Attributable records and an efficient query surface","Key security, retained copies and an accountable operator","One operator is acceptable; editing and private queries matter"],["Transparency service","Inspectable inclusion and consistency under its design","Log availability, monitors and response to inconsistent views","Public auditability is needed without general transaction settlement"],["Ledger anchor plus retained records","Common commitment and accepted ordering under network policy","Record availability, fees, services, governance and settlement","Independent parties benefit enough from a shared public reference"]]}},{"id":"minimum-public-data","title":"Anchor the minimum useful material","kind":"proposed","paragraphs":["Cheap blockspace is not a reason to publish every raw reading. An application may batch commitments while retaining detailed data under appropriate access controls. Decide what must be public and what recipients must preserve. A hash can still reveal information through guessing or correlation when its input is predictable; a compact commitment is not automatically a privacy solution.","Budget for the whole workflow: device operations, retained copies, queries, proof retrieval, wallet and service support, transaction costs and recovery. A throughput promotion answers neither whether anyone needs the service nor whether it is cheaper per successful user task. Useful demand, measured capacity and operator economics require separate evidence.","Corrections need a policy too. If a device was miscalibrated, preserve the original record and a linked correction with the reason and authority. Do not describe immutable evidence as permanently correct interpretation. Readers need enough context to understand why the assessment changed."],"sources":["iot"]},{"id":"decision-worksheet","title":"Choose by the verification job","kind":"proposed","paragraphs":["Use the worksheet to name the parties, disputed fact, acceptable operator trust, retention plan and irreversible consequence. Compare all candidates against the same requirements. Choosing a database after that comparison is a successful outcome when it best serves the user.","The sample manifest is deliberately synthetic and contains no transaction ID, proof or claim of deployment. It shows which categories of material a recovery package might need: record files, schema, device/key context, commitment, proof, acceptance reference and access instructions. A real implementation should specify exact formats and produce a successful independent restore before calling that package tested.","If the original application disappears, another reader should still know what the record means, where the authorized bytes are kept and what can be verified. This is where public proof and practical preservation work together. Link an actual test result when available, including failures and the scope of what was recovered."],"sources":["whitepaper"],"steps":["Name the exact shared fact and why independent verification matters.","Choose acceptable trust in devices, operators and settlement providers.","Compare retention, privacy, cost and failure recovery for each candidate.","Build the smallest bounded demonstration and record actual results.","Retain the evidence and revise the choice when the comparison changes."]}],"sources":[{"id":"iot","title":"The IoT usefulness question","url":"https://x.com/BHatooor13304/status/2106771161602204102","kind":"reported","checkedAt":"2026-10-05","note":"October 4 question about why IoT records need a blockchain. It motivates a design comparison, not a demand forecast."},{"id":"whitepaper","title":"Bitcoin whitepaper · sections 5, 6 and 8","url":"https://bitcoin.org/bitcoin.pdf","kind":"documented","checkedAt":"2026-10-05","note":"The original network, incentive and verification model. It does not document later BSV institutions."},{"id":"signatures","title":"NIST FIPS 186-5 · Digital Signature Standard","url":"https://csrc.nist.gov/pubs/fips/186-5/final","kind":"documented","checkedAt":"2026-10-05","note":"Signature verification addresses authenticity and integrity under key assumptions. It cannot establish that a sensor measured the world correctly."},{"id":"transparency","title":"RFC 9162 · Certificate Transparency v2","url":"https://www.rfc-editor.org/rfc/rfc9162.html","kind":"documented","checkedAt":"2026-09-05","note":"A concrete non-blockchain transparency design; not a drop-in IoT system. Inclusion, consistency, retention and monitoring are distinct responsibilities."}],"related":[{"title":"Proof and preservation","href":"/proof/merkle-proof-not-backup/","purpose":"Build the recovery package behind the commitment."},{"title":"Economic acceptance","href":"/guides/mining-incentives-and-economic-acceptance/","purpose":"Understand the conditions behind accepted ordering."},{"title":"Metanet recovery checklist","href":"https://metanet.fyi/overlays/recovery","purpose":"Inspect service continuity and recovery requirements."}],"downloads":[{"file":"iot-design-worksheet.md","label":"IoT design comparison worksheet","note":"Compare the same job across three designs.","path":"/assets/guides/iot-design-worksheet.md"},{"file":"synthetic-export-manifest.json","label":"Synthetic export manifest","note":"Illustrative only; no chain transaction or tested recovery.","path":"/assets/guides/synthetic-export-manifest.json"}],"changesConclusion":"A measured workflow can show that common commitments improve dispute handling or recovery enough to justify their cost. If ordinary signed records meet the need more simply, use them. Neither throughput nor a signature establishes real-world truth."},{"id":"answer:craig-wright-and-satoshi","path":"/answers/craig-wright-and-satoshi/","title":"Does the BSV case depend on Craig Wright being Satoshi?","format":"Evidence brief","topic":"History & reputation","depth":"Short answer","shortAnswer":"No. A wallet, protocol rule, transaction proof, or application does not become correct because of a person's biography. Craig Wright's identity campaign shaped BSV's reputation, and that cost cannot be wished away. But a serious evaluation can acknowledge the history, decline the identity claim, and test the present system directly.","description":"No identity claim is required. Software, network rules, economics, and actual use should stand or fall on inspectable evidence of their own.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["BSV is Craig","Faketoshi dependency","Craig coin","identity claim dependency","identity-war","reputation","clean-room","due-diligence"],"explanation":["A wallet permission can be inspected, a proof can be checked and a user task can be tested without resolving an identity claim. This separation makes evaluation possible; it does not erase institutional or funding history. Use the official judgment for legal history and the actual implementation for technical behavior."],"limits":["Separating the product case from a person does not erase decisions, institutions, or funding relationships shaped by that history.","A working demo proves a bounded capability, not adoption, sound governance, or commercial success."],"sources":[{"title":"Bitcoin Request for Comments index","url":"https://bsv.brc.dev/","note":"Public specifications and proposal history; a published specification is not itself proof of independent adoption.","accessedAt":"2026-10-05","type":"Primary"},{"title":"Project Babbage quickstarts","url":"https://docs.projectbabbage.com/docs/quickstarts","note":"Runnable wallet-mediated application paths. Maintainer documentation is useful for reproduction, not independent adoption proof.","accessedAt":"2026-10-05","type":"Reference"},{"title":"BSV Blockchain GitHub organization","url":"https://github.com/bsv-blockchain","note":"Current repository inventory and maintenance history; activity is not the same as production use.","accessedAt":"2026-10-05","type":"Code"},{"title":"P2PPSR GitHub organization","url":"https://github.com/p2ppsr","note":"Independent application and infrastructure repositories; evaluate project status and licenses individually.","accessedAt":"2026-10-05","type":"Code"}],"related":[{"href":"https://www.judiciary.uk/judgments/copa-v-wright/","label":"Official COPA v Wright record","purpose":"Read the primary record directly."},{"href":"/proof/#workflow-evidence","label":"Workflow evidence and its limits","purpose":"See what is documented, reported and still untested."}],"changesConclusion":"If ordinary use, support, or user rights actually required accepting a contested identity claim, this separation would fail. More independent implementations and operators would make it stronger."},{"id":"answer:institutional-capture-and-independence","path":"/answers/institutional-capture-and-independence/","title":"Is BSV captured by a small set of institutions and patrons?","format":"Evidence brief","topic":"Institutions","depth":"Short answer","shortAnswer":"BSV has visible institutional concentration: the Association describes a stewardship role and the published Network Access Rules assign it rule and directive functions. That does not establish control over every builder. Independent responsibility becomes credible when projects disclose their dependencies and demonstrate usable challenge, continuity and replacement paths.","description":"Concentration is a legitimate dependency question. It should be answered with an inventory of authority, funding, code ownership, operators, and replaceability—not a decentralization slogan.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["Calvin-controlled","nChain capture","CoinGeek control","single patron ecosystem","institutional dependency","governance","funding","independence","concentration","dependencies"],"explanation":["An independent wallet, application or service can exercise responsibility within its own scope. That matters when it can inspect rules, retain records and continue useful work without one provider. Repository ownership alone does not establish independent funding, administration or a usable replacement path.","A plural stewardship model asks that competence be transferable, institutions correctable and stewards able to cooperate. It is a framework for improving accountability. The Association’s documented directive powers remain part of the current authority map."],"limits":["This site does not currently possess a complete, audited funding and beneficial-ownership map for the ecosystem.","Institutional support can fund useful public goods; the risk is undisclosed dependency and lack of credible replacement paths."],"sources":[{"title":"BSV Association — mission and projects","url":"https://association.bsvblockchain.org/","note":"The institution's own description of its stewardship, standards, tooling, and ecosystem role.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV protocol documentation","url":"https://protocol.bsvblockchain.org/","note":"Association-maintained protocol reference and its stated stewardship model.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV Blockchain GitHub organization","url":"https://github.com/bsv-blockchain","note":"Current repository inventory and maintenance history; activity is not the same as production use.","accessedAt":"2026-10-05","type":"Code"},{"title":"P2PPSR GitHub organization","url":"https://github.com/p2ppsr","note":"Independent application and infrastructure repositories; evaluate project status and licenses individually.","accessedAt":"2026-10-05","type":"Code"}],"related":[{"href":"/guides/stewardship-and-authority/","label":"Stewardship and authority","purpose":"Inspect the authority matrix and reusable responsibility statement."}],"changesConclusion":"Broader independent funding, implementations, operators, and transparent governance would reduce capture risk. Evidence that critical projects cannot act or survive without a single patron would increase it."},{"id":"answer:scam-cult-and-grift-labels","path":"/answers/scam-cult-and-grift-labels/","title":"How should a serious person respond to the “scam” or “cult” label?","format":"Evidence brief","topic":"Trust & reputation","depth":"Short answer","shortAnswer":"Do not answer contempt with demands for loyalty. Translate the label into testable questions: What was promised? What works now? Who benefits? What is the user's risk? Which claims failed? Can the user leave? Evidence cannot prove that every participant is sincere, but a product can avoid manipulative patterns by making bounded claims, exposing dependencies, and offering a low-risk test path.","description":"A label is not a technical analysis, but it often points to a valid proof problem: were people sold allegiance and price stories instead of working utility and disclosed risk?","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["BSV scam","BSV cult","bagholder grift","affinity scam","trust","reputation","claims","proof","consumer-risk"],"explanation":["For a claim that a wallet works with an app, the useful record is the promised behavior, exact versions, reported failure, maintainer response and successful retest if one exists. The October compatibility case gives a concrete example with the outcome still unverified. A functioning product would not, by itself, answer a separate report of deception or harm. Address that report on its own evidence and acknowledge our own conduct where relevant."],"limits":["This site cannot certify the integrity of every BSV project, promoter, founder, or transaction.","The absence of a proven accusation is not proof that a product is safe; users still need ordinary diligence."],"sources":[{"title":"BSV TypeScript stack","url":"https://github.com/bsv-blockchain/ts-stack","note":"Current monorepo for SDK, wallet, overlay, messaging, middleware, helpers, infrastructure, documentation, and conformance vectors.","accessedAt":"2026-10-05","type":"Code"},{"title":"BSV Hub demo catalog","url":"https://hub.bsvblockchain.org/demos-and-onboardings/demo-solutions/demos","note":"Maintainer-curated catalog with repository and status claims. Recheck every live URL, repository, and usage claim.","accessedAt":"2026-10-05","type":"Reference"}],"related":[{"href":"/guides/wallet-compatibility-and-safe-changes/","label":"When a conforming wallet breaks an app","purpose":"Compare interface checks with versioned user-workflow evidence."}],"changesConclusion":"Repeated material misrepresentation, hidden conflicts, or inability to demonstrate promised utility would justify a harsher assessment. Consistent delivery, transparent gaps, and independently verified use would improve it."},{"id":"answer:users-adoption-and-use-cases","path":"/answers/users-adoption-and-use-cases/","title":"Where are the users?","format":"Evidence brief","topic":"Adoption","depth":"Short answer","shortAnswer":"BSV has live infrastructure, applications, wallets, and inspectable transactions. Those facts establish availability, not broad adoption. A credible adoption case needs defined active users, retention cohorts, successful workflows, economic activity, time windows, bot treatment, and independently checkable methods. Until that exists, say exactly what can be verified and keep the broader claim unresolved.","description":"The public adoption proof remains thinner than the technical inventory. That gap should be measured, not covered with anecdotes or raw transaction counts.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["no users","users rejected BSV","fake transaction volume","no adoption","adoption","retention","measurement","applications","users"],"explanation":["Public wallet interfaces, code and transaction inspection make concrete work possible: a user-authorized action, a payment or a retained proof. The evidence inventory distinguishes those inspection surfaces from a tested workflow and a measured user cohort. We have not established broad retained-user adoption from the sources reviewed for this site; that is a scoped evidence gap, not a claim that no such data can exist."],"limits":["Private product analytics may exist but cannot be treated as public proof without methods and auditable aggregates.","This site does not infer user counts from block transactions or repository activity."],"sources":[{"title":"WhatsOnChain explorer","url":"https://whatsonchain.com/","note":"Current block and transaction inspection surface; explorer availability and interpretation remain third-party dependencies.","accessedAt":"2026-10-05","type":"Live"},{"title":"BSV Blockchain GitHub organization","url":"https://github.com/bsv-blockchain","note":"Current repository inventory and maintenance history; activity is not the same as production use.","accessedAt":"2026-10-05","type":"Code"},{"title":"BSV Hub demo catalog","url":"https://hub.bsvblockchain.org/demos-and-onboardings/demo-solutions/demos","note":"Maintainer-curated catalog with repository and status claims. Recheck every live URL, repository, and usage claim.","accessedAt":"2026-10-05","type":"Reference"}],"related":[{"href":"/proof/#workflow-evidence","label":"Workflow evidence and its limits","purpose":"See what is documented, reported and still untested."}],"changesConclusion":"Methodologically sound, repeatable retention and economic-use data would strengthen the adoption case. Continued inability to produce it keeps this objection unresolved even if tooling improves."},{"id":"answer:economically-necessary-use-cases","path":"/answers/economically-necessary-use-cases/","title":"Does anything economically need BSV?","format":"Evidence brief","topic":"Product fit","depth":"Short answer","shortAnswer":"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.","description":"Correct: a cheap transaction is a component, not a product. The case must be a workflow where public proofs, tiny payments, or portable signed records change user value or unit economics.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["no use case","solution looking for a problem","cheap fees are not utility","nothing needs BSV","product-market-fit","micropayments","proofs","signed-data","unit-economics"],"explanation":["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."],"limits":["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."],"sources":[{"title":"BRC-105 — HTTP service monetization framework","url":"https://bsv.brc.dev/payments/0105","note":"Specification for authenticated HTTP 402 pay-per-request flows; implementation and demand must be verified separately.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV TypeScript stack","url":"https://github.com/bsv-blockchain/ts-stack","note":"Current monorepo for SDK, wallet, overlay, messaging, middleware, helpers, infrastructure, documentation, and conformance vectors.","accessedAt":"2026-10-05","type":"Code"},{"title":"Project Babbage quickstarts","url":"https://docs.projectbabbage.com/docs/quickstarts","note":"Runnable wallet-mediated application paths. Maintainer documentation is useful for reproduction, not independent adoption proof.","accessedAt":"2026-10-05","type":"Reference"}],"related":[{"href":"/guides/iot-records-and-shared-evidence/","label":"When shared evidence helps an IoT record","purpose":"Compare a ledger, transparency service and signed database for the same task."}],"changesConclusion":"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."},{"id":"answer:builder-reputational-risk","path":"/answers/builder-reputational-risk/","title":"Does building on BSV create unacceptable reputational risk?","format":"Evidence brief","topic":"Builder strategy","depth":"Short answer","shortAnswer":"A builder can lose credibility by inheriting claims they never needed. The safer path is to lead with the user problem, state that BSV is the present rail, disclose governance and license dependencies, avoid price and identity claims, and provide a runnable proof plus an exit map. That does not eliminate reputational exposure; it makes the product legible on its own merits.","description":"That is a real commercial risk affecting hiring, partnerships, fundraising, and distribution. It can be reduced by clean-room product framing and evidence, not denied.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["career risk","toxic association","builder stain","partner risk","builders","reputation","clean-room","disclosure","go-to-market"],"explanation":["Describe one task, the current rail, exact dependencies, source revision, expected result and known limits. Include an observed result only if the flow was actually run, and state what users can export or replace. This makes a product understandable on its merits. The reputational concern is plausible; this review does not measure lost customers or attribute a partner’s decision without their evidence."],"limits":["Good messaging cannot compensate for a product without users or for undisclosed control and license risks.","Some organizations will reasonably decide the residual association is unacceptable."],"sources":[{"title":"Bitcoin Request for Comments index","url":"https://bsv.brc.dev/","note":"Public specifications and proposal history; a published specification is not itself proof of independent adoption.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV TypeScript stack","url":"https://github.com/bsv-blockchain/ts-stack","note":"Current monorepo for SDK, wallet, overlay, messaging, middleware, helpers, infrastructure, documentation, and conformance vectors.","accessedAt":"2026-10-05","type":"Code"},{"title":"Metanet Academy Builder Lab","url":"https://metanetacademy.com/builder-lab","note":"Ungated architecture, diagnostics, and working-flow walkthroughs for builders.","accessedAt":"2026-10-05","type":"Live"}],"related":[{"href":"/proof/#workflow-evidence","label":"Workflow evidence and its limits","purpose":"See what is documented, reported and still untested."},{"href":"https://metanet.fyi/overlays/recovery","label":"Metanet recovery checklist","purpose":"Define what another operator or user needs to continue the work."}],"changesConclusion":"Independent products winning users and partners through product-led evaluation would reduce the risk. Continued faction-first promotion or hidden dependencies would increase it."},{"id":"answer:is-bsv-really-bitcoin","path":"/answers/is-bsv-really-bitcoin/","title":"Is BSV “really Bitcoin”?","format":"Evidence brief","topic":"Protocol identity","depth":"Short answer","shortAnswer":"BSV shares Bitcoin ancestry and argues that its design better preserves scalable peer-to-peer cash, script, SPV, and miner-set limits. BTC has the dominant market and social claim to the Bitcoin ticker and name. A person need not settle that naming dispute to compare current protocols: inspect chain history, rules, fees, proof model, governance, software, and use.","description":"Chain identity is partly historical and social. For a product decision, compare implemented design goals and current rules instead of demanding agreement on a purity title.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["not Bitcoin","fork legitimacy","real Bitcoin","BTC is Bitcoin","history","fork","protocol","design-goals","naming"],"explanation":["The productive comparison names an implemented property and its evidence. Ancestry, design interpretation, naming convention and suitability for a task answer different questions; none can substitute for all the others. This is a framework for comparison, not a ranking or a legal claim over a name."],"limits":["A claimed design lineage does not prove present security, adoption, or economic success.","Calling BSV Bitcoin does not require others to surrender the conventional BTC usage of the term."],"sources":[{"title":"Bitcoin: A Peer-to-Peer Electronic Cash System","url":"https://bitcoin.org/bitcoin.pdf","note":"The original paper; read its proof-of-work, incentives, privacy, and SPV claims in their own terms.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV protocol documentation","url":"https://protocol.bsvblockchain.org/","note":"Association-maintained protocol reference and its stated stewardship model.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV Network Access Rules","url":"https://docs.bsvblockchain.org/network-access-rules/network-access-rules","note":"The published agreement governing the Association-node relationship; it is evidence of the stated rules, not independent proof of their application.","accessedAt":"2026-10-05","type":"Primary"}],"related":[{"href":"/guides/mining-incentives-and-economic-acceptance/","label":"Mining incentives and economic acceptance","purpose":"Follow the actors, incentive mechanism and conditions for convergence."},{"href":"/guides/iot-records-and-shared-evidence/","label":"When shared evidence helps an IoT record","purpose":"Compare a ledger, transparency service and signed database for the same task."}],"changesConclusion":"Material protocol changes can alter the design comparison. No technical discovery is likely to eliminate the social component of a contested name."},{"id":"answer:satoshis-vision-claim","path":"/answers/satoshis-vision-claim/","title":"Is “Satoshi's Vision” a defensible description?","format":"Evidence brief","topic":"Protocol identity","depth":"Short answer","shortAnswer":"If “Satoshi's Vision” means scalable peer-to-peer electronic cash using proof of work, SPV, script, and fees, it names a design interpretation that can be compared with the paper and software. If it means that every BSV institutional, legal, or licensing choice was authored or mandated by Satoshi, it overclaims. Builders are usually better served by naming the specific design property.","description":"The phrase is defensible only when defined narrowly as a set of design goals. It should not imply that every current governance choice appears in, or is compelled by, the whitepaper.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["Satoshi's Vision dishonesty","Satoshi did not write NAR","original vision slogan","Satoshi","design-goals","governance","messaging","history"],"explanation":["The affirmative design case concerns useful cash transactions, fee-funded operation, programmable conditions and lightweight verification. Each is a mechanism that can be evaluated. Current institutions and directives require their own sources; attributing them to an original vision supplies neither evidence of effective operation nor approval of every later choice."],"limits":["No brief can establish the private intent of a pseudonymous author beyond the published record.","Design fidelity does not prove that a current implementation is secure, useful, or well governed."],"sources":[{"title":"Bitcoin: A Peer-to-Peer Electronic Cash System","url":"https://bitcoin.org/bitcoin.pdf","note":"The original paper; read its proof-of-work, incentives, privacy, and SPV claims in their own terms.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV Network Access Rules","url":"https://docs.bsvblockchain.org/network-access-rules/network-access-rules","note":"The published agreement governing the Association-node relationship; it is evidence of the stated rules, not independent proof of their application.","accessedAt":"2026-10-05","type":"Primary"},{"title":"Bitcoin SV node — Open BSV License","url":"https://github.com/bitcoin-sv/bitcoin-sv/blob/master/LICENSE","note":"Operative repository license. Version 5 conditions derived software use on BSV blockchains.","accessedAt":"2026-10-05","type":"Primary"}],"related":[{"href":"/guides/mining-incentives-and-economic-acceptance/","label":"Mining incentives and economic acceptance","purpose":"Follow the actors, incentive mechanism and conditions for convergence."},{"href":"/guides/stewardship-and-authority/","label":"Stewardship and authority","purpose":"Inspect the authority matrix and reusable responsibility statement."}],"changesConclusion":"New primary historical material could refine an intent claim. Current system evaluation should still distinguish original publication from later choices."},{"id":"answer:proof-of-work-and-honest-nodes","path":"/answers/proof-of-work-and-honest-nodes/","title":"Can nodes reject a longer proof-of-work chain and still claim Bitcoin rules?","format":"Evidence brief","topic":"Consensus & security","depth":"Short answer","shortAnswer":"Block production, independent verification and economic acceptance are different jobs. A non-miner can check and refuse a result; it cannot produce replacement blocks or force everyone else to agree. Credible, coordinated rejection can reduce a profit-seeking attack’s payoff, conditional on enforcement, compatible settlement policies and continued accepted mining. The current BSV rules also assign institutional directive powers that need separate scrutiny.","description":"This is a serious protocol-governance dispute. Proof of work coordinates valid history; the hard questions are who defines validity, what policies can change it, and how operators learn the rules.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["honest nodes longest chain","PoW chain switch","Nakamoto consensus violation","dishonest reorg","proof-of-work","chain-selection","validity","NAR","reorg"],"explanation":["A non-mining verifier can check evidence and refuse a payment without producing blocks. A business can delegate checking to a wallet or service while depending on its policies. Miners still supply work and continuing blocks. Successful settlement needs the relevant participants to apply compatible policies.","Our economic argument is conditional: if effective rejection denies the targeted payoff and recognition of attack-branch rewards in the target economy, accepted mining can be more attractive. Local refusal does not compel others. Sustained sabotage, outside incentives, disagreements and interrupted production remain material.","SV Node’s protective mechanisms and the Association’s published directives document possible responses, not guaranteed convergence. Judge honesty by identifiable rules and conduct, not agreement with a preferred conclusion."],"limits":["This brief does not determine whether a particular historical reorganization contained invalid transactions or breached a contract.","Following more work alone does not solve eclipse attacks, double-spend exposure, or application confirmation policy."],"sources":[{"title":"Bitcoin: A Peer-to-Peer Electronic Cash System","url":"https://bitcoin.org/bitcoin.pdf","note":"The original paper; read its proof-of-work, incentives, privacy, and SPV claims in their own terms.","accessedAt":"2026-10-05","type":"Primary"},{"title":"Network Access Rules — Part III, Enforcement Rules","url":"https://docs.bsvblockchain.org/network-access-rules/network-access-rules/part-iii-enforcement-rules","note":"Directive events, restrictions, and permitted steps including freezes, reassignment, peer controls, and block invalidation.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV Alert System documentation","url":"https://docs.bsvblockchain.org/network-topology/nodes/sv-node/alert-system","note":"Technical description of signed informational and directive messages delivered to nodes.","accessedAt":"2026-10-05","type":"Primary"},{"title":"SV Node configuration reference","url":"https://docs.bsvblockchain.org/network-topology/nodes/sv-node/installation/sv-node/configuration","note":"Current operator-facing configuration surface, including chain and policy controls.","accessedAt":"2026-10-05","type":"Primary"}],"related":[{"href":"/guides/mining-incentives-and-economic-acceptance/","label":"Mining incentives and economic acceptance","purpose":"Follow the actors, incentive mechanism and conditions for convergence."},{"href":"/guides/stewardship-and-authority/","label":"Stewardship and authority","purpose":"Inspect the authority matrix and reusable responsibility statement."}],"changesConclusion":"Clear ex-ante rules, public incident data, and independently reproducible node behavior would reduce ambiguity. Secret, retroactive, or inconsistently applied rules would make the criticism stronger."},{"id":"answer:governance-dar-and-network-rules","path":"/answers/governance-dar-and-network-rules/","title":"Can BSV freeze or reassign coins?","format":"Evidence brief","topic":"Asset recovery","depth":"Short answer","shortAnswer":"Yes, the Network Access Rules list directives that may freeze specified UTXOs, reassign frozen coins, alter peer access, or invalidate specified blocks after defined events. A reassignment enforced by nodes is not the same mechanism as forging the owner's signature or learning a private key, but it can change which spend the network accepts. That weakens pure bearer finality and creates legal-process and governance dependencies.","description":"The published governance surface is real and consequential. It should be evaluated as a disputed-property recovery tradeoff—not denied or confused with ordinary wallet authority.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["DAR confiscation","coin seizure","freeze and reassign","court-controlled transfer","NAR recovery","DAR","NAR","asset-recovery","bearer-finality","governance"],"explanation":["The stated recovery rationale concerns disputed or recoverable property. Whether a particular use is justified depends on its evidence, authority and process; the design rationale is not proof of correct use. Part III contains different event categories, so do not assume every directive has the same court-order prerequisite.","A network-enforced change to accepted spending is consequential even when it does not extract a user’s key or forge an application signature. Keep the accepted-coin effect separate from the cryptographic authority needed for unrelated app operations."],"limits":["Published restrictions do not guarantee correct courts, narrow use, transparent execution, or effective recourse.","The mechanism does not, by itself, disclose private keys, decrypt data, or let an application impersonate a user.","This site offers no legal conclusion about title, enforceability, or jurisdiction."],"sources":[{"title":"Network Access Rules — Part III, Enforcement Rules","url":"https://docs.bsvblockchain.org/network-access-rules/network-access-rules/part-iii-enforcement-rules","note":"Directive events, restrictions, and permitted steps including freezes, reassignment, peer controls, and block invalidation.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV Alert System documentation","url":"https://docs.bsvblockchain.org/network-topology/nodes/sv-node/alert-system","note":"Technical description of signed informational and directive messages delivered to nodes.","accessedAt":"2026-10-05","type":"Primary"},{"title":"Network Access Rules — Part IV, Dispute Resolution Rules","url":"https://docs.bsvblockchain.org/network-access-rules/network-access-rules/part-iv-dispute-resolution-rules","note":"Published dispute path; inspect scope, forum, standing, and remedies rather than assuming an appeal mechanism.","accessedAt":"2026-10-05","type":"Primary"}],"related":[{"href":"/guides/stewardship-and-authority/","label":"Stewardship and authority","purpose":"Inspect the authority matrix and reusable responsibility statement."}],"changesConclusion":"Secret directives, broad triggers, unavailable challenge, or implementation beyond published authority would worsen the assessment. Narrow, independently audited, transparent process with effective correction would improve it."},{"id":"answer:bsv-association-governance","path":"/answers/bsv-association-governance/","title":"Does the BSV Association function as a central authority?","format":"Evidence brief","topic":"Governance","depth":"Short answer","shortAnswer":"The Association is not merely an informal developer group. Its own materials describe protocol stewardship, and the NAR treat it as a party with rule and directive functions. Nodes still operate infrastructure and perform proof of work, but that does not erase the institutional layer. People who require authority-minimized bearer money may reject it; others may value explicit commercial rules. Both should evaluate the actual documents.","description":"BSV does include explicit institutional governance. The defensible question is whether its scope, checks, transparency, and fit are acceptable for a use case.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["BSVA central authority","compliance chain","Association controls rules","centralized governance","BSVA","governance","authority","nodes","rules"],"explanation":["Maintainers, node operators, wallets, overlays and businesses perform different responsibilities. Independent participants can examine evidence and continue work within those scopes. BRC-187 gives an authored framework for transferable competence and institutional correction; it is not an audit showing the framework has been achieved.","Plural application operators do not by themselves distribute Association directive authority. Assess who can amend rules, issue instructions, maintain software and control keys as separate questions. The downloadable matrix makes those distinctions explicit."],"limits":["Explicit rules are not automatically fair, decentralized, enforceable, or competently administered.","Node operation does not necessarily provide a practical veto if hashpower, connectivity, or licensing is concentrated."],"sources":[{"title":"Network Access Rules — Part I, Master Rules","url":"https://docs.bsvblockchain.org/network-access-rules/network-access-rules/part-i-master-rules","note":"Operative language on agreement, node participation, protocol compatibility, and Association responsibilities.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV Association — mission and projects","url":"https://association.bsvblockchain.org/","note":"The institution's own description of its stewardship, standards, tooling, and ecosystem role.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV protocol documentation","url":"https://protocol.bsvblockchain.org/","note":"Association-maintained protocol reference and its stated stewardship model.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV Alert System documentation","url":"https://docs.bsvblockchain.org/network-topology/nodes/sv-node/alert-system","note":"Technical description of signed informational and directive messages delivered to nodes.","accessedAt":"2026-10-05","type":"Primary"}],"related":[{"href":"/guides/stewardship-and-authority/","label":"Stewardship and authority","purpose":"Inspect the authority matrix and reusable responsibility statement."},{"href":"/guides/mining-incentives-and-economic-acceptance/","label":"Mining incentives and economic acceptance","purpose":"Follow the actors, incentive mechanism and conditions for convergence."}],"changesConclusion":"Stronger checks, transparent amendment history, broader operator independence, and credible exit would reduce concentration risk. Secret governance, unilateral expansion, or coerced adoption would increase it."},{"id":"answer:liquidity-delisting-and-operational-risk","path":"/answers/liquidity-delisting-and-operational-risk/","title":"Do delistings and weak liquidity make BSV unusable?","format":"Evidence brief","topic":"Market access","depth":"Short answer","shortAnswer":"Exchange listings, fiat ramps, depth, spreads, withdrawals, custody, accounting, and jurisdictional access can determine whether a BSV product is viable. They are not merely price complaints. Exposure depends on the workflow: a treasury or exchange product has far greater risk than an application that acquires small fee inventory and converts frequently. Never rely on a static exchange list.","description":"Liquidity and service access are real operational dependencies for some products and nearly incidental for others. They must be tested at decision time.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["delisted","no fiat ramps","weak liquidity","hard to buy","thin market","liquidity","exchanges","ramps","treasury","operations"],"explanation":["A listing or block explorer does not establish that you can fund and exit a workflow in your jurisdiction, at your required size and time. No current provider-access test was performed for this review. Use the worksheet below with the selected provider’s own terms and status pages, and leave an unsupported cell unknown.","Record the actual deposit and withdrawal support, network, account requirements, limits, fees and outage handling before making a consequential decision. A source-access date is not a successful withdrawal test."],"limits":["This site does not recommend an exchange, asset purchase, or treasury position.","Explorer or market aggregators are discovery tools; provider terms and working deposit/withdrawal paths are the decision evidence."],"sources":[{"title":"WhatsOnChain explorer","url":"https://whatsonchain.com/","note":"Current block and transaction inspection surface; explorer availability and interpretation remain third-party dependencies.","accessedAt":"2026-10-05","type":"Live"}],"related":[{"href":"/assets/guides/operational-access.csv","label":"Operational access worksheet","purpose":"Record provider-specific primary evidence and unknowns without implying current availability."}],"changesConclusion":"Broader durable access, deeper markets, and reliable settlement would reduce the risk. Provider exits, shallow books, blocked withdrawals, or increasing concentration would raise it immediately."},{"id":"answer:price-and-flippening-contamination","path":"/answers/price-and-flippening-contamination/","title":"Do price and “flippening” narratives invalidate the builder case?","format":"Evidence brief","topic":"Messaging discipline","depth":"Short answer","shortAnswer":"Token price cannot validate a protocol claim, and a protocol demo cannot justify a price forecast. Combining them makes it harder for users to distinguish utility from financial promotion. A builder case should stand on workflow outcomes, total cost, reliability, user control, security, and adoption—while treating any treasury exposure as a disclosed risk.","description":"They do not invalidate a working product, but they contaminate its credibility and attract the wrong success metrics.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["flippening","price vindication","number go up proof","Craig was right trade","price","messaging","builders","financial-promotion","metrics"],"explanation":["Useful product measures include completed tasks, permission completion, cost per success, return use, recovery success and independently reproduced failures. None requires a price prediction. A useful application can still expose a user or operator to conversion and liquidity risk; name that operational exposure separately."],"limits":["Some products legitimately need liquidity and price-risk management; excluding price prophecy does not remove those dependencies.","This site does not forecast, recommend, or assess the investment merits of BSV."],"sources":[{"title":"Bitcoin Request for Comments index","url":"https://bsv.brc.dev/","note":"Public specifications and proposal history; a published specification is not itself proof of independent adoption.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV TypeScript stack","url":"https://github.com/bsv-blockchain/ts-stack","note":"Current monorepo for SDK, wallet, overlay, messaging, middleware, helpers, infrastructure, documentation, and conformance vectors.","accessedAt":"2026-10-05","type":"Code"}],"related":[{"href":"/proof/#workflow-evidence","label":"Workflow evidence and its limits","purpose":"See what is documented, reported and still untested."},{"href":"/answers/liquidity-delisting-and-operational-risk/","label":"Liquidity and operational access","purpose":"Evaluate the actual funding and exit path."}],"changesConclusion":"No market movement should change a technical conclusion by itself. Evidence that a product has no demand beyond speculative promotion would weaken the product case."},{"id":"answer:tribalism-and-ally-tone","path":"/answers/tribalism-and-ally-tone/","title":"Why does BSV discourse so often feel tribal or abusive?","format":"Evidence brief","topic":"Messaging discipline","depth":"Short answer","shortAnswer":"Public technical communities often form identities, but builders are not obliged to inherit the worst behavior of one. The useful discipline is simple: do not amplify contempt, do not require faction membership, answer the strongest concern, link proof, name gaps, and leave low-substance fights alone. A calm page cannot fix the entire culture, but it can set a different interaction contract.","description":"Factional tone is a real credibility and distribution cost. Friendly hostility does not become helpful because it comes from an ally.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["toxic BSV community","BSV tribalism","abusive allies","BTC enemy framing","community","tone","tribalism","reply-discipline","trust"],"explanation":["Answer a substantive question even when it comes from a critic. Correct our own overstatements and apply the same evidentiary burden to supportive claims. When someone reports harm, acknowledge the relevant conduct and respect their boundary; a product link need not be the next move.","In a support conversation, an acknowledgment should lead to a responsible owner and verifiable follow-through. The October compatibility exchange improved once the specific implementation and testing gaps were discussed. That constructive turn does not establish that the affected workflow was repaired."],"limits":["No editorial policy controls independent speakers or proves that one community is uniquely toxic.","Civility is not a substitute for answering a hard technical or governance objection."],"sources":[{"title":"BRC source repository","url":"https://github.com/bsv-blockchain/BRCs","note":"Version history, proposals, and contribution surface for the BRC corpus.","accessedAt":"2026-10-05","type":"Code"},{"title":"BSV TypeScript stack","url":"https://github.com/bsv-blockchain/ts-stack","note":"Current monorepo for SDK, wallet, overlay, messaging, middleware, helpers, infrastructure, documentation, and conformance vectors.","accessedAt":"2026-10-05","type":"Code"}],"related":[{"href":"/guides/wallet-compatibility-and-safe-changes/","label":"When a conforming wallet breaks an app","purpose":"Compare interface checks with versioned user-workflow evidence."}],"changesConclusion":"Sustained builder-first norms and visible correction behavior would improve the environment. Rewarding harassment, loyalty tests, or enemy narratives would worsen it."},{"id":"answer:show-working-product-proof","path":"/answers/show-working-product-proof/","title":"What can a skeptical person actually try?","format":"Evidence brief","topic":"Product proof","depth":"Short answer","shortAnswer":"A useful first test is not ‘join the ecosystem.’ It is: open a documented app, connect a compatible wallet, inspect the requested permission, perform one low-value action, and inspect the resulting wallet history, transaction, or proof. The quickstarts, Builder Lab, public BRCs, and TypeScript stack provide starting points. They still need maintained fixtures and independent reproduction reports.","description":"That request is an opportunity. Every capability claim should lead to a bounded, reproducible path with expected output and honest failure handling.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["show demos","what can I try","screenshots or it didn't happen","working product","demo","quickstart","proof","conversion","reproduction"],"explanation":["Start with passive source and documentation inspection before connecting a wallet or spending. Then name the app, wallet, versions, prerequisites, requested permissions, expected output and measured result. Public examples and maintainer claims should stay distinct from independent reproductions.","The evidence records below include the current public compatibility report and two documented inspection paths. They deliberately mark unrun flows as not tested. A useful proof package preserves failure and resolution evidence as well as a demonstration."],"limits":["A maintainer-authored demo is not independent verification.","One successful path does not establish security, accessibility, retention, scale, or business viability."],"sources":[{"title":"Project Babbage quickstarts","url":"https://docs.projectbabbage.com/docs/quickstarts","note":"Runnable wallet-mediated application paths. Maintainer documentation is useful for reproduction, not independent adoption proof.","accessedAt":"2026-10-05","type":"Reference"},{"title":"Metanet Academy Builder Lab","url":"https://metanetacademy.com/builder-lab","note":"Ungated architecture, diagnostics, and working-flow walkthroughs for builders.","accessedAt":"2026-10-05","type":"Live"},{"title":"BSV TypeScript stack","url":"https://github.com/bsv-blockchain/ts-stack","note":"Current monorepo for SDK, wallet, overlay, messaging, middleware, helpers, infrastructure, documentation, and conformance vectors.","accessedAt":"2026-10-05","type":"Code"}],"related":[{"href":"/proof/#workflow-evidence","label":"Workflow evidence and its limits","purpose":"See what is documented, reported and still untested."},{"href":"/guides/wallet-compatibility-and-safe-changes/","label":"When a conforming wallet breaks an app","purpose":"Compare interface checks with versioned user-workflow evidence."}],"changesConclusion":"Repeated clean-environment reproduction would strengthen each bounded capability claim. Broken, undocumented, or maintainer-only flows would weaken it."},{"id":"answer:onboarding-and-acronym-overload","path":"/answers/onboarding-and-acronym-overload/","title":"Is BSV too complicated to build on?","format":"Evidence brief","topic":"Developer experience","depth":"Short answer","shortAnswer":"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.","description":"The cognitive-load objection is valid. A newcomer should start with one user outcome and a high-level API, then reveal lower layers only when they solve a real problem.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["too many acronyms","too complex to build","BRC overload","developer friction","onboarding","DX","glossary","quickstart","complexity"],"explanation":["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."],"limits":["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."],"sources":[{"title":"BRC-100 — Unified wallet-to-application interface","url":"https://bsv.brc.dev/wallet/0100","note":"The current unified interface covering wallet actions, signatures, encryption, certificates, permissions, and discovery.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV TypeScript stack","url":"https://github.com/bsv-blockchain/ts-stack","note":"Current monorepo for SDK, wallet, overlay, messaging, middleware, helpers, infrastructure, documentation, and conformance vectors.","accessedAt":"2026-10-05","type":"Code"},{"title":"Project Babbage quickstarts","url":"https://docs.projectbabbage.com/docs/quickstarts","note":"Runnable wallet-mediated application paths. Maintainer documentation is useful for reproduction, not independent adoption proof.","accessedAt":"2026-10-05","type":"Reference"}],"related":[{"href":"/proof/#workflow-evidence","label":"Workflow evidence and its limits","purpose":"See what is documented, reported and still untested."},{"href":"/guides/wallet-compatibility-and-safe-changes/","label":"When a conforming wallet breaks an app","purpose":"Compare interface checks with versioned user-workflow evidence."},{"href":"https://metanet.fyi/","label":"Metanet application model","purpose":"Start with plain-language concepts before protocol terminology."}],"changesConclusion":"Fast, repeatable completion by unaffiliated builders would weaken the complexity objection. Fragile setup, undocumented concepts, or hidden services would strengthen it."},{"id":"answer:brc100-interoperability-and-portability","path":"/answers/brc100-interoperability-and-portability/","title":"Is BRC-100 real interoperability or one vendor's interface?","format":"Evidence brief","topic":"Wallets & standards","depth":"Short answer","shortAnswer":"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.","description":"That is the right proof standard. BRC-100 is a substantial public interface; interoperability depends on conforming independent implementations and observable compatibility.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["BRC-100 one vendor","wallet interoperability unproven","paper standard","Babbage API","BRC-100","wallets","conformance","interoperability","standards"],"explanation":["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."],"limits":["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."],"sources":[{"title":"BRC-100 — Unified wallet-to-application interface","url":"https://bsv.brc.dev/wallet/0100","note":"The current unified interface covering wallet actions, signatures, encryption, certificates, permissions, and discovery.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BRC source repository","url":"https://github.com/bsv-blockchain/BRCs","note":"Version history, proposals, and contribution surface for the BRC corpus.","accessedAt":"2026-10-05","type":"Code"},{"title":"BSV TypeScript conformance corpus","url":"https://github.com/bsv-blockchain/ts-stack/tree/main/conformance","note":"Language-neutral vectors and runners. Inspect current coverage and parity before calling the whole interface interoperable.","accessedAt":"2026-10-05","type":"Code"}],"related":[{"href":"/guides/wallet-compatibility-and-safe-changes/","label":"When a conforming wallet breaks an app","purpose":"Compare interface checks with versioned user-workflow evidence."},{"href":"https://metanet.fyi/overlays/recovery","label":"Metanet recovery checklist","purpose":"Define what another operator or user needs to continue the work."}],"changesConclusion":"Multiple independent implementations passing broad shared tests would materially strengthen the claim. Interface drift, uncovered methods, or vendor-only behavior would weaken it."},{"id":"answer:user-data-and-service-portability","path":"/answers/user-data-and-service-portability/","title":"Can users actually leave a wallet, app, or overlay?","format":"Evidence brief","topic":"Portability","depth":"Short answer","shortAnswer":"A user may control signing keys while still depending on one wallet database, hosted overlay, certificate issuer, lookup service, or application schema. BRC-100 and the overlay stack define useful interfaces, but each product must prove what is exportable, intelligible, restorable, and replaceable. The honest output is a layer-by-layer exit matrix and a tested migration.","description":"Correct. Portability is an operational property demonstrated by export, import, discovery, replacement, and recovery—not inferred from public keys or blockchain storage.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["user lock-in","data exit","wallet migration","overlay dependency","portable data","portability","export","migration","wallet","overlays","user-control"],"explanation":["Signing authority is one layer. Recovery may also require derivation or wallet records, transaction history, certificates, schemas, private state, media, indexes and access instructions. A seed alone is not a promise that every implementation can reconstruct these materials.","A retained proof helps verify a particular record. It does not establish that a lookup service returned all relevant records, that its view is fresh, or that a previously included output remains unspent. Define the recovery packet, then perform a scoped restore with the original dependency unavailable before calling it tested."],"limits":["This site has not independently validated a full migration across every wallet and service represented in the ecosystem.","Portability within BSV does not equal portability to another settlement rail."],"sources":[{"title":"BRC-100 — Unified wallet-to-application interface","url":"https://bsv.brc.dev/wallet/0100","note":"The current unified interface covering wallet actions, signatures, encryption, certificates, permissions, and discovery.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV TypeScript stack","url":"https://github.com/bsv-blockchain/ts-stack","note":"Current monorepo for SDK, wallet, overlay, messaging, middleware, helpers, infrastructure, documentation, and conformance vectors.","accessedAt":"2026-10-05","type":"Code"},{"title":"BSV TypeScript conformance corpus","url":"https://github.com/bsv-blockchain/ts-stack/tree/main/conformance","note":"Language-neutral vectors and runners. Inspect current coverage and parity before calling the whole interface interoperable.","accessedAt":"2026-10-05","type":"Code"}],"related":[{"href":"/proof/merkle-proof-not-backup/","label":"Proof, retention and recovery","purpose":"Separate a retained inclusion proof from current state and a recoverable application."},{"href":"https://metanet.fyi/overlays/recovery","label":"Metanet recovery checklist","purpose":"Define what another operator or user needs to continue the work."},{"href":"/guides/wallet-compatibility-and-safe-changes/","label":"When a conforming wallet breaks an app","purpose":"Compare interface checks with versioned user-workflow evidence."}],"changesConclusion":"Routine, independently reproduced migrations would strengthen user-ownership claims. Proprietary stores, unavailable exports, or irreplaceable hosts would weaken them."},{"id":"answer:scale-fees-and-centralization","path":"/answers/scale-fees-and-centralization/","title":"Is BSV scaling real, or a datacenter marketing claim?","format":"Evidence brief","topic":"Scale & economics","depth":"Short answer","shortAnswer":"BSV deliberately moves heavy validation and storage toward specialized block producers while expecting most applications to use headers, Merkle proofs, and services. Teranode source and a public testnet runner now make implementation more inspectable. A vendor or testnet benchmark still does not establish sustained mainnet throughput, economically useful demand, competitive block production, or reproducibility on disclosed hardware.","description":"BSV has a coherent large-block architecture and public Teranode source. Capacity, independent reproduction, production behavior, demand, and operator diversity remain separate claims.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["Teranode vaporware","large blocks centralize","one million TPS","cheap because unused","Teranode","scaling","fees","benchmarks","centralization","SPV"],"explanation":["Specialized block production can move heavy work away from ordinary application users, while relevant proofs let clients inspect what they need. This architecture is useful if service cost, availability and verification remain acceptable for the task. Its existence does not establish competitive production or economical demand.","Keep code, measured capacity, production use, operator diversity and total cost as separate records. A promotional daily transaction target is neither an independently reproduced benchmark nor evidence of customers. No new throughput test or current beneficial-control estimate was produced for this revision."],"limits":["This site does not treat Association-published throughput as independent reproduction.","Public source does not by itself establish production readiness, fault tolerance, or total operating cost."],"sources":[{"title":"Teranode source repository","url":"https://github.com/bsv-blockchain/teranode","note":"Current public implementation. Source availability does not validate throughput or production-readiness claims by itself.","accessedAt":"2026-10-05","type":"Code"},{"title":"Teranode Teratestnet runner","url":"https://github.com/bsv-blockchain/teranode-teratestnet","note":"Public instructions and tooling for running the test network; inspect hardware and workload before comparing results.","accessedAt":"2026-10-05","type":"Code"},{"title":"Bitcoin: A Peer-to-Peer Electronic Cash System","url":"https://bitcoin.org/bitcoin.pdf","note":"The original paper; read its proof-of-work, incentives, privacy, and SPV claims in their own terms.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BRC-67 — Simplified Payment Verification","url":"https://bsv.brc.dev/transactions/0067","note":"Application-side criteria for verifying transaction inclusion and ancestry with proofs.","accessedAt":"2026-10-05","type":"Primary"},{"title":"WhatsOnChain explorer","url":"https://whatsonchain.com/","note":"Current block and transaction inspection surface; explorer availability and interpretation remain third-party dependencies.","accessedAt":"2026-10-05","type":"Live"}],"related":[{"href":"/guides/mining-incentives-and-economic-acceptance/","label":"Mining incentives and economic acceptance","purpose":"Follow the actors, incentive mechanism and conditions for convergence."},{"href":"/proof/#workflow-evidence","label":"Workflow evidence and its limits","purpose":"See what is documented, reported and still untested."}],"changesConclusion":"Independent sustained tests, transparent cost curves, production deployment, and broader operators would strengthen the claim. Unreproducible benchmarks or worsening concentration would weaken it."},{"id":"answer:security-hashpower-and-reorgs","path":"/answers/security-hashpower-and-reorgs/","title":"What do hashpower and reorganization history mean for BSV security?","format":"Evidence brief","topic":"Security","depth":"Short answer","shortAnswer":"Hashpower affects the cost of competing histories and remains essential to continuing production. Economic acceptance also matters: credible, coordinated rejection can deny a profit-seeking attacker’s intended payoff. Its success depends on actual enforcement and compatible policies, with sabotage and coordination failure still possible. Inclusion proofs do not establish absolute finality or current unspent status.","description":"Hash economics, transaction validity, confirmation policy, topology, monitoring, and governance response are separate security layers. None should be hand-waved.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["51 percent attack","reorg attacks","low hash security","weak Nakamoto security","security","hashpower","reorg","confirmations","double-spend"],"explanation":["A profit-seeking attack needs counterparties to recognize a result from which its sponsor benefits. Effective rejection can remove that payoff in the target economy. That makes acceptance and coordination relevant to the economic model, alongside hashpower and the cost of competing histories.","This is conditional deterrence. It does not measure attack frequency, establish holdings from a pool label, or remove sabotage, liveness and concentration risks. Observed pool attribution, beneficial control and net economic exposure are separate facts. An incident record should say what was actually observed and which effects remain unknown."],"limits":["No static confirmation number is safe for every value and failure mode.","Calling adversarial behavior dishonest does not remove the need to detect, price, and respond to it.","This site does not currently publish an independently audited incident database."],"sources":[{"title":"Bitcoin: A Peer-to-Peer Electronic Cash System","url":"https://bitcoin.org/bitcoin.pdf","note":"The original paper; read its proof-of-work, incentives, privacy, and SPV claims in their own terms.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BRC-67 — Simplified Payment Verification","url":"https://bsv.brc.dev/transactions/0067","note":"Application-side criteria for verifying transaction inclusion and ancestry with proofs.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV Alert System documentation","url":"https://docs.bsvblockchain.org/network-topology/nodes/sv-node/alert-system","note":"Technical description of signed informational and directive messages delivered to nodes.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV Network Access Rules","url":"https://docs.bsvblockchain.org/network-access-rules/network-access-rules","note":"The published agreement governing the Association-node relationship; it is evidence of the stated rules, not independent proof of their application.","accessedAt":"2026-10-05","type":"Primary"},{"title":"WhatsOnChain explorer","url":"https://whatsonchain.com/","note":"Current block and transaction inspection surface; explorer availability and interpretation remain third-party dependencies.","accessedAt":"2026-10-05","type":"Live"}],"related":[{"href":"/guides/mining-incentives-and-economic-acceptance/","label":"Mining incentives and economic acceptance","purpose":"Follow the actors, incentive mechanism and conditions for convergence."},{"href":"/proof/merkle-proof-not-backup/","label":"Proof, retention and recovery","purpose":"Separate a retained inclusion proof from current state and a recoverable application."}],"changesConclusion":"Material shifts in hash economics, producer diversity, attack history, monitoring, or rule enforcement should change the assessment quickly."},{"id":"answer:ecosystem-funding-and-project-failures","path":"/answers/ecosystem-funding-and-project-failures/","title":"Why have so many funded BSV projects disappeared?","format":"Evidence brief","topic":"Ecosystem accountability","depth":"Short answer","shortAnswer":"No one should defend every funded project. A grant, accelerator place, press release, repository, demo, maintained product, retained user base, and sustainable business are different statuses. The current BSV Hub and GitHub organizations provide discovery surfaces, but their labels need independent verification. A durable inventory should name owner, funding disclosure, last verified date, live proof, maintainer, license, and shutdown state.","description":"Failed projects are normal; missing accountability is not. Judge a current ecosystem by maintained products, user outcomes, and transparent status—not by cumulative launch announcements.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["Block Dojo failures","funded projects vanish","ecosystem burns money","dead BSV apps","funding","projects","accountability","status","maintenance"],"explanation":["Use a dated record for each selected project: announced, inspectable, reported in use, independently tested, sunset or unknown. An active repository is a maintenance signal, not proof of sustainability. A failure is not by itself evidence of fraud. Public funding relationships should be attributed to their actual documents.","The proof inventory gives bounded inspection records; it is not a complete funding-to-outcome ledger. Historical application records may survive a frontend, but claims about recovered content still require a scope and completeness check. Retain shutdown notices and export instructions instead of making old promises disappear."],"limits":["This site does not yet have an audited historical ledger of every BSV-funded project.","A closed project is not automatically fraud or waste; experiments can fail honestly and still produce reusable work."],"sources":[{"title":"BSV Hub demo catalog","url":"https://hub.bsvblockchain.org/demos-and-onboardings/demo-solutions/demos","note":"Maintainer-curated catalog with repository and status claims. Recheck every live URL, repository, and usage claim.","accessedAt":"2026-10-05","type":"Reference"},{"title":"BSV Blockchain GitHub organization","url":"https://github.com/bsv-blockchain","note":"Current repository inventory and maintenance history; activity is not the same as production use.","accessedAt":"2026-10-05","type":"Code"},{"title":"P2PPSR GitHub organization","url":"https://github.com/p2ppsr","note":"Independent application and infrastructure repositories; evaluate project status and licenses individually.","accessedAt":"2026-10-05","type":"Code"}],"related":[{"href":"/proof/#workflow-evidence","label":"Workflow evidence and its limits","purpose":"See what is documented, reported and still untested."},{"href":"/proof/merkle-proof-not-backup/","label":"Proof, retention and recovery","purpose":"Separate a retained inclusion proof from current state and a recoverable application."}],"changesConclusion":"A transparent inventory showing maintained projects, repeat use, accountable funding, and honest sunsets would improve the record. Repeated promotion without verifiable delivery would worsen it."},{"id":"answer:cheap-database-data-and-spam","path":"/answers/cheap-database-data-and-spam/","title":"Is BSV just a cheap database for spam?","format":"Evidence brief","topic":"Design tradeoffs","depth":"Short answer","shortAnswer":"BSV permits a broader use of transaction outputs and script than a money-only design. For workflows needing public timestamping, payment-linked events, or verifiable commitments, cheap blockspace can be useful. It is usually a mistake to publish private or bulky application data merely because fees are low. Good designs put only the minimum verification material on-chain and price the long-term externalities.","description":"This is a genuine design-priority disagreement. Cheap public blockspace can support proofs and signed records while imposing permanent-resource and privacy costs.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["cheap database","blockchain spam","data grifters","Bitcoin is only money","data","blockspace","privacy","commitments","design-fit"],"explanation":["A compact commitment can give independent parties a shared reference while detailed records remain available under a deliberate retention plan. It cannot make the inputs true or reconstruct missing data. Public timestamping supplies a bounded ordering or existence claim, not an exact certified time for a real-world event.","Compare signed database logs, a transparency service and a ledger against the same task. Include indexing, retained copies, privacy, settlement and service costs. Cheap capacity is useful when it improves the workflow; it is not a reason to publish every payload."],"limits":["A public timestamp does not prove that the underlying statement is true; it proves that particular data existed no later than a point in the chain.","Encryption does not make permanent publication harmless; keys can leak and metadata can remain visible."],"sources":[{"title":"BSV protocol documentation","url":"https://protocol.bsvblockchain.org/","note":"Association-maintained protocol reference and its stated stewardship model.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV TypeScript stack","url":"https://github.com/bsv-blockchain/ts-stack","note":"Current monorepo for SDK, wallet, overlay, messaging, middleware, helpers, infrastructure, documentation, and conformance vectors.","accessedAt":"2026-10-05","type":"Code"},{"title":"Bitcoin: A Peer-to-Peer Electronic Cash System","url":"https://bitcoin.org/bitcoin.pdf","note":"The original paper; read its proof-of-work, incentives, privacy, and SPV claims in their own terms.","accessedAt":"2026-10-05","type":"Primary"}],"related":[{"href":"/guides/iot-records-and-shared-evidence/","label":"When shared evidence helps an IoT record","purpose":"Compare a ledger, transparency service and signed database for the same task."},{"href":"/proof/merkle-proof-not-backup/","label":"Proof, retention and recovery","purpose":"Separate a retained inclusion proof from current state and a recoverable application."}],"changesConclusion":"Products demonstrating durable verification value with proportionate data and costs would strengthen the case. Indiscriminate payload storage, hidden privacy harm, or unsustainable resource subsidy would weaken it."},{"id":"answer:wallet-authority-identity-and-data","path":"/answers/wallet-authority-identity-and-data/","title":"Can miners, the chain, or an app sign as me or read my private data?","format":"Evidence brief","topic":"Wallet trust model","depth":"Short answer","shortAnswer":"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.","description":"These are different authority layers. Network recovery can affect accepted coin ownership without automatically granting a user's signing keys, decryption keys, certificates, or app permissions.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["chain can steal identity","miners can impersonate me","wallet permission confusion","DAR reads private data","wallet","identity","keys","permissions","DAR","privacy"],"explanation":["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."],"limits":["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."],"sources":[{"title":"BRC-100 — Unified wallet-to-application interface","url":"https://bsv.brc.dev/wallet/0100","note":"The current unified interface covering wallet actions, signatures, encryption, certificates, permissions, and discovery.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BRC-56 — Abstract wallet-to-application messaging layer","url":"https://bsv.brc.dev/wallet/0056","note":"Earlier interface rationale and permission-oriented wallet/application boundary.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BRC-103 — Mutual authentication and certificate exchange","url":"https://bsv.brc.dev/peer-to-peer/0103","note":"Peer-to-peer authentication, message signatures, and selective certificate exchange protocol.","accessedAt":"2026-10-05","type":"Primary"},{"title":"Network Access Rules — Part III, Enforcement Rules","url":"https://docs.bsvblockchain.org/network-access-rules/network-access-rules/part-iii-enforcement-rules","note":"Directive events, restrictions, and permitted steps including freezes, reassignment, peer controls, and block invalidation.","accessedAt":"2026-10-05","type":"Primary"},{"title":"BSV TypeScript stack","url":"https://github.com/bsv-blockchain/ts-stack","note":"Current monorepo for SDK, wallet, overlay, messaging, middleware, helpers, infrastructure, documentation, and conformance vectors.","accessedAt":"2026-10-05","type":"Code"}],"related":[{"href":"/guides/wallet-compatibility-and-safe-changes/","label":"When a conforming wallet breaks an app","purpose":"Compare interface checks with versioned user-workflow evidence."},{"href":"/guides/stewardship-and-authority/","label":"Stewardship and authority","purpose":"Inspect the authority matrix and reusable responsibility statement."}],"changesConclusion":"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."},{"id":"answer:babbage-and-bsv-rail-dependency","path":"/answers/babbage-and-bsv-rail-dependency/","title":"Does Project Babbage depend too heavily on the BSV rail?","format":"Evidence brief","topic":"Architecture & contingency","depth":"Short answer","shortAnswer":"Project Babbage builds a wallet-mediated application model around BRCs, keys, payments, certificates, and overlays currently anchored to BSV. Some concepts and application data can be portable; transaction history, satoshi-denominated payments, proof semantics, BSV-only code, and deployed services may not be. The responsible architecture is to label every boundary, minimize irreplaceable hosted dependencies, export user-controlled material, and maintain contingency triggers.","description":"BSV is the current rail, so failure is a material dependency. Portability claims must distinguish reusable interfaces and user data from BSV-specific transactions, proofs, licenses, and services.","modifiedAt":"2026-10-05","evidenceScope":"Content reviewed October 5. Source access dates are listed separately; no new product test is implied.","aliases":["Babbage rail dependency","if BSV fails","Metanet lock-in","application layer contingency","Project-Babbage","rail-dependency","architecture","contingency","portability"],"explanation":["The newer architectural goal is a consistent user permission boundary across applications while transactions stay on their native rails. This can reduce application integration work where implemented and tested. It does not merge chains, bridge assets, migrate transaction history automatically or remove each rail’s settlement and governance risks.","Classify each claimed capability as deployed and tested, documented, reimplementable or proposed. Review the license of the specific component and release instead of treating the stack as one legal object. A portable design principle is not evidence that every current service can move unchanged."],"limits":["This site does not claim an existing drop-in replacement rail for the complete Babbage stack.","Exportable keys or records do not guarantee equivalent functionality, counterparties, or legal meaning elsewhere."],"sources":[{"title":"BRC-100 — Unified wallet-to-application interface","url":"https://bsv.brc.dev/wallet/0100","note":"The current unified interface covering wallet actions, signatures, encryption, certificates, permissions, and discovery.","accessedAt":"2026-10-05","type":"Primary"},{"title":"Project Babbage quickstarts","url":"https://docs.projectbabbage.com/docs/quickstarts","note":"Runnable wallet-mediated application paths. Maintainer documentation is useful for reproduction, not independent adoption proof.","accessedAt":"2026-10-05","type":"Reference"},{"title":"BSV TypeScript stack","url":"https://github.com/bsv-blockchain/ts-stack","note":"Current monorepo for SDK, wallet, overlay, messaging, middleware, helpers, infrastructure, documentation, and conformance vectors.","accessedAt":"2026-10-05","type":"Code"},{"title":"BSV TypeScript conformance corpus","url":"https://github.com/bsv-blockchain/ts-stack/tree/main/conformance","note":"Language-neutral vectors and runners. Inspect current coverage and parity before calling the whole interface interoperable.","accessedAt":"2026-10-05","type":"Code"},{"title":"Bitcoin SV node — Open BSV License","url":"https://github.com/bitcoin-sv/bitcoin-sv/blob/master/LICENSE","note":"Operative repository license. Version 5 conditions derived software use on BSV blockchains.","accessedAt":"2026-10-05","type":"Primary"}],"related":[{"href":"/guides/wallet-compatibility-and-safe-changes/","label":"When a conforming wallet breaks an app","purpose":"Compare interface checks with versioned user-workflow evidence."},{"href":"https://metanet.fyi/overlays/recovery","label":"Metanet recovery checklist","purpose":"Define what another operator or user needs to continue the work."},{"href":"/guides/stewardship-and-authority/","label":"Stewardship and authority","purpose":"Inspect the authority matrix and reusable responsibility statement."}],"changesConclusion":"Demonstrated replacement of critical services and portable implementations would reduce dependency. New BSV-only code, single-host services, or unavailable exports would increase it."},{"id":"field-note:merkle-proof-not-backup","path":"/proof/merkle-proof-not-backup/","title":"A Merkle Proof Is a Receipt, Not a Backup","format":"Field note","topic":"Proof and preservation","depth":"Full explanation","shortAnswer":"A retained transaction and Merkle proof establish inclusion relative to a particular block. They do not alone establish current accepted inclusion, finality, unspent status or data availability. Keep the bytes, application context and recovery plan, and separately check the current history and spend evidence needed for the task.","description":"What Bitcoin proves about transaction inclusion, order, and integrity—and what builders must still preserve, index, explain, and make portable.","modifiedAt":"2026-10-05","evidenceScope":"Editorial explanation; example claims are not independent completeness or recovery tests.","aliases":["Merkle proofs","SPV","data availability","overlay networks","Twetch","Treechat","builder architecture","seed backup","proof versus finality","unspent","retention"],"sources":[{"id":"field-whitepaper","title":"Bitcoin: A Peer-to-Peer Electronic Cash System","url":"https://bitcoin.org/bitcoin.pdf","type":"Primary record","publisher":"Satoshi Nakamoto","note":"Sections 3 and 8 describe the distributed timestamp server and the Merkle branch linking a retained transaction to a block in the proof-of-work chain.","accessedAt":"2026-09-05"},{"id":"field-blocks","title":"Bitcoin Protocol Documentation — Blocks","url":"https://protocol.bsvblockchain.org/bsv-blockchain/blocks","type":"Specification","publisher":"BSV Association","note":"Defines the block header, Merkle root, proof construction, and the important limitation that the block timestamp is not a precise civil-time attestation.","accessedAt":"2026-09-05"},{"id":"field-brc67","title":"BRC-67 — Simplified Payment Verification","url":"https://bsv.brc.dev/transactions/0067","type":"Specification","publisher":"BRC contributors","note":"Lists the transaction, ancestry, script, fee, locktime, sequence, and Merkle-path checks needed for application-side verification.","accessedAt":"2026-09-05"},{"id":"field-pruning","title":"Bitcoin SV Node Knowledge Base — Pruning","url":"https://github.com/bitcoin-sv/bitcoin-sv/wiki/Node-Knowledge-Base/10997092f7944cd532fa03368d6358f475cb7d6c","type":"Implementation","publisher":"Bitcoin SV node maintainers","note":"Documents the node's prune mode and the resulting failure to retrieve block data that is no longer present on that node.","accessedAt":"2026-09-05"},{"id":"field-brc88","title":"BRC-88 — Overlay Services Synchronization Architecture","url":"https://bsv.brc.dev/overlays/0088","type":"Specification","publisher":"BRC contributors","note":"Specifies host discovery, relevant-transaction propagation, lookup availability, and synchronization across interested overlay services.","accessedAt":"2026-09-05"},{"id":"field-brc24","title":"BRC-24 — Overlay Network Lookup Services","url":"https://bsv.brc.dev/overlays/0024","type":"Specification","publisher":"BRC contributors","note":"Makes query and hydration a distinct service layer rather than pretending a block commitment is itself an application index.","accessedAt":"2026-09-05"},{"id":"field-treechat","title":"Treechat — Twetch archive continuity claim","url":"https://treechat.ai/","type":"Live example","publisher":"Treechat","note":"Treechat states that it preserves and surfaces records from earlier BSV social networks. This is operator evidence of a live recovery surface, not an independent completeness audit.","accessedAt":"2026-09-05"},{"id":"field-bananablocks","title":"BananaBlocks bird-sighting transaction","url":"https://bananablocks.com/tx/22d4d18d4b3147c9b2621b0d56fb940ec00dc1f714d7ebbff0cd4e2e836bf312","type":"Live example","publisher":"BananaBlocks","note":"The transaction raised the practical recovery question in the original thread: what must be retained and documented so a sighting survives the application?","accessedAt":"2026-09-05"},{"id":"field-recovery-question","title":"The recoverability question that opened the exchange","url":"https://x.com/OldCraig/status/2095276609658077268","type":"Public exchange","publisher":"Old Craig on X","note":"Asks whether Twetch posts and a BananaBlocks bird sighting can still be found and understood after their original applications disappear.","accessedAt":"2026-09-05"},{"id":"field-context-objection","title":"The frontend, private-account, and context objection","url":"https://x.com/jataka01/status/2095698630229283190","type":"Public exchange","publisher":"Jataka on X","note":"Presses the strongest application-layer concern: product context, authentication, private state, and social meaning do not become portable merely because transactions exist.","accessedAt":"2026-09-05"},{"id":"field-closing-timestamp","title":"The closing timestamp-server claim","url":"https://x.com/ProjectBabbage/status/2096230328230982027","type":"Public exchange","publisher":"Project Babbage on X","note":"Frames the miner-returned Merkle proof as a receipt for ordering and timestamping. The field note preserves that useful claim while narrowing its database comparison.","accessedAt":"2026-09-05"},{"id":"field-objection","title":"The strongest version of the storage objection","url":"https://x.com/robert964492/status/2096070478540525596","type":"Public exchange","publisher":"Robert Greene on X","note":"Argues that pruning, off-chain retention, and application indexes collapse the value proposition. The field note concedes the availability premise and tests the conclusion.","accessedAt":"2026-09-05"},{"id":"field-response","title":"The full layer-by-layer response","url":"https://x.com/ProjectBabbage/status/2095726935804678644","type":"Public exchange","publisher":"Project Babbage on X","note":"Separates community, interface, identity, protocol meaning, indexes, record availability, and Bitcoin verification instead of calling every layer decentralized.","accessedAt":"2026-09-05"},{"id":"field-opentimestamps","title":"OpenTimestamps","url":"https://opentimestamps.org/","type":"Outside example","publisher":"OpenTimestamps contributors","note":"A production example of retaining a document separately while anchoring a compact, independently verifiable Bitcoin timestamp proof.","accessedAt":"2026-09-05"},{"id":"field-ct","title":"RFC 9162 — Certificate Transparency Version 2.0","url":"https://www.rfc-editor.org/rfc/rfc9162.html","type":"Outside example","publisher":"Internet Engineering Task Force","note":"Shows the same separation outside blockchain: Merkle proofs support auditability, while logs and monitors must still retain and serve the underlying entries.","accessedAt":"2026-09-05"}]},{"id":"proof-copa-record","path":"/proof/#proof-copa-record","title":"COPA v Wright official record","format":"Proof record","topic":"legal-record","depth":"Reference","description":"The court's published findings and stated reasons are directly inspectable.","shortAnswer":"The court's published findings and stated reasons are directly inspectable.","modifiedAt":"2026-10-05","evidenceScope":"Source availability checked October 5. Original evidence assessment date retained; no new workflow test.","aliases":["legal-record"],"sources":[{"url":"https://www.judiciary.uk/judgments/copa-v-wright/"}],"limits":["Whether an unrelated protocol or application claim works."]},{"id":"proof-nar-record","path":"/proof/#proof-nar-record","title":"Network Access Rules and enforcement surface","format":"Proof record","topic":"governance-record","depth":"Reference","description":"The Association publishes an explicit node-governance agreement.","shortAnswer":"The Association publishes an explicit node-governance agreement. Part III describes possible freeze, reassignment, peer, and block directives.","modifiedAt":"2026-10-05","evidenceScope":"Source availability checked October 5. Original evidence assessment date retained; no new workflow test.","aliases":["governance-record"],"sources":[{"url":"https://docs.bsvblockchain.org/network-access-rules/network-access-rules"}],"limits":["That every directive is fair, enforceable, public, or correctly executed.","That courts or key holders cannot err."]},{"id":"proof-brc-corpus","path":"/proof/#proof-brc-corpus","title":"Public BRC specification corpus","format":"Proof record","topic":"standard","depth":"Reference","description":"Wallet, identity, payment, proof, and overlay interfaces are publicly versioned and inspectable.","shortAnswer":"Wallet, identity, payment, proof, and overlay interfaces are publicly versioned and inspectable.","modifiedAt":"2026-10-05","evidenceScope":"Source availability checked October 5. Original evidence assessment date retained; no new workflow test.","aliases":["standard"],"sources":[{"url":"https://github.com/bsv-blockchain/BRCs"}],"limits":["Independent implementation, conformance, production security, or adoption."]},{"id":"proof-ts-stack","path":"/proof/#proof-ts-stack","title":"Current BSV TypeScript implementation stack","format":"Proof record","topic":"code","depth":"Reference","description":"SDK, wallet, overlay, messaging, middleware, helper, and infrastructure source is inspectable in a current monorepo.","shortAnswer":"SDK, wallet, overlay, messaging, middleware, helper, and infrastructure source is inspectable in a current monorepo. The repository publishes build, test, and conformance entry points.","modifiedAt":"2026-10-05","evidenceScope":"Source availability checked October 5. Original evidence assessment date retained; no new workflow test.","aliases":["code"],"sources":[{"url":"https://github.com/bsv-blockchain/ts-stack"}],"limits":["Production security of every deployment.","Users, retention, commercial demand, or cross-language parity."]},{"id":"proof-conformance","path":"/proof/#proof-conformance","title":"Language-neutral conformance vectors","format":"Proof record","topic":"code","depth":"Reference","description":"A shared vector format, coverage record, runners, and parity material exist.","shortAnswer":"A shared vector format, coverage record, runners, and parity material exist.","modifiedAt":"2026-10-05","evidenceScope":"Source availability checked October 5. Original evidence assessment date retained; no new workflow test.","aliases":["code"],"sources":[{"url":"https://github.com/bsv-blockchain/ts-stack/tree/main/conformance"}],"limits":["Complete coverage of BRC-100.","Multiple independent wallets pass every vector."]},{"id":"proof-teranode-source","path":"/proof/#proof-teranode-source","title":"Teranode source and public testnet runner","format":"Proof record","topic":"code","depth":"Reference","description":"Teranode is publicly inspectable software rather than only a future architecture claim.","shortAnswer":"Teranode is publicly inspectable software rather than only a future architecture claim. A public Teratestnet runner exists.","modifiedAt":"2026-10-05","evidenceScope":"Source availability checked October 5. Original evidence assessment date retained; no new workflow test.","aliases":["code"],"sources":[{"url":"https://github.com/bsv-blockchain/teranode"}],"limits":["Any headline throughput under independent conditions.","Sustained mainnet demand, production safety, cost, or operator diversity."]},{"id":"proof-wallet-quickstart","path":"/proof/#proof-wallet-quickstart","title":"Wallet-mediated application quickstart","format":"Proof record","topic":"live-flow","depth":"Reference","description":"A documented path exists for a builder to exercise wallet-mediated operations.","shortAnswer":"A documented path exists for a builder to exercise wallet-mediated operations.","modifiedAt":"2026-10-05","evidenceScope":"Source availability checked October 5. Original evidence assessment date retained; no new workflow test.","aliases":["live-flow"],"sources":[{"url":"https://docs.projectbabbage.com/docs/quickstarts"}],"limits":["Independent reproduction, production readiness, retained users, or wallet neutrality."]},{"id":"proof-builder-lab","path":"/proof/#proof-builder-lab","title":"Metanet Academy Builder Lab","format":"Proof record","topic":"live-flow","depth":"Reference","description":"An ungated architecture and diagnostic learning path is live.","shortAnswer":"An ungated architecture and diagnostic learning path is live.","modifiedAt":"2026-10-05","evidenceScope":"Source availability checked October 5. Original evidence assessment date retained; no new workflow test.","aliases":["live-flow"],"sources":[{"url":"https://metanetacademy.com/builder-lab"}],"limits":["That unaffiliated builders complete it successfully or adopt the stack."]},{"id":"proof-chain-inspection","path":"/proof/#proof-chain-inspection","title":"Live block and transaction inspection","format":"Proof record","topic":"network-data","depth":"Reference","description":"Current blocks and transactions can be inspected through a third-party explorer.","shortAnswer":"Current blocks and transactions can be inspected through a third-party explorer.","modifiedAt":"2026-10-05","evidenceScope":"Source availability checked October 5. Original evidence assessment date retained; no new workflow test.","aliases":["network-data"],"sources":[{"url":"https://whatsonchain.com/"}],"limits":["Human user counts, economic necessity, producer independence, or explorer correctness."]},{"id":"proof-demo-catalog","path":"/proof/#proof-demo-catalog","title":"Official BSV demo catalog","format":"Proof record","topic":"live-flow","depth":"Reference","description":"The Association publishes a discovery catalog linking demos and repositories.","shortAnswer":"The Association publishes a discovery catalog linking demos and repositories.","modifiedAt":"2026-10-05","evidenceScope":"Source availability checked October 5. Original evidence assessment date retained; no new workflow test.","aliases":["live-flow"],"sources":[{"url":"https://hub.bsvblockchain.org/demos-and-onboardings/demo-solutions/demos"}],"limits":["Independent status, complete working flows, users, retention, or sustainable businesses."]},{"id":"term:brc","path":"/glossary/#brc","title":"BRC","format":"Glossary","topic":"Definitions","depth":"Reference","description":"A Bitcoin Request for Comments: a public specification or proposal in the BSV BRC corpus.","shortAnswer":"A Bitcoin Request for Comments: a public specification or proposal in the BSV BRC corpus.","modifiedAt":"2026-10-05","evidenceScope":"A BRC documents an interface or idea; it does not by itself prove implementation, interoperability, security, or adoption.","aliases":["BRC"]},{"id":"term:brc-100","path":"/glossary/#brc-100","title":"BRC-100","format":"Glossary","topic":"Definitions","depth":"Reference","description":"The unified wallet-to-application interface covering wallet actions, signatures, encryption, certificates, permissions, baskets, and discovery.","shortAnswer":"The unified wallet-to-application interface covering wallet actions, signatures, encryption, certificates, permissions, baskets, and discovery.","modifiedAt":"2026-10-05","evidenceScope":"A common interface enables independent implementation; compatible semantics, wallet policy and complete workflows still need versioned evidence.","aliases":["BRC-100"]},{"id":"term:beef","path":"/glossary/#beef","title":"BEEF","format":"Glossary","topic":"Definitions","depth":"Reference","description":"A transaction-data format used to carry a transaction together with information needed to evaluate its ancestry and proofs.","shortAnswer":"A transaction-data format used to carry a transaction together with information needed to evaluate its ancestry and proofs.","modifiedAt":"2026-10-05","evidenceScope":"Possessing a BEEF structure does not create absolute settlement or prove a real-world claim.","aliases":["BEEF"]},{"id":"term:spv","path":"/glossary/#spv","title":"SPV","format":"Glossary","topic":"Definitions","depth":"Reference","description":"Simplified Payment Verification: checking relevant transactions with block headers and Merkle evidence without maintaining the complete block database.","shortAnswer":"Simplified Payment Verification: checking relevant transactions with block headers and Merkle evidence without maintaining the complete block database.","modifiedAt":"2026-10-05","evidenceScope":"SPV reduces client burden; it does not remove chain-selection, data-availability, or reorganization risk.","aliases":["SPV"]},{"id":"term:merkle-proof","path":"/glossary/#merkle-proof","title":"Merkle proof","format":"Glossary","topic":"Definitions","depth":"Reference","description":"A compact path showing that a transaction or item is committed by a particular Merkle root, such as one in a block header.","shortAnswer":"A compact path showing that a transaction or item is committed by a particular Merkle root, such as one in a block header.","modifiedAt":"2026-10-05","evidenceScope":"It proves inclusion relative to a root; it does not establish current accepted inclusion, finality, unspent status, availability or the truth of an off-chain statement.","aliases":["Merkle proof"]},{"id":"term:utxo","path":"/glossary/#utxo","title":"UTXO","format":"Glossary","topic":"Definitions","depth":"Reference","description":"An unspent transaction output: a spendable output governed by a locking script and the network's accepted rules.","shortAnswer":"An unspent transaction output: a spendable output governed by a locking script and the network's accepted rules.","modifiedAt":"2026-10-05","evidenceScope":"Current unspent status needs current spend/conflict evidence; a proof of the creating transaction alone is insufficient. Key control and network acceptance remain distinct.","aliases":["UTXO"]},{"id":"term:nar","path":"/glossary/#nar","title":"NAR","format":"Glossary","topic":"Definitions","depth":"Reference","description":"The Network Access Rules published by the BSV Association for the relationship among the Association and participating nodes.","shortAnswer":"The Network Access Rules published by the BSV Association for the relationship among the Association and participating nodes.","modifiedAt":"2026-10-05","evidenceScope":"Read the operative parts and current version; summaries are not the agreement.","aliases":["NAR"]},{"id":"term:dar","path":"/glossary/#dar","title":"DAR","format":"Glossary","topic":"Definitions","depth":"Reference","description":"Digital Asset Recovery: the ecosystem term for processes intended to support freezing and reassignment of disputed or recoverable BSV through node-enforced rules.","shortAnswer":"Digital Asset Recovery: the ecosystem term for processes intended to support freezing and reassignment of disputed or recoverable BSV through node-enforced rules.","modifiedAt":"2026-10-05","evidenceScope":"It is not the same technical mechanism as obtaining the former holder's private key or signature.","aliases":["DAR"]},{"id":"term:directive","path":"/glossary/#directive","title":"Directive","format":"Glossary","topic":"Definitions","depth":"Reference","description":"A signed instruction contemplated by the Network Access Rules and delivered to nodes through the alert mechanism after specified events.","shortAnswer":"A signed instruction contemplated by the Network Access Rules and delivered to nodes through the alert mechanism after specified events.","modifiedAt":"2026-10-05","evidenceScope":"Authority, restrictions, legal basis, technical effect, notice, and challenge must be checked for the actual directive.","aliases":["Directive"]},{"id":"term:proof-of-work","path":"/glossary/#proof-of-work","title":"Proof of work","format":"Glossary","topic":"Definitions","depth":"Reference","description":"The expenditure evidenced by finding a block hash below a target, used to make history costly to rewrite and to coordinate ordering among valid blocks.","shortAnswer":"The expenditure evidenced by finding a block hash below a target, used to make history costly to rewrite and to coordinate ordering among valid blocks.","modifiedAt":"2026-10-05","evidenceScope":"More work is not a substitute for transaction and block validity, and security remains economic and probabilistic.","aliases":["Proof of work"]},{"id":"term:chainwork","path":"/glossary/#chainwork","title":"Chainwork","format":"Glossary","topic":"Definitions","depth":"Reference","description":"The accumulated proof-of-work represented by a chain of block headers.","shortAnswer":"The accumulated proof-of-work represented by a chain of block headers.","modifiedAt":"2026-10-05","evidenceScope":"Applications still need a chain-selection and incident policy; the meaning of valid and accepted must be explicit.","aliases":["Chainwork"]},{"id":"term:reorganization","path":"/glossary/#reorganization","title":"Reorganization","format":"Glossary","topic":"Definitions","depth":"Reference","description":"A change in the accepted chain tip that removes one or more previously accepted blocks and replaces them with another branch.","shortAnswer":"A change in the accepted chain tip that removes one or more previously accepted blocks and replaces them with another branch.","modifiedAt":"2026-10-05","evidenceScope":"A reorg can be ordinary, accidental, or adversarial; describe the actual blocks, work, transactions, and rules.","aliases":["Reorganization"]},{"id":"term:wallet-action","path":"/glossary/#wallet-action","title":"Wallet action","format":"Glossary","topic":"Definitions","depth":"Reference","description":"A BRC-100 request for a wallet to create, sign, internalize, list, or otherwise manage an application-related operation.","shortAnswer":"A BRC-100 request for a wallet to create, sign, internalize, list, or otherwise manage an application-related operation.","modifiedAt":"2026-10-05","evidenceScope":"The wallet's permission and custody implementation determines the actual user boundary.","aliases":["Wallet action"]},{"id":"term:basket","path":"/glossary/#basket","title":"Basket","format":"Glossary","topic":"Definitions","depth":"Reference","description":"A wallet-level organization mechanism for outputs associated with an application or purpose.","shortAnswer":"A wallet-level organization mechanism for outputs associated with an application or purpose.","modifiedAt":"2026-10-05","evidenceScope":"A basket label is not a universal data-export or cross-wallet migration guarantee.","aliases":["Basket"]},{"id":"term:identity-key","path":"/glossary/#identity-key","title":"Identity key","format":"Glossary","topic":"Definitions","depth":"Reference","description":"A public-key identity used in BRC-103 authentication and related wallet-mediated interactions.","shortAnswer":"A public-key identity used in BRC-103 authentication and related wallet-mediated interactions.","modifiedAt":"2026-10-05","evidenceScope":"A key is an identifier and cryptographic control point; it is not automatically a civil identity or a proof that every attached claim is true.","aliases":["Identity key"]},{"id":"term:certificate","path":"/glossary/#certificate","title":"Certificate","format":"Glossary","topic":"Definitions","depth":"Reference","description":"A signed claim about a subject that can be selectively exchanged and verified in BRC-oriented identity flows.","shortAnswer":"A signed claim about a subject that can be selectively exchanged and verified in BRC-oriented identity flows.","modifiedAt":"2026-10-05","evidenceScope":"Trust depends on issuer, claim semantics, expiry, revocation, disclosure, and verifier policy.","aliases":["Certificate"]},{"id":"term:counterparty","path":"/glossary/#counterparty","title":"Counterparty","format":"Glossary","topic":"Definitions","depth":"Reference","description":"The other party in a wallet key-derivation, payment, signature, encryption, or authenticated-message relationship.","shortAnswer":"The other party in a wallet key-derivation, payment, signature, encryption, or authenticated-message relationship.","modifiedAt":"2026-10-05","evidenceScope":"Human-readable presentation and authentication are needed; a raw public key alone may not convey who the user is dealing with.","aliases":["Counterparty"]},{"id":"term:overlay","path":"/glossary/#overlay","title":"Overlay","format":"Glossary","topic":"Definitions","depth":"Reference","description":"An application-specific service layer that admits, tracks, indexes, discovers, and synchronizes relevant UTXO-based state.","shortAnswer":"An application-specific service layer that admits, tracks, indexes, discovers, and synchronizes relevant UTXO-based state.","modifiedAt":"2026-10-05","evidenceScope":"An overlay can decentralize application state while still depending on schemas, hosts, discovery, and the BSV rail.","aliases":["Overlay"]},{"id":"term:topic-manager","path":"/glossary/#topic-manager","title":"Topic manager","format":"Glossary","topic":"Definitions","depth":"Reference","description":"Overlay logic that decides which outputs are admissible for an application-defined topic.","shortAnswer":"Overlay logic that decides which outputs are admissible for an application-defined topic.","modifiedAt":"2026-10-05","evidenceScope":"Admission rules are application policy and should be inspectable, versioned, and consistently enforced.","aliases":["Topic manager"]},{"id":"term:lookup-service","path":"/glossary/#lookup-service","title":"Lookup service","format":"Glossary","topic":"Definitions","depth":"Reference","description":"An overlay component that indexes admitted outputs and answers application-specific queries.","shortAnswer":"An overlay component that indexes admitted outputs and answers application-specific queries.","modifiedAt":"2026-10-05","evidenceScope":"Query availability, meaning, completeness and freshness depend on the operator and index. A valid returned record does not prove that all relevant records were returned.","aliases":["Lookup service"]},{"id":"term:ship","path":"/glossary/#ship","title":"SHIP","format":"Glossary","topic":"Definitions","depth":"Reference","description":"The overlay service-discovery mechanism used to advertise hosts that serve particular topics.","shortAnswer":"The overlay service-discovery mechanism used to advertise hosts that serve particular topics.","modifiedAt":"2026-10-05","evidenceScope":"Discovery does not guarantee service honesty, uptime, completeness, or independent operation.","aliases":["SHIP"]},{"id":"term:slap","path":"/glossary/#slap","title":"SLAP","format":"Glossary","topic":"Definitions","depth":"Reference","description":"The overlay discovery mechanism used to locate services that answer particular lookup queries.","shortAnswer":"The overlay discovery mechanism used to locate services that answer particular lookup queries.","modifiedAt":"2026-10-05","evidenceScope":"A discovered lookup provider remains a trust, availability, and consistency dependency.","aliases":["SLAP"]},{"id":"term:gasp","path":"/glossary/#gasp","title":"GASP","format":"Glossary","topic":"Definitions","depth":"Reference","description":"Graph Aware Sync Protocol: a mechanism for synchronizing relevant transaction-graph state between overlay services.","shortAnswer":"Graph Aware Sync Protocol: a mechanism for synchronizing relevant transaction-graph state between overlay services.","modifiedAt":"2026-10-05","evidenceScope":"Synchronization protocol does not prove independent hosts exist or that an application's complete off-chain state is portable.","aliases":["GASP"]},{"id":"term:rail-dependency","path":"/glossary/#rail-dependency","title":"Rail dependency","format":"Glossary","topic":"Definitions","depth":"Reference","description":"A product's dependence on the settlement network, token, proof semantics, node rules, services, or licenses specific to a blockchain.","shortAnswer":"A product's dependence on the settlement network, token, proof semantics, node rules, services, or licenses specific to a blockchain.","modifiedAt":"2026-10-05","evidenceScope":"Portable concepts or data do not make a complete running product rail-neutral.","aliases":["Rail dependency"]},{"id":"term:conformance-vector","path":"/glossary/#conformance-vector","title":"Conformance vector","format":"Glossary","topic":"Definitions","depth":"Reference","description":"A versioned test input and expected result used by multiple implementations to check compatible behavior.","shortAnswer":"A versioned test input and expected result used by multiple implementations to check compatible behavior.","modifiedAt":"2026-10-05","evidenceScope":"Coverage, negative cases, runner independence, and published failures matter as much as the existence of vectors.","aliases":["Conformance vector"]},{"id":"term:acceptance-policy","path":"/glossary/#acceptance-policy","title":"Acceptance policy","format":"Glossary","topic":"Definitions","depth":"Reference","description":"The rules and evidence a participant uses to recognize a payment or history for a particular task.","shortAnswer":"The rules and evidence a participant uses to recognize a payment or history for a particular task.","modifiedAt":"2026-10-05","evidenceScope":"Local refusal does not compel other participants or create replacement blocks.","aliases":["Acceptance policy"]},{"id":"term:economic-acceptance","path":"/glossary/#economic-acceptance","title":"Economic acceptance","format":"Glossary","topic":"Definitions","depth":"Reference","description":"Recognition of a result by the businesses, services and users whose agreement makes an exchange useful.","shortAnswer":"Recognition of a result by the businesses, services and users whose agreement makes an exchange useful.","modifiedAt":"2026-10-05","evidenceScope":"Credible rejection can affect realizable payoff; outside incentives and failed coordination remain possible.","aliases":["Economic acceptance"]},{"id":"term:liveness","path":"/glossary/#liveness","title":"Liveness","format":"Glossary","topic":"Definitions","depth":"Reference","description":"The ability of the relevant system to continue producing accepted results and serving its users.","shortAnswer":"The ability of the relevant system to continue producing accepted results and serving its users.","modifiedAt":"2026-10-05","evidenceScope":"Refusing a history does not itself provide continuing accepted production.","aliases":["Liveness"]},{"id":"term:finality","path":"/glossary/#finality","title":"Finality","format":"Glossary","topic":"Definitions","depth":"Reference","description":"The practical assurance, under stated assumptions, that a settlement result will remain accepted.","shortAnswer":"The practical assurance, under stated assumptions, that a settlement result will remain accepted.","modifiedAt":"2026-10-05","evidenceScope":"A retained inclusion proof is not absolute finality; identify history, policy and irreversible exposure.","aliases":["Finality"]},{"id":"term:availability","path":"/glossary/#availability","title":"Availability","format":"Glossary","topic":"Definitions","depth":"Reference","description":"Whether authorized parties can obtain the records and service needed for their task.","shortAnswer":"Whether authorized parties can obtain the records and service needed for their task.","modifiedAt":"2026-10-05","evidenceScope":"Hashes and proofs cannot reconstruct missing bytes, schemas or keys.","aliases":["Availability"]},{"id":"term:stewardship","path":"/glossary/#stewardship","title":"Stewardship","format":"Glossary","topic":"Definitions","depth":"Reference","description":"Responsibility for maintaining shared work, preserving competence and making decisions correctable within a defined scope.","shortAnswer":"Responsibility for maintaining shared work, preserving competence and making decisions correctable within a defined scope.","modifiedAt":"2026-10-05","evidenceScope":"This is an editorial framework, not proof that current authority is distributed or replaceable.","aliases":["Stewardship"]},{"id":"term:workflow-compatibility","path":"/glossary/#workflow-compatibility","title":"Workflow compatibility","format":"Glossary","topic":"Definitions","depth":"Reference","description":"Successful completion of a named task using specified app, wallet and platform versions.","shortAnswer":"Successful completion of a named task using specified app, wallet and platform versions.","modifiedAt":"2026-10-05","evidenceScope":"A passing interface check does not establish every policy or full user workflow.","aliases":["Workflow compatibility"]}]}