> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beaconcha.in/llms.txt
> Use this file to discover all available pages before exploring further.

# System deposits and withdrawals

> You may see deposits and withdrawals on your validator that you never initiated. These are protocol-generated balance movements. This page explains what they are, how the protocol creates them, how to recognize them, and why they don't affect your rewards or your net balance.

## TL;DR

* After the **Pectra (Electra)** upgrade, the protocol can move a validator's balance **internally**. These movements are recorded as deposits and withdrawals even though **you never initiated them** and **no ETH left or entered your wallet**.
* They usually occur in a **pair**: the protocol removes the balance above 32 ETH from your validator (shown as a **withdrawal**) and re-queues that same amount as a **deposit** back into the same validator.
* They are **net-zero** for you and **do not affect your rewards or APR**. Don't treat them as real payouts or income (for example, for tax accounting).
* You'll see them in **two situations**: a **one-time bulk batch at the Pectra fork**, and then **individually** afterwards whenever a validator **switches to compounding**.
* How to spot them:
  * Both system **deposits** and **withdrawals** are flagged with **`type: system`** in the API.
  * System **withdrawals** also have an **empty recipient** (the explorer shows `SYSTEM`); system **deposits** also carry a **placeholder signature** instead of a real one.

## Why these appear

Pectra introduced compounding (`0x02`) withdrawal credentials and a deposit queue ([EIP-7251](https://eips.ethereum.org/EIPS/eip-7251)). The core operation is the consensus-spec `queue_excess_active_balance` function: for a validator whose balance is above 32 ETH (`MIN_ACTIVATION_BALANCE`), the protocol resets the active balance to 32 ETH and appends a pending deposit for the excess. beaconcha.in shows **both halves** of this internal move — the balance leaving as a **withdrawal**, and the re-queued amount as a **deposit** — even though no execution-layer transaction happened and no funds left your control. The amount is added back afterwards: it is an internal re-deposit of your own balance.

This happens in **two situations** — one historical, one ongoing:

### 1. The one-time Pectra activation — `upgrade_to_electra`

At the transition into Pectra (epoch 364032), the consensus-layer [`upgrade_to_electra`](https://github.com/ethereum/consensus-specs/blob/master/specs/electra/fork.md) routine applied this across the **entire validator set in a single state transition**, producing two kinds of protocol-generated entries:

* **Excess re-queue for early compounding adopters.** Every validator that already carried `0x02` credentials at the fork had its balance above 32 ETH re-queued via `queue_excess_active_balance` — a **system withdrawal** (the balance leaving) paired with a **system deposit** (the same amount queued back).
* **Activation-queue migration.** Pectra replaced the old eth1 activation queue with the deposit queue, so every validator still waiting to activate (`activation_epoch == FAR_FUTURE_EPOCH`) had its staked balance moved into the new queue — recorded as a **system deposit** for its full balance.

Because it all happened at once, this shows up as a **large one-time batch** dated to the activation slot, [slot 11649023](https://beaconcha.in/slot/11649023#withdrawals), whose Withdrawals tab is dominated by system withdrawals. It is historical and **does not repeat**.

### 2. When a validator switches to compounding — `switch_to_compounding_validator`

Going forward, the **same excess re-queue happens individually** whenever a validator switches to compounding, by submitting an execution-layer consolidation request to itself. `switch_to_compounding_validator` changes the credentials to `0x02` and then calls `queue_excess_active_balance`, so any balance above 32 ETH is moved into the deposit queue: again a **system withdrawal** paired with a **system deposit** for that validator.

## Identifying them in the API

In the API, system deposits and withdrawals are both flagged with **`type: system`** — the category for entries the protocol generates automatically, rather than ones a user initiated. Beyond that flag, deposits and withdrawals each carry an additional distinguishing field.

**Deposits**

* `type: system` — as opposed to `deposit` (a new validator) or `top_up` (funds added to an existing one).
* The `signature` is a **placeholder**: the "point at infinity" value, `0xc0` followed by all zero bytes, never a real 96-byte BLS signature. The protocol uses this because it generated the deposit itself.

**Withdrawals**

* `type: system` — as opposed to `manual`, `partial_sweep`, or `full_exit_sweep` for real withdrawals.
* The `recipient` field is **empty** — there is no execution-layer payout address, because this is the internal balance reduction that pairs with a system deposit.

The consensus spec sets these markers deliberately; from `queue_excess_active_balance`:

> Use `bls.G2_POINT_AT_INFINITY` as a signature field placeholder and `GENESIS_SLOT` to distinguish from a pending deposit request.

## Not the same as a partial withdrawal or a consolidation

A normal **partial withdrawal** skims the balance above your validator's *maximum effective balance* — 32 ETH for `0x01`, or **2048 ETH** for `0x02` compounding validators — and pays it **to your withdrawal address** (a real recipient). See [How withdrawals work](/faqs/how-withdrawals-work).

A **system** deposit/withdrawal is different: it's the protocol moving balance above **32 ETH** into the deposit queue for compounding validators — in bulk at the Pectra fork, and individually as validators switch to compounding. It stays inside your validator and has no execution-layer recipient.

A **consolidation** (moving one validator's balance into another) is tracked separately — as a *consolidation*, not as a deposit or withdrawal. The protocol transfers the source's balance to the target directly, and the source validator exits with any remaining balance paid out by a **normal sweep to its withdrawal address**. So an ordinary consolidation produces **neither** a system deposit **nor** a system withdrawal.

## What this means for you

* **Net balance:** unchanged. The balance stays inside your validator — a withdrawal and its matching deposit cancel out.
* **Rewards / APR:** unaffected. These movements are excluded from reward calculations.
* **Accounting / tax:** these are **not** real withdrawals or deposits of your funds — they are the protocol re-depositing your own balance — so they should not be counted as income or payouts.
* **On-chain vs. explorer counts:** because a system withdrawal isn't an execution-layer withdrawal object, a block's on-chain withdrawal count can be lower than the number of withdrawal entries beaconcha.in shows for that slot. This is most visible at the Pectra activation slot, but applies to any slot containing a system withdrawal.

## Where to see them on beaconcha.in

* **Validator page → Deposits / Withdrawals tabs** — system entries appear alongside your normal ones; a system withdrawal shows `SYSTEM` as its recipient.
* **Slot page** — any slot that processed system entries lists them. The Pectra activation slot, [slot 11649023](https://beaconcha.in/slot/11649023#withdrawals), shows the large one-time batch; individual system deposits and withdrawals also appear on ordinary slots as validators switch to compounding.

## References

* [EIP-7251: Increase the MAX\_EFFECTIVE\_BALANCE](https://eips.ethereum.org/EIPS/eip-7251)
* [Electra consensus specs — beacon chain](https://github.com/ethereum/consensus-specs/blob/master/specs/electra/beacon-chain.md) (`queue_excess_active_balance`, `switch_to_compounding_validator`, `apply_pending_deposit`)
* [Electra consensus specs — fork](https://github.com/ethereum/consensus-specs/blob/master/specs/electra/fork.md) (`upgrade_to_electra`)