feat(eth-rpc): implement eth_baseFee, returning next block base fee

[wjmelements]

The eth_baseFee method is a nonstandard eth jsonrpc method that returns the base fee of the next block.
It is similar to eth_blobBaseFee, and already implemented by erigon and some third-party RPC services.

Changes

• adds eth_baseFee RPC method

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

Documentation

Requires documentation update

• Yes
• No

I think the docs for eth_baseFee will be auto-generated by the DocGen tool from the [JsonRpcMethod] tag

Requires explanation in Release Notes

• Yes

• No

  • eth_baseFee added — returns the base fee of the next block in wei

Remarks

I have no prior experience with dotnet.

[svlachakis]

@claude review

[claude]

Claude finished @svlachakis's task in 3m 37s —— View job

---

PR Review: feat(eth-rpc): implement eth_baseFee

• Gathering context and reading changed files
• Loading repo coding rules
• Reviewing implementation correctness
• Reviewing tests
• Checking for security/performance issues
• Posting findings

---

Summary

The implementation is clean and correct. It follows the existing eth_blobBaseFee pattern closely and delegates to BaseFeeCalculator.Calculate(head, specFor1559), which correctly dispatches to the spec-registered calculator — meaning custom chains (Optimism, Taiko) that override base fee calculation are automatically supported.

The four test cases verify the main EIP-1559 scenarios (pre-London null return, at-target, over-target, under-target), and the math in each expected value checks out.

---

Findings

Correctness

The implementation semantics are correct:

• GetSpecFor1559(head.Number + 1) fetches the spec for the next block — this is the same pattern used in FeeHistoryOracle.cs:127.
• BaseFeeCalculator.Calculate(head, specFor1559) computes the next block's base fee from the current head, matching the PR description and Erigon's behavior.
• The EIP-1559 transition block case (isForkBlockNumber) is handled correctly inside DefaultBaseFeeCalculator — it returns ForkBaseFee for the first London block.
• Returning null for pre-London chains is appropriate and distinguishes from eth_blobBaseFee's 0 for pre-Cancun (different semantics, both reasonable).

Low: long overflow on head.Number + 1

EthRpcModule.cs:132 — If head.Number == long.MaxValue this overflows silently. Unreachable in practice and the same pattern exists in FeeHistoryOracle. No action required, but noted for consistency.

Low: Null-head branch is untested

EthRpcModuleTests.GasPrice.cs:71 — All test cases supply a block, so the if (head is null) return null guard is never exercised. Suggest adding an empty-chain test case.

---

Verdict

No Critical, High, or Medium issues. The implementation is correct, follows codebase patterns, handles edge cases properly, and includes meaningful tests. The two Low findings are either theoretical (overflow) or a minor test coverage gap. The PR is ready to merge pending minor test improvement.

[claude]

Low — missing null-head test case

All four test cases supply a non-empty block tree, so the if (head is null) guard in the implementation is never exercised. Consider adding:

yield return new TestCaseData(UInt256.Zero, 0L, 0L, false)
{
    TestName = "Empty blockchain returns null",
    ExpectedResult = NullResult
};

with a corresponding ctx.Test built from an empty block tree (or simply leaving the default block tree with no explicit head). The guard is correct — this is just an untested branch.

[svlachakis]

This endpoint is not implemented in geth, not sure if it's worth supporting

[wjmelements]

This endpoint is not implemented in geth, not sure if it's worth supporting

ethereum/go-ethereum#34904

[svlachakis]

Please make sure it's consistent with eth_blobBaseFee. I think the existing eth_blobBaseFee returns UInt256.Zero when blob fees aren't applicable (pre-Cancun), but this PR returns null for pre-London. That's a real divergence in the "fee not applicable" contract. Please let's confirm both with geth first and align them in nethermind also.

I think it's missing fork-transition test. The most error-prone scenario is "last pre-London block N (no BaseFeePerGas) → first post-London block N+1 (initial 1 gwei)". BaseFeeCalculator handles this via Eip1559BaseFeeInitialValue, but the PR's test cases all use a single fixed spec. A test where londonEnabled=true but the parent block is still pre-London would catch any regression there.