Ethereum Proof of Stake: Validators, Block Building, MEV and Consensus

Disclaimer: This article is for informational and educational purposes only and simplifies underlying technical concepts for clarity. It is not financial, investment, tax or legal advice.

Ethereum Proof of Stake (PoS) is how Ethereum secures its blockchain and coordinates agreement on the order of transactions. Instead of miners competing to solve computational puzzles by burning electricity, Ethereum relies on validators that commit ETH and perform specific duties under the network's consensus rules.

Several different activities take place when Ethereum creates a block. Users submit transactions, searchers identify trading opportunities, block builders assemble transactions, validators propose blocks, and other validators attest to the chain they consider valid.

Understanding how these roles interact explains how Ethereum creates blocks, distributes rewards, handles invalid transactions, and resolves temporary disagreements between different versions of the blockchain.

1. From Mining to Staking

Bitcoin and Ethereum both need a mechanism that allows thousands of independent participants to agree on one version of a blockchain without relying on a central authority. Proof of Work and Proof of Stake solve this problem through different economic incentives.

In Proof of Work, miners spend electricity competing for the opportunity to produce a block. Their expenditure makes attacks costly, even though the electricity is consumed regardless of whether they win.

In Proof of Stake, validators commit ETH instead. The stake is not automatically spent; it remains subject to the protocol's rules and withdrawal conditions. Validators earn rewards for performing their duties and can lose rewards or face penalties for failing to do so.

2. The Merge: How Ethereum Changed Its Security Model

Ethereum did not begin with Proof of Stake. It originally used Proof of Work, like Bitcoin. The transition occurred through an upgrade called The Merge, completed on 15 September 2022.

The Beacon Chain, launched in December 2020, introduced Proof of Stake and operated alongside the original Ethereum network. It allowed the staking and consensus system to operate before it took over the security role of the main network.

During The Merge, Ethereum's existing transaction execution environment was joined to the Beacon Chain's Proof of Stake consensus mechanism. The transition occurred without requiring users to move their ETH or change their wallet addresses.

Three important things changed:

• Energy consumption: Ethereum's energy use fell by more than 99% because the network no longer relied on mining.
• ETH issuance: New ETH issuance fell substantially because validators did not need mining rewards to cover large electricity and hardware expenses.
• Block timing: Block production moved to regular 12-second slots rather than the irregular timing of mining.

The Merge did not, by itself, make transactions cheaper or increase the network's execution capacity. Subsequent scaling improvements, such as Layer 2 networks and the Dencun upgrade (March 2024), which made posting data for Layer 2 networks much cheaper, have addressed those concerns.

Withdrawals of staked ETH were also not possible immediately after The Merge. They were enabled later by the Shapella upgrade in April 2023.

3. Who Participates in Creating and Securing a Block?

Several participants perform distinct roles in the block-production process.

These roles are not always performed by separate organisations. A validator can build its own blocks, and a staking provider may operate many validators.

4. How Can Someone Participate in Staking?

There are several ways to participate in Ethereum staking, each offering a different balance of control, convenience and risk.

Solo staking

A participant deposits 32 ETH into Ethereum's staking deposit contract and operates a validator using the required software.

The operator manages the infrastructure, protects validator keys and performs validator duties. It receives applicable protocol rewards and, when selected as proposer, can earn transaction-related revenue. This approach provides direct control but requires technical knowledge and reliable uptime.

Staking as a service

A participant provides the ETH while a professional operator manages validator infrastructure. The arrangement reduces operational work, but the participant depends on the operator's reliability and the service's custody and key-management arrangements.

Pooled staking

Multiple participants contribute smaller amounts of ETH to a pool. The pool coordinates the underlying validators and distributes rewards according to its rules and fees. Participants do not ordinarily propose blocks or attest personally through their own validator identities.

Pooled staking can be custodial, where a company holds and controls the deposited ETH, or non-custodial, where smart contracts manage the pooled ETH according to programmed rules, reducing reliance on a central custodian. In both cases, validator operators run the validators, and users remain exposed to risks such as penalties, protocol failures, and delays in withdrawing their ETH.

Liquid staking

A participant deposits ETH into a liquid staking protocol and may receive a transferable token representing the staking position, such as stETH. Liquid staking is a form of pooled staking; what sets it apart is the transferable token.

The protocol coordinates validators, while the token can potentially be traded, lent or used as collateral in DeFi applications. This illustrates composability: an asset representing a staking position can be used in other applications while the underlying ETH participates in staking. However, this introduces smart-contract, liquidity and depegging risks.

Exchange or custodial staking

A centralised exchange or custodian manages the underlying staking activity and distributes returns under its terms. This is convenient, but customers depend on the provider for custody, access and withdrawal arrangements.

Staked ETH investment products

An investor can also obtain exposure through an investment fund or exchange-traded product that holds and stakes ETH. The investor owns an interest in the product rather than holding the underlying ETH directly. Fees, custody arrangements and product terms affect the investor's return.

5. How Does Ethereum Select Validators?

Ethereum divides time into slots and epochs:

• One slot lasts 12 seconds.
• One epoch contains 32 slots and lasts 6.4 minutes.
• One validator is selected as proposer for each slot.
• Committees of validators are assigned attestation duties.

Proposer selection is pseudo-random and governed by Ethereum's protocol. Proposers are known in advance, typically about one epoch ahead, so builders and relays know which validator they are bidding to.

Does the amount staked matter?

Yes. A validator's effective balance influences its consensus weight, including its probability of being selected as proposer and the weight of its attestations.

A standard validator has 32 ETH of effective balance. Since the Pectra upgrade in May 2025, validators using compounding withdrawal credentials can have an effective balance above 32 ETH, up to 2,048 ETH. Older validator configurations remain subject to their 32 ETH effective-balance cap.

An operator can also run multiple validators. For example, suppose two organisations each stake a total of 2,048 ETH on Ethereum:

• Organisation A operates 1 validator with 2,048 ETH of effective balance.
• Organisation B operates 64 validators, each with 32 ETH of effective balance.

Both organisations have the same total effective stake. Therefore, their overall probability of being selected as the block proposer is approximately the same.

More effective stake can increase selection weight, while operating more validators provides additional opportunities to be selected. Neither approach allows an operator to choose which slot it proposes.

6. How a Single Ethereum Block Is Created

Consider a fictional Block N. Alice wants to transfer ETH, Bob wants to swap tokens on a decentralised exchange, and Carol wants to interact with a lending protocol. The simplified journey looks like this:

Step 1: Users Submit Transactions

• The wallet signs the transaction using the user's private key.
• The wallet submits it to an RPC provider, which forwards it to an Ethereum execution node.
• The execution node verifies the transaction's validity, checking things such as the signature, nonce, and whether the sender can cover the transaction's costs.
• The node adds the valid transaction to its local mempool and typically propagates it to its connected peers.
• Other nodes independently validate the transaction and may add it to their own mempools before propagating it further.
• Some transactions bypass the public mempool entirely. Private or MEV-protection RPCs send them directly to block builders, which reduces the risk of front-running and sandwich attacks.
• The block's builder, either an external builder or the proposer itself, selects transactions from those available to it and includes them in a block.

Step 2: Ethereum Selects a Proposer

Suppose Validator V is selected to propose Block N. The validator may be operated by a solo staker, pool, exchange or liquid staking protocol. Regardless of the staking arrangement, the protocol determines the proposer.

Step 3: Searchers Identify Opportunities

1. Searcher identifies an opportunity. The searcher calculates that buying a token on one DEX and selling it on another could generate 0.1 ETH in gross profit, before gas and other costs.

2. Searcher submits a bundle. Through a builder's API or a service connecting searchers to builders, the searcher submits the required transactions, often as a bundle that must execute in a particular order. The submission may include a payment or incentive for the builder.

3. Searcher decides how much to offer. The searcher might offer 0.03 ETH in value to the builder, expecting to retain the remaining profit after gas and other costs. The offer needs to be competitive against other bundles and transactions.

4. Builder evaluates the submission. The builder simulates the bundle, estimates its profitability and checks whether it can execute successfully. The builder compares it with other available transactions and opportunities, then decides how to construct the block.

Step 4: Builders Assemble Candidate Blocks

In a common MEV-Boost workflow, external block builders assemble candidate blocks. They consider transaction validity, execution dependencies, priority fees, possible MEV and the payment they can offer the proposer.

Builders compete by offering bids. A builder aims to capture more value than it spends on searchers, payments to the proposer and operating costs. A validator can also build its own block without an external builder.

Step 5: The Proposer Selects and Publishes a Block

With MEV-Boost, builders send their blocks and bids to one or more relays. A relay checks each block and forwards the bids, but not the block contents, to Validator V. MEV-Boost selects the highest valid bid, and Validator V signs the block header (a “blinded” block) without seeing the transactions. Once the relay receives this signature, it releases the full block, which is then published to the network.

Because the proposer commits before seeing the contents, a builder's strategy cannot be copied by the proposer. In turn, the proposer relies on the relay to have checked the block and to release it on time.

The builder's bid is a payment offered to the proposer under the relevant arrangement. The validator does not ordinarily pay the builder.

Step 6: Nodes Independently Verify the Block

Other nodes receive the block, check its consensus validity and execute the transactions in its execution payload. They verify that the transactions produce the state changes prescribed by Ethereum's rules.

Step 7: Validators Attest to the Chain

Validators assigned attestation duties construct signed attestations reflecting their view of the chain. These votes contribute to Ethereum's fork-choice and finality mechanisms. Validators do not manually approve each transaction; their software checks the block and determines the chain they consider valid.

Step 8: Ethereum Progresses Towards Finality

The network uses attestations to determine the preferred chain. As sufficient stake supports the required checkpoints, Ethereum can justify and finalise them.

A block may be proposed and accepted by nodes before it is finalised. A 12-second slot is an opportunity to propose a block, not a guarantee of finality within 12 seconds. Under normal conditions, a block is finalised after about two epochs, roughly 12.8 minutes.

7. What Is MEV?

Common examples include:

• Arbitrage: Buying an asset where it is cheaper and selling it where it is more expensive.
• Liquidations: Executing eligible liquidations in lending protocols.
• Sandwich strategies: Placing transactions around another user's trade to profit from the resulting price movement.

MEV is not inherently malicious. Arbitrage can help align prices across markets, and liquidations help lending protocols manage risk. However, sandwich attacks can worsen ordinary users' execution prices.

How Does a Builder Earn?

Suppose a builder's illustrative block economics are:

These are illustrative figures, not market averages. The builder earns 0.013 ETH because its revenue exceeds its payment to the proposer and its operating costs. Actual accounting depends on the treatment of priority fees, searcher payments, trading proceeds and the block's fee-recipient configuration.

Can Anyone Become a Builder?

In principle, anyone capable of operating the necessary infrastructure can compete to build blocks. A builder does not need to stake 32 ETH merely to perform this role.

However, building a candidate block does not guarantee its selection. Builders compete for opportunities, and a builder may lose many bids before winning one. Only the validator selected by Ethereum for the slot can propose the block for that slot.

8. How Are Validator Rewards Calculated?

Validators can earn rewards from several sources.

New ETH issuance

Ethereum issues new ETH through its consensus reward mechanism. Validators receive protocol rewards for performing their assigned duties correctly. The amount depends on protocol parameters, effective balance, network conditions and validator performance. It is not a fixed payment for every block.

Priority fees

Users pay transaction fees that can include a priority fee, or tip, to incentivise inclusion. Ethereum burns the base fee.

Priority fees are credited to the execution-layer fee recipient specified for the block. In a block built through MEV-Boost, the builder usually sets itself as the fee recipient and collects the tips, then pays the proposer in a final transaction in the block. The builder's bid already reflects that payment, so the proposer should not count the tips separately on top of the bid.

Builder payments

An external builder may offer a payment to the validator in exchange for proposing its block. The amount depends on competition, block economics and the payment arrangement.

Worked example

Suppose the selected validator receives a 0.075 ETH builder payment and 0.0002 ETH in applicable consensus rewards attributable to the example. Its illustrative total is:

The builder's profit is calculated separately. A validator operating its own builder has a different revenue calculation because it can capture value directly rather than receiving an external builder's bid.

9. What Happens When a Transaction Fails?

A transaction that reverts during execution is not necessarily an invalid transaction or an invalid block.

Suppose Bob submits a swap with a maximum slippage of 1%. The market price changes before execution, and the DEX contract determines that the swap exceeds Bob's limit. The transaction reverts. Its intended state changes are rolled back, but Bob still pays gas for the execution that took place.

The block can remain valid because Ethereum correctly executed the transaction according to the contract's rules.

Missing duties normally results in lost rewards or applicable penalties rather than automatic slashing. Slashing is reserved for specific provable consensus violations.

Slashing punishes one specific thing: a validator signing two messages that contradict each other. There are three ways this happens:

• Double proposal: signing two different blocks for the same slot.
• Double vote: signing two different attestations for the same target checkpoint.
• Surround vote: signing one attestation whose source-to-target link wraps around the link in an earlier attestation. That's like voting for one version of history and then for a conflicting one.

10. How Do Validators Vote?

Validators vote through attestations, digitally signed messages generated by their validator software. Every active validator normally has an attestation duty during each epoch, but not every validator attests in every slot.

An attestation includes information about the validator's view of the chain and the checkpoints it supports. Three important components are:

• Head vote: The block the validator currently considers the head of the chain. LMD-GHOST uses these votes to pick the chain head.
• Source vote: The most recent checkpoint the validator sees as justified, the point the network has already agreed on.
• Target vote: The checkpoint at the start of the current epoch, the next point the validator wants the network to agree on.

A checkpoint is a block: specifically, the block in the first slot of an epoch. Since an epoch has 32 slots, roughly one block in every 32 is a checkpoint. If the first slot of an epoch is empty because the proposer missed it, the checkpoint is the most recent block before that slot. Every checkpoint is a block, but not every block is a checkpoint.

Every attestation effectively says: “I accept checkpoint S as already agreed (source), and I vote to move on to checkpoint T (target).”

When validators holding at least two-thirds of the stake vote for the same source-to-target link, the target becomes justified. When the checkpoint that follows a justified checkpoint is also justified, the earlier one becomes finalised.

Casper FFG votes only on checkpoints, so when a checkpoint is finalised, every block before it is finalised too. This is why finality advances roughly one epoch at a time rather than block by block. The ordinary blocks between checkpoints are covered by the head vote, which LMD-GHOST uses to decide the current tip of the chain.

A Simple Worked Example

Imagine three consecutive epochs, 10, 11 and 12. Their checkpoints are C10, C11 and C12, the blocks in the first slot of each epoch. The other blocks are ordinary blocks. Real epochs have 32 slots; only three per epoch are shown here.

A validator attesting during epoch 12 submits three votes in one signed message:

Notice the distinction: the head vote is about the latest block, while the source and target votes are about checkpoints and finality.

Now suppose, for simplicity, there are 100 validators with equal stake, and 70 of them vote for the same link, C11 → C12. Seventy per cent is more than two-thirds, so C12 becomes justified. Because C11 was already justified and C12 is the very next checkpoint, C11 becomes finalised.

In epoch 13, validators vote for C12 → C13. Once two-thirds of the stake supports that link, C13 is justified and C12 is finalised, together with every block before it.

When C12 is finalised, everything up to and including C12 (C11, B12, B13 and earlier blocks) is final. Blocks after it, such as B14 and B15, are not final yet; they become final once C13 is finalised.

The validator signs the attestation using its validator signing key and broadcasts it to the network. Other nodes verify the signature and process the attestation under Ethereum's rules.

Validators do not vote on whether a transaction is economically sensible. They attest to the chain according to the protocol.

Example: Temporary Disagreement

Suppose Validator A proposes Block 105. Some validators receive it quickly, while others receive it later. Their local views may temporarily differ, so they may initially attest to different chain heads. As information spreads, Ethereum's fork-choice mechanism uses the latest attestations and their effective-balance-weighted support to determine the preferred chain.

11. Can Ethereum Have a Fork?

Yes. One proposer is selected per slot, but temporary forks can still occur, most often when a block arrives late and the next proposer builds on an earlier block instead. Consider this simplified example:

Validators that received Block 105 in time may attest to it, while the proposer of slot 106, not having seen it, builds Block 106 on Block 104. For a short period, nodes can consider different branches as the head of the chain until fork choice settles on one.

LMD-GHOST: Fork Choice

Ethereum uses LMD-GHOST to determine the preferred chain head. It considers the latest attestations and the effective-balance-weighted support behind competing branches. The branch with the greatest accumulated support under the fork-choice rules is preferred.

This is not simply a one-validator-one-vote system. Voting weight depends on effective balance.

Casper FFG: Finality

Ethereum also uses Casper FFG to justify and finalise checkpoints. Finality normally requires a supermajority representing at least two-thirds of the relevant active stake to support the required checkpoint links.

Finality is stronger than merely being the currently preferred chain. Reverting finalised history would require a serious consensus failure or a substantial economic cost.

A validator may temporarily attest to a branch that does not ultimately become canonical because it received information late. That does not automatically mean it acted maliciously or will be slashed. However, signing two conflicting blocks for the same slot is a slashable offence.

What If the Proposer Misses Its Slot?

If the selected validator fails to publish a block, the slot can remain empty. The next slot proceeds according to the normal schedule with its own proposer.

A missed proposal generally means the validator misses the opportunity to earn applicable proposal rewards. It is not, by itself, a slashable offence.

12. Economic Security: Why Attacks Are Expensive

Proof of Stake makes attacks costly by placing the attacker's financial stake at risk.

To rewrite finalised history on Ethereum, an attacker would need to get conflicting checkpoints finalised. Ethereum requires at least two-thirds of the total active stake to support a checkpoint for it to become finalised.

If two conflicting checkpoints were both finalised, at least one-third of the stake would have to participate in conflicting votes, which is slashable behaviour. This exposes the attacker to potentially substantial losses of staked ETH, alongside the risk of damaging confidence in Ethereum and reducing the value of their remaining holdings.

Penalties also distinguish between different kinds of failure:

• Going offline: The validator misses duties and may lose rewards or incur small penalties.
• Large-scale inactivity: If enough validators go offline that the network cannot finalise, inactivity penalties can grow over time.
• Provable cheating: Specific conflicting proposals or attestations can trigger slashing and forced exit from the validator set.

Slashing penalties can be larger when many validators are slashed around the same time. This discourages coordinated attacks more strongly than isolated mistakes.

13. Staking Yield and Its Risks

Staking can turn an ETH holding into an asset that earns a return, but it does not remove the risks of holding ETH.

Staking returns vary with the amount of ETH staked, protocol rewards, validator performance, service fees and market conditions. The yield is paid in ETH, not in a guaranteed amount of dollars or dirhams.

For example, if ETH falls 30% in price over a year, a 3% staking return in ETH would not compensate for that price decline in fiat terms.

Staking may partly offset dilution from new ETH issuance, but it does not guarantee a positive investment return.

Principal Risks

14. Energy, ESG and Institutional Adoption

The Merge reduced Ethereum's energy consumption by more than 99%, addressing one of the major environmental objections to using the network.

Before the Merge, Ethereum mining consumed substantial electricity and relied on specialised hardware. Under Proof of Stake, validators can operate using conventional computers or cloud infrastructure, and adding more stake does not create a mining race.

For businesses, this has several implications:

• Environmental reporting can be easier because Ethereum's consensus mechanism has a much smaller energy footprint than Proof of Work.
• The reputational concerns associated with energy-intensive mining are reduced.
• The network's energy profile can be a consideration for institutions evaluating tokenisation and blockchain infrastructure.

However, energy is only one part of ESG. Governance and social questions remain, including the concentration of staking providers, the influence of large stakeholders and how network decisions are made. Data centres, RPC providers and Layer 2 infrastructure also have their own environmental footprints.

Businesses should evaluate the environmental impact of the entire technology stack rather than assume every component has zero cost.

15. Concentration and Software Diversity

Proof of Stake introduces governance and operational concerns that differ from Proof of Work.

Staking Concentration

A large share of staked ETH can flow through a relatively small number of staking providers.

Concentration matters because a provider controlling more than one-third of the relevant stake could, in theory, prevent the network from finalising blocks if that stake were coordinated or unavailable. A provider controlling more than half of the stake could dominate fork choice and censor or reorder transactions, and control exceeding two-thirds would allow it to finalise blocks on its own.

This does not mean that a provider automatically controls every validator it services. Large providers may distribute operations across many independent operators. Nevertheless, concentration is a significant factor in assessing Ethereum's resilience.

Software Diversity

Ethereum validators rely on independently developed software clients. If a very large share of validators uses the same client and that client has a serious bug, many validators could make the same mistake, potentially disrupting consensus or causing substantial penalties.

Software diversity reduces the risk that one implementation failure affects the entire network.

These considerations show that Proof of Stake security depends not only on the quantity of ETH committed, but also on the distribution of stake and the reliability of the software and operators maintaining the network.

16. Bringing It All Together

The lifecycle of an Ethereum block can be summarised as follows:

Each mechanism solves a different problem:

17. Conclusion

The central idea is that Ethereum separates the economic incentives to construct valuable blocks from the consensus process that determines which blocks and state transitions the network accepts.

A builder may create a profitable block, but it cannot force the network to accept an invalid one. A proposer can publish a block, but other nodes independently verify it. Validators attest to the chain they consider valid, and Ethereum's fork-choice and finality mechanisms coordinate agreement across the network.

This combination of economic incentives, independent execution, signed attestations and finality allows Ethereum to maintain a shared blockchain without relying on a central authority.

Key Takeaways