> For the complete documentation index, see [llms.txt](https://docs.xyo.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.xyo.network/xyo-layer-one/architecture/block-structure.md). # Block Structure In XYO Layer One, blocks are a specific type of [Bound Witness](/xyo-layer-one/xyo-layer-one-features/bound-witness.md). Some of the defining features of a Block Bound Witness are the additions of several unique fields, such as the number of the block itself and the hash of the chain it exists on. As a Bound Witness, an XYO Layer One Block also contains a list of each of the following: Payloads, Transactions, and Signatures. ### Payloads **Payloads** are data hashes selected for permanent inclusion, or "Elevation", in the XYO Layer One Blockchain. Each hash must be validated prior to being elevated, and once elevated, it is stored immutably on-chain. These payloads typically represent one of the following: a full Transaction, a specific hash elevated from within a Transaction, or a schema-compliant payload added directly by the block producer, known as a Producer Payload. All payloads must conform to an approved schema—such as the Transaction or Transfer schema—to be included. For example, a block producer might include a Transfer payload to designate the recipient of the block reward once the block is successfully built and validated. #### Producer Payloads Producer payloads represent essential protocol-level operations and must be formatted under standardized schemas, such as `network.xyo.boundwitness`. These payloads are always generated by the block producer and will be fully validated when determining chain state. Examples include transfers, claims, protocol votes, and staking intents. * **Inclusion Criteria**: For a transaction to be included in a block by a block builder, it needs to be first-order validated. This means that all payloads in the transaction Bound Witness must be available (hash matches provided payload) and pass full validation. * **Voting**: Block Producers can participate in **Producer Voting** to vote on adopting a protocol update. This is done via the `network.xyo.chain.vote` payload. **Producer Payload Schemas** * `network.xyo.transfer` * `network.xyo.chain.stake.intent` * `network.xyo.chain.claim` * `network.xyo.chain.vote` ### Transactions **Transactions** are an additional type of Bound Witness, containing fields such as `chain`, `fees`, `exp` (or "Expiration"), and `nbf` (or "Not Before"). These transactions contain information about the transaction and also have a specific script field that designates smart contract-like scripts to be executed. Any script in this field must be a standardized script for the XYO Layer One Blockchain, such as the `elevate` script that designates a hash to be elevated to the next level. ### Signatures **Signatures** are addresses that cryptographically sign the block, representing addresses confirming block existence. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.xyo.network/xyo-layer-one/architecture/block-structure.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.