Public testnet RPC clamps eth_estimateGas at 16,777,216 (2^24), below the documented 30M --rpc.gascap default and the 30M block gas limit

[osr21]

Summary

The public testnet endpoint rpc.testnet.arc.network currently clamps eth_estimateGas at 16,777,216 gas (2^24) — below both the documented production default --rpc.gascap=30M and the current block gas limit (30M). The value 16777216 appears nowhere in this repository, so this looks like either an undocumented infrastructure-level override on the public endpoint or an unintended regression in the v0.8.0 rollout. Filing as an issue rather than a PR because the discrepancy is in endpoint behavior, not repo code.

Observed 2026-08-29, post-v0.8.0 (the endpoint already emits the v0.8.0 error texts).

Observed

A request whose intrinsic gas (~31.2M via calldata) exceeds the cap:

$ curl -s https://rpc.testnet.arc.network -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_estimateGas","params":[{"from":"<funded>","to":"0x0000000000000000000000000000000000000002","data":"0xff…(1,950,000 bytes)","maxFeePerGas":"0x174876e800"}]}'
{"error":{"code":-32000,"message":"gas required exceeds allowance (16777216)"}}

The bound does not move with an explicit gas field (tested gas: 20M and gas: 40M — both still report (16777216)), and a ~25M-intrinsic-gas request (between 2^24 and 30M) is also rejected with the same bound. Meanwhile, the same endpoint reports:

eth_getBlockByNumber("latest") → gasLimit: 30000000

Expected

• crates/execution-e2e/tests/e2e/static_rpc_gas_cap.rs documents --rpc.gascap=30_000_000 as "the production Arc default" (installed by crates/node/src/args.rs) and pins it with a launched-node test.
• tests/localdev/evm_compatibility.test.ts expects the 30M default on debug_traceCall's implicit gas budget, and its comment states the cap "should [be] greater or equal than gas limit in the block".
• BREAKING_CHANGES.md documents the v0.7.2 change of the default from 50M → 30M; no subsequent entry documents a further reduction.

So a request needing 17–30M gas currently fails estimation on the public endpoint even though a block would accept the transaction — the opposite of the invariant the localdev comment describes (cap ≥ block gas limit).

Impact

• Any transaction in the 16.8M–30M gas range cannot be estimated via the public endpoint; libraries that gate submission on eth_estimateGas (ethers, viem, wallets, AA infra) will report such transactions as impossible even though the protocol accepts them — exactly the failure mode described in docs: explicitly distinguish RPC gas cap from protocol transaction gas limits #271.
• The rejection string is identical to the insufficient-balance error (gas required exceeds allowance (<limit>), see bug: GatewayClient mislabels receipt-wait failures as "Mint transaction failed" and never checks receipt.status for real reverts #203), so affected callers can only recognize the condition by parsing the numeric bound — and 16,777,216 is not a value they can currently find in any Arc documentation.

Questions

1. Is the 2^24 clamp on the public endpoint intentional (gateway-level protection)? If so, could it be documented where the 30M default is documented today, since it supersedes that default for most developers?
2. If unintentional, did the v0.8.0 rollout change the endpoint's --rpc.gascap (or introduce a proxy-level limit)?

Happy to provide additional transcripts or re-test after any change.

[osr21]

Correction to this issue's framing, prompted by re-verification while reviewing #299: the 16,777,216 clamp is not a public-endpoint infrastructure policy layered over the 30M --rpc.gascap default — it is the EIP-7825 per-transaction gas cap, protocol-active since the Osaka hardfork on testnet (ARC_TESTNET_HARDFORKS activates EthereumHardfork::Osaka at ForkCondition::Timestamp(1779890400), ≈2026-05-28; hardforks.rs notes Osaka is "already activated on testnet/mainnet").

Verified today: an eth_estimateGas probe whose required gas exceeds 2²⁴ returns the identical {"code":-32003,"message":"out of gas: gas required exceeds: 16777216"} on all four independently-operated endpoints (primary, dRPC, Blockdaemon, QuickNode), and an explicit "gas": 30000000 is silently clamped to 2²⁴. Since these providers run independent Arc node infrastructure, uniform behavior points at the protocol/node layer, not endpoint config.

Implications:

• Self-hosted v0.8.0 nodes cap identically; raising --rpc.gascap cannot lift single-tx estimates above 16,777,216.
• Transactions needing 17–30M gas are not merely un-estimatable — they are invalid under EIP-7825. The 30M block gas limit permits multiple transactions per block, not one large one.

So the actionable residue of this issue is documentation: the v0.7.2 --rpc.gascap breaking-change entry (and anything advising "pass a higher gascap to restore budget") is stale for single transactions post-Osaka, since the 7825 cap always undercuts the 30M default. #299 is touching this area.