> 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.

## 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`).

### 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                                              |
| `GroupBlockBroadcast` | `0xFFFE` | Block control multicast group index (egress)                                   |
| `GroupCoinbaseFlow`   | `0xFFF8` | Virtual HashKey ingredient; coinbase flow identity (never a multicast address) |

## References

* [BRC-124: Multicast Transaction Frame Format](/brc/transactions/0124.md) — base header layout reused by BRC-131
* [BRC-134: Chained Anchor Transaction Frames](/brc/transactions/0134.md) — another control-group transaction type


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://hub.bsvblockchain.org/brc/transactions/0133.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.