---
eip: 4863
title: Beacon chain push withdrawals
description: Support validator withdrawals from the beacon chain to the EVM via a new "push-style" transaction type.
author: Alex Stokes (@ralexstokes), Danny Ryan (@djrtwo)
discussions-to: https://ethereum-magicians.org/t/eip-4863-beacon-chain-push-withdrawals/8465
status: Stagnant
type: Standards Track
category: Core
created: 2022-02-28
---

## Abstract

Introduce a new [EIP-2718 transaction type](./eip-2718.md) to support validator withdrawals that are "pushed" from the beacon chain to the EVM.

Add block validations to ensure the withdrawal transactions are sound with respect to withdrawal processing on the beacon chain.

## Motivation

This EIP provides a way for validator withdrawals made on the beacon chain to enter into the EVM.
The architecture is "push"-based, rather than "pull"-based, where withdrawals are required to be processed in the execution block as soon as they are dequeued from the beacon chain.

This approach is more involved than "pull"-based alternatives (e.g. [EIP-4788](./eip-4788.md) + user-space withdrawal contract) with respect to the core protocol (by providing a new transaction type with special semantics) but does provide tighter integration of a critical feature into the protocol itself.

## Specification

| constants                     | value                                          | units
|---                            |---                                             |---
| `FORK_TIMESTAMP`              | TBD                                            |
| `WITHDRAWAL_TX_TYPE`          | `0x3`                                          | byte

Beginning with the execution timestamp `FORK_TIMESTAMP`, execution clients **MUST** introduce the following extensions to transaction processing and block validation:

### New transaction type

Define a new [EIP-2718](./eip-2718.md) transaction type with `TransactionType` `WITHDRAWAL_TX_TYPE`.

The `TransactionPayload` is an RLP-encoded list `RLP([index, address, amount])` where the `index` is a 64-bit value uniquely labeling a specific withdrawal, the `address` refers to an execution layer account and the `amount` refers to an ether value given in units of wei.

These values are provided by the consensus layer.

### Block validity

If a block contains *any* transactions with `WITHDRAWAL_TX_TYPE` type, they **MUST** come after **ALL** other transactions in the block.

If the execution client receives a block where this is not the case, it **MUST** consider the block invalid.

### Transaction processing

When processing a transaction with `WITHDRAWAL_TX_TYPE` type, the implementation should increase the balance of the `address` specified by
the `WithdrawalTransaction` by the `amount` of wei specified.

This balance change is unconditional and **MUST** not fail.

This transaction type has no associated gas costs.

TODO: add logs?

## Rationale

### Push vs pull approach

This push approach gives validators a small subsidy with respect to processing, in lieu of needing to buy gas via normal EVM processing that would be required for a pull-based approach.

This style also happens automatically when the requisite conditions are met on the beacon chain which is nicer UX for validators.

### Why a new transaction type?

This EIP suggests a new transaction type as it has special semantics different from other existing types of EVM transactions.

An entirely new transaction type firewalls off generic EVM execution from this type of processing to simplify testing and security review of withdrawals.

### Why no (gas) costs for new transaction type?

The maximum number of this transaction type that can reach the execution layer at a given time is bounded (enforced by the consensus layer) and this limit is kept small so that
any execution layer operational costs are negligible in the context of the broader block execution.

### Why only balance updates? No general EVM execution?

More general processing introduces the risk of failures, which complicates accounting on the beacon chain.

This EIP suggests a route for withdrawals that provides most of the benefits for a minimum of the (complexity) cost.

### Why new block validations?

The beacon chain must be able to efficiently validate that the withdrawal transactions in a given execution block are
the ones expected based on its own internal scheduling logic to maintain the soundness of the withdrawal mechanism.

By requiring all withdrawal transactions to be at the back of every block where they are applicable, the algorithm to
check consistency becomes a straightforward linear walk from the start of the set until a known, bounded (small) number.

Having a simple ordering scheme like this facilitates optimizations clients may do with respect to withdrawal processing, which
would be hampered if withdrawal transactions could be placed in the block freely.

## Backwards Compatibility

No issues.

## Security Considerations

Consensus-layer validation of withdrawal transactions is critical to ensure that the proper amount of ETH is withdrawn back into the execution layer.
This consensus-layer to execution-layer ETH transfer does not have a current analog in the EVM and thus deserves very high security scrutiny.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
