▪️Block Building
Block building is the process of selecting pending transactions from the mempool, ordering them according to network rules, executing them, and producing a candidate block to be finalized by Proof-of-Stake consensus. On SATUCHAIN, block building is designed to be predictable and observable so applications, operators, and indexers can rely on consistent execution outcomes.
Overview
A block is produced through three stages:
Transaction Selection The proposer selects valid transactions from the mempool based on network rules and priority.
Execution and State Transition Transactions are executed in order, producing state changes, logs, and receipts.
Block Proposal and Finality The proposer broadcasts the block to validators, which verify it under PoS consensus until finality is reached.
Mempool Intake and Validation
Before a transaction can be considered for inclusion, nodes perform basic validation:
correct transaction format and signature
valid nonce for the sender account
sufficient balance to cover value transfer and fees
gas limit and fee fields within protocol constraints
Invalid transactions are rejected and are not propagated.
Transaction Ordering
The proposer orders transactions in a block according to network rules. In general:
transactions must respect account nonces (sender order is enforced)
higher-fee transactions may be prioritized to improve inclusion speed
transactions that fail pre-execution checks are excluded
Ordering impacts execution results, especially for DEX trades, liquidations, and state-dependent calls.
Execution Outputs
Each included transaction produces:
Receipt Status, gas used, logs, and other execution fields.
Event Logs Indexed topics and data emitted by contracts during execution.
State Updates Account balances, storage changes, and contract state transitions.
These outputs are used by explorers, indexers, analytics, and application backends.
Block Contents
A SATUCHAIN block contains:
header metadata (block number, timestamp, parent hash)
list of transactions
receipts and execution-related references
hashes required for chain integrity and verification
The explorer and JSON-RPC expose these fields for verification and debugging.
Finality and Reorg Expectations
After a block is proposed:
validators verify execution and block validity
PoS consensus finalizes the block
once finalized, the block becomes canonical
Applications should treat finalized blocks as stable. Pending or non-final blocks may be subject to short reorgs depending on network conditions.
Operational Notes
High-volume periods increase mempool size and inclusion competition.
RPC nodes should be configured and monitored to ensure stable mempool propagation and block tracking.
Indexers should consume blocks, receipts, and logs in order and handle potential short reorgs safely.
Developer Notes
Do not rely on transaction ordering beyond protocol guarantees.
Use receipts and confirmed block numbers for state transitions in application backends.
For time-sensitive flows, track confirmations until the required finality threshold is reached.
Last updated