> For the complete documentation index, see [llms.txt](https://bsv.brc.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bsv.brc.dev/tokens/0150.md). # 1Sat Provenance Remittance for Basket 1sat Brandon Cryderman / HandCash () ## Abstract This BRC defines the **provenance remittance** carried in [BRC-37](/outpoints/0037.md) `customInstructions` for outputs in the companion basket profile `1sat` ([BRC-147](/tokens/0147.md)). It specifies an offline-verifiable package that binds a current 1-sat outpoint (*tip*) to a 1Sat Ordinals *origin* ([BRC-159](/tokens/0159.md)), 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](/tokens/0160.md)). Together with [BRC-147](/tokens/0147.md), 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](/tokens/0147.md) 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](/transactions/0062.md) / [BRC-95](/transactions/0095.md) already provide SPV transaction ancestry packages. This BRC applies those formats to the 1Sat tip→origin path ([BRC-159](/tokens/0159.md)) and adds the local script rule that the origin locking script contains a valid first `ord` envelope ([BRC-160](/tokens/0160.md), aligned with [BRC-67](/transactions/0067.md) SPV principles). ## Specification ### Scope This remittance applies when: * The output is associated with basket `1sat` as defined in [BRC-147](/tokens/0147.md) (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](/tokens/0159.md)), inscription envelope format ([BRC-160](/tokens/0160.md)), and basket naming/tags (see [BRC-147](/tokens/0147.md)). ### Transport Provenance is embedded as the `provenance` field of the basket profile’s `customInstructions` JSON object ([BRC-37](/outpoints/0037.md)). Display fields (`origin`, `name`, `app`) remain as defined by [BRC-147](/tokens/0147.md) 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](/outpoints/0037.md)). ### Provenance object (v2) ```json { "v": 2, "origin": "", "tip": "", "path": ["", "…", ""], "beefB64": "", "contentType": "" } ``` | 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](/transactions/0062.md)) covering every `path` transaction **and** every preceding input source required for BRC-159 sat ordering on each hop. AtomicBEEF ([BRC-95](/transactions/0095.md)) 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](/tokens/0147.md). #### 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](/tokens/0147.md) 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](/transactions/0062.md)) for remittance ancestry. AtomicBEEF ([BRC-95](/transactions/0095.md)) 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](/tokens/0147.md). ### 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](/tokens/0147.md) claims rule). 1. **Parse** — Decode `beefB64` as BEEF ([BRC-62](/transactions/0062.md)) or AtomicBEEF ([BRC-95](/transactions/0095.md)). Failure → unproven. 2. **Structure** — The BEEF MUST pass structural validation (e.g. `Beef.verifyValid`). Use of txid-only entries ([BRC-96](/transactions/0096.md)) 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](/tokens/0159.md) (*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](/tokens/0160.md) on a 1-sat output. Subsequent envelopes on the same sat MUST be ignored for origin identity ([BRC-159](/tokens/0159.md) / [BRC-160](/tokens/0160.md)). 10. **Headers (RECOMMENDED)** — Receivers SHOULD confirm BEEF merkle roots against a header source / ChainTracker per [BRC-67](/transactions/0067.md) 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](/tokens/0159.md) (*Examples*). **Pass (canonical — no extra input sources):** token input first, tip at `o0`. ``` inputs: i0 = 1-sat parent P i1 = funding … outputs: o0 = 1-sat tip T change … ``` 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):** ``` inputs: i0 = funding (5_000) i1 = 1-sat parent P outputs: o0 = 1 sat o1 = change … ``` 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](/tokens/0159.md) | | `ord` inscription envelopes | [BRC-160](/tokens/0160.md) | | Basket name `1sat`, tags, display `customInstructions`, createAction / internalizeAction flows | [BRC-147](/tokens/0147.md) | | `provenance` object schema + verify/build rules | **This BRC** | | Whether unproven tips may be shown with sender `name`/`app` | [BRC-147](/tokens/0147.md) (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](/transactions/0158.md) **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](/tokens/0159.md)). 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](/transactions/0158.md) 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](/tokens/0159.md) / [BRC-160](/tokens/0160.md) 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](/transactions/0158.md) 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](https://github.com/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](/tokens/0159.md) — 1Sat Ordinals — Single-Satoshi Tokens and Origin Tracking 2. [BRC-160](/tokens/0160.md) — 1Sat Ordinals — Inscription Envelopes 3. [BRC-147](/tokens/0147.md) — 1Sat Ordinals Basket Profile for BRC-46 / BRC-100 4. 1Sat Ordinals protocol — 5. [BRC-37](/outpoints/0037.md) — Basket and Custom Instructions Extension for Bitcoin Outpoints 6. [BRC-46](/wallet/0046.md) — Wallet Transaction Output Tracking (Output Baskets) 7. [BRC-62](/transactions/0062.md) — Background Evaluation Extended Format (BEEF) Transactions 8. [BRC-67](/transactions/0067.md) — Simplified Payment Verification 9. [BRC-95](/transactions/0095.md) — Atomic BEEF Transactions 10. [BRC-96](/transactions/0096.md) — BEEF V2 Txid Only Extension 11. [BRC-158](/transactions/0158.md) — Outpoint BEEF 12. [BRC-100](/wallet/0100.md) — Unified Open BSV Wallet-to-Application Interface --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://bsv.brc.dev/tokens/0150.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.