Feature/eip 8282

[Marchhill]

Fixes Closes Resolves #

Please choose one of the keywords above to refer to the issue this PR solves followed by the issue number (e.g. Fixes #000). If no issue number, remove the line. Also, remove everything marked optional that is not applicable. Remove this note after reading.

Changes

• List the changes

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Description

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Notes on testing

Optional. Remove if not applicable.

Documentation

Requires documentation update

• Yes
• No

If yes, link the PR to the docs update or the issue with the details labeled docs. Remove if not applicable.

Requires explanation in Release Notes

• Yes
• No

If yes, fill in the details here. Remove if not applicable.

Remarks

Optional. Remove if not applicable.

[claude]

Claude finished @Marchhill's task in 6m 6s —— View job

---

EIP-8282 PR Review

Tasks:

• Gather context and read changed files
• Review diff against base branch
• Analyze correctness, edge cases, and potential regressions
• Check security implications
• Check performance (hot-path considerations)
• Verify adherence to repo rules
• Post inline comments for specific issues
• Finalize review summary

---

Summary

The PR adds EIP-8282 builder execution requests (builder deposit + builder exit) following the same system-call pattern as EIP-7002 and EIP-7251. The scaffolding (spec flag, chain spec plumbing, fork assignment, BAL validation, error messages) is correct and well-structured. However, there is one critical omission and several medium/low issues:

---

Critical

GetFlatDecodedRequests throws on builder request types — ExecutionRequestExtensions.GetFlatDecodedRequests (in ExecutionRequestExtensions.cs, not in this diff) has default: throw new ArgumentOutOfRangeException(...) in its switch over ExecutionRequestType. The new BuilderDepositRequest = 3 and BuilderExitRequest = 4 values are not handled. This method is called in production by Nethermind.Stateless.Executor/IO/NewPayloadRequest.cs:66:

= ExecutionRequestExtensions.GetFlatDecodedRequests(block.ExecutionRequests);

Once Amsterdam activates and a block contains builder requests, the stateless executor path will throw. Fix: add explicit case entries, or change default: throw to default: break (EIP-7685 says clients MUST accept unknown request types). Also, MaxRequestsCount = 3 in the same file should be updated to 5, and the test assertion Has.Count.EqualTo(MaxRequestsCount) in ExecutionRequestExtensionsTests.cs will fail once builder requests are exercised.

Fix this →

---

High

No tests for EIP-8282 code paths — ExecutionProcessorTests.cs sets up mock accounts only for eip7002Account and eip7251Account. The _spec.BuilderRequestsEnabled returns false by default (NSubstitute default for bool), so the new builder request processing block is never exercised in tests. There should be tests verifying:

• Builder requests are correctly read and appended in type order when BuilderRequestsEnabled = true
• The BuilderDepositsContractEmpty / BuilderExitsContractEmpty errors are raised when the predeploy has no code
• RequestsHash includes builder request contributions

Fix this →

---

Medium

Contract addresses not configurable via spec (see inline comment) — EIP-7002 and EIP-7251 store their predeploy addresses in IReleaseSpec (Eip7002ContractAddress, Eip7251ContractAddress) with defaults set in 00_Olympic.cs and override support in ChainSpecParamsJson. EIP-8282 bypasses this and hard-codes addresses from constants, making it impossible to configure different addresses for devnets or test networks through chain spec JSON.

---

Low

• Comment style (see inline on ExecutionRequest.cs:14) — // eip-8282 should be // EIP-8282, or omit the comment (the enum member names are self-documenting). BuilderExitRequest = 4 is also missing a trailing comma.
• ArrayPoolListRef initial capacity (see inline on ExecutionRequestsProcessor.cs:77) — requests = new(3) on line 85 (not in diff) should be new(5).

[claude]

Medium — Inline comments on enum members add noise here; the type names are already self-documenting. If the EIP reference is useful, prefer XML doc on the enum member or at minimum use // EIP-8282 (uppercase) for consistency with how EIP references appear elsewhere in the codebase. Also note BuilderExitRequest = 4 is missing a trailing comma (style inconsistency with the other members).

[claude]

Medium — EIP-7002 and EIP-7251 read their contract addresses through spec.Eip7002ContractAddress / spec.Eip7251ContractAddress, which are set from constants by default in 00_Olympic.cs but can be overridden per-chain via chain spec JSON (Eip7002ContractAddress field in ChainSpecParamsJson). EIP-8282 hard-codes the address from constants here and doesn't add a spec property, breaking that pattern. If any devnet or test network ever needs a different predeploy address, there's no way to configure it. Consider adding Eip8282BuilderDepositContractAddress and Eip8282BuilderExitContractAddress properties to IReleaseSpec / ChainSpecParamsJson, following the existing pattern.

[claude]

Low — ArrayPoolListRef<byte[]> requests = new(3) on line 85 (not in diff) now has an incorrect initial capacity. With EIP-8282, there are 5 possible request-type buckets (deposits, withdrawals, consolidations, builder deposits, builder exits). The buffer will auto-resize if needed, so this is not a correctness issue, but it causes an extra allocation on Amsterdam blocks.