> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/brc/transactions/0133.md).

# Multicast Coinbase Transaction Frame Format

Jeff Harris (<jeff@lightweb.net>)

## Abstract

This BRC defines the policy and wire mechanism for distributing coinbase transactions over the IPv6 multicast fabric. Coinbase transactions are carried as a dedicated message type within BRC-131 block control frames and delivered to all subscribers via the control-plane multicast group, independently of the shard groups used for ordinary transaction distribution.

## Status Note

**Deprecated, and retained deliberately.** Standalone coinbase carriage, the mechanism this BRC specifies (BRC-131 `MsgType 0x02`, `BlockMsgCoinbase`), is deprecated. It is kept on purpose and is not withdrawn.

* **Not produced.** A coinbase transaction is invalid to a node unless it is connected to its block, so current implementations never emit standalone coinbase frames. The coinbase travels inline in the block body defined by [BRC-144](/brc/transactions/0144.md), where it inherits the proof of work of the block it belongs to.
* **Dropped by default.** A standalone coinbase frame carries no proof of work of its own, so nothing about it can be validated in isolation. A listener that gates block-control frames before fan-out (the reference listener's block-control gate, which is on by default) drops such a frame; the reference implementation counts it under the drop reason `coinbase_legacy`.
* **Retained deliberately.** A future design may need to carry blocks and their coinbase separately across the multicast fabric and recombine them at the edges. This specification keeps that option open, so it remains the reference for such a design, for deployments that disable the gate, and for decoding archived traffic.
* **Reserved.** The BRC-133 number, BRC-131 `MsgType 0x02`, and the virtual flow index `0xFFF8` (`GroupCoinbaseFlow`) remain reserved for standalone coinbase carriage. They must not be reused for any other purpose.

## Copyright

This BRC is licensed under the Open BSV License.

## Motivation

The multicast fabric shards ordinary transactions across per-shard multicast groups based on the top bits of each transaction's TxID. Coinbase transactions cannot be sharded this way because:

1. **Universal relevance** — the coinbase TxID is included in every block announcement and is required to verify the block's Merkle root.
2. **Fee aggregation** — coinbase outputs pay the block subsidy and miner fee aggregations that downstream systems need to validate template construction.
3. **Unpredictable placement** — no subscriber can predict which shard a coinbase TxID would hash to before the block is found.

BRC-133 addresses this by routing coinbase frames to the **GroupBlockBroadcast** group (`FF0E::B:FFFE`), a global control channel that all subscribers join unconditionally.

## Specification

### Control-Plane Multicast Group

Coinbase frames are delivered on the **GroupBlockBroadcast** group:

| Index    | Scope  | Compressed Address | Constant              |
| -------- | ------ | ------------------ | --------------------- |
| `0xFFFE` | global | `FF0E::B:FFFE`     | `GroupBlockBroadcast` |

The global scope (`FF0E`) ensures coinbase transactions cross site boundaries. The group index `0xFFFE` is in the reserved control-plane range and never overlaps with data-plane shard groups (maximum shard group index is `0x0FFF` for `shard_bits=12`).

The address is shown in ASM form (`FF0E::B:FFFE`), intra-domain only under RFC 8815; inter-domain delivery uses the SSM address `FF3E::B:FFFE` (see [BRC-129](/brc/transactions/0129.md)). The frame format and NACK path are unchanged. Coinbase and block-announce frames are separate flows but share the same egress source (the emitting proxy, `senderIPv6`), so SSM receivers `(S,G)`-join `0xFFFE` once; block-broadcast sources are distributed per BRC-129.

### Wire Format

Coinbase transactions are carried as BRC-131 frames (FrameVer `0x04`) with `MsgType = 0x02` (`BlockMsgCoinbase`).

| Offset | Size | Field        | Value                                                 |
| ------ | ---- | ------------ | ----------------------------------------------------- |
| 6      | 1    | FrameVersion | `0x04` (BRC-131)                                      |
| 7      | 1    | MsgType      | `0x02` = `BlockMsgCoinbase`                           |
| 8      | 32   | ContentID    | CoinbaseTxID — SHA256d of the raw coinbase tx bytes   |
| 40     | 8    | HashKey      | XXH64(senderIPv6 ∥ 0xFFF8 ∥ zeros); stamped by proxy  |
| 48     | 8    | SeqNum       | Monotonic per-sender counter; stamped by proxy        |
| 56     | 32   | LayoutPad32  | All zeros                                             |
| 88     | 4    | PayloadLen   | Length of the raw coinbase transaction bytes          |
| 92     | \*   | Payload      | Raw serialised coinbase transaction (no P2P envelope) |

**Payload encoding:** The payload is a raw BSV serialised transaction — version (4 bytes LE), input vector, output vector, locktime (4 bytes LE) — identical to the encoding used in BRC-12/BRC-124 frames.

### Sequencing and Retransmission

Coinbase frames participate in the same NACK-based reliability mechanism as BRC-124 shard frames:

* The proxy stamps `HashKey = XXH64(senderIPv6 ∥ 0xFFF8 ∥ zeros)` and `SeqNum` (monotonic per sender on the coinbase flow) in-place before forwarding. The virtual index `0xFFF8` (`GroupCoinbaseFlow`) is never used as an actual multicast destination — it appears only in the HashKey computation to give coinbase frames an independent flow identity from BRC-131 block announces, which share the same egress multicast group. If the frame arrives pre-stamped (`SeqNum != 0`), it is forwarded verbatim.
* Listeners observe `(coinbaseFlowIdx=0xFFF8, zeroSubtreeID, HashKey, SeqNum, ContentID)` for gap detection and dispatch NACKs to retry endpoints on gap.
* Retry endpoints join `FF0E::B:FFFE` and cache coinbase frames by `HashKey ∥ SeqNum`. On NACK, the frame is retransmitted to `FF0E::B:FFFE`.

### Relationship to BRC-131 Block Announcements

A `BlockAnnounce` frame (BRC-131, MsgType `0x01`) is sent first and carries the `CoinbaseTxID` in its payload. The separate `BlockMsgCoinbase` frame then carries the full raw coinbase bytes. Subscribers that only need to verify the Merkle root may use the `CoinbaseTxID` from the announce frame without waiting for the coinbase frame itself.

`BlockAnnounce` and `BlockMsgCoinbase` form **separate flows** on the proxy. BlockAnnounce frames use a `HashKey` derived from `(sender, 0xFFFE, zeros)`; Coinbase frames use a `HashKey` derived from `(sender, 0xFFF8, zeros)`. Each flow therefore has its own monotonic `SeqNum` counter, its own `HashKey` value, and is gap-tracked independently by listeners — even though both egress to the same `FF0E::B:FFFE` multicast destination.

## Constants Reference

| Name                  | Value    | Description                                                                              |
| --------------------- | -------- | ---------------------------------------------------------------------------------------- |
| `FrameVerV4`          | `0x04`   | BRC-131 block control frame version                                                      |
| `BlockMsgCoinbase`    | `0x02`   | MsgType: raw coinbase transaction (deprecated; reserved, see Status Note)                |
| `GroupBlockBroadcast` | `0xFFFE` | Block control multicast group index (egress)                                             |
| `GroupCoinbaseFlow`   | `0xFFF8` | Virtual HashKey ingredient; coinbase flow identity (never a multicast address); reserved |

## References

* [BRC-124: Multicast Transaction Frame Format](/brc/transactions/0124.md) — base header layout reused by BRC-131
* [BRC-129: Multicast Group Address Assignments](/brc/transactions/0129.md) — SSM/ASM addressing, scopes, and `(S,G)` source discovery
* [BRC-134: Chained Anchor Transaction Frames](/brc/transactions/0134.md) — another control-group transaction type
* [BRC-144: Block Frame Format](/brc/transactions/0144.md): the block body that carries the coinbase inline, superseding standalone coinbase carriage


---

# 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://hub.bsvblockchain.org/brc/transactions/0133.md?ask=<question>&goal=<user_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.