Jeff Harris (jeff@lightweb.net)
This BRC specifies a payload variant for the BRC-124 multicast frame format in which the transaction payload uses the BRC-30 Extended Format (EF) instead of the BRC-12 raw transaction format. The 92-byte BRC-124 header is unchanged; the payload is self-identifying via the BRC-30 EF marker. This enables multicast receivers and broadcast services to fully validate transaction signatures and fee amounts without external UTXO lookups.
This BRC is licensed under the Open BSV License.
BRC-124 frames carry BSV transactions in BRC-12 raw format, which omits the locking scripts and satoshi amounts of spent inputs. Validating signatures or computing fees from a BRC-12 payload requires an external UTXO lookup — a bottleneck that BRC-30 was specifically designed to eliminate.
By defining BRC-124 frames with BRC-30 Extended Format payloads, multicast infrastructure gains:
- Self-contained validation — receivers can verify all input signatures and compute exact fee amounts from the frame payload alone, with no UTXO index dependency.
- Zero header changes — the BRC-124 header (Frame Version
0x02, 92 bytes) is reused as-is. The EF marker embedded in the payload provides unambiguous format detection. No frame version bump is required. - Transparent infrastructure — proxies, retry endpoints, and listeners treat the payload as opaque bytes. Existing multicast infrastructure forwards BRC-128 frames without modification.
- Coexistence — BRC-124 frames with BRC-12 payloads and BRC-128 frames with BRC-30 EF payloads share the same multicast groups, frame version, and processing pipeline.
A BRC-128 frame consists of a standard 92-byte BRC-124 header followed by a
variable-length payload containing a BRC-30 Extended Format transaction. The
header is identical to BRC-124 in every respect — same field layout, same Frame
Version byte (0x02), same alignment.
The header is defined by BRC-124 and reproduced here for reference:
| Offset | Size | Alignment | Field | Description |
|---|---|---|---|---|
| 0 | 4 | — | Network Magic | 0xE3E1F3E8 (BSV mainnet P2P magic) |
| 4 | 2 | — | Protocol Version | 0x02BF (703, BSV large-block baseline) |
| 6 | 1 | — | Frame Version | 0x02 |
| 7 | 1 | — | Reserved | Must be 0x00 |
| 8 | 32 | 8-byte | Transaction ID | Raw 256-bit TXID (internal byte order) |
| 40 | 8 | 8-byte | HashKey | Stable per-flow XXH64 identifier; 0 = unstamped |
| 48 | 8 | 8-byte | SeqNum | Monotonic per-flow counter (starts at 1); 0 = unstamped |
| 56 | 32 | 8-byte | Subtree ID | 32-byte batch identifier; zeros = unset |
| 88 | 4 | 8-byte | Payload Length | uint32 BE |
| 92 | * | — | Payload | BRC-30 Extended Format transaction bytes |
All header fields retain the semantics defined in BRC-124. The only difference from a BRC-124 frame is the payload format.
The payload is a BSV transaction serialized in the BRC-30 Extended Format. The format is summarized here; see BRC-30 for the full specification.
| Field | Description | Size |
|---|---|---|
| Version no | Transaction version, currently 2 | 4 bytes (LE) |
| EF marker | Extended Format marker | 6 bytes: 0x00 0x00 0x00 0x00 0x00 0xEF |
| In-counter | Number of inputs (VarInt) | 1–9 bytes |
| list of inputs | Extended Format input structures | variable |
| Out-counter | Number of outputs (VarInt) | 1–9 bytes |
| list of outputs | Standard output structures | variable |
| nLocktime | Lock time | 4 bytes (LE) |
Each input in an EF transaction appends the spent output's satoshi value and locking script after the standard input fields:
| Field | Description | Size |
|---|---|---|
| Previous Transaction hash | TXID of the transaction the output was created in | 32 bytes |
| Previous Txout-index | Index of the output (non-negative integer) | 4 bytes |
| Txin-script length | VarInt | 1–9 bytes |
| Txin-script / scriptSig | Unlocking script | <script length> bytes |
| Sequence_no | Sequence number | 4 bytes |
| Previous TX satoshi output | Satoshi value of the spent output | 8 bytes (LE) |
| Previous TX script length | VarInt | 1–9 bytes |
| Previous TX locking script | Locking script of the spent output | <script length> bytes |
Receivers distinguish BRC-128 (EF) payloads from BRC-124 (BRC-12 raw) payloads by inspecting the first 10 bytes of the payload:
Payload bytes 0–3: Transaction version (4 bytes LE) — typically 0x02000000
Payload bytes 4–9: EF marker check
- BRC-30 EF: 0x00 0x00 0x00 0x00 0x00 0xEF
- BRC-12 raw: VarInt input count (never matches the EF marker)
The 6-byte EF marker 0x000000000000EF is placed immediately after the 4-byte
version number. In a BRC-12 raw transaction, bytes 4–9 contain the input count
VarInt followed by the first bytes of the first input — a sequence that cannot
produce the EF marker pattern. This makes detection unambiguous without any
header-level signaling.
The Frame Version byte remains 0x02 for the following reasons:
- Self-identifying payload — BRC-30 was explicitly designed with the EF marker for format detection. A header-level signal is redundant.
- Consistent BSV precedent — BRC-62 (BEEF), BRC-95 (Atomic BEEF), and BRC-96 (BEEF V2) all use payload-level markers for format discrimination rather than outer envelope version numbers.
- Non-breaking — existing infrastructure (
frame.Decode, TCP reader, proxy forwarder, retry endpoint cache) treats the payload as opaque bytes. A new frame version would cause all deployed components to reject frames (ErrBadVer) until updated, with no structural benefit. - Version semantics — Frame Version
0x01→0x02changed the header from 44 to 92 bytes. A version bump should signal a header structure change, not a payload format change.
BRC-128 frames are fully compatible with the existing multicast infrastructure:
- Proxy — forwards BRC-128 frames verbatim, stamps HashKey and SeqNum as usual. The proxy does not inspect the payload.
- Listener — decodes the BRC-124 header, applies shard and subtree filters, tracks gaps via SeqNum per flow. Payload format is irrelevant to these operations.
- Retry endpoint — caches and retransmits BRC-128 frames identically to
BRC-124 frames. The cache indexes by
(HashKey, SeqNum), not payload content. - Downstream consumers — applications that receive forwarded frames inspect payload bytes 4–9 to determine whether to parse as BRC-12 raw or BRC-30 EF.
- Transport — BRC-128 frames are byte-identical on the wire under ASM and
SSM. Multicast addressing, scopes, and the SSM
(S,G)join and source-discovery model are inherited from BRC-124 and specified in BRC-129; the source is the emitting proxy (senderIPv6).
BRC-124 (BRC-12 payload) and BRC-128 (BRC-30 EF payload) frames can be intermixed on the same multicast group without conflict.
TCP transport is unchanged from BRC-124. The reader:
- Reads 44 bytes (sufficient for legacy header or BRC-124 header start)
- Inspects byte 6 (Frame Version)
- Version 0x01 (legacy): header complete; read
PayLenat bytes 40–43 - Version 0x02 (BRC-124/BRC-128): read 48 more bytes; read
PayLenat bytes 88–91
- Version 0x01 (legacy): header complete; read
- Reads exactly
PayLenbytes - Processes the complete frame
The receiver determines the payload format (BRC-12 vs BRC-30 EF) after reading the payload, not from the header.
A frame carrying a BRC-30 EF transaction. The payload begins with the 4-byte version and 6-byte EF marker:
// Header (92 bytes) — identical to BRC-124
E3E1F3E8 // Network Magic
02BF // Protocol Version
02 // Frame Version (0x02 — same as BRC-124)
00 // Reserved
11c6900eee6e68d191cd25034a5f872ed29e3b69273906a10e021f39ed866471 // TXID
A1B2C3D4E5F6A7B8 // HashKey (XXH64 of flow)
0000000000000001 // SeqNum (1)
baadf498a00ca5a44d1c4d9d103b49017f53cd8cb2a70a9c67fc884ecdd622b5 // Subtree ID
00000130 // Payload Length (304)
// Payload (304 bytes of BRC-30 Extended Format transaction)
02000000 // TX version (2, LE)
0000000000EF // EF marker
01 // Input count (1)
// Extended Format input:
aabb...0000 // Previous TX hash (32 bytes)
00000000 // Previous Txout-index
6a47...3e76 // scriptSig (VarInt length + script)
FFFFFFFF // Sequence number
3E66000000000000 // Previous TX satoshi output (LE, 26174 sats)
1976...c288 // Previous TX locking script (VarInt + script)
// Outputs:
01 // Output count (1)
3C66000000000000 // Output value (LE, 26172 sats)
1976...c288 // Locking script (VarInt + script)
00000000 // nLocktime
The same transaction in BRC-12 raw format (without extended input data):
// Header (92 bytes)
E3E1F3E8 // Network Magic
02BF // Protocol Version
02 // Frame Version
00 // Reserved
11c6900eee6e68d191cd25034a5f872ed29e3b69273906a10e021f39ed866471 // TXID
A1B2C3D4E5F6A7B8 // HashKey (XXH64 of flow)
0000000000000001 // SeqNum (1)
baadf498a00ca5a44d1c4d9d103b49017f53cd8cb2a70a9c67fc884ecdd622b5 // Subtree ID
000000C8 // Payload Length (200)
// Payload (200 bytes of BRC-12 raw transaction)
0200000001...00000000
Note that the headers are byte-identical; only the payload differs.
- BRC-12: Raw Transaction Format — Standard transaction payload format
- BRC-30: Transaction Extended Format (EF) — Extended Format payload used by this specification
- BRC-74: BSV Unified Merkle Path (BUMP) Format — Merkle proof format for transaction verification
- BRC-119: SubTree Unified Merkle Path (STUMP) Format — Defines the Subtree ID concept referenced in the frame header
- BRC-124: Multicast Transaction Frame Format — Header format reused by this specification
- BRC-129: Multicast Group Address Assignments — SSM/ASM addressing, scopes, and
(S,G)source discovery