Subject BEEF
Some BSV transaction bundles need to say 'here is everything about this one transaction' without being limited to only its ancestor history. Before this, a format that pinned down a single subject transaction, Atomic BEEF, forced the bundle to contain only ancestors and nothing else, which breaks when a protocol needs sibling or related transactions included too. Without a way to say 'this bag is about transaction X, and it can contain whatever a given use case requires,' a developer had no clean way to hand over a flexible, well-identified bundle.
Reference for an AI
Everything an assistant needs to answer questions about BRC-233 accurately, including what it depends on.
Summary
- Why
- A bundle of transactions needs to clearly name which transaction it is about while still allowing arbitrary related transactions, not just the subject's ancestors, something Atomic BEEF's strict ancestor rule does not permit.
- What
- BRC-233 defines Subject BEEF, a byte format that is Atomic BEEF in shape (a prefix plus a subject transaction id) wrapped around a BRC-96 BEEF V2 body, but without Atomic BEEF's restriction to only the subject's ancestors.
- How
- A sender writes the 4-byte prefix 0x5709beef, then the 32-byte subject transaction id, then a full BEEF V2 body containing any transactions a given profile (such as BRC-176) requires, and a reader checks only that the subject transaction is present, not that every other transaction is its ancestor.
What this lets you do
- Tag a bag of transactions with the single transaction it is about
- Carry a BRC-96 BEEF V2 body without being restricted to the subject's ancestors
- Let a parser fail fast if the named subject transaction is missing
- Build profile-specific bundles (e.g. BRC-176 token proofs) that need more than just ancestor history
- Distinguish a flexible bag from Atomic BEEF using a different 4-byte prefix
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
The specification
Abstract
Subject BEEF is Atomic BEEF in shape (a prefix and a subject transaction id in front of a BRC-96 BEEF V2) without BRC-95's restriction to the subject's ancestors. The subject names which transaction the bag is about. Anything else in the bag is allowed: a profile decides what must be present.
Specification
| Atomic BEEF (BRC-95) | Subject BEEF (this BRC) | |
|---|---|---|
| Prefix (4 bytes) | 0x01010101 | 0x5709beef |
| Subject | TXID (32 bytes) | TXID (32 bytes) |
| Body | BEEF | BEEF V2 (BRC-96) |
| Graph | Ancestors of the subject transaction | Any transactions |
| Fail if | Subject tx missing, or unrelated txs present | Subject tx missing |
5709beef // prefix
2222222222222222222222222222222222222222222222222222222222222222 // subject TXID
0200beef // BEEF V2 (example)
...
Notes (informative)
- A reader MUST NOT apply BRC-95's ancestor rule or strip transaction bodies from a Subject BEEF. Re-encoding it as Atomic BEEF may drop transactions a profile requires.
- Completeness is profile-defined (e.g. BRC-176). Subject BEEF alone says only which transaction is the subject.
- The distinct prefix lets a strict Atomic BEEF reader fail cleanly instead of rejecting a valid bag as malformed Atomic BEEF.
- For a subject output rather than a transaction, use Outpoint BEEF.