ethereum · eth-bot · Jun 10, 2026 · May 21, 2026 · May 22, 2026 · May 22, 2026
@@ -156,14 +156,28 @@ The same rules apply when the top-level call frame reverts or halts. Here, `stat
 
 ##### Gas accounting for [EIP-7702](./eip-7702.md) authorizations
 
-While computing the intrinsic gas cost, [EIP-7702](./eip-7702.md) authorizations are charged the worst-case cost for each delegation. Then, during authorization processing, the following gas adjustments are made for each processed authorization:
+Intrinsic gas charges the worst-case state-gas cost (`(STATE_BYTES_PER_NEW_ACCOUNT + STATE_BYTES_PER_AUTH_BASE) × CPSB`) for each authorization. However, an authority's account leaf and its 23 byte delegation indicator can only be written once per transaction, even if the same authority appears in multiple authorizations. Therefore, per authorization adjustments are applied while processing the authorization list.
-Intrinsic gas charges the worst-case state-gas cost (`(STATE_BYTES_PER_NEW_ACCOUNT + STATE_BYTES_PER_AUTH_BASE) × CPSB`) for each authorization. However, an authority's account leaf and its 23 byte delegation indicator can only be written once per transaction, even if the same authority appears in multiple authorizations. Therefore, per authorization adjustments are applied while processing the authorization list.
+Intrinsic gas charges the worst-case gas cost (`(STATE_BYTES_PER_NEW_ACCOUNT + STATE_BYTES_PER_AUTH_BASE) × CPSB`) for each authorization. However, an authority's account leaf and its 23 byte delegation indicator can only be written once per transaction, even if the same authority appears in multiple authorizations. Therefore, per authorization adjustments are applied while processing the authorization list.
-Intrinsic gas charges the worst-case state-gas cost (`(STATE_BYTES_PER_NEW_ACCOUNT + STATE_BYTES_PER_AUTH_BASE) × CPSB`) for each authorization. However, an authority's account leaf and its 23 byte delegation indicator can only be written once per transaction, even if the same authority appears in multiple authorizations. Therefore, per authorization adjustments are applied while processing the authorization list.
+Intrinsic gas charges the worst-case gas cost (`(STATE_BYTES_PER_NEW_ACCOUNT + STATE_BYTES_PER_AUTH_BASE) × CPSB`) for each authorization. However, an authority's account leaf and its 23 byte delegation indicator can only be written once per transaction, even if the same authority appears in multiple authorizations. Therefore, per authorization adjustments are applied while processing the authorization list.
 
-- If the `authority`'s account leaf already exists (i.e., non-zero nonce, non-zero balance, or non-empty code), the `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` portion is refilled directly to `state_gas_reservoir` and the `ACCOUNT_WRITE` portion is refunded to the refund counter.
-- If the `authority`'s `codeHash` is not `emptyHash` (i.e., a prior authorization indicator already occupies the 23 bytes) or `authorization.address` is `ZERO` (the authorization is clearing the delegation), the `STATE_BYTES_PER_AUTH_BASE × CPSB` portion is also refilled directly to `state_gas_reservoir`.
+The adjustments enforce a single invariant: the `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` account-leaf portion is charged at most once per authority and only when the account did not exist before the transaction, and the `STATE_BYTES_PER_AUTH_BASE × CPSB` delegation-indicator portion is charged at most once per authority and only when the authority ends the transaction delegated having started it undelegated.
+Processing reads the account state at two points:
 
-`execution_state_gas_used` decreases by the corresponding amount of state-gas refills.
+- **pre-transaction state**: the account state before transaction execution.
+- **current state**: the account state while processing authorizations, updated after each authorization.
 
-Because `execution_state_gas_used` is initialized to `0`, this refill may bring it below zero before any execution-time charges. Implementations may equivalently track the refill separately and subtract it from `tx_state_gas` when accumulating `block_state_gas_used`.
+For each authorization, let `cur_delegated` be `true` when the authority has a non-empty delegation indicator in the **current state**, and `pre_delegated` be `true` when it had one in the **pre-transaction state**. 
+
+Authorization processing follows 3 gas accounting rules:
+
+**1. Invalid authorizations.** Invalid authorizations are skipped without per-auth processing. Their entire intrinsic state-gas portion, `(STATE_BYTES_PER_NEW_ACCOUNT + STATE_BYTES_PER_AUTH_BASE) × CPSB`, is refilled to `state_gas_reservoir` and `ACCOUNT_WRITE` is refunded to the refund counter.
+
+**2. Account-leaf refill.** If the authority's account leaf already exists in the **current state** (non-zero nonce, non-zero balance, or non-empty code), refill `STATE_BYTES_PER_NEW_ACCOUNT × CPSB` to `state_gas_reservoir` and refund `ACCOUNT_WRITE` to the refund counter.
+
+**3. Delegation-indicator refill.**
+
+- If `authorization.address` is not `ZERO` (setting a delegation), refill `STATE_BYTES_PER_AUTH_BASE × CPSB` to `state_gas_reservoir` when `cur_delegated` or `pre_delegated` is `true`. In that case the 23-byte indicator slot is already occupied, so this authorization overwrites it without writing new bytes. Otherwise this authorization performs the net-new creation and its intrinsic charge stands.
+- If `authorization.address` is `ZERO` (clearing the delegation), refill `STATE_BYTES_PER_AUTH_BASE × CPSB` to `state_gas_reservoir`, since the clear writes no indicator. Additionally, when `cur_delegated` is `true` and `pre_delegated` is `false`, refill another `STATE_BYTES_PER_AUTH_BASE × CPSB`: the delegation being cleared was created by an earlier authorization in this same transaction, so the chain writes zero net delegation bytes and the earlier creation charge is no longer justified. This covers patterns such as `0->a->0`, where the creation by an earlier authorization is undone by a later clearing one in the same list.
+
+`execution_state_gas_used` decreases by the corresponding amount of state-gas refills. Because `execution_state_gas_used` is initialized to `0`, this refill may bring it below zero before any execution-time charges. Implementations may equivalently track the refill separately and subtract it from `tx_state_gas` when accumulating `block_state_gas_used`.
 
 #### Pre-state and post-state gas validation