**Date:** 2026 / 04 / 30
**Hosts:** Marius, Maria
**Time:** 11:00

**Context:** Breakout session to resolve the approach for state gas accounting in EIP-8037, following disagreements between clients in BAL devnet-4 and devnet-5. The team needed to decide between two implementation approaches and plan the next devnet release ahead of Glamsterdam testing.

## Core Decision: Opcode Level vs Call Frame Level Accounting

### Background
- **devnet-4** used **opcode level accounting** (charge state gas at each opcode)
- **devnet-5** used **call frame level accounting** (defer accounting to end of frame)
- The shift to frame level was originally motivated by a belief it would be simpler to implement

### Discussion Points

**Arguments for Opcode Level:**
- User receives gas refunds sooner (at point of operation)
- Plays nicer with BAL (Block Access List) - no entries appear for state changes that didn't have sufficient gas
- More efficient - charges happen on the spot instead of additional checks during calls
- Edge cases are easier to trigger and debug (no need to wrap them in nested calls)
- More localized spec change
- Frame level can be "tricked" by sub-calls returning back, effectively forcing opcode-level behavior anyway

**Arguments for Call Frame Level:**
- Besu's implementation found it simpler (using boolean flags tracking pre-transaction, pre-SSTORE, and post-SSTORE values)
- More polished current implementation in devnet-5

**Key Insight (Pavel):** The team had misidentified the source of complexity on Monday. The real complexity comes from the **reservoir model** introducing edge cases, not from the accounting computation itself. The reservoir is necessary to avoid requiring a new transaction type.

### Decision
**Revert to opcode level accounting.** Broad consensus achieved, with no strong objections (Nethermind/Ivan's only concern was being close to passing tests).

## Release Planning

### BAL devnet-6
- New release will be **devnet-6** = devnet-4 spec + bug fixes from devnet-5 work
- Dynamic pricing **removed** (consistent with devnets 3, 5, and 6; only devnet-4 had it)
- Spec release target: **end of day Thursday**
- Test fixes and stability target: **end of day Friday**

### Workflow
1. Clients immediately revert to devnet-4 branches, remove dynamic pricing
2. Run local Kurtosis pairwise between clients to surface bugs early
3. Friday morning: review test failures and fix
4. Friday standup or 10am: aim for resolution

### Glamsterdam Coordination
- Glamsterdam devnet-1 is dead
- Recommend Barnabas use **BAL devnet-3** (most stable) with EIP-7702 cherry-picked on top (a few minutes of work)
- Plan: **Glamsterdam devnet-2** by Friday evening, combining BAL-devnet-6 + ePBS devnet-5
- Snowball 4 tests can be used as interim until new tests are released (with bug-risk caveat)

## Edge Cases Discussed

### 1. EIP-7702 Authorization Refunds
**Scenario:** Setting a delegation then unsetting it within the same transaction (X→0 for code).

**Decision for devnet-6:** Charge per auth (don't refund), even for redundant/duplicate auths. This is consistent with devnet-4 behavior. Group acknowledged this gives up some consistency but agreed to revisit later. Edge case: multiple authorizations in same transaction = charged multiple times.

**Note:** Code goes to empty code hash (not zero), so technically X→X, not X→0.

### 2. Exceptional Halt Gas Accounting (Mario's Edge Case)

**Setup:** Transaction starts with 10 regular / 5 state. SSTORE costs 1 regular + 6 state.

**Problem:** On exceptional halt, two possible accounting outcomes:
- **Option A (0-6):** Zero out gas left, refund state cost back to reservoir
- **Option B (0-5):** Look at what was available at start of frame, zero that out, don't change reservoir

**Mario's Argument:** Option B is correct because otherwise the cost depends on *where* the halt occurs (inner vs outer frame), creating inconsistency between halts during compute-only operations vs state operations. The end result of any halt should always reset to "reservoir as it was available, gas left = 0."

**Implication (Daniel):** No need to track which counter (reservoir vs regular) the state gas came from - just snapshot initial gas budget at each frame.

**Counter-proposal (Pavel/Erigon approach):** Track precisely where state gas was borrowed from, so refunds always go back to the correct counter. This would collapse to a single consistent answer and avoid this edge case entirely. Mario previously didn't favor this but is open to it now.

### 3. Spilling Between Counters
**Concern (Guillem):** Current model can spill from state reservoir into regular gas, allowing user to "execute more" than expected before discovering state failure. Suggested allowing negative state and splitting accounting.

**Counter:** This is essentially equivalent to current accounting - just different presentation. The GAS opcode would need to return the lower bound to prevent attack vectors.

**Critical Concern:** Direction matters - going from state reservoir into compute would be an attack vector (allowing computation paid by state budget). Current rules prevent this; alternative proposals must also prevent it.

### 4. Bundle Attack Vector
Acknowledged: in bundles, an attacker could move gas from regular→state to cause other bundles to revert from insufficient gas. Considered low priority.

### 5. Alternative Reservoir Sizing (Gary's Idea)
**Proposal:** With 70M gas limit, instead of splitting, cap regular gas at 60M but make reservoir full 70M.

**Issue (recalled):** This was the original EIP-7783 design. Was abandoned because users can't see how much reservoir they actually have - they fail without knowing why.

## Action Items

| Owner | Action |
|-------|--------|
| Mario | Rewrite EIP back to opcode level accounting |
| Spec team | Release devnet-6 by EOD Thursday |
| All clients | Revert to devnet-4 branches, remove dynamic pricing, start local Kurtosis with paired client |
| Stefan | Coordinate with Barnabas on Glamsterdam (use BAL-devnet-3 + cherry-pick 7702) |
| Mario | Investigate halt edge case downstairs (verify the previously found counter-example) |
| Test team | Begin test work now; client implementation aligned for Friday |
| Future | Revisit double-auth refund semantics post-devnet |

## Open Questions
- Halt accounting: 8-5 vs 7-6 outcome (current is 7-6) - dependent on whether refunds-to-borrow-source approach is adopted
- Whether to track state gas borrowing source explicitly (Erigon-style) to eliminate halt edge case entirely
- DDoS implications of giving execution gas back vs not - needs verification against original counter-example