feat(eth): EVM block-gas for EIP-1559 fee projection (takeover of #1585)

[pragmaxim]

This builds on and takes over #1585 (@53gur0's feat/evm-1559-fields). The four original commits are preserved as-is; everything else here is review fixes and the decisions described below.

Built on the existing PR

A takeover of #1585. The original push-path work (block-level gas data on the subscribeNewBlock notification, plus its tests) is kept unchanged. The added commits address issues found in review, correct the on-chain fee tiers, and document the result.

What it delivers

EVM block-level gas data so wallets can project EIP-1559 base fees, via two paths:

• Push — subscribeNewBlock now carries evmData { baseFeePerGas, blockGasUsed, blockGasLimit } taken from the just-connected block header. All three values come from one block, with no extra RPC; the wallet can apply the consensus base-fee formula to get the next block deterministically.
• Pull — estimateFee keeps returning eip1559.baseFeePerGas, which (via eth_feeHistory) is already the projected base fee of the next block, and now returns corrected on-chain fee tiers (see below).

Companion Trezor Suite change

The user-facing "fees too high" fix lives in the wallet, on the companion branch:
https://github.com/trezor/trezor-suite/tree/fix/evm-fee

We went with Option B — the wallet owns the fee-buffer policy:

• Suite computes maxFeePerGas = 2 × baseFee + tip itself, from the chain's base fee, instead of passing a provider's pre-padded suggestedMaxFeePerGas straight through. Infura pads the high tier to ~2.5× the base fee and Suite used maxFeePerGas verbatim — that was the "too high".
• In EthereumFeeLevels the block-based estimate is preferred and falls back to the backend tiers when block data is unavailable, so nothing regresses.
• Coverage today: evm-rpc-backed networks get the block-based fees via getBlock('latest'); blockbook-backed networks fall back to the backend (Infura) tiers until the subscribeNewBlock evmData from this PR is wired in as their block-data source.

docs/fees.md (added here) documents the full cross-repo flow.

Why setLatestBlockGas was removed

The original approach added a setLatestBlockGas step to EthereumTypeGetEip1559Fees, issuing an extra eth_getBlockByNumber("latest") to populate BlockGasUsed/BlockGasLimit. Two real problems and one minor one:

• Data race — the alternative fee provider returns the same cached *Eip1559Fees pointer to every caller; setLatestBlockGas then mutated BlockGasUsed/BlockGasLimit on it without a lock, racing concurrent estimateFee goroutines (reproduced with -race).
• Incoherent data — baseFeePerGas (from eth_feeHistory, newest = pending) and gasUsed/gasLimit (from a separate latest block) described different blocks, so the trio could not form a correct single-block EIP-1559 projection.
• Minor — extra RPC — it added an eth_getBlockByNumber("latest", false) per estimateFee. That call is cheap on its own (header only, usually served from the node's memory), so it is not a significant cost. The fair point is architectural rather than raw overhead: it also fired on the alternative-fee-provider path, which is deliberately served from an in-memory cache with no node RPC, so it quietly undid that optimization.

The deciding factor is that the data was not needed in the pull path at all: baseFeePerGas is already the next block's projected fee, and the push evmData carries per-block gas consistently. Fix: drop setLatestBlockGas — nothing is lost.

Corrected the on-chain fee tiers

On the on-chain estimate (coins with no alternative provider — ethereum non-archive and the ETH testnets), each tier's maxFeePerGas was set to the priority fee alone, omitting the base fee — i.e. below the block's base fee, so not mineable. Since Suite uses maxFeePerGas directly, these coins produced unusable EIP-1559 fees.

Now each tier is built from the eth_feeHistory response: maxPriorityFeePerGas = the tier's reward percentile (the real tip), and maxFeePerGas = eip1559BaseFeeMultiplier(2) × baseFee + tip — the EIP-1559-standard 2× buffer (survives ~6 full blocks of +12.5%/block growth), in a documented, tunable constant. This also drops the now-redundant eth_maxPriorityFeePerGas call, so the on-chain path makes one RPC (eth_feeHistory) instead of two. The Infura path is untouched.

Decision: no separate "next-block base fee" field in the pull path

We considered exposing the next-block base fee from the eth_feeHistory response already fetched (no extra RPC). Investigation (go-ethereum eth/gasprice/feehistory.go + live probes against the deployed backends) showed the extra projected element eth_feeHistory returns has backend-dependent semantics:

• ethereum (Erigon, no distinct pending block): go-ethereum drops the extra element, so the existing baseFeePerGas is already the next block's projected fee.
• arbitrum / optimism / base: the indices shift, so the extra element is N+1 while baseFeePerGas becomes the latest mined block.
• polygon (real pending block): the extra element is an N+2 estimate computed off an incomplete pending block.

No single field can describe all of these consistently, so we deliberately did not add one. The reasoning is captured inline in ethrpc.go. Clients needing an exact next-block base fee should use the push evmData (the real previous-block header). The existing pull-side baseFeePerGas is left as-is; its own backend-dependent meaning is a pre-existing property, out of scope here.

Could it be richer?

The one genuinely-sound enrichment would be a server-computed next-block base fee on the push side — safe there because we have the exact header (deterministic), unlike the pull path:

export interface EthereumGasData {
    baseFeePerGas?: string;
    blockGasUsed?: string;
    blockGasLimit?: string;
    nextBaseFeePerGas?: string;  // computed from THIS block's header
}

But I'd lean against it:

1. the client can derive it from the trio in ~2 lines;
2. the formula's parameters are chain-specific — Ethereum uses denominator 8 / elasticity 2, some OP-stack L2s differ, and Arbitrum's base-fee mechanism is different altogether — so computing it server-side risks being subtly wrong across the EVM family. Shipping the raw trio lets each client apply the rule it trusts.

Fee observability (Grafana + metrics)

The dashboard had only two fee panels (UTXO estimated_fee and alternative_fee_provider_requests), both buried in General, and EVM EIP-1559 fees were invisible in metrics entirely. This adds a dedicated Fees section and the metrics behind it, aimed at troubleshooting the "fees too high" reports and at making both the pull and push paths observable.

Six new metrics (declared in configs/metrics.yaml, the single source of truth; the dashboard is generated from template.json + panels.yaml by render_grafana.py):

• Pull path — eth_eip1559_fee{tier,kind} (the per-tier maxFeePerGas / priority fee actually served) and eth_eip1559_base_fee (the base fee they are built on), in raw wei; plus eth_eip1559_fee_source_total{source} = provider / onchain_fallback / onchain, i.e. how often the served estimate bypassed the provider.
• Provider — alternative_fee_provider_last_sync_timestamp_seconds{provider}: cache age via time() - metric (a timestamp, not a computed age, so it keeps rising when a provider wedges). The leading indicator that explains a fallback.
• Push path — eth_block_gas_used_ratio (latest connected block's congestion, the driver of base-fee moves) and eth_block_base_fee (realized base fee), the latter overlaid against the pull-path projection.

All values are emitted in base units (wei / ratio), nil-guarded, and only on the relevant success paths; nil tiers create no empty series. The push gauges are set synchronously in OnNewBlock (invoked in monotonic height order) rather than in the per-block broadcast goroutines, so an older block can't clobber a newer value.

The Fees section orders the panels pull → provider-health → push → legacy and includes a buffer-ratio panel (maxFeePerGas / baseFee, with a dashed 2× reference) that separates a congested chain from estimator/provider over-buffering — the direct read on "fees too high". Every panel carries a self-contained description.

The design and the final diff were each run through an adversarial multi-lens review; the only changes it produced were wording-precision tweaks (already applied). It also surfaced one pre-existing, out-of-scope issue: the 1inch provider never sets staleSyncDuration, so its cache is treated as stale immediately — its series is dormant in current deployments, and the new fee_source / cache-age panels would now make it visible.

Other fixes

• Wire naming — renamed the new-block field evm_data → evmData (it was the only snake_case key among the websocket types) before it ships, since changing a wire key after release is breaking.
• OpenAPI / parity — documented the subscribeNewBlock payload (WsNewBlock / EthereumGasData, with evmData modeled as nullable in 3.1) and added them to the parity check. The parity typecheck (a CI gate) had been failing because the new Eip1559Fees fields were not mirrored in openapi.yaml; it passes again now.
• Tests — added coverage for the block → evmData mapping (non-EVM, pre-London, post-London) and for the corrected on-chain tier computation (asserting maxFeePerGas > baseFee).
• Docs — added docs/fees.md with diagrams of the full cross-repo fee flow (pull path, push path, Suite policy, end-to-end).

Testing

• Unit: full suite green (725 tests across common/eth/server, including new coverage for every fee-metric emit helper); go vet clean (the only vet warnings are pre-existing in server/public_test.go, unrelated).
• Integration: ethereum=main/rpc (incl. EstimateFee — which now exercises the corrected on-chain tiers — and GetBlock) and bsc=main/rpc/EstimateFee pass.
• OpenAPI: lint:spec, generate, and parity typecheck all pass.
• Grafana: render_grafana.py --check consistent (102 panels, 85 metrics); go.mod/go.sum untouched. grafana.json is the git-ignored rendered artifact.

Deployment / compatibility

This change is backward-compatible and can be deployed independently of, and before, the Suite release:

• subscribeNewBlock gains evmData additively ({height, hash} → {height, hash, evmData}); existing clients ignore the new field, and the deployed Suite reads only height/hash from the notification.
• The estimateFee / Eip1559Fees response shape is unchanged vs master.

The only behavioral change for current clients is on the no-provider on-chain coins, where maxFeePerGas goes from unmineable to correct (a bugfix). The user-facing "too high" improvement lands only once the Suite branch ships; deploying blockbook first is safe and makes evmData available for it.

1inch provider tier remapping

1inch returns 4 fee tiers (low/medium/high/instant) with systematically tighter values per tier than Infura (3 tiers). The previous 1:1 mapping (suite low/medium/high ← 1inch low/medium/high) produced fees that were too conservative compared to Infura, causing ~2× fee differences between providers that made reliable cross-provider fee estimation impossible.

Fix: remap the tiers in the 1inch provider so the suite's low/medium/high are fed from comparable aggressiveness regardless of which provider serves the response:

Suite tier	Infura source	1inch source (after remap)
low	low	medium
medium	medium	high
high	high	instant

1inch's low tier is discarded (too conservative to be useful). The instant field (not consumed by the suite) is left nil, consistent with Infura's behavior. The on-chain fallback path is unaffected — its percentile-based tiers (p20/p70/p90/p99) already produce correct per-tier values. The fee formula (maxFeePerGas = 2×baseFee + tip) is already handled on the suite side; this change ensures the input tier values are comparable.

Verified live against dev blockbooks via WebSocket:

# 1inch provider (eth-dev:9116)
echo '{"id":"1","method":"estimateFee","params":{"blocks":[1],"specific":{"from":"0x0000000000000000000000000000000000000000"}}}' | websocat -k wss://blockbook-dev.corp.sldev.cz:9116/websocket

# Infura provider for comparison (base-dev:9311)
echo '{"id":"1","method":"estimateFee","params":{"blocks":[1],"specific":{"from":"0x0000000000000000000000000000000000000000"}}}' | websocat -k wss://blockbook-dev3.corp.sldev.cz:9311/websocket

1inch response (commit 66d7aff deployed — tier remapping active):

Suite tier	Mapped from 1inch	baseFeePerGas	maxFeePerGas	maxPriorityFeePerGas	Ratio to base
low	medium	84,922,820	102,094,050	186,666	1.20×
normal	high	84,922,820	102,374,049	466,665	1.21×
high	instant	84,922,820	204,748,098	933,330	2.41×

Infura response for comparison:

Suite tier	Source	baseFeePerGas	maxFeePerGas	maxPriorityFeePerGas	Ratio to base
low	low	5,000,000	11,100,000	1,100,000	2.22×
normal	medium	5,000,000	24,000,000	4,000,000	4.80×
high	high	5,000,000	55,000,000	5,000,000	11.0×

Absolute values differ (different chains/networks), but the remapping ensures each suite tier receives a meaningful priority fee — without it, the suite's low would have been populated from 1inch's low (~100K wei priority fee, too conservative to be reliably mineable).

[cranycrane]

Review notes

Went through the diff carefully. The PR is in good shape — most of the things I initially suspected turned out to be non-issues (see bottom). Two points worth a look, one actionable.

1. On-chain priority fee now comes solely from eth_feeHistory rewards — tip can be 0 on idle chains

bchain/coins/eth/ethrpc.go:1999-2007

Dropping eth_maxPriorityFeePerGas means the per-tier tip is now the average of the reward percentile over the window. On chains/blocks where the backend returns an empty reward array or all-zero percentiles (idle testnets like Sepolia/Holesky, or a backend that omits rewards), priorityFee stays 0 for every tier, so maxPriorityFeePerGas = 0. maxFeePerGas still covers 2×baseFee so the tx stays mineable, but the served tip drops to zero where the old node-suggested minimum wasn't. This is the documented consequence of removing the RPC — just flagging that the zero-tip case on low-activity networks should be a conscious accept.

2. Unchecked h.Reward[j][i] can panic on a non-compliant backend

bchain/coins/eth/ethrpc.go:2000

p, _ := hexutil.DecodeUint64(h.Reward[j][i])

This indexes columns 0–3 assuming every reward row has the 4 entries matching the requested percentiles. A backend returning a row shorter than 4 elements panics the EthereumTypeGetEip1559Fees request. Pre-existing, but the function is reworked here and the new len(h.Reward) > 0 guard just below shows the intent to harden this block — a len(h.Reward[j]) > i check would close the remaining hole cheaply.

---

Checked and cleared (not bugs)

• No data race on the cached fees — GetEip1559Fees returns the pointer under p.mux, and a refresh swaps in a new struct (p.eip1559Fees = &fees) rather than mutating the live one, so observeEip1559Fees reads a stable snapshot. This is exactly the property the setLatestBlockGas removal restores.
• observeNewBlockGas GasLimit.Sign() > 0 is correct div-by-zero protection, not a missed-metric case (real blocks never have limit 0).
• bigIntToFloat "duplication" in websocket.go is a cross-package inline (server vs. eth) and not trivially shareable.

[cranycrane]

Otherwise LGTM

[pragmaxim]

Fixed in 17c494d — bounds-guarded the reward column index (short rows skipped, divisor counts only contributing rows) and documented the zero-tip-on-idle-chains accept. Added a regression test.