Part 2: Technical Overview

Deposits and Withdrawals

Overview

As a proof of stake protocol, Ethereum depends on stakers locking up capital within the protocol (deposits), and, eventually, receiving that capital back along with the rewards they have earned (withdrawals).

The form of capital that is staked is Ether (ETH), Ethereum's native currency. Ether on the consensus layer exists separately, and is accounted for separately, from Ether in normal Ethereum accounts and contracts. Ether on the consensus layer is in the form of balances of validator accounts. Validator accounts are extremely limited: they have a balance that increases due to deposits and rewards, and decreases due to withdrawals and penalties. You cannot make transfers between validator accounts or run any kind of transaction on them. Validator account balances are tracked as part of the beacon state, and do not form part of the normal Ethereum execution state. Note that execution balances are denominated in Wei ($10^{-18}$ ETH), whereas validator balances are denominated in Gwei ($10^{-9}$ ETH).

The basic architecture (that we'll cover thoroughly in the following sections) is that stakers make a deposit by sending an Ethereum transaction to the deposit contract, which is a standard Ethereum smart contract on the execution layer. It is important that staking is completely permissionless. Anybody may stake and gain the right to run a validator by sending 32 ETH to the deposit contract in a normal Ethereum transaction.

On receiving a deposit, the deposit contract emits a receipt. After a while, this receipt is picked up by the consensus layer, and a validator account is created and credited with the deposit amount. The staker can then run an Ethereum validator.

All being well, the validator will earn rewards. These will be periodically, and automatically, debited from the validator's balance and credited to the Eth1 account specified in the withdrawal credentials, the withdrawal address.

When the validator finally signals that it wants to exit the protocol (or is slashed), then any remaining balance is debited from the validator account and credited to the withdrawal address.

The whole flow is illustrated in the following diagram.

An amusing observation from the diagram is that there is no minus sign attached to the deposit contract: the deposit contract's balance is "up-only" as validators exit and restake. When a validator exits and restakes, the deposit contract's balance increases by 32 ETH while everything else is essentially unchanged. If this were to happen 3.2 million times (not inconceivable with well over half a million validators currently staked) then the balance of the deposit contract would exceed the total amount of Ether that's ever circulated, roughly 120 million ETH. This is of no importance, except to underline that the balance of the deposit contract should be considered burned, and counted as zero when totting up Ethereum's total supply.¹

More importantly, there are two types of deposit and two types of withdrawals. A validator is created when its first deposit is processed by the consensus layer (which may or may not be enough to activate it). Any subsequent deposits for the same validator are top-up deposits and have a slightly different workflow with less validation.

As for withdrawals, partial withdrawals are regular transfers of anything above 32 ETH from the validator's balance to the execution layer. A full withdrawal occurs when the validator has exited the protocol and has become "withdrawable", at which point the whole of the validator's remaining balance will be transferred. Both types of withdrawal occur automatically and periodically.

In the following sections, we will look first at the mechanics of making a deposit, followed by an in-depth study of the deposit contract. We will close by looking at the consensus layer mechanics for processing deposits and withdrawals.

A constant theme of the next sections is that much of the complexity in the current deposit and withdrawal processes has arisen due to Ethereum's peculiar history. The deposit contract's incremental Merkle tree, the Eth1Data voting period, the Eth1 follow distance - all these are due to the execution layer having remained on proof of work while we built a separate beacon chain on proof of stake. The whole BLS withdrawal credentials saga arose from our uncertainty about the roadmap at the time.

Another theme is that, post-Merge, we have the opportunity to clean some of this up. EIP-6110 is a proposal for significantly streamlining deposit handling. Nevertheless, some of the complexity will be with us forever.