fix(wallet): pass eth_feeHistory and eth_maxPriorityFeePerGas through the zkEVM provider

[allan-almeida-imtbl]

Summary

The Passport zkEVM provider now forwards eth_feeHistory and eth_maxPriorityFeePerGas to the node. These are the two calls viem, wagmi and ethers make to estimate EIP-1559 fees; until now they fell through to Method not supported.

Linear: BLOC-686 (parent BLOC-680, Fee model vector, zkEVM → OP Stack migration).

The problem, by example

A dapp built on viem sends a transaction through Passport. Before it signs anything, viem's estimateFeesPerGas asks the provider two questions:

Call	Question it answers	Passport today	Passport after
eth_feeHistory	what did recent blocks charge?	Method not supported (4200)	node's answer, as-is
eth_maxPriorityFeePerGas	what tip gets me included now?	Method not supported (4200)	node's answer, as-is
eth_gasPrice	legacy single price	forwarded	forwarded (unchanged)

Today the send fails at the estimation step, before the user sees anything. The common workaround is to hardcode a fee in the dapp. That is the habit the migration has to break: op-reth has no 10 gwei floor, so a hardcoded fee is either overpaying or underpaying from cutover onward. Correct estimation has to be possible through the provider first.

Detail and impact of the change

Fixed

Two method names added to the forward-as-is group in packages/wallet/src/zkEvm/zkEvmProvider.ts, next to eth_gasPrice. No shape translation; the node's JSON-RPC result is returned unchanged, the same as the other read-only passthroughs. Both methods exist on the current immutable-geth node, so this ships ahead of the migration with no behaviour change for callers not using them.

Tests: the two methods are forwarded with their params and the result returned untouched; a method not on the list still throws Method not supported.

Anything else worth calling out?

• Passport's own transaction path (eth_sendTransaction via the relayer) is untouched. This only affects dapps that read fees through the provider for their own purposes.
• The lint warnings on this file (no-floating-promises, lines 119/239/435) are pre-existing and not in the changed lines.

🤖 Generated with Claude Code

[nx-cloud]

View your CI Pipeline Execution ↗ for commit 507ebbe

Command	Status	Duration	Result
nx affected -t build,test	✅ Succeeded	1m 19s	View ↗

💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗

---

☁️ Nx Cloud last updated this comment at 2026-09-30 00:02:09 UTC

[allan-almeida-imtbl]

Closing unmerged. This is not a migration issue.

Both methods exist on immutable-geth today and on op-reth after, and the Passport provider blocks them in both worlds, so the migration neither creates the gap nor is blocked by it. Checking viem 2.18.2 as installed here: estimateMaxPriorityFeePerGas wraps the call in a bare try/catch and falls back to eth_gasPrice minus block.baseFeePerGas, both already in the passthrough. That fallback returns the correct tip on either client, so the standard send path works today and would work post-cutover unchanged. Only viem's explicit getFeeHistory surfaces the error, and no Immutable flow depends on it.

The PR description's claim that dapps "hard-error today" was wrong for the common path. Recorded on BLOC-686, which is cancelled.

The underlying change is still a reasonable SDK improvement on its own merits: two fewer RPC round trips per send, and an unblocked fee-history path. If it is wanted, it should be raised as ordinary SDK work rather than carried in the migration scope. Branch kept.