Outpoint BEEF
Sometimes you need to prove something about one specific piece of a transaction, like a single stamped token, rather than the whole transaction. Existing proof formats bundle everything needed to trust a transaction, but they assume the thing you care about is the transaction itself, not one output buried inside it. Without a way to say "prove this particular output," you either send far more data than needed or leave out the odd extra transactions a token proof actually depends on.
Reference for an AI
Everything an assistant needs to answer questions about BRC-158 accurately, including what it depends on.
Summary
- Why
- Proving the history and validity of one specific output, not a whole transaction, needed its own envelope because bundling only "ancestor" transactions is not always enough for output-scoped proofs like token provenance.
- What
- Outpoint BEEF is a binary envelope, like Atomic BEEF but keyed to a transaction id plus output index (an outpoint) instead of just a transaction id, wrapping a BRC-62/BRC-96 BEEF bundle of the transaction proofs a given output needs.
- How
- A sender prefixes a BEEF bundle with the four-byte marker 0x16a7beef, then the subject transaction id (32 bytes) and the output index (4-byte little-endian uint32), and the receiver rejects the envelope if any transaction the proof depends on is missing.
What this lets you do
- Prove provenance for a single output rather than an entire transaction
- Bundle extra non-ancestor transactions a profile needs, such as funding alongside a 1Sat tip
- Transport output-scoped proofs over binary channels like gateways
- Detect an incomplete proof bundle by checking for missing required transactions
- Support token profiles such as BRC-150 1Sat tip provenance without redefining BEEF itself
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
The specification
Abstract
Outpoint BEEF is Atomic BEEF with a subject outpoint instead of a subject transaction id. Encoding, inclusion, and validation follow BRC-95 except as in the table below. The body is a standard BRC-62 / BRC-96 BEEF. Use for proofs scoped to a specific output (e.g. 1Sat ,[object Object] provenance in BRC-150).
Specification
| Atomic BEEF (BRC-95) | Outpoint BEEF (this BRC) | |
|---|---|---|
| Prefix (4 bytes) | 0x01010101 | 0x16a7beef |
| Subject | TXID (32 bytes) | TXID (32 bytes) + vout (uint32 LE, 4 bytes) |
| Body | BEEF | BEEF (same rules) |
| Graph | Ancestors of the subject transaction | Bundle of transaction proofs needed for the subject outpoint (profile-defined; not limited to tx ancestors) |
| Fail if | Subject tx missing, or unrelated txs present | Any transaction required for the proof is missing |
16a7beef // prefix
2222222222222222222222222222222222222222222222222222222222222222 // subject TXID
00000000 // subject vout (uint32 LE)
0200beef // BEEF V2 (example)
...
Notes (informative)
- The embedded BEEF MAY include transactions that are not ancestors of the subject tx (e.g. funding spent beside a 1Sat tip). That is intentional for profiles such as BRC-150.
- Completeness is profile-defined. Outpoint BEEF alone does not define sat ordering, inscription rules, or BSV-21 admission — see BRC-159 / BRC-160 / BRC-150 / BRC-176.
- Bundle size grows with whatever the profile requires. For 1Sat tip→origin remittance, prefer extending a prior package and omitting oversized bags rather than dropping required input sources; see BRC-150 (Scalability).
- Do not nest this envelope inside BRC-150
beefB64. Basket remittance stays the JSON object; Outpoint BEEF is a parallel binary wire format (gateways, other transports).