Consensus Payload

Overview

A consensus payload carries the information participants evaluate during an agreement instance. It may contain transactions, an execution payload, state roots, data commitments, validator changes, timestamps, or references to content stored elsewhere.

Consensus approval authenticates the payload under protocol rules, but components can validate different portions. In layered systems, the consensus engine may commit to an execution result supplied by another component after checking its validity through a defined interface. Implementers must verify encoding, size limits, parent references, state commitments, version, and network domain before voting. Payment systems should decode the canonical executed payload and receipt, since a proposal or commitment alone may not prove that a transfer succeeded.

Parsing should be version-aware and fail closed when an unknown format affects validation, accounting, or settlement decisions. Test fixtures for Consensus Payload should cover normal blocks, boundary sizes, protocol upgrades, and invalid encodings. Consensus Payload must be interpreted under the exact chain rules and software version that define its encoding and validation. Field names can appear similar across networks while using different byte order, commitment schemes, size limits, activation heights, or relationships to the block header and body.

Competing blocks can temporarily occupy the same height, and a reorganization can replace data that was previously observed, so applications should retain hashes and update dependent records when canonicality changes. Verification of Consensus Payload should begin with a canonical block identifier rather than a height alone. Operational use of Consensus Payload depends on node mode and data retention. Pruned, archive, light, and indexing services may expose different historical fields or proofs. Teams should document which component supplies the data and how missing, malformed, or version-unknown records are handled.