PAYLOAD-FORMATTING

Field	Value
Name	Payload Formatting
Slug	97
Status	raw
Category	Standards Track
Editor	Marcin Pawlowski [email protected]
Contributors	Youngjoon Lee [email protected], Alexander Mozeika [email protected], Álvaro Castro-Castilla [email protected], Filip Dimitrijevic [email protected]

Timeline

2026-09-11 — b7301a6 — [RFC] Mantle: Enable basic EmPoWering machinery (#400)
2026-08-31 — 5fa8ee4 — docs(blockchain): compress the block proposal with 16-byte transaction reference prefixes (#389)
2026-08-19 — a2a85cb — RFC Bedrock: Cryptarchia with uncle references (#385)
2026-07-03 — 709cf7f — Bedrock-RFC: Remove Concept of a Session (#365)
2026-05-28 — d45eed2 — Chore: mirror blochain specs into github/mdbook (#347)

Revision History

Version	Changes	Date
1.0.0	Initial revision.	2026-04-09
1.1.0	Updated `Max_Body_Length` to 34574 bytes, the maximum block proposal size once a proposal carries the signed headers of the uncles it references (see Block Construction, Validation and Execution).	2026-08-06
1.1.1	Updated `Max_Body_Length` to 18192 bytes, following the compression of transaction references to 16-byte prefixes and their encoding as a variable-length list (see Block Construction, Validation and Execution).	2026-08-18
1.2.0	Add the transaction `body_type`, bound a carried transaction to `Max_Body_Length`, and state the fixed-length padding cost it inherits	2026-09-08

Introduction

This document defines an implementation-friendly specification of the Payload Formatting, which is introduced in the Formatting section.

Overview

The payload contains a header and a body. The header informs the protocol about the way the body must be handled. The body contains a raw message (data/proposal or cover message). The payload must be of a fixed length to prevent adversaries from distinguishing types of messages based on their length. Therefore, shorter messages must be padded with random data.

Construction

Payload

The Payload is a structure that contains a header and a body.

class Payload:
    header: Header,
    body: bytes

The header is a structure that contains a body_type and a body_length.

class Header:
    body_type: byte,
    body_length: uint16

Type

We define the following values of the body_type:

body_type=0x00, informs that the body contains a cover message.
body_type=0x01, informs that the body contains a data message carrying a block proposal.
body_type=0x02, informs that the body contains a data message carrying a Mantle transaction.

Any other value of type means that the message was not decapsulated correctly and must be discarded.

Length

We define the body_length as uint16 (encoded as little-endian). Therefore, the theoretical limit of the length of the body is 65535 bytes. The body_length must be set to the length of the body of the payload message (body_length=len(raw_message)).

Body

The Max_Body_Length parameter defines the maximum length of the body. The maximal length of a raw data message is the maximum size of a Block Proposal — 18192 bytes, reached when the proposal carries MAX_UNCLES signed uncle headers and references MAX_BLOCK_TXS transactions — so the Max_Body_Length=18192. Because the padding below fixes every body to this length, the variable size of a proposal (which depends on the number of referenced uncles and transactions) is not observable on the wire, which is what preserves the indistinguishability of proposals required by the Blend Protocol.

A transaction carried over the Blend network must fit into Max_Body_Length once encoded.

The body length is fixed to Max_Body_Length bytes. Therefore, if the length of the raw message is shorter than the Max_Body_Length, then it must be padded with random data.

If the body length is less than the Max_Body_Length, then the last Max_Body_Length - len(Raw_Message) bytes must be filled with random data.

Logos LIP