> 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/0134.md).

# Multicast Anchor Transaction Frame Format

Jeff Harris (<jeff@lightweb.net>)

## Abstract

This BRC defines a new frame version (`0x06`) for distributing chained anchor transactions over the IPv6 multicast fabric. An anchor transaction is the root (first) transaction in a chain of dependent transactions. Because all subsequent transactions in the chain reference the anchor as an input, every subscriber must receive it regardless of which shard its TxID would otherwise hash to.

## 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 TxID. Chained anchor transactions cannot be sharded this way because:

1. **Dependency root** — all dependent (chained) transactions in the set reference the anchor's TxID as an input. A subscriber that misses the anchor cannot validate any dependent transaction in the chain.
2. **Unpredictable placement** — the anchor's TxID is not known in advance by subscribers; they cannot pre-join the correct shard group.
3. **Cross-shard span** — the chain may span many shards. The anchor itself might hash to shard 0 while dependents are spread across shards 1–15. Every subscriber needs the anchor irrespective of which shards they follow.
4. **Visibility over confirmation** — anchor transactions do not need to be confirmed before use; they need only to be visible and valid. Wide visibility is the primary requirement.

BRC-134 addresses this by routing anchor frames to the **GroupBlockBroadcast** group (`FF0E::B:FFFE`), the same global control channel used for block headers and coinbase transactions (BRC-131, BRC-133). All subscribers join this group unconditionally.

## Specification

### Control-Plane Multicast Group

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

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

The global scope (`FF0E`) ensures anchor transactions cross site boundaries and reach all geographically distributed subscribers. 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`).

### Frame Header Format (92 bytes)

The BRC-134 header is **layout-identical** to BRC-124. Infrastructure components that inspect the Magic, HashKey, or SeqNum fields read correct values at the same offsets.

| Offset | Size | Align | Field         | Value / Notes                                             |
| ------ | ---- | ----- | ------------- | --------------------------------------------------------- |
| 0      | 4    | —     | Network Magic | `0xE3E1F3E8` (BSV mainnet P2P magic)                      |
| 4      | 2    | —     | Protocol Ver  | `0x02BF` (703, BSV large-block baseline)                  |
| 6      | 1    | —     | Frame Version | **`0x06`** — BRC-134 anchor transaction                   |
| 7      | 1    | —     | Reserved      | `0x00`                                                    |
| 8      | 32   | 8B    | TxID          | SHA256d of the anchor transaction (internal byte order)   |
| 40     | 8    | 8B    | HashKey       | XXH64(senderIPv6 ∥ 0xFFF9 ∥ zeros); stamped by proxy      |
| 48     | 8    | 8B    | SeqNum        | Monotonic per-sender counter; stamped by proxy; 0 = unset |
| 56     | 32   | 8B    | LayoutPad32   | All zeros (no subtree scope for anchor frames)            |
| 88     | 4    | —     | PayloadLen    | Size of anchor transaction payload in bytes (uint32 BE)   |
| 92     | \*   | —     | Payload       | Raw serialised anchor transaction (no P2P envelope)       |

**Key distinction from BRC-124:** the version byte at offset 6 is `0x06` rather than `0x02`. All other field offsets and sizes are identical. The `LayoutPad32` field at bytes 56–87 is always zeros — anchor frames have no subtree scope. The field is kept for layout uniformity: the proxy TCP reader, stamping path, listener, and retry endpoint all share the single `HeaderSize` constant.

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

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

* The proxy stamps `HashKey = XXH64(senderIPv6 ∥ 0xFFF9 ∥ zeros)` and `SeqNum` (monotonic per sender) in-place before forwarding. The virtual index `0xFFF9` gives anchor frames an independent flow identity from BRC-131 block frames, which both travel on the same `GroupBlockBroadcast` multicast address. If the frame arrives pre-stamped (`SeqNum != 0`), it is forwarded verbatim.
* Listeners observe `(anchorGroupIdx=0xFFF9, zeroSubtreeID, HashKey, SeqNum, TxID)` for gap detection and dispatch NACKs to retry endpoints on gap.
* Retry endpoints join `FF0E::B:FFFE` and cache BRC-134 frames by `HashKey ∥ SeqNum`. On NACK, the frame is retransmitted to `FF0E::B:FFFE`.

## Constants Reference

| Name                  | Value    | Description                                                                  |
| --------------------- | -------- | ---------------------------------------------------------------------------- |
| `FrameVerV6`          | `0x06`   | BRC-134 chained anchor transaction frame version                             |
| `GroupBlockBroadcast` | `0xFFFE` | Control-plane multicast group index (shared with BRC-131/BRC-133)            |
| `GroupAnchorFlow`     | `0xFFF9` | Virtual HashKey ingredient; anchor flow identity (never a multicast address) |

## References

* [BRC-124: Multicast Transaction Frame Format](/brc/transactions/0124.md) — base header layout reused by BRC-134
* [BRC-133: Coinbase Transaction Delivery](/brc/transactions/0133.md) — another control-group transaction type using BRC-131


---

# 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/0134.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.