Skip to main content


What is a Block Proposer?

A block proposer is a validator that is pseudorandomly selected to build a block and is assigned a slot within an epoch, which consists of 32 slots. Selection is done from the set of validators using the standard RANDAO method.

Validators are tasked to attest, or cast votes on, proposed blocks. These assignments are determined two epochs ahead of time for attesters and one epoch ahead of time for proposers. Within each slot, a single validator acts as the proposer, while multiple validators serve as attesters to all information in that block. Attesters are rewarded for correctly voting on the current values of three key aspects of the beacon chain: the LMD Ghost head of the chain, the justified checkpoint, and the Casper FFD finalized checkpoint.

The Role of Block Proposers

The validator’s responsibilities consist of:

  • Signing and proposing blocks received from their local execution client, such as a local block-builder.

  • Signing blocks without reviewing the underlying execution payload, received from one or more relays, which holds the transactions in escrow.

It's important to note that validators in the PoN Relay cannot steal the MEV proposed by the builder as the block provided by the builder is encrypted.

MEV Rewards

Validators come together in the PoN Relay to earn rewards and these rewards accrue in the PBS Smoothing Pool. Validators get payouts every 7 days, regardless of whether they proposed a block or not.

PoN Relay Block Proposal

Validators must complete a registration step before proposing blocks through the PoN Relay. Registration is necessary for builders to construct blocks for a specific validator’s block proposal. After registering, validators wait until they are chosen to submit the block proposal. Once selected, a block proposer must perform the following steps to construct a block on top of the beacon state in a specific slot and obtain an execution payload:

  1. Users send transactions to block-builders via public or private peer-to-peer pools.
  2. Builders create execution payloads using transactions they have received and parameters specified by the block proposer during registration. For MEV payment processing, builders set the payoutPool's address to receive the payload and at the end of the proposed block lives a transaction to the payoutPool's feeRecipient address. The block is then sent to relays.
  3. Relays verify the validity of the payload using zero knowledge proofs, including the amount of ETH paid to the payoutPool's feeRecipient address. Then the ExecutionPayloadHeader(execution payloads without tx content) to the PoN Relay, which selects the most valuable payload and sends it to the block proposer for further processing. PoN Relays are ultra optimistic and do not perform block simulations significantly reducing latency.
  4. After receiving the payload from the PoN Relay, the block proposer signs it and sends it back via a SignedBlindedBeaconBlock call. The relay then verifies the signature and sends back the full execution payload from the builder for the validator to use when proposing a SignedBeaconBlock to the network.

PBS violations are mainly related to skipping a request, not paying to the payout pool, etc. To learn more about violations, see the Penalties section of the docs.