1Sat Provenance Remittance for Basket `1sat`

Abstract

This BRC defines the provenance remittance carried in BRC-37 customInstructions for outputs in the companion basket profile 1sat (BRC-147). It specifies an offline-verifiable package that binds a current 1-sat outpoint (tip) to a 1Sat Ordinals origin, using BEEF or AtomicBEEF plus local verification of the first ord inscription envelope.

Together with BRC-147, this enables interoperable 1Sat hold/transfer while preventing forgeable origin: tags from being treated as proof. Verification does not require a global ordinals indexer.

Motivation

BRC-147 documents how wallets hold and transfer 1Sat tips and how they attach display metadata. Those metadata fields remain claims: a malicious or buggy sender can attach another inscription’s origin to an unrelated 1-sat UTXO. Indexer-only checks help UX but introduce a trust dependency when the indexer is wrong, lagging, or unavailable.

BRC-62 / BRC-95 already provide SPV transaction ancestry packages. This BRC applies those formats to the 1Sat tip→origin path and adds the local script rule that the origin locking script contains a valid first ord envelope (1Sat Ordinals, aligned with BRC-67 SPV principles).

Specification

Scope

This remittance applies when:

• The output is associated with basket 1sat as defined in BRC-147 (after BRC-46 name normalization), and
• The tip being transferred or internalized is a 1-satoshi output.

Out of scope: OrdLock marketplace contracts, BSV-20/21, minting APIs, redefinition of 1Sat origin theory, and basket naming/tags (see BRC-147).

Transport

Provenance is embedded as the provenance field of the basket profile’s customInstructions JSON object (BRC-37). Display fields (origin, name, app) remain as defined by BRC-147 and MUST NOT be treated as proven unless this remittance verifies.

Wallets that do not implement this BRC MUST still store and forward unknown customInstructions unchanged (BRC-37).

Provenance object (v2)

{
  "v": 2,
  "origin": "<txid_vout>",
  "tip": "<txid_vout>",
  "path": ["<tip>", "…", "<origin>"],
  "beefB64": "<base64>",
  "contentType": "<optional string>"
}

Outpoint normalization (dot ↔ underscore) follows BRC-147.

Non-conforming versions

Provenance objects with v !== 2, or path-only packages without beefB64, are not defined by this BRC and MUST NOT be considered conforming remittances. Implementations MAY use private fallbacks for local UX; they MUST NOT advertise those fallbacks as this BRC.

Sender requirements

A conforming sender transferring a 1sat tip under BRC-147 SHOULD:

1. Determine the true origin of the tip (indexer-assisted discovery is allowed for building the package).
2. Construct path tip→origin such that each consecutive pair with different transaction ids is related by a spend of the parent outpoint as an input to the child transaction.
3. Assemble beefB64 covering every transaction id appearing in path.
4. Prefer AtomicBEEF (BRC-95) whose subject txid is the tip transaction.
5. Self-verify using the Receiver rules below before broadcast.
6. If a valid v2 package cannot be produced, the sender MUST NOT claim a verified origin via tags alone. The sender MAY omit provenance; receivers MUST then treat identity as unverified per BRC-147.

Senders MUST NOT embed full inscription content solely for this remittance; envelope presence at origin is sufficient.

Receiver requirements

Given a candidate tip outpoint T and customInstructions.provenance with v === 2, a conforming receiver MUST verify as follows. On any failure, the receiver MUST treat origin identity as unproven and MUST NOT adopt sender name / app / origin: tags as authoritative for that tip (BRC-147 claims rule).

1. Parse — Decode beefB64 as BEEF (BRC-62) or AtomicBEEF (BRC-95). Failure → unproven.

2. Structure — The BEEF MUST pass structural validation (e.g. Beef.verifyValid). Use of txid-only entries (BRC-96) is allowed only when the receiver already trusts those transactions by other means.

3. Atomic subject (when AtomicBEEF) — If the bytes are AtomicBEEF, the subject txid MUST equal the tip’s transaction id.

4. Tip binding — provenance.tip and path[0] MUST equal tip outpoint T after normalization.

5. Origin binding — path[path.length - 1] MUST equal provenance.origin.

6. Ancestry — For each consecutive pair (child, parent) in path with different transaction ids, the child transaction in the BEEF MUST spend parent as an input.

7. One-sat — For each outpoint in path present in the BEEF with a known satoshi value, that value MUST be 1.

8. Inscription — The locking script of origin MUST contain a valid first ord envelope as defined by 1Sat Ordinals:

   OP_FALSE OP_IF <"ord"> … OP_ENDIF
   

   on a 1-sat output. Subsequent envelopes on the same sat MUST be ignored for origin identity (1Sat rule).

9. Headers (RECOMMENDED) — Receivers SHOULD confirm BEEF merkle roots against a header source / ChainTracker per BRC-67 when available.

On success, the receiver MAY treat provenance.origin as the proven origin for tip T and MAY use indexer metadata keyed by that origin for display.

Relationship to BRC-147

Compatibility

• This BRC does not alter BRC-62/95 encodings; it only constrains how they are used inside customInstructions.provenance.
• Deep histories may produce large remittances. Implementations SHOULD prefer AtomicBEEF and MAY refuse to embed packages above an implementation-defined size, falling back to “unproven” rather than truncated proofs.
• Partial BEEF (structurally valid but missing a path transaction) MUST fail verification.

Security considerations

• Tag spoofing — Without this remittance, origin: tags are forgeable. Receivers that skip verification reintroduce the attack.
• Indexer divergence — Indexers may lag or err. A verified remittance is authoritative for tip↔origin binding; indexers remain useful for discovery and media URLs.
• Burn / re-origin — If a sat is packed into a multi-sat output, 1Sat origin tracking ends. Remittances MUST NOT invent a continuous path across a burn.
• Oversized remittance — Truncating path or beefB64 to fit a size budget invalidates the proof; omit provenance instead.
• Unspent status — This remittance proves tip→origin identity. Proving the tip remains unspent requires the same network / UTXO checks as accepting any BSV payment.

Implementations

• HandCash Desktop (reference): builds and verifies provenance v2 on collectable send / list.
  Source: src/wallet/oneSatProvenance.ts, src/wallet/oneSatInscription.ts in HandCash/HANDCASH-DESKTOP.

References

1. BRC-147 — 1Sat Ordinals Basket Profile for BRC-46 / BRC-100
2. 1Sat Ordinals protocol — https://docs.1satordinals.com
3. BRC-37 — Basket and Custom Instructions Extension for Bitcoin Outpoints
4. BRC-46 — Wallet Transaction Output Tracking (Output Baskets)
5. BRC-62 — Background Evaluation Extended Format (BEEF) Transactions
6. BRC-67 — Simplified Payment Verification
7. BRC-95 — Atomic BEEF Transactions
8. BRC-96 — BEEF V2 Txid Only Extension
9. BRC-100 — Unified Open BSV Wallet-to-Application Interface