# Engine API: Shanghai checks

Source: https://github.com/ethereum/execution-apis/blob/main/src/engine/shanghai.md

* [x] Paris payloads MUST be processed by `newPayloadV2` and `forkchoiceUpdatedV2`
* [x] case with `forkchoiceUpdatedV2` and `payloadAttributes == null`, and Paris block data
* [x] case with `forkchoiceUpdatedV2` and `payloadAttributes == null`, and Shanghai block data
* [x] case with `forkchoiceUpdatedV2` and `payloadAttributes = {data of the first Capella slot}`
* etc
* [x] EL MUST return `-32602: Invalid params` in the following cases:
* [x] `newPayloadV2`
* `ExecutionPayloadV1` passed with `timestamp >= SHANGHAI_TIMESTAMP`
* `ExecutionPayloadV2` passed with `timestamp < SHANGHAI_TIMESTAMP`
* [x] `forkchoiceUpdatedV2`
* `PayloadAttributesV1` passed with `timestamp >= SHANGHAI_TIMESTAMP`
* `PayloadAttributesV2` passed with `timestamp < SHANGHAI_TIMESTAMP`
* Note: the diff between these struct versions is basically `withdrawals` field which is `null` for `V1` and not null for `V2`
* [x] EL MUST return `INVALID` in response to `newPayloadV2` in all cases where `V1` call responded with `INVALID_BLOCK_HASH`, i.e. `INVALID_BLOCK_HASH` is supplanted by `INVALID` and deprecated
* [x] Withdrawals logic is enabled since Shanghai, i.e. `payload.withdrawals` are applied to the state
* [x] `getPayloadV2` returns the same list of withdrawals as were passed via `PayloadAttributesV2` in the `forkchoiceUpdatedV2` method call
* [x] `blockValue` in response to `getPayloadV2` call is greater than zero if payload has transactions with priority fees
* [x] `getPayloadV2` returns `ExecutionPayloadV1` pre-Shanghai, and `ExecutionPayloadV2` after Shanghai
* [x] CL MUST send `WithdrawalV1.amount` field value in `gwei`, encoded big-endian
* [x] `getPayloadBodiesByHashV1`
* [x] normal case when all hashes are responded with bodies, the order and content are correct
* [x] request with a mix of existing and random block hashes
* `null` values should be in place of random hashes
* [x] request with all random hashes
* a response full of `null` values should be returned
* [x] work with not yet finalized chain as some clients may always return `null` in the response if hashes are from finalized part of the chain
* [x] `withdrawals == null` for pre-Shanghai block bodies
* [x] check that 32 block hashes in request does work
* [x] `getPayloadBodiesByRangeV1`
* [x] normal case when the whole range is covered by the response, the order and content are correct
* the response contains bodies of consecutive blocks, with the first block having a `start` number
* [x] check the case where there is a block at the same height as the head of canonical chain but it is not canonical, only canonical blocks must be returned
* the edge case when non-canonical block number is the highest block number
* [x] check that 32 blocks as count works
* [x] `withdrawals == null` for pre-Shanghai block bodies
* [x] check the case when requested range goes beyond the head of canonical chain
* the response must be trimmed, i.e. must have no trailing `null` values
* [x] the edge case with entire range beyond the head of canonical chain
* the response must equal to `[]`
* [x] check that `count < 1` and `start < 1` are responded with `Invalid params` error
* [x] `exchangeCapabilities` must return the following list: `newPayloadV1`, `newPayloadV2`, `getPayloadV1`, `getPayloadV2`, `exchangeTransitionConfigurationV1`, `forkchoiceUpatedV1`, `forkchoiceUpatedV2`
* note that the order of the list is undefined