Blocks

Blocks include a header containing metadata required for validation and chaining. A block header includes, at minimum:

• Block height (or block identifier)

• Previous block hash

• Timestamp (protocol-defined time field)

• Nonce or equivalent consensus field (if applicable)

• Proposer or minting node identifier

• Proposer signature (authorizing the block proposal)

• Transaction commitment (a digest committing to the included transactions)

• Block hash (a digest of the block header)

Note: the transaction commitment and the block hash are distinct fields. The transaction commitment commits to the block contents, while the block hash commits to the header.

Single Hash Transactions

Rather than using a single Merkle tree over all transactions, the system can commit to block contents using a transaction hashing scheme that binds each transaction to the block header. For each transaction, a digest is computed over the transaction payload together with selected header fields, and the block’s transaction commitment is derived from the set of resulting digests according to the client’s commitment rules.

This approach is intended to reduce overhead and support faster execution for full nodes. Proof and light-client properties depend on the exact commitment construction and may differ from Merkle-based designs.

Fees and Proposer Rewards

The block proposer may receive protocol-defined rewards, which can include a minting reward (if applicable) and the collection of eligible transaction fees such as priority fees.

A priority fee is an optional fee parameter that is intended to increase a transaction’s priority under network policy. Actual confirmation time remains dependent on network conditions and validator policy.

Block size and throughput policy

Blocks do not have a single fixed size. The maximum number of transactions per block and related throughput parameters are configurable protocol limits and may be adjusted under defined rules based on network conditions and performance targets. Consecutive blocks may therefore vary in size.

Storage formats and auxiliary indexing

Nodes may store blocks using different storage formats depending on the client implementation and device constraints, such as:

• Structured files per block (for example JSON-like representations)

• Binary block files

• Local databases

In addition, optional auxiliary indexing services may be deployed to accelerate search and query workloads. These services are not required for consensus and do not determine transaction validity.