Data Infrastructure

Electronic signatures can survive as documents while the evidence explaining how those documents were signed remains dependent on the service that coordinated the process.

Proposed BRC-222 — Consent Envelope explores a different model.

Submitted on October 15 by Crumbs, using the GitHub account vincemedia, the proposal defines a multi-party document-signing process in which each approval or signature advances an on-chain state. The resulting evidence is intended to travel with the completed document so that a later verifier can reconstruct the signing order without contacting the original signing platform. GitHub

The proposal remains open and unmerged, with no released implementation. Its current BRC number may also change during review.

Each Step Advances the Previous State

The central mechanism is straightforward.

A signing process begins with a one-satoshi state output representing the envelope. Each subsequent signature, authorization or other defined action spends that output and creates its successor.

The acting party signs a digest that commits not only to the document and action but also to the specific previous outpoint being advanced.

That creates an ordering relationship between signatures.

A signature made for one stage cannot simply be moved into another stage because it is cryptographically bound to the state that preceded it. Likewise, two different confirmed successors cannot both spend the same previous state output.

The proposal therefore uses the transaction chain itself to establish the sequence of confirmed signing actions rather than leaving that ordering solely inside a coordinator’s database. GitHub

A signing policy can define several stages and roles, including signers, authorizers, witnesses, delegates and copy recipients. Some stages can require approval before later stages become available.

This allows the evidence to represent not only that several people signed a document, but also that a particular approval occurred before another participant was permitted to continue.

The Evidence Travels With the Document

Consent Envelope is designed so that the final document can carry the material needed for later verification.

The proposed evidence bundle includes the envelope definition, the certificates associated with each signing step, identity evidence that was disclosed for verification, and transaction proofs covering the state history.

A verifier can then check that history against independently obtained block headers rather than asking the original signing provider whether its own audit record is authentic. GitHub

The proposal builds this from existing BSV Blockchain standards rather than introducing a new cryptographic system. BRC-220 supplies the signed-hash certificate format, while existing BRCs provide key derivation, PushDrop state outputs, identity certificates, wallet interaction, SPV evidence and message delivery.

The new part is primarily the relationship between those pieces: each signing certificate is tied to the exact state it advances.

That is what turns a collection of independently valid signatures into an ordered signing history.

The Coordinator Still Has a Role

Consent Envelope does not eliminate the signing service.

A coordinator can still store encrypted material, relay signing requests, fund transactions and broadcast state changes. The proposal instead attempts to reduce how much authority that coordinator has over the evidence itself.

Documents are encrypted, and the specification says the coordinator should not receive their unwrapped encryption keys. Parties verify the history before signing, while the evidence needed for later verification is retained outside the coordinator’s private database. GitHub

There is nevertheless an important availability boundary.

If control of the state output has been delegated to a coordinator and that coordinator disappears, an unfinished envelope can become stranded. The signing steps completed up to that point remain verifiable, but the original envelope may no longer be able to advance. The specification therefore recommends that senders concerned about this risk retain control while delegating only funding and relay functions. GitHub

Portable evidence does not mean every operational dependency has disappeared.

Cryptographic Evidence Is Not the Same as Legal Identity

The proposal is also careful about what its verification establishes.

A verifier may be able to establish that particular keys signed particular steps, that those steps appeared in a particular confirmed order and that the relevant transactions are included under the supplied blockchain evidence.

That does not automatically prove the real-world identity of the person operating a key.

Consent Envelope defines several identity levels and can incorporate organization keys, certificates, domain observations and delegated authority, but those mechanisms still depend on the quality of the identity evidence supplied.

Nor does the proposal declare a document legally binding merely because its cryptographic checks succeed.

Its legal-considerations section explicitly separates technical evidence from legal signature status, which depends on jurisdiction and circumstances outside the specification. GitHub

Tested Specification, Not Yet an Implementation

The submission includes an extensive set of reproducible test vectors.

According to the PR, the author independently recomputed the specification’s commitments, derived keys, signatures, scripts and other test values using a separate Python implementation and cross-checked relevant values against @bsv/sdk. The submission reports 40 checks passing. GitHub

But that should not be mistaken for a released Consent Envelope application.

The PR explicitly contains no runnable implementation. It is currently a documentation and interoperability proposal, with test vectors intended to make later independent implementations checkable against the same rules. GitHub

The proposed number is also not final. The pull request currently calls the standard BRC-222, but review has noted that lower unallocated numbers may need to be considered under the repository’s numbering convention. GitHub

Evidence That Can Outlive the Service

The interesting idea in Consent Envelope is therefore not simply recording document hashes on BSV Blockchain.

A hash can establish that particular data existed in relation to a transaction, but it does not by itself describe a multi-party approval process.

BRC-222 attempts to preserve something richer: who acted, which state they acted on, what role they were performing and where that action occurred in the sequence.

The completed document is then intended to carry the evidence necessary to reconstruct that history later.

If implemented successfully, that would give a signed document a degree of independence from the application that originally coordinated it. The service can disappear while the retained document, transaction evidence and block headers remain available for another verifier to examine.

That is still a proposal rather than a demonstrated document-signing system. But it addresses a recognizable data-infrastructure question: can the evidence behind a digital approval process remain independently checkable after the service that created the experience is gone?

Developer context

Crumbs (vincemedia on GitHub) submitted the Consent Envelope proposal. The public GitHub profile describes its owner as a product designer and front-end developer focused on making complicated systems easier to use. GitHub

Crumbs is also a coauthor, with root and Kuro, of BRC-210 — Derived Collectibles, which defines collectible behavior derived from block height and on-chain provenance rather than storing only a fixed rendered state. GitHub

The two proposals address very different applications, but both emphasize information that can be independently recomputed or checked rather than relying only on an application’s interpretation of its own records.

Source Links

BRC-222 — Proposal and Discussion, GitHub PR #323

BRC-222 — Submitted Specification

BSV TIMES – Under the Surface

Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.

Update — October 16, 2026