Beersy
BRC-158

Outpoint BEEF

Some proofs need to be about one specific output of a transaction, like a single carrying a token, rather than about the whole transaction. The existing atomic proof format could only point at a transaction id and had to include only its true ancestors, so it could not describe proofs that needed extra transactions or that only cared about one output. Without a format for this, systems built around tracking individual outputs had no standard way to package and hand over the evidence a recipient needs.

David Casechanged 10 Aug 20261 min read

Reference for an AI

Everything an assistant needs to answer questions about BRC-158 accurately, including what it depends on.

Summary

Why
Some proofs need to certify a single specific output rather than an entire transaction, and existing atomic proof formats could only address a transaction as a whole and only include its strict ancestors.
What
is a binary proof envelope, a variant of , whose subject is a specific transaction output (TXID plus vout) rather than a whole transaction.
How
A verifier reads the 4 byte prefix 0x16a7beef, then a 32 byte TXID plus a 4 byte little endian vout identifying the subject output, then a standard BRC-62/BRC-96 BEEF body containing exactly the transactions the relevant profile requires, and it fails validation if any needed transaction is missing.

What this lets you do

  • Prove that a specific output exists and is spendable, not just that its transaction was mined
  • only the transaction proofs a given profile actually needs, skipping unrelated ancestors
  • Package funding transactions alongside a tip transaction even when they are not ancestors
  • Send this proof over binary transports like gateways instead of embedding it as a JSON string
  • Detect an incomplete bundle immediately because any missing required transaction fails validation

Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.

outpoint beefatomic beefbeef body

The specification

Abstract

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 . Use for proofs scoped to a specific output (e.g. 1Sat tip provenance in BRC-150).

Specification

(BRC-95)Outpoint BEEF (this BRC)
Prefix (4 bytes)0x010101010x16a7beef
SubjectTXID (32 bytes)TXID (32 bytes) + vout (uint32 LE, 4 bytes)
BodyBEEFBEEF (same rules)
GraphAncestors of the subject transaction of transaction proofs needed for the subject outpoint (profile-defined; not limited to tx ancestors)
Fail ifSubject tx missing, or unrelated txs presentAny 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 or inscription rules — see BRC-159 / BRC-160 / BRC-150.
  • 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. remittance stays the JSON object; Outpoint BEEF is a parallel binary wire format (gateways, other transports).
Was this helpful?

Search Beersy

Search standards by number, title, author or topic