fix(tests): correct mip4 transition and MIP-11 shim

[pdobacz]

Closes ENG-1131

Derive pre-transition precompile availability from transitions_from() so MONAD_NINEToMONAD_NEXT passes.

Greptile Summary

This PR fixes the MIP-4 fork-transition test so it passes for subsequent forks (e.g. MONAD_NINEToMONAD_NEXT) by deriving precompile_before from fork.transitions_from().precompiles() instead of hard-coding 0. It also wires in a MIP-11 shim that burns priority fees in the monad_next execution layer and adjusts the corresponding coinbase-reward assertion in the reserve-balance transfer test.

• test_fork_transition.py: Computes precompile_before at collection time via fork.transitions_from().precompiles(), making the 14_999 storage slot assertion correct for both MONAD_EIGHTToMONAD_NINE (0) and MONAD_NINEToMONAD_NEXT (1). Address.__eq__ ignores the label kwarg and compares raw bytes, so the in membership check is sound.
• fork.py / test_transfers.py: Introduces a MIP-11 shim that stops crediting priority fees to the coinbase (they are effectively burned); the transfer test's expected reward is updated to 0 for fork >= MONAD_NEXT, which resolves correctly for transition forks via TransitionBaseMetaClass.__ge__.

Confidence Score: 5/5

Safe to merge — all three changes are narrowly scoped to test correctness and a well-documented execution-layer shim.

The core fix (deriving precompile availability from transitions_from().precompiles()) is logically correct and consistent with how address equality is implemented in the base types. The MIP-11 priority-fee burn is intentional and clearly documented, and the companion test adjustment matches the new behaviour. No functional regressions were identified.

No files require special attention.

Important Files Changed

Filename	Overview
tests/monad_nine/mip4_checkreservebalance/test_fork_transition.py	Adds precompile_before flag derived from fork.transitions_from().precompiles() to correctly handle subsequent-fork case (MONAD_NINEToMONAD_NEXT) where the reserve balance precompile is already live before the fork under test. Logic and address-equality semantics are sound.
tests/monad_eight/reserve_balance/test_transfers.py	Updates reward calculation to 0 for MONAD_NEXT and later (MIP-11 burns priority fees instead of crediting coinbase). The fork >= MONAD_NEXT comparison correctly resolves through TransitionBaseMetaClass.__ge__ for transition forks.
src/ethereum/forks/monad_next/fork.py	Removes create_ether call for priority fees (MIP-11 shim: burns priority fees rather than crediting coinbase) and comments out now-unused priority_fee_per_gas/transaction_fee variables with a TODO to revisit after MIP-11 lands.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant Test as test_fork_transition
    participant Fork as TransitionFork
    participant Pre as transitions_from()
    participant Post as transitions_to()

    Test->>Fork: fork.transitions_from()
    Fork-->>Pre: e.g. MONAD_EIGHT or MONAD_NINE

    Test->>Pre: .precompiles()
    Pre-->>Test: list of Address objects

    Test->>Test: "precompile_before = Address(0x1001) in list"

    Note over Test: Block ts=14999 (pre-fork)
    Test->>Pre: CALL 0x1001
    Pre-->>Test: "RETURNDATASIZE == 32 if precompile_before else 0"

    Note over Test: Block ts=15000 (fork block)
    Test->>Post: CALL 0x1001
    Post-->>Test: "RETURNDATASIZE == 32"

    Note over Test: Block ts=15001 (post-fork)
    Test->>Post: CALL 0x1001
    Post-->>Test: "RETURNDATASIZE == 32"

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant Test as test_fork_transition
    participant Fork as TransitionFork
    participant Pre as transitions_from()
    participant Post as transitions_to()

    Test->>Fork: fork.transitions_from()
    Fork-->>Pre: e.g. MONAD_EIGHT or MONAD_NINE

    Test->>Pre: .precompiles()
    Pre-->>Test: list of Address objects

    Test->>Test: "precompile_before = Address(0x1001) in list"

    Note over Test: Block ts=14999 (pre-fork)
    Test->>Pre: CALL 0x1001
    Pre-->>Test: "RETURNDATASIZE == 32 if precompile_before else 0"

    Note over Test: Block ts=15000 (fork block)
    Test->>Post: CALL 0x1001
    Post-->>Test: "RETURNDATASIZE == 32"

    Note over Test: Block ts=15001 (post-fork)
    Test->>Post: CALL 0x1001
    Post-->>Test: "RETURNDATASIZE == 32"

Loading

Comments Outside Diff (2)

1. tests/monad_nine/mip4_checkreservebalance/test_fork_transition.py, line 32-37 (link)

   Docstring no longer accurate for subsequent_forks=True

   The docstring still reads "Before the fork, the precompile doesn't exist, so CALL returns empty output". When this test runs for a subsequent transition (e.g. MONAD_NINEToMONAD_NEXT), precompile_before is True and the precompile is already live before the tested fork, so the "before" block gets a 32-byte return, not empty output. The docstring should describe both variants (or at least note the conditional behaviour introduced by subsequent_forks=True).

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: tests/monad_nine/mip4_checkreservebalance/test_fork_transition.py
   Line: 32-37
   
   Comment:
   **Docstring no longer accurate for `subsequent_forks=True`**
   
   The docstring still reads "Before the fork, the precompile doesn't exist, so CALL returns empty output". When this test runs for a subsequent transition (e.g. `MONAD_NINEToMONAD_NEXT`), `precompile_before` is `True` and the precompile is already live before the tested fork, so the "before" block gets a 32-byte return, not empty output. The docstring should describe both variants (or at least note the conditional behaviour introduced by `subsequent_forks=True`).
   
   How can I resolve this? If you propose a fix, please make it concise.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

   

2. tests/monad_nine/mip4_checkreservebalance/test_fork_transition.py, line 110 (link)

   Stale inline comment for the precompile_before=True case

   When precompile_before is True (e.g. MONAD_NINEToMONAD_NEXT), the outer CALL to callee_address still succeeds (result 1), but the precompile is not "returning empty" — it returns 32 bytes. The comment is misleading for the subsequent-fork scenario.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: tests/monad_nine/mip4_checkreservebalance/test_fork_transition.py
   Line: 110
   
   Comment:
   **Stale inline comment for the `precompile_before=True` case**
   
   When `precompile_before` is `True` (e.g. `MONAD_NINEToMONAD_NEXT`), the outer CALL to `callee_address` still succeeds (result `1`), but the precompile is not "returning empty" — it returns 32 bytes. The comment is misleading for the subsequent-fork scenario.
   
   
   
   How can I resolve this? If you propose a fix, please make it concise.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

   

_{Reviews (5): Last reviewed commit: "fix(tests): zero priority fee reward at ..." | Re-trigger Greptile}

[pdobacz]

@greptileai re-review