The checks behind
a payment receipt.

A payment receipt becomes useful when it tells a merchant what was checked, what remains unknown and who will answer if the service gets it wrong. A green tick without those distinctions is a poor foundation for competition.

The next stage of the BSV decentralisation argument concerns the evidence exchanged between independently operated products. Stable base rules permit different wallets, verifiers and commercial services to do the work in different ways. Their customers still need to compare the result. That comparison becomes difficult when one product reports a number of hops, another reports a successful verification and neither explains the scope of its claim.

BRC-237, Payment Evidence Statements for BREAD and BEEF, credited to RexStarBSV, offers a timely proposal for making those distinctions explicit. The inspected revision describes a common statement about the evidence a receiver holds for a payment. It does not decide whether a merchant should accept that payment. This article examines the engineering and commercial consequences of that separation, rather than claiming that the proposal has already been deployed.

1. Keep the rules separate from the service

The BSV protocol reference locates the base contract in transaction and block validity. Wallet interfaces, transport arrangements and operating choices sit outside that contract. Its policy discussion also distinguishes a node's decision to relay or mine a transaction from the rules determining validity.

I favour fixed base rules because businesses need a foundation on which they can invest without asking a software committee for a new permission each time they improve a service. That position leaves considerable room for commercial disagreement. Two merchants may accept different risks. Two wallet suppliers may offer different verification arrangements. Neither difference requires rewriting the meaning of a valid transaction.

A voluntary reporting standard can make that competition more informative. A supplier may adopt it because customers find its statements useful. Another supplier may offer a different interface. Compatibility with an application can depend on the chosen interface, but an application's preference should not be advertised as an obligation imposed on every BSV participant.

BRC-237 makes adoption voluntary and separates the responsibilities of the statement's maker, its reader and a wallet offering its optional method. Those roles matter. Choosing to claim conformance creates specific obligations within the chosen interface. It does not turn that interface into the base protocol.

2. Measure distance and work separately

The ElectrumSVP 0.2.0 release notes describe improvements to BREAD creation and verification, expanding BREAD as Blockchain Referenced Evidence and Data. That is the project's own documentation. It should be read as documentation of ElectrumSVP, rather than importing assumptions from another wallet with a similar name.

The reporting problem can be explained without choosing a wallet. Imagine a payment with two input branches. One spends a confirmed ancestor directly, giving a distance of one; the other reaches an anchor through four unconfirmed transactions, counting the payment itself in both cases. The nearest anchor is one step away, but the longest branch has four steps. Reporting only the shorter distance would hide part of the dependency the receiver needs to consider.

Now imagine that the second branch is missing a source transaction. A visible short branch does not fill that gap. The receiver needs a way to distinguish a complete graph from incomplete material before attaching confidence to a convenient distance.

BRC-237 records anchoring, unresolved inputs, minimum and maximum distances, and the transactions whose prescribed checks were completed. These describe different properties. Possessing the material from which a check could be performed is different from having performed it. The proposed statement lets a reader inspect that difference instead of inferring the work from a file-format name.

My two-branch example is a teaching example, not a new test vector or measured wallet result. Its practical point is that procurement should ask for the scope of the verification. A small number on a screen may be perfectly accurate and still answer only a small part of the customer's question.

3. Preserve the difference between missing work and failed work

One important design choice in the proposal concerns a verifier that cannot finish a check. Under its validation rules, a local script-resource limit or an interpreter lacking an applicable operation leaves the affected transaction and its unconfirmed descendants outside the validated set. A completed check that fails under the applicable rules instead requires refusal. These outcomes must not be exchanged merely to make the interface look simpler.

There is a separate boundary around the material walk itself. Exceeding the proposal's bounds on material, transaction count, distance or statement length requires an OVER_BOUND refusal, rather than a statement about a silently truncated graph. A script-evaluation limit and a graph-size limit therefore have different reporting consequences in this specification.

For an independently written implementation, that distinction is an engineering obligation worth testing. A product should not promote its own limited interpreter into an authority over BSV validity. Equally, it should not conceal an actual failed check by relabelling it as work it did not perform.

I would test these branches deliberately: material missing an ancestor; a supported script that fails; an operation the test interpreter cannot evaluate correctly; a graph beyond its configured bound; and a payment that has not yet satisfied the relevant timing condition. The last case may be premature rather than intrinsically invalid. The expected answer must be attached to the exact case. This is a proposed evaluation, not a report that any named wallet has passed it.

The commercial benefit of retaining these distinctions is straightforward. A merchant can decide to wait, obtain additional evidence or use another service. A single undifferentiated failure message deprives the merchant of that choice and makes the supplier's limitations harder to price.

4. A signature has a scope

The series has already examined hierarchical signing keys and compromise boundaries. A different boundary appears here: the boundary between authenticating a statement and establishing the truth of the event it describes.

BRC-237 permits an optional BRC-77 signature over the statement's canonical bytes. The signature travels separately. Verification concerns those exact bytes; an alternative serialization of the same JSON object does not inherit the original signature. The proposal also says that signing does not enlarge the statement's claim.

A merchant must therefore establish which verification key belongs to the service it intends to trust. A mathematically valid signature under an unfamiliar key supplies no missing commercial relationship. A known supplier's signature can support attribution of the statement, but the supplier may still have used incomplete evidence or made an implementation error. Anchors also depend on the header source: a signature does not establish that the source's proof of work was checked. Identity, evidence and responsibility remain separate questions.

This distinction also prevents a misleading comparison between signing algorithms. Faster signature generation does not demonstrate better payment assessment. More derived keys do not demonstrate that the receiver checked a longer dependency graph. A supplier can improve either operation, but the evidence for each improvement must match the claim being sold.

Nor should a signed report of an unmined payment be presented as a promise of eventual mining. A later conflicting spend, a miner's fee policy or evidence the reporting service never held may change the commercial outcome. A service offering an additional guarantee would need to define that guarantee separately, including its exclusions and the resources behind it. The reporting format itself supplies no such guarantee.

5. Scale the accountability as well as the throughput

Resource bounds are unavoidable in an operated service. Memory, bandwidth and verification time have costs. Decentralisation allows suppliers to compete over those costs and the service levels they can sustain. It does not make a bounded machine unbounded by declaration.

Consider an invented evaluation containing 1,000 submitted payment cases. Suppose 900 receive the service's complete evidence assessment, 60 produce partial assessments and 40 exceed the supported material bound. The completion fraction is 900/1,000, or 90 per cent. Reporting latency only for the 900 completed cases can be useful, but calling that figure the latency of all submitted payments would conceal the other outcomes.

I would retain all four quantities: submitted cases, assessment coverage, time to each reported outcome and the unresolved population at the observation deadline. Costs should include unsuccessful work. Repeat the comparison with the same materials, header view and stated bounds across independently implemented services. Then vary those conditions explicitly, rather than mixing changes in the workload with changes in the implementation.

This is a proposed service comparison using invented counts. It provides no throughput result, safety threshold or recommendation for accepting a particular payment. Its purpose is to make the cost of incomplete work visible.

Responsibility can then be assigned to an observable promise. The interface supplier is responsible for accurately describing its contract. The implementer must report what its code actually established. The operator must explain its limits, availability and incident response. The merchant chooses an acceptance policy appropriate to its own transaction. A contract may allocate additional duties between them; a common message format cannot silently allocate those duties on their behalf.

6. Competition needs independent checking

The inspected BRC-237 revision is unusually explicit about its verification limits. It reports no mainnet or testnet run. Its second implementation uses the same vectors and has the same author, so that agreement should not be presented as an independent external audit. It also reports that no wallet offers the optional method and that no existing ancestry-distance wallet, including BREAD in ElectrumSVP, has produced one of these statements.

Those disclosures make the next work easier to identify. Independent teams can build from the document, publish disagreement cases, vary the materials beyond the supplied examples and test operational behaviour within authorised environments. Agreement on shared fixtures is useful evidence; agreement produced by shared assumptions is not the end of the investigation.

A reporting proposal earns adoption when it helps customers compare services and helps competing implementers find mistakes. Its author need not become a permanent authority over those services. Fixed BSV rules, voluntary interfaces and independent implementation are compatible with demanding engineering scrutiny. Indeed, they make scrutiny more important.

The receipt I want is one that makes the supplier's work examinable. It should show the evidence boundary, retain what remains unknown and identify the party standing behind the service. That gives the customer something more valuable than an impressive count of keys, nodes or signatures: a basis for choosing, checking and changing suppliers.