Multicast Anchor Transaction Frame Format
The first transaction in a chain has to arrive before any that depend on it, or the rest cannot be checked. This gives it its own frame so it can be treated as the prerequisite it is.
Summary
- Why
- Chained transactions that all depend on one root transaction cannot be safely sharded by TxID, because missing the root makes every dependent transaction unverifiable and its destination shard is unpredictable in advance.
- What
- BRC-134 defines frame version 0x06, a wire format for delivering the root ("anchor") transaction of a dependent transaction chain to every subscriber on a shared control-plane multicast group, instead of sharding it.
- How
- A proxy stamps the BRC-124-layout header with frame version 0x06 and sends it on the GroupBlockBroadcast multicast address (FF0E::B:FFFE, or its SSM equivalent), where listeners detect gaps by HashKey and SeqNum and retry endpoints resend on NACK just as with shard frames.
What this lets you do
- Broadcast an anchor transaction to every subscriber regardless of shard
- Reuse the BRC-124 header layout at identical byte offsets
- Distinguish anchor frames from block and coinbase frames sharing the same group via a virtual HashKey ingredient
- Recover missing anchor frames through the same NACK-based retry path as shard frames
- Route anchor transactions without waiting for confirmation, since only visibility and validity are required
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
Reference for an AI
Everything an assistant needs to answer questions about BRC-134 accurately, including what it depends on.
The specification
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:
- 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.
- Unpredictable placement — the anchor's TxID is not known in advance by subscribers; they cannot pre-join the correct shard group.
- 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.
- 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).
The address is shown in ASM form (FF0E::B:FFFE), intra-domain only under RFC
8815; inter-domain and geographically distributed delivery uses the SSM address
FF3E::B:FFFE (see BRC-129). The frame format and NACK path are
unchanged. Anchors are user-submitted, so under SSM their source set (the
emitting proxies, senderIPv6) is broader than the miner-only block and
coinbase sources; receivers (S,G)-join 0xFFFE per the source set distributed
per BRC-129.
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)andSeqNum(monotonic per sender) in-place before forwarding. The virtual index0xFFF9gives anchor frames an independent flow identity from BRC-131 block frames, which both travel on the sameGroupBlockBroadcastmulticast 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:FFFEand cache BRC-134 frames byHashKey ∥ SeqNum. On NACK, the frame is retransmitted toFF0E::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 — base header layout reused by BRC-134
- BRC-129: Multicast Group Address Assignments — SSM/ASM addressing, scopes, and
(S,G)source discovery - BRC-133: Coinbase Transaction Delivery — another control-group transaction type using BRC-131