Block Proposal

Overview

A block proposal contains the transactions, state commitments, consensus fields, and signature or proof required for peers to evaluate a candidate block. The authorized proposer broadcasts it during an assigned slot, round, or mining event according to the network’s rules.

Receiving nodes verify the proposal independently. They may reject it for invalid transactions, incorrect state roots, timing violations, excessive size, unauthorized authorship, or conflicts with a preferred chain. Several valid proposals can temporarily compete before consensus chooses one. Payment systems should distinguish proposal, acceptance, confirmation, and finality. A transaction shown inside a proposal may disappear if that block is rejected or loses a fork. Monitoring should bind events to the proposal’s block hash and update status only when canonical consensus advances.

The incentives around Block Proposal can include fees, priority payments, MEV, builder or proposer payments, and missed-opportunity costs. Ordering policy, private transaction flow, censorship, and concentration should be evaluated alongside nominal block-production performance. A locally built or accepted candidate is not proof of final inclusion. Implementations of Block Proposal need deterministic validity checks, current protocol rules, capacity limits, and a defined response when a candidate becomes stale or conflicts with the canonical head.

Operational monitoring should track construction time, failed candidates, propagation, inclusion, reorganization, and dependencies on relays or external builders. Payment systems should rely on canonical block evidence rather than internal production or auction events. Control of one stage does not necessarily imply control of every stage. Block Proposal should be described within the complete block-production pipeline: transaction intake, candidate construction, ordering, execution or validation, proposal, propagation, and canonical acceptance.