eth_createAccessList: clarify gas-fee affordability when fee fields are omitted

[smallyunet]

Summary

The eth_createAccessList specification accepts a generic transaction object, and both the specification example and an existing conformance fixture omit gas and all fee fields. However, the specification does not define whether a client may reject such a request because the sender cannot afford fee values selected by the client as simulation defaults.

This matters for an unfunded sender with zero transaction value: four major execution clients currently generate the access list successfully, while Geth rejects the request after populating default EIP-1559 fee values.

Reproduction scope

The narrow case discussed here is:

• from is explicitly supplied and has zero balance;
• to has no code;
• value is zero or omitted;
• gas is omitted;
• gasPrice, maxFeePerGas, and maxPriorityFeePerGas are all omitted;
• the request targets a state where access-list transactions are active.

Request:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_createAccessList",
  "params": [{
    "from": "0xaa00000000000000000000000000000000000000",
    "to": "0xbb00000000000000000000000000000000000000"
  }, "latest"]
}

Preconditions:

eth_getBalance(0xaa...) = 0x0
eth_getCode(0xbb...)    = 0x

Current client behavior

Retested on 2026-07-22:

Client	Version	Result
Reth	v2.4.1 (8eb2101)	success
Nethermind	1.39.2 (65689105)	success
Besu	26.7.0	success
Erigon	v3.5.2 (8a829d21)	success
Geth	master 6e49f8e6b340	insufficient-funds error

Reth, Nethermind, Besu, and Erigon all returned:

{
  "accessList": [],
  "gasUsed": "0x5208"
}

The successful clients were tested on development chains with equivalent relevant state. Reth, Besu, and Erigon used their built-in dev chains; Nethermind used a minimal London-active genesis. This was not yet run as a single shared Hive fixture.

Geth currently fails with:

failed to apply transaction: ... err: insufficient funds for gas * price + value:
address 0xaa00000000000000000000000000000000000000
have 0 want 17500000000000000

The original Geth issue and the updated reproduction/client matrix are here:

• internal/ethapi: eth_createAccessList fails without fee parameters go-ethereum#25319
• internal/ethapi: eth_createAccessList fails without fee parameters go-ethereum#25319 (comment)

Existing specification coverage

The current method definition says only that eth_createAccessList “Generates an access list for a transaction” and does not define fee-default or affordability behavior:

https://github.com/ethereum/execution-apis/blob/main/src/eth/execute.yaml

The existing create-al-value-transfer.io fixture already omits gas and all fee fields and expects success, but it uses a funded sender:

https://github.com/ethereum/execution-apis/blob/main/tests/eth_createAccessList/create-al-value-transfer.io

The missing edge case is an unfunded sender with zero value.

Proposed clarification

One possible normative clarification is:

When all gas fee fields are omitted, the client may select implementation-defined fee values for simulation. The request MUST NOT fail solely because the sender cannot afford gas fees implied by those client-selected defaults. This does not waive balance requirements for a non-zero transaction value.

This wording would not require clients to use a zero gas price or standardize their fee oracle. It would only prevent client-selected defaults from introducing an affordability failure that was not present in the request.

Normal RPC gas caps, execution timeouts, and other resource limits would continue to apply.

Proposed conformance case

A fixture using an address absent from the test genesis could expect:

>> {"jsonrpc":"2.0","id":1,"method":"eth_createAccessList","params":[{"from":"0xaa00000000000000000000000000000000000000","to":"0xbb00000000000000000000000000000000000000"},"latest"]}
<< {"jsonrpc":"2.0","id":1,"result":{"accessList":[],"gasUsed":"0x5208"}}

Out of scope

This proposal intentionally does not define:

• behavior when value is non-zero and the sender cannot fund the transfer;
• behavior when fee fields are explicitly supplied;
• a universal default value for GASPRICE or other fee-sensitive execution context;
• general eth_estimateGas affordability semantics.

The immediate question is whether clients agree on the narrow behavior above and whether it should be made explicit in the specification and rpc-compat suite.