--- eip: 8375 title: ePBS Mandatory Burn of Execution Rewards description: Burns priority fees and targets external builder bids subject to a PTC-observed competitive floor. author: Ben Adams (@benaadams) discussions-to: https://ethereum-magicians.org/t/eip-8375-ember-epbs-mandatory-burn-of-execution-rewards/29380 status: Draft type: Standards Track category: Core created: 2026-08-07 requires: 7732 --- ## Abstract This EIP changes execution-layer fee accounting and the [EIP-7732](./eip-7732.md) enshrined Proposer-Builder Separation (ePBS) payment mechanism. Every executed payload burns a configured fraction of its transaction priority fees. For an external build, the same fraction of the selected builder's `gross_value` is an auction target. The whole-Gwei part of the priority-fee burn credits up to that target, so the builder supplies only the remaining top-up. External total MEV burn is therefore the greater of the priority-fee burn and auction target, except that a sub-Gwei priority-fee remainder can make it less than one Gwei higher. The [EIP-1559](./eip-1559.md) base-fee burn remains separate. The builder reserves the full target and trustless proposer payment at bid time. The payment decision remains atomic. A zero-credit burn resolves immediately when payable; other burn realization waits for the canonical payload outcome. PTC members also report their highest eligible public bids. Timely gossiped reports produce a robust local floor below which honest validators do not support an external bid. Self-build remains unconditional, has no external target or floor, and pays the priority-fee burn. ## Motivation [EIP-7732](./eip-7732.md) makes a builder payment a protocol object. This lets the protocol burn a deterministic share without a second auction or a subjective MEV oracle. ### Variable validator revenue Execution payloads can contain arbitrage, liquidations, order-flow advantages, and other maximal extractable value (MEV). Competitive builders pay some of this value to proposers. These payments are highly skewed: rare slots can produce large rewards. Large variable rewards can increase incentives for reorganization, denial of service, key theft, reward pooling, and specialized infrastructure. Large operators also spread fixed costs and income variance across more validators. This EIP targets that reward component; it does not try to measure physical nodes or independent operator control. The objective is to reduce the share and variance of validator revenue from random execution-auction value without materially increasing the advantage of large or vertically integrated operators. ### Protocol-visible value [EIP-1559](./eip-1559.md) burns the base fee, not priority fees or builder payments. This EIP adds one rate for two visible value streams: - Every executed payload burns a fraction of priority fees. - An external bid targets the same fraction of `gross_value`. - Priority-fee burn credits the external target instead of being charged twice. - Self-build is not a zero-burn path. The protocol cannot measure value retained internally or paid outside both streams. PTC reports therefore do not estimate MEV. They only constrain external `gross_value` using real public offers. The competitive floor does not eliminate off-protocol avoidance. It makes ordinary external-path under-declaration harder and shifts the principal bilateral avoidance routes toward proposer-authorized self-build, suppressed public price discovery, and value competitors cannot observe. A voluntary burn field would create a second auction dimension because a proposer prefers payment over an otherwise equal burn. A fixed fraction removes that choice. For fully collateralized public bids, a larger `gross_value` still gives a larger proposer payment. ### Design goals This EIP aims to: 1. Burn an objective share of priority fees for every executed payload. 2. Derive an external target from the selected signed bid. 3. Credit priority-fee burn toward that target. 4. Keep public bids fully collateralized and allow declared trusted payments on private paths. 5. Keep the target and trustless proposer payment in one liability decision. 6. Use local PTC observations only for external-bid eligibility. 7. Prevent proposer omission from neutralizing timely reports. 8. Keep self-build unconditional. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174). This specification changes both the execution layer and the consensus-layer ePBS mechanism from [EIP-7732](./eip-7732.md). Types, constants, and helper functions not defined in this document have the meanings given in [EIP-7732](./eip-7732.md) and the [consensus specifications](https://github.com/ethereum/consensus-specs/tree/c94138e73e0e70eb4b27f9be4d4e9325fa1aebf7/specs/gloas). ### Definitions For an executed payload and, where applicable, one selected external-builder bid, use these terms: - `G`: `gross_value`. This is the signed external-bid amount that determines the auction target and declared proposer compensation. - `T`: `priority_fee_value`, the aggregate transaction priority fees in the executed payload, in Wei. - `U`: `priority_fee_burn`, the amount in Wei that the execution layer destroys for every executed payload. - `R`: `priority_fee_burn_credit`, the whole-Gwei part of `U` credited against the external auction target, capped at `A`. - `A`: `burn_target`. This is the external auction burn target reserved from the builder. - `D`: `builder_burn`. Consensus destroys this top-up from builder balance. - `P`: total proposer compensation after the burn. - `E`: `execution_payment`. This is the trusted proposer-payment amount from EIP-7732. - `V`: `trustless_payment`. Consensus guarantees this proposer-payment amount. - `C`: `consensus_liability`. The builder MUST cover this amount with consensus-layer builder balance. - `F`: the robust local PTC-observed public-bid floor. - `H`: the local floor after applying the configured haircut. The following equations MUST hold, using the burn constants defined in Configuration below: ```text U = floor(T * BUILDER_PAYMENT_BURN_NUMERATOR / BUILDER_PAYMENT_BURN_DENOMINATOR) A = floor(G * BUILDER_PAYMENT_BURN_NUMERATOR / BUILDER_PAYMENT_BURN_DENOMINATOR) R = min(A, floor(U / 10**9)) P = G - A V = P - E G = A + V + E C = A + V C = G - E ``` A bid is invalid if `E > P`. Consensus does not guarantee `E`. A larger `E` does not reduce the auction target if `G` stays the same. A larger declared total commitment requires a larger `G`. A larger `G` increases `A`. For a payable external-builder commitment with a valid executed payload: ```text D = max(0, A - R) total_mev_burn_wei = U + D * 10**9 ``` The external total is at least `max(U, A * 10**9)` and less than one Gwei above it. The possible excess is the sub-Gwei part of `U`, which consensus cannot credit against a Gwei-denominated builder balance. For a payable external-builder commitment on a no-payload or withheld-payload path, realized `U = R = 0` and `D = A`. For a self-built executed payload, `total_mev_burn_wei = U`. The proposer-compensation calculation MUST use `A`, not `D`. A high `R` MUST NOT increase `P`, `V`, or `E` for a fixed `G`. The EIP-1559 base-fee burn is separate and is not included in `T`, `U`, `R`, `A`, or `D`. ### Configuration The proposed mainnet configuration is: ```python BUILDER_PAYMENT_BURN_NUMERATOR = uint64(1) BUILDER_PAYMENT_BURN_DENOMINATOR = uint64(3) ``` A devnet or testnet MAY configure a different burn numerator and denominator. The same numerator and denominator MUST be used to calculate both `U` and `A`. There is no separate priority-fee, self-build, or external-builder burn rate. Add: ```python BID_FLOOR_DUE_BPS = uint64(TBD) BID_FLOOR_THRESHOLD = uint64(TBD) BID_FLOOR_HAIRCUT_BPS = uint64(TBD) DOMAIN_BID_FLOOR = DomainType('0x0F000000') ``` `0x0F000000` is a proposed domain value. It MUST be deconflicted and allocated in the consensus specifications before activation. `BID_FLOOR_DUE_BPS` is measured in basis points into the slot immediately preceding the report's `target_slot`. It ends the public-bid observation window. `BID_FLOOR_DUE_BPS` MUST be less than `10_000`, leaving time for reports to propagate before `target_slot`. Its selection MUST account for concurrent pre-proposal deadlines, including [EIP-7805](./eip-7805.md) inclusion-list freezing when active. `BID_FLOOR_THRESHOLD` is a number of distinct target-slot PTC members. Its mainnet value is TBD pending propagation and adversarial analysis. It MUST be greater than zero and MUST NOT exceed `PTC_SIZE`. `BID_FLOOR_HAIRCUT_BPS` is the proportional margin below `F`. It MUST be less than `10_000`. The active values MUST be part of chain configuration and MUST NOT change without a protocol upgrade. `BUILDER_PAYMENT_BURN_DENOMINATOR` MUST be greater than zero. `BUILDER_PAYMENT_BURN_NUMERATOR` MAY be zero. A zero numerator disables `U`, `A`, the PTC bid-floor duty, and external-bid floor enforcement without disabling ordinary ePBS payments. `BUILDER_PAYMENT_BURN_NUMERATOR` MUST NOT be greater than `BUILDER_PAYMENT_BURN_DENOMINATOR`. An implementation MUST use integer floor division to calculate `U` and `A`. An implementation MUST calculate products for `T` and `G` without intermediate overflow. It MUST use a sufficiently wide intermediate type or an equivalent overflow-safe algorithm. Any division remainder from calculating `A` stays in `P`. Therefore, `A + P == G` always holds. ### Execution layer For transaction `i`, define: ```text tip_wei_i = (effective_gas_price_i - base_fee_per_gas) * gas_used_i T = sum(tip_wei_i) U = floor(T * BUILDER_PAYMENT_BURN_NUMERATOR / BUILDER_PAYMENT_BURN_DENOMINATOR) ``` `gas_used_i` includes failed transactions and reflects refund accounting. The execution layer MUST withhold exactly `U` Wei from priority-fee credits. It initializes `T_running = 0` and `U_previous = 0`. After each transaction, it adds `tip_wei_i` to `T_running` and calculates `U_current = get_priority_fee_burn(T_running)`. It burns `U_current - U_previous` Wei from that transaction's tip, credits the remainder, and sets `U_previous = U_current`. The increment cannot exceed `tip_wei_i` because the fraction is at most one. The increments telescope to `U` and do not depend on transaction boundaries. The next fork version of `engine_newPayload` MUST extend a payload-status response whose `status` is `VALID` with these `QUANTITY` fields: ```text priorityFeeValue: T priorityFeeBurn: U ``` Both fields MUST be present when `status == VALID` and MUST be absent for every other payload status. Both fields are Wei-denominated. Payload-envelope verification MUST derive `burn_target = get_mev_burn_amount(bid.gross_value)` and verify `priorityFeeBurn == get_priority_fee_burn(priorityFeeValue)` and `bid.priority_fee_burn_credit == get_priority_fee_burn_credit(priorityFeeValue, burn_target)`. The canonical signed bid therefore carries `R`; the Engine API result verifies the commitment but is not itself an input to a later beacon state transition. ### Modified `ExecutionPayloadBid` Replace `ExecutionPayloadBid.value` with `gross_value`: ```python class ExecutionPayloadBid(ProgressiveContainer(active_fields=[1] * 13)): parent_block_hash: Hash32 parent_block_root: Root block_hash: Hash32 prev_randao: Bytes32 fee_recipient: ExecutionAddress gas_limit: Uint64 builder_index: BuilderIndex slot: Slot gross_value: Gwei execution_payment: Gwei blob_kzg_commitments: BlobKZGCommitments execution_requests_root: Root priority_fee_burn_credit: Gwei ``` `SignedExecutionPayloadBid` signs `gross_value` and `priority_fee_burn_credit`. A builder knows `R` because the bid already commits to a completed payload by `block_hash`. The builder MUST set it to `get_priority_fee_burn_credit(T, A)`. The builder MUST NOT supply `trustless_payment` as an independent field. The builder MUST NOT supply `burn_target` or `builder_burn` as an independent field. Consensus MUST derive the auction target and trustless payment from `gross_value` and `execution_payment`. For a verified canonical payload, it MUST derive the builder top-up from that target and `bid.priority_fee_burn_credit`. No additional `ExecutionPayloadBid` field is required for the PTC floor. The signed bid already contains the builder, slot, parent context, block commitment, proposer preferences, and `gross_value`. ### Builder bid construction An external builder MUST use `gross_value` for the amount that determines both the auction burn target and declared proposer compensation. The builder MUST choose `execution_payment` so that `execution_payment <= P`. A public bid MUST set `execution_payment = 0`. For a public bid, the trustless proposer payment is `gross_value - burn_target`. A private or relay bid MAY set `execution_payment > 0`. For a private or relay bid, the trustless proposer payment is the remaining proposer compensation after `execution_payment`. A builder MUST NOT treat `execution_payment` as an amount in addition to `gross_value`. ### Burn and payment helpers Consensus implementations MUST calculate the bid components deterministically. The following pseudocode is normative in behavior: ```python def get_mev_burn_amount(value: Gwei) -> Gwei: return Gwei( value * BUILDER_PAYMENT_BURN_NUMERATOR // BUILDER_PAYMENT_BURN_DENOMINATOR ) def get_priority_fee_burn(value: uint256) -> uint256: return ( value * BUILDER_PAYMENT_BURN_NUMERATOR // BUILDER_PAYMENT_BURN_DENOMINATOR ) def get_priority_fee_burn_credit(value: uint256, burn_target: Gwei) -> Gwei: return Gwei(min(burn_target, get_priority_fee_burn(value) // 10**9)) def get_bid_payment_components(bid: ExecutionPayloadBid) -> tuple[Gwei, Gwei, Gwei]: burn_target = get_mev_burn_amount(bid.gross_value) proposer_amount = Gwei(bid.gross_value - burn_target) assert bid.execution_payment <= proposer_amount trustless_payment = Gwei(proposer_amount - bid.execution_payment) return burn_target, trustless_payment, bid.execution_payment def get_bid_consensus_liability(bid: ExecutionPayloadBid) -> Gwei: burn_target, trustless_payment, _ = get_bid_payment_components(bid) return Gwei(burn_target + trustless_payment) def get_builder_burn_top_up( burn_target: Gwei, priority_fee_burn_credit: Gwei, ) -> Gwei: if priority_fee_burn_credit >= burn_target: return Gwei(0) return Gwei(burn_target - priority_fee_burn_credit) ``` For every valid external bid, the following equation is also valid: ```text consensus_liability = gross_value - execution_payment ``` ### `BuilderPendingSettlement` Replace `BuilderPendingPayment` with a settlement object that contains both protocol liabilities: ```python class BuilderPendingSettlement(Container): weight: Gwei withdrawal: BuilderPendingWithdrawal proposer_index: ValidatorIndex gross_value: Gwei burn_target: Gwei priority_fee_burn_credit: Gwei is_payable: boolean ``` `withdrawal.amount` MUST equal `V`, `burn_target` MUST equal `A`, `priority_fee_burn_credit` MUST equal the signed bid's `priority_fee_burn_credit`, and `is_payable` MUST initially be `False`. `proposer_index` identifies the proposer for the existing EIP-7732 proposer-slashing release path. It is not a payment recipient. `withdrawal.fee_recipient` keeps the existing EIP-7732 fee-recipient semantics. It is the proposer-designated recipient used by the existing bid flow. `BuilderPendingSettlement` is consensus-derived. Consensus derives `burn_target`, copies the signed bid's `priority_fee_burn_credit`, controls `is_payable`, and stores the credit so later burn realization does not depend on an uncommitted Engine API result or local cache. Replace `builder_pending_payments` with an equivalent `builder_pending_settlements` vector. A payable entry with nonzero credit remains in that vector until its burn is resolved. ### Pending builder liability The pending-liability helper MUST count both trustless proposer payments and full auction burn targets. Conceptually: ```python def get_pending_builder_liability(state: BeaconState, builder_index: BuilderIndex) -> Gwei: pending_withdrawals = sum( withdrawal.amount for withdrawal in state.builder_pending_withdrawals if withdrawal.builder_index == builder_index ) pending_settlements = sum( settlement.burn_target + (0 if settlement.is_payable else settlement.withdrawal.amount) for settlement in state.builder_pending_settlements if settlement.withdrawal.builder_index == builder_index ) return Gwei(pending_withdrawals + pending_settlements) ``` `can_builder_cover_bid` MUST use the new bid's `consensus_liability`. `can_builder_cover_bid` MUST NOT require collateral for the trusted `execution_payment`. Conceptually: ```python def can_builder_cover_bid( state: BeaconState, builder_index: BuilderIndex, consensus_liability: Gwei, ) -> bool: builder_balance = state.builders[builder_index].balance pending_liability = get_pending_builder_liability(state, builder_index) min_balance = MIN_DEPOSIT_AMOUNT + pending_liability if builder_balance < min_balance: return False return builder_balance - min_balance >= consensus_liability ``` Builder exit processing MUST treat a pending burn as a pending builder liability. A builder MUST NOT exit while a pending auction target, payable burn reserve, or pending trustless proposer payment exists. Before the liability decision, the settlement counts `A + V`. While a payable settlement remains, the withdrawal queue counts `V` and the settlement counts only `A`. Pending consensus liabilities have priority over later builder-balance deductions. A transition MUST leave enough balance to cover every remaining pending liability. For each builder after such a transition, this invariant MUST hold: ```text builder_balance >= get_pending_builder_liability(state, builder_index) ``` A future penalty or slashing rule that decreases builder balance MUST preserve this invariant or MUST first resolve the affected pending liabilities. ### Process an execution payload bid For `BUILDER_INDEX_SELF_BUILD`, these conditions MUST hold: ```text gross_value == 0 execution_payment == 0 priority_fee_burn_credit == 0 ``` A self-build does not create an auction target or a pending builder settlement. Its executed payload remains subject to `U`. For an external builder, the implementation MUST do these steps: 1. Calculate `A`, `V`, and `C`. 2. Verify that `execution_payment <= gross_value - A` and `priority_fee_burn_credit <= A`. 3. Perform the existing EIP-7732 builder activity, version, and signature checks. 4. Verify that the builder can cover `C` and all other pending liabilities. 5. If `C > 0`, record one `BuilderPendingSettlement` that contains `A`, `V`, and the bid-derived `R`. 6. Cache the bid as the latest execution payload bid as specified by EIP-7732. Conceptually: ```python burn_target, trustless_payment, _ = get_bid_payment_components(bid) consensus_liability = Gwei(burn_target + trustless_payment) assert bid.priority_fee_burn_credit <= burn_target if bid.builder_index == BUILDER_INDEX_SELF_BUILD: assert bid.gross_value == 0 assert bid.execution_payment == 0 assert bid.priority_fee_burn_credit == 0 assert signed_bid.signature == bls.G2_POINT_AT_INFINITY else: assert is_active_builder(state, bid.builder_index) assert state.builders[bid.builder_index].version == PAYLOAD_BUILDER_VERSION assert can_builder_cover_bid(state, bid.builder_index, consensus_liability) assert verify_execution_payload_bid_signature(state, signed_bid) if consensus_liability > 0: settlement = BuilderPendingSettlement( weight=0, withdrawal=BuilderPendingWithdrawal( fee_recipient=bid.fee_recipient, amount=trustless_payment, builder_index=bid.builder_index, ), proposer_index=get_beacon_proposer_index(state), gross_value=bid.gross_value, burn_target=burn_target, priority_fee_burn_credit=bid.priority_fee_burn_credit, is_payable=False, ) settlement_index = SLOTS_PER_EPOCH + bid.slot % SLOTS_PER_EPOCH assert ( state.builder_pending_settlements[settlement_index] == BuilderPendingSettlement() ) state.builder_pending_settlements[settlement_index] = settlement ``` The destination entry MUST be empty before a new settlement is written. A beacon block that targets a nonempty entry is invalid, and processing MUST NOT overwrite the existing liability. ### Atomic settlement lifecycle The auction burn target and the trustless proposer payment MUST use one liability decision. A pending settlement has only two final results: 1. `PAYABLE`: `V` becomes a proposer payment and the full `A` reserve remains locked until burn realization. 2. `RELEASED`: the protocol charges neither `A` nor `V`. The protocol MUST NOT retain or charge `A` and release `V`. The protocol MUST NOT pay `V` and later release `A` without resolving it according to this EIP. The existing EIP-7732 payment conditions MUST control the complete settlement. These conditions include the normal payload path and the builder-payment quorum path. This EIP does not add a separate burn-liability condition. If an EIP-7732 proposer-slashing path clears a pending payment before it becomes payable, it MUST clear the matching `BuilderPendingSettlement`. That path MUST NOT charge `A` or `V`. ### Apply a payable settlement When a settlement becomes payable, consensus MUST queue `V` exactly once if `V > 0` and set `is_payable = True`. If stored `R == 0`, it MUST deduct `A` and clear the settlement immediately. Otherwise, it MUST keep `A` reserved until a canonical FULL or EMPTY payload outcome resolves the burn. Conceptually: ```python def mark_builder_settlement_payable( state: BeaconState, settlement_index: uint64, ) -> None: settlement = state.builder_pending_settlements[settlement_index] assert settlement != BuilderPendingSettlement() assert not settlement.is_payable if settlement.withdrawal.amount > 0: state.builder_pending_withdrawals.append(settlement.withdrawal) settlement.is_payable = True if settlement.priority_fee_burn_credit == 0: realize_payable_builder_burn(state, settlement_index, Gwei(0)) def realize_payable_builder_burn( state: BeaconState, settlement_index: uint64, priority_fee_burn_credit: Gwei, ) -> None: settlement = state.builder_pending_settlements[settlement_index] assert settlement.is_payable assert priority_fee_burn_credit in ( Gwei(0), settlement.priority_fee_burn_credit, ) builder_index = settlement.withdrawal.builder_index builder_burn = get_builder_burn_top_up( settlement.burn_target, priority_fee_burn_credit, ) assert state.builders[builder_index].balance >= builder_burn state.builders[builder_index].balance -= builder_burn state.builder_pending_settlements[ settlement_index ] = BuilderPendingSettlement() ``` `mark_builder_settlement_payable` is the only transition that queues `V`. Calling it for an already payable settlement is invalid. When stored `R == 0`, FULL and EMPTY both imply `D == A`; no payload outcome is needed to realize the burn. This includes the zero-numerator case, where `A == 0` and the settlement clears after queuing `V`. For a remaining settlement, a canonical FULL payload MUST use `settlement.priority_fee_burn_credit`. FULL requires successful payload-envelope verification, including agreement between the execution result and the signed bid's `priority_fee_burn_credit`. A canonical EMPTY or no-payload path MUST use zero. Local payload absence alone MUST NOT select the zero value. An execution payload for which the Engine API returns `INVALID` fails payload-envelope verification and MUST NOT create a FULL payload branch. It provides no priority-fee credit. If the canonical EIP-7732 outcome for the commitment is EMPTY and a remaining settlement is `PAYABLE`, consensus uses zero credit and charges the full `A`; if the settlement is `RELEASED`, consensus charges neither `A` nor `V`. The balance reduction for `D` is the consensus-layer builder burn. Clearing the settlement releases the unused `A - D` reserve. The protocol MUST NOT represent `D` as an execution-layer transfer to a burn address. The existing withdrawal path continues to process `V`. ### Settlement rotation and collision The EIP-7732 epoch transition processes the older half of `builder_pending_settlements`, shifts the newer half into the older half, and initializes an empty newer half. This EIP modifies that transition as follows: 1. Apply the existing quorum rule to every nonempty older entry whose liability is not yet decided. A quorum result makes it `PAYABLE`; otherwise it becomes `RELEASED`. 2. Clear every `RELEASED` entry without charging `A` or `V`. 3. Resolve every remaining `PAYABLE` entry from the canonical payload outcome. An EMPTY status uses zero priority-fee credit. A FULL status uses the stored `settlement.priority_fee_burn_credit` after successful payload-envelope verification. 4. Assert that every entry in the older half is empty. Then shift the newer half into the older half and initialize the newer half with empty `BuilderPendingSettlement` values. An unresolved entry in the newer half MAY shift once into the older half. An unresolved entry MUST NOT be discarded or survive the next rotation. For a payable entry with nonzero stored `R`, a node that lacks the canonical payload outcome cannot verify the epoch transition until it obtains that outcome; it MUST NOT substitute zero credit for a FULL outcome. A payload received after a canonical EMPTY outcome does not reopen the settlement. ### Attestation weight accounting EIP-7732 uses attestation weight to decide when a pending builder payment becomes payable if the normal payload path is not available. Under this EIP, weight MUST accumulate when the pending `consensus_liability` is not zero. This rule also applies when `V == 0` and `A > 0`. An implementation MUST use a check equivalent to this check: ```python def has_pending_consensus_liability(settlement: BuilderPendingSettlement) -> bool: return ( not settlement.is_payable and settlement.withdrawal.amount + settlement.burn_target > 0 ) ``` After the liability decision becomes `PAYABLE`, further attestation weight does not change the result. The full `A` remains reserved until burn realization. The quorum threshold does not change. The other EIP-7732 attestation rules do not change. ### Public bid gossip The existing EIP-7732 public-gossip rule MUST remain unchanged: ```text execution_payment == 0 ``` Therefore, every public bid has: ```text C = G ``` A public bid is fully collateralized for its complete gross commitment. Public gossip MUST compare `gross_value` instead of the former `value` field. For public bids, the target fraction is constant and `execution_payment == 0`. Ordering by `gross_value` therefore also orders the declared trustless proposer payment. The existing EIP-7732 one-bid-per-builder-per-slot-and-parent gossip policy does not change. ### Private and relay bids A bid that does not use the public gossip topic MAY have `execution_payment > 0`. The following condition MUST hold: ```text execution_payment <= gross_value - burn_target ``` Consensus reserves `A + V`. The builder MUST provide consensus collateral for `A + V` at bid time. A later priority-fee credit does not reduce this requirement. Consensus does not define the credit value of `E`. A proposer MAY discount or reject `E`. A proposer MAY use relay guarantees, builder reputation, or other local information to value `E`. `gross_value` sets the auction burn target and the builder's declared total commitment. `gross_value` does not tell the proposer how to compare bids that have different trusted-payment risk. The external PTC floor applies equally to a public, private, or relay-selected external bid. Only eligible public bids provide evidence for the floor. ### Bid-floor messages Add: ```python class BidFloorMessage(Container): validator_index: ValidatorIndex target_slot: Slot bid_root: Root gross_value: Gwei class SignedBidFloorMessage(Container): message: BidFloorMessage signature: BLSSignature ``` For a positive report, `bid_root` MUST equal `hash_tree_root(signed_bid)` for the referenced `SignedExecutionPayloadBid`. Its `gross_value` MUST equal `signed_bid.message.gross_value`. A member that observed no eligible public bid MAY report: ```text bid_root == Root() gross_value == 0 ``` The signature is over `BidFloorMessage` under `DOMAIN_BID_FLOOR` for the epoch containing `target_slot`. ### Floor-eligible public bids A PTC member MUST report only a public bid that it received by `BID_FLOOR_DUE_BPS` and that satisfies these objective checks against the referenced proposal context: 1. The container is well formed, its builder signature is valid, its commitments satisfy the EIP-7732 limits, and `priority_fee_burn_credit <= burn_target`. 2. The builder is active and has the required builder version in the state referenced by the bid's parent context. 3. The bid is for `target_slot` and has the correct parent execution hash, parent beacon root, and `prev_randao` for that context. 4. The bid matches the target proposer's valid signed preferences, including fee-recipient and gas-limit constraints. 5. `execution_payment == 0`. 6. The builder has sufficient consensus collateral for `gross_value` and its other pending liabilities in the referenced state. Local public-gossip admission policy is not objective bid eligibility. First-seen rules, duplicate suppression, highest-seen rules, rate limits, current-head compatibility, and whether local context data was available when the bid arrived MUST NOT make otherwise valid retrieved evidence ineligible. These rules can affect which bids a PTC member receives or forwards, but another validator MUST be able to verify a reported bid from the signed object and referenced context alone. A positive report MUST NOT contribute to a floor until the validator has the referenced signed bid and has verified these objective checks for the candidate proposal context. ### PTC public-bid observation duty If `BUILDER_PAYMENT_BURN_NUMERATOR == 0`, the PTC bid-floor duty is disabled and members MUST NOT issue `SignedBidFloorMessage` objects. Otherwise, each PTC member assigned to `target_slot` MUST observe eligible public bids during the pre-proposal window in the preceding slot. At `BID_FLOOR_DUE_BPS`, the member MUST choose its observed eligible public bid with the greatest `gross_value`. It MUST break equal-value ties by the lexicographically smallest `bid_root`. The member MUST sign and broadcast a `SignedBidFloorMessage` on the `bid_floor_message` gossip topic. An honest member MUST issue at most one nonzero report for a target slot and proposal context. The PTC member is not estimating MEV. It is reporting the highest real, signed, collateral-backed public offer it received by the deadline. ### Bid-floor gossip Add the `bid_floor_message` global gossip topic for `SignedBidFloorMessage` objects. Gossip validation MUST verify at least: 1. `target_slot` is within the permitted propagation range. 2. `validator_index` is a member of the PTC assigned to `target_slot`. 3. The PTC signature is valid under `DOMAIN_BID_FLOOR`. 4. A positive report references a matching, verified, floor-eligible `SignedExecutionPayloadBid`. 5. A zero report uses both zero sentinel values. Validators MUST store timely reports and their evidence. At the start of `target_slot`, each validator freezes its report set. Later reports MUST NOT change that slot's floor or an earlier fork-choice decision. For multiple valid reports from one member, a validator MUST use only the greatest eligible `gross_value`. It MAY retain the signed messages as equivocation evidence. This EIP does not add a slashing condition. ### Bid evidence retrieval Add the `ExecutionPayloadBidsByRoot` request/response protocol: ```text MAX_REQUEST_BIDS = MAX_REQUEST_PAYLOADS Protocol: /eth2/beacon_chain/req/execution_payload_bids_by_root/1/ Request: List[Root, MAX_REQUEST_BIDS] Response: zero or more SignedExecutionPayloadBid chunks ``` Each request root is `hash_tree_root(signed_bid)`. A response MUST contain no more than one bid for each requested root, MUST NOT contain an unrequested bid, and MAY omit an unavailable bid. Each chunk uses the fork digest for the epoch containing the bid's slot. A PTC member that publishes a positive report MUST retain and serve its referenced signed bid until the start of `target_slot + 2`. A node that obtains the bid SHOULD serve it for the same period. When a validator, including a proposer, receives a positive report but lacks its bid, it MUST defer validation and request the bid from one or more peers. It MUST NOT count or forward the report as valid until it has verified the bid. Only reports whose evidence is verified before the target-slot snapshot contribute to `F`. ### Local PTC floor From the frozen set, a validator forms one value `m_i` per distinct PTC member. The report must reference an eligible public bid compatible with the candidate's slot, parent context, and proposer preferences. Let `q = BID_FLOOR_THRESHOLD`. If fewer than `q` distinct compatible positive reports are available, set `F = 0`. Otherwise: ```text F = highest value such that at least q distinct PTC members reported an eligible public bid with gross_value >= F ``` Equivalently, sort the distinct-member values in descending order and use the `q`-th value. The reports do not need to reference the same bid root. Conceptually: ```python def get_local_ptc_floor( reports: Sequence[VerifiedBidFloorReport], ) -> Gwei: if BUILDER_PAYMENT_BURN_NUMERATOR == 0: return Gwei(0) maxima_by_member = get_highest_compatible_report_per_member(reports) values = sorted(maxima_by_member.values(), reverse=True) if len(values) < BID_FLOOR_THRESHOLD: return Gwei(0) return Gwei(values[BID_FLOOR_THRESHOLD - 1]) def get_enforced_bid_floor(floor: Gwei) -> Gwei: return Gwei( uint256(floor) * (10_000 - BID_FLOOR_HAIRCUT_BPS) // 10_000 ) ``` Set `H = get_enforced_bid_floor(F)`. ### External-bid floor enforcement When `BUILDER_PAYMENT_BURN_NUMERATOR > 0`, an honest proposer MUST NOT select an external bid for which: ```text selected_bid.gross_value < H ``` During `target_slot` and `target_slot + 1`, an honest validator MUST exclude such a block and its descendants from head selection and MUST NOT attest to them as head. The filter applies before ordinary head selection. An honest proposer in `target_slot + 1` MUST propose on the resulting head, normally the filtered block's parent when no eligible sibling exists. When the numerator is zero, this filter is disabled. The filter expires at the start of `target_slot + 2`; both branches then use ordinary fork choice. Prior votes are not revised. Reports and external bids are not transferable between parent contexts. If filtering changes the head for `target_slot + 1`, reports and bids referencing the filtered subtree MUST NOT establish `F` or be selected for the new context. An honest proposer that produces a block MUST self-build if no compatible external bid is available. Bid-floor head filtering is independent of the EIP-7732 payload-timeliness duty. A PTC member observing a below-floor block MUST continue its normal payload observation and attestation duties for that commitment. A floor decision MUST NOT be treated as a payload-unavailability vote. The floor is not a state-transition validity rule. Its direct effect is bounded to two slots of head selection; normal LMD-GHOST consequences of those votes can persist. Expiry does not permanently exclude the branch. If no competing proposal is produced or supported, ordinary fork choice can still make the below-floor branch canonical. The floor MUST NOT change the amount charged for a selected bid. This EIP does not charge a proposer or validator `t * (F - G)`. It does not define `burn = t * max(G, F)`. PTC reports do not need beacon-block inclusion. Proposer omission MUST NOT remove a locally received report from fork-choice enforcement. A future specification MAY add inclusion or aggregation for rewards and auditing. Inclusion MUST NOT give a report its force. ### Self-built payloads A self-built payload MUST have these values: ```text builder_index == BUILDER_INDEX_SELF_BUILD gross_value == 0 execution_payment == 0 priority_fee_burn_credit == 0 ``` A self-built payload does not create an external auction target or pending builder settlement. The external PTC floor does not apply. The execution layer MUST still calculate `T` and burn `U` for the executed payload. The protocol does not estimate MEV that a proposer keeps inside a self-built payload and does not attempt to prove who physically constructed it. ### Burn observability For each executed payload and, where applicable, selected external-builder bid, canonical data MUST make these values derivable: ```text slot builder_index gross_value priority_fee_value priority_fee_burn priority_fee_burn_credit burn_target builder_burn trustless_payment execution_payment settlement outcome ``` The signed bid is the canonical commitment to `gross_value`, `execution_payment`, and `priority_fee_burn_credit`. Execution derives `priority_fee_value` and `priority_fee_burn` and verifies the signed `priority_fee_burn_credit`. Consensus derives `burn_target`, `builder_burn`, and `trustless_payment`. Consensus clients SHOULD expose these values through a stable state-inspection, event, or API surface. Clients SHOULD also expose locally timely PTC reports, verified bid evidence, and the local `F` and `H` used for fork-choice decisions. Implementations used for activation evaluation SHOULD retain signed floor reports and referenced bids long enough for cross-node analysis of high-floor self-build behavior. This exposure supports supply accounting and post-fork economic analysis. This EIP does not define a specific API endpoint. ## Rationale ### Why these rules activate together The three rules address different parts of the same accounting path. The universal priority-fee burn gives every executed payload a minimum burn. The auction target covers value declared by an external builder. The competitive floor limits trivial under-declaration of that value. Priority-fee burn must credit the auction target to avoid charging both rules for the same value. A single activation also gives both layers one rate and one set of cross-layer tests. An activation that omits a rule would restore either double counting, the self-build zero-burn path, or low-value external bids. ### Auction accounting The signed external bid decomposes as follows: ```text G = A + V + E A = floor(t * G) V = G - A - E ``` The builder supplies only `gross_value` and `execution_payment`. Consensus derives `burn_target` and `trustless_payment`. This avoids redundant monetary fields. The proposer amount is `G - A`. It does not change when `R` reduces the later builder top-up. The full protocol liability is reserved at bid time: ```text C = A + V ``` After execution, the realized builder deduction is `max(0, A - R)`. Thus, `gross_value` defines the external commitment and target. It does not state that every part of `A` is deducted from builder balance. ### Priority-fee credit and channel substitution For a whole-Gwei gross value `X` represented entirely in either `T` or `G`, the burn is the configured fraction of `X`, subject to integer rounding. To deliver a fixed post-burn amount `x`, either endpoint requires gross value `x / (1 - t)` and burns `t * x / (1 - t)`. The two endpoints therefore have the same marginal rate apart from rounding. When `T` and `G` are economically distinct additive streams, crediting `U` against `A` deliberately burns less than applying the rate to `T + G`; third-party priority fees can reduce `D`. Each credited Gwei replaces one Gwei of `D` until `R = A`; further priority-fee burn increases the total. This follows from treating `U` as a universal minimum rather than an additive burn. The external total is at least `max(U, A * 10**9)` and can exceed it only by the sub-Gwei part of `U`. Evaluation must test this overlap assumption. The public-bid floor constrains `G`, and `U` remains unavoidable for every executed payload. ### Priority-fee scope and precision The execution layer aggregates priority fees in Wei before applying the burn fraction. It burns the exact Wei-denominated `U`, so splitting the same total fees across transactions cannot change the result. Consensus builder balances remain Gwei-denominated and therefore use `R = min(A, floor(U / 10**9))`. Any sub-Gwei part of `U` is still burned but cannot reduce the builder top-up. Failed transactions are included because they consume gas and pay priority fees. Excluding them would make the burn depend on the success flag and would let equivalent gas demand avoid `U` by reverting. ### Trusted payments `execution_payment` preserves the EIP-7732 distinction between trustless and trusted proposer compensation. Consensus reserves `A + V` but does not collateralize `E`. The target still uses all of `G`, so moving compensation into `E` does not reduce `A`. Public bids require `E == 0` and are fully collateralized. Private paths may use trusted payments. This EIP does not set a minimum `V` because that would add an arbitrary credit-risk rule and increase collateral requirements. ### Self-build A self-built payload has no measurable external `gross_value`. The protocol cannot prove who constructed it or require a truthful declaration of its MEV. Self-build therefore has no auction target or competitive floor. It still pays `U`. This preserves local construction as the unconditional fallback. Once the floor constrains low-value external bids, proposer-authorized outsourced self-build becomes the primary bilateral residual. An external constructor leaves the normal ePBS builder relationship and must either disclose the payload before authorization or arrange off-protocol authorization of a payload the proposer has not inspected. Disclosure gives the proposer an option to copy, reorder, leak, or extract from the payload and can make confidential order-flow providers less willing to share flow. Keeping the payload hidden instead adds counterparty, validation, signing, and fair-exchange infrastructure risk. These are economic frictions, not consensus guarantees. Vertically integrated proposer-builders can internalize much of them, giving them lower avoidance costs and creating vertical-integration pressure. ### PTC order statistic and local snapshot PTC members report signed, collateral-backed public bids, not estimates of MEV. Different members can observe different bids. The `q`-th greatest distinct-member maximum uses these observations without requiring an identical `bid_root`. The threshold trades off two failures. A low threshold makes selective delivery easier. A high threshold makes ordinary propagation failure or report suppression more likely to produce a low floor. The haircut reduces false filtering from marginal bid-view differences but creates a bounded under-declaration band. Mainnet values must follow propagation and adversarial analysis, so all three constants remain `TBD`. Each validator freezes its report set at the start of the target slot. Late reports do not revise the floor. The below-floor filter remains through the next slot so an honest proposer can create a supported sibling, then expires. Changing the parent can make prepared external bids incompatible and force self-build fallback. This bounds the filter's direct effect to two slots of head selection, although ordinary LMD-GHOST consequences can persist. A colluding proposer cannot neutralize the rule by omitting reports from a block because timely gossip, not inclusion, gives a report effect. Signed reports make conflicting messages attributable. However, the main selective delivery attack needs only one valid report per PTC member. An equivocation penalty alone would therefore not prevent it. ### Objective accounting and deferred settlement The burn remains objective. The signed bid commits `R` in the beacon block, payload-envelope verification checks it against canonical execution, `A` comes from the bid, and `D` is a deterministic function of `A` and `R`. Local PTC observations affect only bounded external-bid fork-choice eligibility. One `BuilderPendingSettlement` stores the target, proposer liability, and bid-derived credit, so historical settlement does not read an uncommitted Engine API result. The `is_payable` flag records the atomic liability decision. A released entry reserves nothing. A payable entry queues `V` once; zero stored `R` resolves immediately, while nonzero `R` keeps `A` reserved until the canonical payload outcome selects stored credit for FULL or zero credit for EMPTY. The signed bid commits `R` rather than placing it only in the payload envelope because consensus creates and retains the settlement from the bid. Appending one field to the progressive bid container keeps the prior field order and lets the settlement remain self-contained. Payload-envelope verification accepts neither an overstated nor an understated `R`. Before payload reveal, `R < A` discloses the whole-Gwei part of `U`; a capped `R` discloses only that the cap was reached. The execution layer destroys `U` by withholding it from priority-fee credit. The consensus layer destroys `D` by reducing builder balance without creating a withdrawal. No burn address is used. ### Proposed fraction and evaluation The proposed mainnet fraction remains one third. For an expenditure-inclusive bid, a fraction `t` requires extra gross expenditure `t / (1 - t)` per unit of proposer compensation. At one third, the extra gross expenditure is one half. A static builder-payment backcast is insufficient for the combined mechanism. It omits priority-fee overlap, the competitive floor, and behavioral changes. Before activation, evaluation should measure: 1. Distributions of `T`, `U`, `R`, `A`, and `D`. 2. Declared external value retained at the proposed rate. 3. Public, private, and self-build shares by count and estimated value. 4. PTC propagation by deadline and local-floor disagreement. 5. The probability that a below-floor block becomes canonical, conditioned on colluding stake, report and evidence propagation, threshold, and haircut. 6. Self-build probability by local-`F` quantile and the distribution of `F` for self-built slots. 7. For nonzero floor targets, the ratio `U / (get_mev_burn_amount(F) * 10**9)`, the fraction of high-`F` slots that self-build, and the frequency of large-`F`, low-`U` self-builds. 8. High-`F` self-build concentration by identifiable staking operator and sensitivity to the configured burn rate. 9. Trusted-payment defaults, builder collateral concentration, proposer-payment tails, and missed proposal or payload rates, including external-bid availability and self-build rates immediately after floor-triggered reorgs. 10. Across instrumented nodes, public-floor coverage by selected external-`G` quantile: the fraction with `F > 0`, `F / G` and `H / G` for `G > 0`, and the high-`G` share with `F = 0`, split by public or private selected bid. The rate should reduce security-relevant proposer windfalls while retaining enough protocol-visible bidding for the mechanism to remain effective. ## Backwards Compatibility This EIP changes execution consensus, consensus-layer state transition, networking, honest validator behavior, and fork choice. It requires a hard fork. This specification assumes activation with EIP-7732, when no live `BuilderPendingPayment` entries exist. A later activation requires a separate legacy-settlement transition. It changes the SSZ semantics and field name of `ExecutionPayloadBid.value` to `gross_value`. The field keeps its position and type, and the container adds the Gwei-denominated `priority_fee_burn_credit` commitment. It replaces the builder pending-payment object with a settlement object that adds `gross_value`, `burn_target`, `priority_fee_burn_credit`, and `is_payable`. It changes builder collateral accounting. It adds the universal priority-fee burn and the `priorityFeeValue` and `priorityFeeBurn` fields to a `VALID` payload-status response. It adds `BidFloorMessage`, `SignedBidFloorMessage`, `DOMAIN_BID_FLOOR`, the `bid_floor_message` gossip topic, and the `ExecutionPayloadBidsByRoot` request/response protocol. A pre-fork signed bid is not valid as a post-fork bid. Execution clients, consensus clients, validator clients, builders, relays, and APIs must use the new semantics after activation. The public bid path keeps the same trust model. Public bids still have `execution_payment == 0`, full collateral, and one scalar value for ordering. ## Test Cases Unless stated otherwise, these examples use a one-third rate, and monetary values use Gwei unless labeled Wei or ETH. ### Priority-fee burn and rounding The transaction priority-fee values in Wei are: ```text 120_000_000_999 60_000_000_500 # failed transaction 120_000_000_001 ``` Aggregate before applying the fraction: ```text T = 300_000_001_500 Wei U = 100_000_000_500 Wei R = 100 Gwei ``` The execution layer burns `100_000_000_500` Wei and credits `200_000_001_000` Wei to the fee recipient. The result includes the failed transaction. Repartitioning the same aggregate priority fees across transactions does not change `U`. The EIP-1559 base-fee burn is additional. ### Bid derivation | Rate | `G` | `E` | `A` | `P` | `V` | `C` | Result | | ---: | --: | --: | --: | --: | --: | --: | ----------------------------- | | 1/3 | 9 | 0 | 3 | 6 | 6 | 9 | valid public bid | | 1/3 | 9 | 2 | 3 | 6 | 4 | 7 | valid private bid | | 1/3 | 9 | 6 | 3 | 6 | 0 | 3 | valid private bid | | 1/3 | 9 | 7 | 3 | 6 | - | - | invalid because `E > P` | | 1/3 | 10 | 0 | 3 | 7 | 7 | 10 | valid; remainder stays in `P` | | 0 | 9 | 0 | 0 | 9 | 9 | 9 | burn and bid floor disabled | | 1 | 9 | 0 | 9 | 0 | 0 | 9 | full burn | The row with `V = 0` still accumulates attestation weight because `C > 0`. For the overflow vector, use these inputs: ```text rate = 2/3 G = 18446744073709551615 E = 0 ``` The expected values are: ```text A = 12297829382473034410 P = 6148914691236517205 V = 6148914691236517205 C = 18446744073709551615 ``` The implementation must obtain this result without fixed-width intermediate overflow. ### Auction-target credit For `G = 9 ETH` and `T = 0.3 ETH`: ```text A = 3.0 ETH U = 0.1 ETH R = 0.1 ETH D = 2.9 ETH total_mev_burn = 3.0 ETH ``` If `A = 3 Gwei` and `U = 4 Gwei`, then `R = 3 Gwei`, `D = 0`, and total MEV burn is `4 Gwei`. If `A = 3 Gwei` and `U = 1.5 Gwei`, then `R = 1 Gwei`, `D = 2 Gwei`, and total MEV burn is `3.5 Gwei`. The sub-Gwei burn remains destroyed even though it cannot credit the builder balance. ### Self-build For `BUILDER_INDEX_SELF_BUILD`, `G = 0`, `E = 0`, and `T = 3 Gwei`: ```text A = 0 V = 0 C = 0 U = 1 ``` No pending builder settlement is created. A self-build is invalid if `G != 0`, `E != 0`, or `R != 0`. ### Settlement lifecycle Start with `A = 3`, `V = 6`, stored `R = 1`, and `is_payable = False`. For `PAYABLE`, `mark_builder_settlement_payable` queues `V` once, sets `is_payable = True`, and keeps all three units of `A` reserved. A second call is invalid. If a canonical FULL payload has `U = 1 Gwei`, then `R = 1 Gwei`; consensus deducts `D = 2` and clears the settlement. If the canonical outcome is EMPTY, it uses `R = 0`, deducts `D = 3`, and clears the settlement. For `RELEASED`, consensus queues no withdrawal, deducts no burn, and clears the settlement. With `A = 0`, `V > 0`, and stored `R = 0`, `PAYABLE` queues `V` and clears immediately. With `A > 0` and stored `R = 0`, it deducts `A` and clears immediately. Only stored `R > 0` waits for FULL or EMPTY. If envelope validation returns `INVALID`, the envelope cannot create a FULL branch and cannot supply priority-fee credit. A later payable EMPTY outcome therefore deducts `D = A`; a released outcome deducts nothing. At an epoch rotation, every older-half settlement must become `PAYABLE` or `RELEASED` and then clear. An unresolved newer-half entry can shift into the older half once. A nonempty older entry after processing makes the epoch transition invalid. For stored `R > 0`, a node that lacks the canonical payload outcome cannot verify the transition and must not substitute zero credit for a FULL outcome. After rotation, every newer-half entry is empty. Processing a new bid against a nonempty destination entry is invalid and must not overwrite that entry. A builder with balance 12 and pending liability 9 cannot make another deduction that leaves balance 8. The remaining balance must cover all pending liability. ### PTC floor and expiry For `BID_FLOOR_THRESHOLD = 10`, use these distinct-member maxima in ETH: ```text 10.0, 10.0, 9.9, 9.9, 9.8, 9.8, 9.7, 9.7, 9.5, 9.4, 8.9, 8.8, 8.7, 8.6, 8.5, 8.0 ``` The floor is `F = 9.4 ETH`. The reports can reference different signed bid roots. With fewer than ten compatible positive reports, `F = 0`. If the burn numerator is zero, `F = 0` regardless of reports. A positive report received without its signed bid does not initially contribute. If `ExecutionPayloadBidsByRoot` returns the matching bid and its objective checks succeed before the target-slot snapshot, the report contributes even if a local first-seen gossip rule would have ignored that bid. Evidence obtained after the snapshot does not revise `F`. Given `F = 9 ETH` and a hypothetical 500 basis-point haircut, `H = 8.55 ETH`. An external block with `G = 8.5 ETH` and its descendants lose local head eligibility through `target_slot + 1`. An honest proposer applying the filter in that next slot builds a sibling on the lower block's parent. An external block with `G = 8.55 ETH` and any self-build remain eligible under this EIP. If every observed external bid for `target_slot + 1` references the filtered subtree, none is eligible for the reorg context and compatible reports establish `F = H = 0`. An honest proposer that produces a block self-builds unless it receives a compatible external bid. A report received after the target-slot snapshot does not change `F`. At `target_slot + 2`, this EIP's filter expires. Both branches are again considered under ordinary fork choice. The lower block's state transition was never invalid. ## Reference Implementation A complete implementation requires changes to the execution specification, Engine API, Gloas beacon-chain specification, P2P specification, fork choice, and honest validator guide. The Specification section is normative. The remaining mainnet configuration items are `BID_FLOOR_DUE_BPS`, `BID_FLOOR_THRESHOLD`, and `BID_FLOOR_HAIRCUT_BPS`. Their values require propagation measurement and adversarial network analysis. ## Security Considerations ### Limits of the competitive floor Without the floor, an external builder and proposer can declare a low `G` and move compensation to a side channel. With the floor, an external bid below `H` must overcome a competing branch built and supported during the next slot by validators that received enough reports. This mitigates trivial bilateral under-declaration beyond the configured haircut in the normal external ePBS path when public bids reach the threshold. The mechanism is not coalition-proof. An adversary can suppress bids or reports, possess value that competitors cannot price, receive value after the deadline, or leave the external-builder path. Ethereum can burn only visible priority fees, signed bid value, and builder balance. ### PTC divergence and griefing An adversary can delay reports or bid evidence, eclipse participants, or deny service to the new gossip and request/response protocols. Missing verified reports lower `F`. Conversely, a malicious builder can deliver one valid high bid to at least `q` honest PTC members without making it timely retrievable by every validator. Their honest reports can then raise `F` only where the evidence arrives before the snapshot. Malicious PTC members can create the same disagreement. Bid-by-root retrieval reduces this selective-evidence risk but cannot eliminate deadline, eclipse, or targeted-delivery effects. Because the filter persists into the next slot, disagreement in `H` can cause honest proposers to create competing branches. The deadline, threshold, and haircut therefore jointly determine avoidance resistance and short-reorg risk. A floor-setting bid is a signed, fully collateralized public offer that the eligible proposer can select, not a fabricated oracle value. An artificially high bid therefore requires collateral for `G` and exposes the builder to that consensus liability under the EIP-7732 settlement conditions. Evidence retrieval makes the offer more widely actionable but does not eliminate selective-delivery griefing, especially near the deadline. The frozen snapshot and expiry rule define recovery. Reports received after the target-slot boundary have no effect. During `target_slot + 1`, validators run head selection without the filtered subtree and support the resulting branch; in the simple case this creates a sibling on the below-floor block's parent. At `target_slot + 2`, both branches return to ordinary fork choice. The rule directly affects at most two slots; it does not bound indirect economic loss or later LMD-GHOST effects. Enforcement is probabilistic and does not guarantee orphaning. If `B` is the avoided burn, `L` is the coalition economic surplus lost on orphaning, and `p` is the orphaning probability, the simplified deterrence condition is `p * L > B`. This becomes approximately `p > t` only when `B` is approximately `t * L` and orphaning loses all `L`. Control or loss of the next proposal can prevent creation of the competing branch, so effectiveness depends on colluding stake, report propagation, and ordinary fork choice. Signed conflicting reports make equivocation attributable. However, the selective-delivery attack can use one valid message from each participating member and requires no equivocation. An equivocation penalty would not prevent the main attack, so this EIP does not add a new slashing system. Clients should retain conflicting messages and expose report-receipt metrics. The deadline, threshold, and haircut require propagation measurement and adversarial network analysis before mainnet activation. These values must account for targeted behavior and ordinary network variance. Simulations must estimate the probability that a below-floor block eventually becomes canonical as a function of colluding stake, report and evidence propagation, threshold, and haircut. ### Unpriced and self-build value The floor cannot price late, exclusive, or private value that public builders did not bid for. Such value can move through undeclared transfers or integrated accounting. The universal priority-fee burn still applies, but value outside `T` and `G` is not burned. Once the floor constrains ordinary external under-declaration, proposer-authorized outsourced self-build is the primary remaining bilateral avoidance path. Holding the payload and `U` fixed, this avoids `D * 10**9` Wei, where `D = A - R` when `R < A`. Avoidance is attractive when that saving exceeds expected disclosure, counterparty, signing, reputation, and infrastructure costs. The protocol does not assume those costs always exceed the avoided top-up; exceptional-MEV slots and vertically integrated operators are the most attractive cases. Every executed self-build still pays `U`. ### Trusted payments, capital, and residual jackpots `execution_payment` remains trusted. A proposer that accepts `E > 0` accepts default risk. Public bids avoid this risk because `E == 0`. Consensus does not define a global credit model for ranking private bids. The builder reserves all of `A + V` even if `R` later reduces `D`. Exceptional slots, concurrent liabilities, and unresolved targets can favor builders with more capital. A one-third rate still leaves about two thirds of a fully trustless gross bid as proposer compensation. Remaining tail payments can motivate reorganizations, key theft, denial of service, or operator misconduct. Evaluation must track tail payments, self-build concentration, and builder capital concentration. ### Payload withholding and settlement safety This EIP does not solve EIP-7732 payload withholding. A payable no-payload outcome burns all of `A` because no `R` exists to credit. The `PAYABLE` or `RELEASED` decision must remain atomic for `A` and `V`. For stored `R > 0`, burn realization must use the same settlement and canonical payload outcome. An implementation must not: - queue `V` twice; - charge both `A` and `D`; - use `R` from a noncanonical or execution-invalid payload; - substitute zero for nonzero stored `R` merely because a local node lacks a payload; - release `A` after a payable no-payload outcome; - discard a payable unresolved settlement; or - let a builder exit while a related liability remains. Tests must cover reorganization, proposer slashing, payload absence, quorum payment, zero-credit settlement, delayed local processing, and settlement rotation. ### Supply and cross-layer agreement The execution layer reports and verifies `T` and `U` in Wei and destroys exactly `U` Wei by withholding priority-fee credit. The consensus layer derives `R = min(A, floor(U / 10**9))` from the verified signed commitment and destroys `D` Gwei by reducing builder balance without a withdrawal. Each amount must be counted once, and neither is sent to a burn address. All calculations use integer floor division. Clients must aggregate transaction priority fees in Wei before calculating `U`, convert only the builder credit `R` to Gwei, and avoid floating-point arithmetic and fixed-width intermediate overflow. A disagreement in `T`, `U`, or `R` changes builder balances or supply. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).