Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

1Sat Provenance Remittance for Basket 1sat

Brandon Cryderman / HandCash (brandongcryderman@gmail.com)

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 (BRC-159), using BEEF (or AtomicBEEF when it still covers the hop), BRC-159 sat ordering on every path hop, and a valid first ord envelope on the origin (BRC-160).

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 (BRC-159) and adds the local script rule that the origin locking script contains a valid first ord envelope (BRC-160, 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 (BRC-159), inscription envelope format (BRC-160), 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)

Field
Type
Requirement
Description

v

number

MUST

Schema version. This BRC defines 2.

origin

string

MUST

Inscription origin outpoint in underscore form txid_vout.

tip

string

MUST

Current outpoint being proven, underscore form. MUST equal path[0].

path

string[]

MUST

Ordered outpoints tip → … → origin, inclusive. Length ≥ 1.

beefB64

string

MUST

Base64 encoding of BEEF (BRC-62) covering every path transaction and every preceding input source required for BRC-159 sat ordering on each hop. AtomicBEEF (BRC-95) is allowed only when it still covers that set.

contentType

string

OPTIONAL

Hint from the origin ord envelope content-type field when known.

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. Prefer extending a prior remittance when the tip (or its immediate parent tip) already carries a verified v2 package: prepend the tip being proven to path and merge that tip’s transaction plus preceding input sources needed for BRC-159 sat ordering into beefB64. Do not re-walk full tip→origin lineage when an inductive extension verifies.

  3. Otherwise construct path tip→origin such that each consecutive pair with different transaction ids is a BRC-159 1→1 transfer hop: the parent 1-sat outpoint is the child input vin whose satoshis land on the child vout under sat ordering (sum(input sats before vin) === sum(output sats before vout), and that input is exactly 1 satoshi). A mere spend of the parent as some input is not sufficient — funding inputs that precede the ordinal vin can assign a different sat to the claimed vout.

  4. Assemble beefB64 covering every transaction id appearing in path, and the source transaction of every input that precedes (and including) the ordinal-mapping vin on each hop, so a verifier can calculate the ordinal. Canonical transfers (i0 1-sat → o0 1-sat) add nothing beyond the path transactions. Complex hops (funding before the ordinal input, ordinal paid to o1+, etc.) MUST include those preceding input sources. Missing sats → the hop cannot be proven; omit provenance rather than guessing.

  5. Prefer a full BEEF serialization (BRC-62) for remittance ancestry. AtomicBEEF (BRC-95) keeps only the subject and its recursive SPV dependencies; mined path parents and non-ancestor preceding input sources (funding spent alongside the ordinal) are dropped. AtomicBEEF remains allowed only when it still covers the full path and every preceding input source required for sat ordering.

  6. Self-verify using the Receiver rules below before broadcast.

  7. 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.

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 (the tip named by provenance.tip after normalization).

  4. Tip binding (direct) — If provenance.tip and path[0] equal tip outpoint T after normalization, continue with steps 5–9 for that package.

  5. Tip binding (parent remittance — settle-style) — If step 4 fails, receivers SHOULD accept the package when all of the following hold (soft-latch / pre-broadcast remittance that inherits origin onto held tip T):

    • provenance.tip and path[0] name a parent outpoint P (not T);

    • the package verifies under steps 5–9 with held outpoint P (direct tip binding to P);

    • transaction T spends P as an input vin;

    • output T is 1 satoshi;

    • BRC-159 sat ordering maps that vin onto T’s vout. Preceding input source sats for T MUST be known (in beefB64, linked on T, or otherwise available with T) — fail closed if missing. This inductive hop exists because settle-style transfers often embed remittance for the spent tip before the new tip’s txid is known. Receivers that omit this step remain conforming for direct tip-bound packages but will treat settle-style remittances as unproven unless they rebuild lineage themselves. Receivers that only check “T spends P” without sat ordering MUST NOT treat origin as proven for T.

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

  7. Ordinal continuity — For each consecutive pair (child, parent) in path with different transaction ids:

    • the child transaction in the BEEF MUST spend parent as some input vin;

    • that vin MUST be the BRC-159 ordinal input for the child vout (sum(input sats before vin) === sum(output sats before vout), input satoshis === 1). If any preceding input’s satoshi value is unknown (source tx missing from the BEEF and not otherwise known), verification MUST fail. For parent-remittance acceptance (step 5), the spend and sat-ordering check T → P are applied to transaction T (which MAY be obtained outside beefB64, but preceding input sources for T still MUST be available). An informative outpoint→origin walk is in BRC-159 (Finding origin from an outpoint).

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

  9. Inscription — The locking script of origin MUST contain a valid first ord envelope as defined by BRC-160 on a 1-sat output. Subsequent envelopes on the same sat MUST be ignored for origin identity (BRC-159 / BRC-160).

  10. 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.

Hop examples (informative)

These examples show why spend-as-input ≠ sat continuity, and why AtomicBEEF / SPV ancestry ≠ ordinality. Full sat-ordering walks are in BRC-159 (Examples).

Pass (canonical — no extra input sources): token input first, tip at o0.

Sats before i0 = 0, sats before o0 = 0, and i0 is 1 sat → P lands on T. Path edge T → P needs only the path txs in beefB64.

Fail (funding-first — spend alone is not enough):

The tx still spends P as i1, so a spend-only check passes. Sat ordering does not: funding fills o0 first; P’s sat is #5001 and lands in o1 (or as fee), not in o0. A remittance that claims path o0 → P MUST fail — o0 is a funding sat wearing the wrong origin.

If the real tip is the output that received P, beefB64 MUST include the funding source so the verifier can compute the map. AtomicBEEF often drops that funding tx (it is not a tip ancestor); the bag can still look SPV-valid and still cannot prove ordinality → fail closed.

Settle inherit: soft-latch often proves parent P, then the receiver holds new tip T. Checking only “T spends P” accepts the bad o0 above. Step 5 therefore also requires sat ordering of that vin onto T’s vout (preceding sats known).

Relationship to companion BRCs

Concern
Defined by

Origin, sat ordering, transfer, tip→origin walk

BRC-159

ord inscription envelopes

BRC-160

Basket name 1sat, tags, display customInstructions, createAction / internalizeAction flows

BRC-147

provenance object schema + verify/build rules

This BRC

Whether unproven tips may be shown with sender name/app

BRC-147 (claims); this BRC (when proof fails)

Compatibility

  • This BRC does not alter BRC-62/95 encodings; it only constrains how they are used inside customInstructions.provenance. BEEF/AtomicBEEF prove SPV ancestry, not BRC-159 sat ordering by themselves.

  • Deep histories may produce large remittances. Implementations SHOULD prefer full BEEF when AtomicBEEF would drop path parents or preceding input sources, 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 or a preceding input source needed for sat ordering) MUST fail verification.

  • BRC-158 Outpoint BEEF is a binary wire format for the same tip→origin proof (outpoint-subject BEEF envelope). It is an alternative to this JSON remittance, not a beefB64 encoding option inside it. An Outpoint BEEF used for this remittance MUST still carry the preceding input sources required by BRC-159.

Scalability (informative)

Remittance correctness needs path txs plus preceding input sources for sat ordering (BRC-159). Bundle size therefore grows with tip depth. The hot path is one new hop, not a full tip→origin rebuild.

Prefer

  • Extend a prior verified remittance (sender step 2) — prepend the new tip, merge that tip’s tx and any preceding input sources needed for that hop. Cost stays roughly O(1) per send.

  • Remember a verified package for the held tip and reuse it on the next send.

  • Omit provenance when the package would exceed an implementation size budget (see Compatibility). Unproven is better than a truncated proof.

  • Pin a local verdict after a successful cold verify / genesis hydrate, then discard the large assembled BEEF if it will not travel on the wire.

Avoid

  • Re-walking tip→origin and re-fetching every hop on every send or every inventory refresh when a prior remittance already verifies.

  • Preferring AtomicBEEF (or nesting BRC-158 inside beefB64) to “save bytes” when that drops funding sources needed for sat ordering — the bag looks smaller and still cannot prove the hop.

  • Blocking the UI on an unbounded genesis hydrate — cap hops, allow cancellation, and treat hydrate as cold-start only.

Settle / soft-latch: when the remittance still names spent tip P and the receiver holds new tip T, include (or link) the preceding input sources for T with the package or with T so inherit does not force an extra network hunt to run sat ordering on T → P.

BRC-159 / BRC-160 are not the bottleneck — sat math and envelope parse are cheap. Depth × full BEEF is. Offline proof packaging and size policy live in this BRC (and optionally BRC-158 as a parallel wire format).

Security considerations

  • Tag spoofing — Without this remittance, origin: tags are forgeable. Receivers that skip verification reintroduce the attack.

  • Sat ordering vs spend-only — Spending a 1-sat parent does not prove that output received that sat. Verifiers that skip BRC-159 sat ordering can be convinced an unrelated 1-sat output (e.g. a funding slice paid as 1 sat before the ordinal lands) carries the origin — including on settle-style inherit from parent remittance to tip T.

  • AtomicBEEF omission — AtomicBEEF is an SPV package, not an ordinality package. Do not treat a valid AtomicBEEF as proof that preceding input sources were unnecessary.

  • 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. ≥ 1.2.130 enforces the rules in this revision: BRC-159 sat ordering on every path hop and on settle-style inherit (T from parent remittance P), preceding input sources in full BEEF, fail closed when sats are missing. Hot path extends or reuses a prior remittance; full lineage hydrate is cold-start only, with a size budget that omits oversized packages rather than truncating.

References

  1. BRC-159 — 1Sat Ordinals — Single-Satoshi Tokens and Origin Tracking

  2. BRC-160 — 1Sat Ordinals — Inscription Envelopes

  3. BRC-147 — 1Sat Ordinals Basket Profile for BRC-46 / BRC-100

  4. 1Sat Ordinals protocol — https://docs.1satordinals.com

  5. BRC-37 — Basket and Custom Instructions Extension for Bitcoin Outpoints

  6. BRC-46 — Wallet Transaction Output Tracking (Output Baskets)

  7. BRC-62 — Background Evaluation Extended Format (BEEF) Transactions

  8. BRC-67 — Simplified Payment Verification

  9. BRC-95 — Atomic BEEF Transactions

  10. BRC-96 — BEEF V2 Txid Only Extension

  11. BRC-158 — Outpoint BEEF

  12. BRC-100 — Unified Open BSV Wallet-to-Application Interface

Previous1Sat Ordinals Basket Profile for BRC-46 / BRC-100Next1Sat Ordinals — Single-Satoshi Tokens and Origin Tracking

Last updated

Was this helpful?