# What will "withdrawal" change in e-v-m?

### Useful links
[Ethereum roadmap](https://notes.ethereum.org/@domothy/roadmap)
[Validator lifecycle](https://notes.ethereum.org/@hww/lifecycle)
[Slashing](https://hackmd.io/TrAFne7ZTTymE2OXH7_T7A)
[Withdrawals FAQ](https://notes.ethereum.org/@launchpad/withdrawals-faq)
[Withdrawals. Validator status flow](https://notes.ethereum.org/@launchpad/withdrawals-guide)
[Withdrawals metaspec](https://notes.ethereum.org/@ralexstokes/validator-withdrawals-meta-spec)
[Capella spec](https://github.com/ethereum/consensus-specs/tree/dev/specs/capella)
[Testing CL withdrawals with Docker](https://mirror.xyz/ladislaus.eth/nYZCmrO7ZndrP92kGyJG0-wzbnIsd3HwxsII-gT1zu8)
[Lido Withdrawals](https://hackmd.io/XGrVcicVTm-_IRcIUXPbnQ?view)

---

This is a very simplified blueprint that shows processing tasks in application


The new feature affects only two high-level tasks: 1st and 2nd, so I suggest you consider how they work now

## [Task 1] Process data from chain


### [Subtask 0] Prefetch blocks

Execution payload of blocks will be stored in internal cache

### [Subtask 1] Check duties and calculate rewards


1. New field `withdrawn` will be added to on-memory storage for validators epoch summary
2. Another one parallel task will be added to bunch of duty checking tasks. It will look like this loop

for (const block of get_epoch_blocks(processedEpoch)) {
    for (const withdrawal of block.withdrawals) {
        this.summary.epoch(processedEpoch).set(
            { 
                val_id: withdrawal.validator_index,
                val_balance_withdrawn: withdrawal.amount 
            }
        );
    }
}

### [Subtask 4] Write summary of validator checks to storage

Migration with new `val_balance_withdrawn` field will be added

## [Task 2] Publish metrics

Add labels `withdrawal_pending` (alias for states `active_exiting` and `withdrawal_possible`) and `withdrawal_done` for metrics below:
>[TODO]: Need to figure out when `exited_slashed` or `exited_unslashed` will be happened. Looks like it's a border status before withdrawal and they should be in `withdrawal_pending` alias. Do these statuses affect the calculation of base reward and attestation participation rate?
* `user_validators`
* `validators`

We should consider `val_balance_withdrawn` in query for each metric bellow.
Like add another one `JOIN` section with aggregate function `sum(val_balance_withdrawn)` on needed epoch range and subtract this value from balance in query for each old metric bellow:
* `validator_balances_delta` (means avg for operator validators)
* `operator_real_balance_delta`
* `validator_quantile_001_balances_delta`
* `validator_count_with_negative_balances_delta`
* `total_balance_24h_difference`
* `operator_balance_24h_difference`

New metrics:
* `operator_withdrawn` (sum of all lido validators withdrawals per epoch (with full and partial separation))
* `chain_withdrawn` (sum of all non-lido validators withdrawals per epoch (with full and partial separation))