> 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/transactions/0149.md). # Multicast BEEF Object Frame Format Jeff Harris () ## Abstract This BRC specifies the three wire forms of the [BRC-148](/transactions/0148.md) BEEF object plane: the **multicast object frame** (FrameVer `0x09`, assigned here), which carries one BEEF-family transaction object on the plane's domain-tagged shard groups; the **submission record**, the unicast envelope a publisher sends to operator ingress naming one object to one or more overlay topics; and the **delivery record**, the unicast envelope a delivery edge streams to a subscriber. The frame reuses the [BRC-124](/transactions/0124.md) 92-byte header layout at identical offsets, so existing classifiers, retransmission, and fragmentation infrastructure require no changes. The records exist because BEEF bytes are not self-delimiting without a full structural parse — which the fabric never performs — so unlike the BRC-143/BRC-144 push lanes, BEEF lanes carry an explicit length-carrying envelope. ## Copyright This BRC is licensed under the Open BSV License. ## Motivation [BRC-148](/transactions/0148.md) allocates the BEEF object plane (domain `0x1`), defines its topical sharding, filtering, and coordination, and constrains the header fields that addressing, retransmission, and filtering depend on — but, following the convention that frame formats are specified separately from addressing (BRC-124 vs BRC-129; BRC-143/BRC-144 vs their carriage rules), it defers the concrete formats to this BRC. This BRC assigns the frame version and fixes the byte layouts: the fabric frame, and the two unicast record forms that carry BEEF objects between participants and operator infrastructure. ## Specification ### BEEF object frame (FrameVer `0x09`) — 92-byte header + payload FrameVer `0x09` is assigned to the BEEF object frame (the next code after BRC-142's `0x08`). | Offset | Size | Type | Field | Description | | ------ | ---- | ----------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 0 | 4 | `uint32` BE | Network Magic | `0xE3E1F3E8` (BSV mainnet P2P magic). Frames with incorrect magic are rejected. | | 4 | 2 | `uint16` BE | Protocol Version | `0x02BF` (703). Informational; receivers do not validate. | | 6 | 1 | `byte` | Frame Version | `0x09` — BEEF object frame. Any other value is handled by a different decoder. | | 7 | 1 | `byte` | DeliverCount | How many of the payload record's leading topics are **deliverable** (matched by delivery edges): `1` from open ingress, up to the operator's cap from authenticated ingress. `0` is the legacy encoding and is read as `1`. Every further name in the record is a **label**: carried to the subscriber, never matched. Set by the ingress, never taken from a publisher's pre-framed value. The BEEF encoding version is **not** here — it is the object's first four bytes. | | 8 | 32 | `[32]byte` | ContentID | `SHA-256d(payload bytes)` — the object's identity, over the payload as carried (the submission record when the ingress carried one, so the same object under a different label set is a distinct submission); and the BRC-130 reassembly verification hash. With TopicID it keys both fragment reassembly and duplicate suppression. Never the subject TxID. | | 40 | 8 | `uint64` BE | HashKey | Per-(sender, group) flow identifier; stamped at ingress; `0` = unset. Derivation and flow semantics per [BRC-148](/transactions/0148.md) §Frame carriage (TopicID excluded). | | 48 | 8 | `uint64` BE | SeqNum | Per-sender monotonic counter within the (sender, group) flow; stamped at ingress; `0` = unstamped. Drives gap detection, NACK recovery, and retransmit dedup. | | 56 | 32 | `[32]byte` | TopicID | `SHA-256(UTF-8 topic name)` of the record's **first** topic. The shard key: group derivation takes its top bits, and it is always the first deliverable topic. Occupies the field that carries the SubtreeID in transaction frames. | | 88 | 4 | `uint32` BE | Payload Length | Byte length of the payload. | | 92 | \* | `[]byte` | Payload | The **submission record verbatim** (leads with the `0xBEEF` tag; every topic name the publisher submitted, then the object, proof data intact), or a bare BEEF object (leads with `0x01`). The two cannot collide on their leading bytes. | #### Object leading bytes — BEEF version word The object is the record's `Object` field, or the whole payload when the payload is a bare object. | Object `[0:4]` | Type | Encoding | Reference | | -------------- | -------------------------------------------- | ----------------------------- | ------------------------------- | | `0100BEEF` | `uint32` LE (4022206465) | BEEF | [BRC-62](/transactions/0062.md) | | `0200BEEF` | `uint32` LE (4022206466) | BEEF V2 (TXID-only extension) | [BRC-96](/transactions/0096.md) | | `01010101` | 4-byte prefix (32-byte subject TxID follows) | Atomic BEEF | [BRC-95](/transactions/0095.md) | The version word is the BRC-148 version filter's input — an encoding-capability gate only, never an overlay namespace. Intentionally absent from the header: the subject TxID (consumer-level semantics inside the payload) and any per-format sub-type byte (the marker is self-identifying at a fixed offset). #### Fragmentation Objects exceeding the path MTU are carried as [BRC-130](/transactions/0130.md) fragments (`FrameVer 0x03`, `OrigFrameVer = 0x09`) with bytes 0–91 layout-identical to the table above, so ContentID, TopicID and DeliverCount appear in every fragment; ContentID is the reassembly verification hash. Reassembly MUST key slots on the (ContentID, TopicID) pair. The record's field order puts the topic list before the object, so fragment 0 carries the whole list and an edge may discard a non-matching object before reassembling it; that order is fixed for this reason. The interaction with filtering is specified in BRC-148 §Frame carriage. ### Submission record (ingress) A publisher submits the pair *(topic list, BEEF object)* as one record: ``` Offset Size Field 0 2 Tag (uint16 BE = 0xBEEF — record discriminator on shared ports) 2 1 RecordVer (0x01) 3 1 TopicCount (1..15) 4 … Topics (TopicCount × { uint8 NameLen (1..64) ∥ NameLen bytes UTF-8 topic name }) … 4 ObjectLen (uint32 BE, ≥ 1; operators bound the maximum accepted size) … … Object (the BEEF object; leading marker per the version-word table) ``` The ingress emits the record as **one** `FrameVer 0x09` frame at any topic count: the payload is the record verbatim, `TopicID = SHA-256(topics[0])`, ContentID is over the record, and the frame goes to the first topic's group. Ingress duplicate suppression keys on the (ContentID, TopicID) pair per BRC-148. A record whose object does not lead with a marker from the version-word table, whose lengths violate the bounds above, or whose object exceeds the operator's size bound MUST be rejected. A malformed record desynchronises its stream; the receiver MUST close the connection. #### Deliverable topics and labels A record names 1..15 topics on every path and is never rejected for its count. What the ingress path decides is how many of the leading names are **deliverable** — matched by delivery edges against subscribers' elections — and it writes that number into `DeliverCount`. Every further name is a **label**: it reaches every subscriber the object reaches, inside the payload, and is never matched on, so a subscriber electing only a label topic does not receive the object. * **Open / public / anonymous ingress** MUST set `DeliverCount = 1`. One deliverable topic per anonymous record is what keeps the free door free of amplification: a record costs one frame and reaches one topic's subscribers however many names it carries. * **Authenticated / consumer-tunnel ingress** MAY set `DeliverCount` up to the operator's cap, which is at most 15 and is operator policy. The operator's fan-out exposure is bounded by that cap, not by `TopicCount`. `DeliverCount` is the ingress's to set. An ingress accepting a pre-framed `FrameVer 0x09` MUST overwrite it from its own policy for that source, and MUST reject a pre-framed record whose header TopicID is not the hash of its first topic. There is no per-topic charge on either path: nothing beyond the deliverable prefix is delivered, so nothing beyond it is priced, and a subscriber's cost stays what its lane carried. A subscriber that elected more than one of a frame's deliverable topics receives the object **once**, under the first elected topic in record order; the delivery record below names that topic. #### Detection on shared ports BEEF submission records MAY ride the open transaction port alongside the existing grammars, distinguished by leading bytes — network magic `0xE3E1F3E8` selects a framed datagram, the `0xBEEF` tag selects a submission record, and anything else is a bare transaction ([BRC-12](/transactions/0012.md) raw / [BRC-30](/transactions/0030.md) Extended Format, whose little-endian version byte at offset 1 is `0x00` — the three forms cannot collide). Over TCP the grammar is committed once per connection; over UDP it is detected per datagram, and a record must fit one datagram (larger objects submit over a stream transport). Operators MAY additionally expose a dedicated single-record-grammar port for flow separation; it carries no additional admission semantics. ### Delivery record (egress) A delivery edge streaming BEEF objects to a subscriber over a unicast lane emits, per delivered object: ``` Offset Size Field 0 32 TopicID (the identifier of the elected topic that matched) 32 4 PayloadLen (uint32 BE, ≥ 1) 36 … Payload (the frame payload verbatim: the submission record, or a bare object) ``` The TopicID is the one of the subscriber's elected topics that the edge matched, which need not be the frame's header TopicID. The payload is the frame payload verbatim, so when the publisher submitted a record the subscriber receives every topic name it wrote, deliverable and label alike, and can map the matched identifier back to one of them; a subscriber that receives a bare object maps the identifier back from its own election. The subscriber tells the two forms apart by the payload's leading bytes exactly as the frame does. Subscribers taking whole `FrameVer 0x09` frames instead of a stripped lane need no record; the frame already carries the identifiers and the payload. ## References * [BRC-12: Raw Transaction Format](/transactions/0012.md) — bare-transaction grammar sharing the open port * [BRC-30: Extended Format Transaction](/transactions/0030.md) — bare-transaction grammar sharing the open port * [BRC-62: Background Evaluation Extended Format (BEEF) Transactions](/transactions/0062.md) — BEEF encoding and version word * [BRC-95: Atomic BEEF Transactions](/transactions/0095.md) — explicit-subject BEEF encoding * [BRC-96: BEEF V2 Txid Only Extension](/transactions/0096.md) — TXID-only BEEF encoding * [BRC-124: Multicast Transaction Frame Format](/transactions/0124.md) — the 92-byte header layout this frame reuses * [BRC-126: Multicast Transaction NACK Retransmission Protocol](/transactions/0126.md) — retransmission machinery operating on HashKey/SeqNum * [BRC-130: Multicast Transaction Frame Fragmentation](/transactions/0130.md) — fragmentation for large objects * BRC-143 / BRC-144 (Multicast Subtree Data / Block Push Frame Formats) — push-lane format precedent * [BRC-148: Multicast Shard Domain Partitioning and the BEEF Object Plane](/transactions/0148.md) — the plane, sharding, filtering, and coordination this format serves --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://bsv.brc.dev/transactions/0149.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.