In this track: From send to settlement
Who includes a transaction?
A block proposal chooses candidate transactions, while nodes verify the result.
A person assembling a shared notebook page chooses entries, but other readers still check whether the page follows the rules.
Maya prepares an instruction: send 0.01 pretend ETH to Leo.
A local simulation. Nothing is signed or sent to a network.
A proposer is selected by the protocol
Ethereum’s proof-of-stake system selects validators for block proposal duties. The execution payload contains the proposed transaction sequence. The surrounding system can involve builders and other participants in assembling that payload.
Selection is not arbitrary permission to break rules
The proposer cannot make an invalid balance change valid merely by including it. Nodes execute and verify the state transition. A block that violates protocol validity rules is not accepted simply because it came from a selected proposer.
Not every pending request fits
Transactions compete for finite block resources and must satisfy relevant conditions. Fee incentives, ordering, nonce dependencies and submission paths can affect selection. A public pending arrival time alone does not guarantee an inclusion position.
Separate proposer choice from finality
A proposal containing the transaction is one step. Network verification and consensus determine the accepted chain and eventual finality. A wallet should not label a merely broadcast instruction as settled.
Can a selected proposer authorize spending someone else’s funds without valid authorization?
Nodes still enforce authorization and execution validity rules.
Original explanations by EtherTools. Examples are educational and source-linked; this site is independent of the Ethereum Foundation. Our approach.