BRC-237 Enters Repository With Shared Format for Reporting Payment Checks

BRC / Payments Infrastructure

In Brief

BRC-237 has merged into the BRC repository, defining a common format for reporting what a receiver checked about a payment and what remains unverified.

The specification is designed for receivers working with BREAD or BEEF evidence. It separates transaction ancestry, completed validation and observed payment status, while leaving payment-acceptance decisions to the receiving application. The merge establishes a specification milestone; deployed wallet support has not been demonstrated.

News Report

Pull request #367, “Payment Evidence Statements for BREAD and BEEF,” merged on October 31 at 20:57 UTC. It adds BRC-237 to the repository’s transaction specifications.

The document defines an interface for describing evidence. Adoption is voluntary, and the contribution changes neither BEEF’s transaction encoding nor the existing BRC-100 wallet method set.

A Common Description of Payment Evidence

The existing BRC-67 specification describes Simplified Payment Verification through checks on scripts, amounts, transaction ancestry and transaction timing. These are distinct checks, even when a wallet presents their outcome through one status indicator.

BEEF, defined in BRC-62, packages transactions and supporting Merkle proofs so a receiver can independently evaluate a payment and its ancestors. ElectrumSVP’s BREAD functionality also supports transaction verification, confirmed-ancestor anchoring, ancestry-distance reporting and evidence export, according to its release notes.

BRC-237 provides shared reporting terms for those different approaches without requiring either implementation to adopt the other’s evidence format.

Its statement identifies the confirmed ancestors used as anchors, unresolved inputs, shortest and longest unconfirmed ancestry paths, and transactions that completed validation. It also records the block-header tip used, payment status and any observed conflicting-spend check.

Separating Unchecked Evidence From Failed Checks

Validation is explicitly reported as none, partial or all. Tracing every input back to a confirmed ancestor does not, by itself, establish that the receiver evaluated all intervening scripts and amounts.

A receiver that performs no validation can produce a conforming statement reporting none. When a validation check is performed and fails under the applicable consensus rules, the maker must refuse to produce a statement rather than hide that failure as an unchecked transaction.

A statement can optionally be signed. That identifies its maker; it does not guarantee the claims are true. The receiver still needs its own checks or a statement maker it trusts. Seeing no conflicting spend at one moment cannot establish that none exists or will appear later. Even complete validation does not guarantee that miners will confirm the payment.

Implementation and Testing Status

The specification describes an optional getPaymentEvidence wallet extension. It remains outside BRC-100’s standard method set.

The submission reports a reference implementation and a second implementation by the same author, with agreement across 71 checks involving the published vectors and document tables. This is not independent interoperability testing.

The stated limitations include no mainnet or testnet run, synthetic test headers without proof of work, and no testing against the Go or Python SDKs. No wallet yet offers the optional method, according to the submission, and ElectrumSVP has not been shown producing these statements.

BSV TIMES reviewed the merged specification, contribution record and cited release notes. It has not independently run the reference implementation or verified a live wallet integration.

BSV TIMES Read

Payment interfaces benefit when they explain the evidence behind a status label. A merchant or application may care whether ancestry is complete, scripts were checked, a broadcaster received the transaction or the payment was confirmed. Those facts support different decisions.

The potential value of BRC-237 is a common reporting format across wallet architectures. Its usefulness will depend on implementations preserving those distinctions and applications interpreting them correctly. The next practical milestone is demonstrated support across independently developed wallets and applications.

Developer Context

BRC-237 is authored by RexStarBSV, the name used in the specification and its GitHub contribution.

The same contributor submitted the BRC-181 amendment merged on October 31, which clarifies what signing interfaces must disclose about destinations and changes to an agent’s spending policy. Both contributions concern making the evidence and authority behind wallet decisions more explicit.

Source Links

Posted on November 1, 2026 (UTC)