The selected proposer offers a candidate block; the network checks it.
LET’S PICTURE IT
An editor can assemble a page, while readers enforce the publication’s rules before accepting it.
SEE IT FOR YOURSELF
Receive, check and share across independent nodesStep 1 / 4
A node receives a proposed transaction or block-related message. Receipt is not the same as accepting its claims.
A node receives a proposed transaction or block-related message. Receipt is not the same as accepting its claims.The node checks the relevant authorization and protocol rules. Popularity does not make an invalid state transition valid.Valid candidate data can propagate to peers. Connections and timing differ, so there is no perfect simultaneous worldwide view.Peers validate under the same protocol rules. This illustration is about verification and propagation, not a complete proof-of-stake consensus algorithm.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
Selection gives a duty
Proof-of-stake rules assign proposal opportunities to validators. A proposer can assemble or obtain a candidate execution payload as part of constructing its block. The wider production flow may involve builders.
Content must remain valid
The selected role does not grant authority to invent balances or ignore invalid authorization. Execution and consensus verification still determine whether the candidate follows the protocol.
Ordering can affect applications
Which valid transactions are selected and how they are ordered can change execution outcomes and economic opportunities. This is one reason pending arrival order is not a universal fairness guarantee.
A proposal is not finality
A candidate’s inclusion in the current head differs from checkpoint finality. Interfaces should represent these stages separately rather than collapse proposal, success and settlement into one label.
QUICK CHECK · NO PRESSURE
Does a proposer duty grant permission to bypass protocol validity checks?