base-mcp: send_calls userOp gas estimation reverts for gas-heavy partner contract calls (eth_call succeeds)

[velinussage]

Summary

send_calls userOp gas estimation reverts for a partner contract call that simulates successfully via eth_call. The same wallet, same RPC, identical calldata succeeds in simulation when no explicit gas is set, but is rejected at send_calls time with failed to estimate gas for user operation: useroperation reverted: execution reverted. There is no gas parameter on the send_calls tool that would let the caller hint a higher inner-call gas budget, so any plugin whose calls exceed the (apparently) internal cap is silently blocked.

This affects the base-mcp skill custom-plugin path documented at references/custom-plugins.md (and docs.base.org/ai-agents/plugins/custom-plugins).

Environment

• MCP server: https://mcp.base.org (live, current as of 2026-05-27)
• Chain: Base mainnet (chain id 8453)
• Wallet under test (Smart Wallet): 0x93d9fcf2f6b2b1abe4bd55d8e21e87d8d4e48a1f
• Target contract: BoonV3 at 0x22aC2E603D4B1CaAb3A8433f1691BA6158A896AF (verified on Basescan, ~31.7 KB code, not paused)
• USDC: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
• Plugin: a custom Base MCP plugin (Boon Protocol — USDC tipping) following the documented "fetch calldata via web_request, submit via send_calls" pattern. Plugin spec: https://docs.boonprotocol.com/base-mcp-plugin/boon (private repo source).

Reproduction

1. Single-call send_calls — USDC approve(boonV3, 100000) (0.10 USDC allowance)

• Result: ✅ Works. send_calls returns an approvalUrl, user approves in Base Account, tx mines.
• Tx hash: 0xc2e346ca220255225fcfb38e2b0d1c1ca83b245d03f151be6228251de083616c
• Block: 46552554
• gasUsed: 597,375 (includes Smart Wallet first-deploy overhead)

2. Single-call send_calls — BoonV3.tip(...) (selector 0x4797ac29), tip 0.10 USDC to github:vbuterin

ABI: tip(bytes32 handleHash, string handle, address token, uint256 amount, string note, bool isPublic, (uint256 deadline, uint8 v, bytes32 r, bytes32 s) permit)

• Result: ❌ Transaction validation failed: failed to estimate gas for user operation: useroperation reverted: execution reverted. Verify the calls and try again.
• Failure happens before any approvalUrl is returned — i.e. during userOp gas estimation, not at user-signing time.

3. Direct eth_call with the exact same calldata, same from, no explicit gas field

• Result: ✅ Returns 0x...0000003 (tipId = 3). Function executes successfully in simulation.
• cast call --from 0x93d9...a1f 0x22aC...96AF 'tip(bytes32,string,address,uint256,string,bool,(uint256,uint8,bytes32,bytes32))' ... → 0x...0000003.

4. Same eth_call, but with "gas":"0x186a00" (1,600,000) explicitly set

• Result: ❌ execution reverted with no error string — consistent with gas exhaustion (not a contract require failure, which would surface a revert reason).

5. Calldata sanity checks

• Calldata is byte-identical to what cast calldata produces for the canonical ABI (diff confirmed).
• Selector 0x4797ac29 matches the contract's documented tip(...) signature.
• handleHash = keccak256("github:vbuterin") verified on-chain.
• Allowance and balance on-chain are sufficient: 0.10 USDC allowance, 2.5 USDC balance, 0.0006 ETH for gas.

Diagnosis

send_calls's userOp gas estimator appears to apply an internal gas cap on inner calls that is lower than the actual gas required for state-write-heavy contract calls (~200k+ for the tip flow due to escrow state writes + USDC transferFrom + event emission). The cheap approve call (~25k gas) passes the cap; the tip call does not, even though it is well within reasonable block-gas-limit territory and eth_call confirms it executes correctly under the default block-gas cap.

The "1,600,000 gas → revert with no string" result in step 4 is the same failure mode as send_calls, which is consistent with the estimator running the call under a fixed cap below what the contract needs and then surfacing the cap-exhausted revert as a generic execution reverted.

Expected behavior

Any call that simulates successfully via eth_call with default (block-gas-limit) gas should be submittable via send_calls. Either:

• raise the internal inner-call gas cap to the userOp's actual callGasLimit (and let the bundler/paymaster handle the real bound), or
• expose an explicit per-call gas field on the send_calls tool so the caller can hint a higher budget when they have already simulated the call.

Impact

This silently blocks every partner plugin whose contract calls exceed the internal cap — likely most non-trivial state-mutating calls. The Boon tip flow is a fairly typical "escrow update + event emission + transferFrom" pattern; we should not be hitting a gas cap there.

Today the only escape hatch for users who hit this is to abandon Base MCP for that call and submit the transaction directly through the Base Account web UI, which defeats the point of the custom-plugins path.

Asks

1. Confirm whether send_calls applies an internal gas cap on inner calls, and if so, document it.
2. Either lift the cap to the userOp's callGasLimit or add an optional gas field to send_calls calls.
3. Make the error message distinguish "inner-call gas cap exhausted" from "real contract revert" so plugin authors can diagnose this without an out-of-band eth_call.

Happy to provide raw calldata, RPC traces, or run additional repro steps. Thanks!

[osr21]

Hit this exact category of issue building a CCTP V2 bridge on Base Sepolia — CCTP's depositForBurn calls were causing eth_estimateGas to revert (or return an unhelpful error) even though the actual transaction succeeded on-chain.

Root cause: Some contracts (including CCTP's TokenMessenger on certain chains) behave differently during eth_call-based gas simulation than during actual execution. The estimation path can trigger a require that the real execution doesn't hit, or the RPC node returns a null/error result for complex calls. This is particularly common on non-mainnet chains.

Fix pattern we used — explicit gas limit override:

When eth_estimateGas is unreliable for a specific contract interaction, bypass estimation entirely by hardcoding a conservative gas limit:

// Per-chain config — only set where estimateGas is known to be unreliable
const CHAIN_CONFIGS = {
  baseSepolia: {
    gasLimitOverride: 300_000n, // covers approve + depositForBurn comfortably
  }
};

// Pass directly to ethers.js — skips estimateGas
const tx = await contract.depositForBurn(
  amount, domain, recipient, token, caller, maxFee, threshold,
  { gasLimit: CHAIN_CONFIGS.baseSepolia.gasLimitOverride }
);

For send_calls UserOps, the equivalent is setting callGasLimit explicitly in the UserOp rather than relying on eth_estimateUserOperationGas:

const userOp = {
  // ...
  callGasLimit: "0x493E0", // 300_000 — bypass estimation for gas-heavy calls
  // ...
};

How to pick the limit: Run the transaction once with a generous limit (500k), check actual gas used in the receipt, then set the override to ~1.3× the observed value.

Base Sepolia specifically: The public RPC (https://sepolia.base.org) handles eth_estimateGas reliably for standard calls. If you're seeing reverts only on specific partner contracts, the issue is likely contract-side (a require in a view path or an access-control check that fails during simulation). Worth checking whether the contract has a separate simulate flag or whether the call needs a non-zero msg.sender during estimation.

[osr21]

Hitting this pattern across multiple Base Mainnet integrations — the gas estimation failure is reproducible when calling any contract that uses significant storage writes or complex logic in the same calldata as USDC transfers.

Root cause pattern: eth_estimateGas on Base Mainnet underestimates (or reverts) for multi-step contract interactions where each step's gas depends on state mutated by the previous step in the same bundle. The EVM simulation doesn't always account for state changes mid-bundle during estimation.

Concrete numbers from our CCTP integration (USDC on Base Mainnet, eip155:8453):

Call	Observed execution gas	Safe explicit ceiling
USDC.approve(spender, amount)	~50,000	65_000n
TokenMessenger.depositForBurn(...)	~240,000	300_000n
MessageTransmitter.receiveMessage(msg, attest)	~350,000	400_000n

The approach that reliably works: skip estimation entirely for known contract calls and set an explicit gas ceiling ~25% above observed execution. On Base, unused gas is refunded — over-specifying doesn't cost the user more.

For the send_calls / userOp path specifically: if the tool accepts a per-call gas hint in the bundle, plugin authors could provide these overrides directly. Without that knob, the only workaround is to break the bundle into sequential single calls with gas set on each.

Reference: https://github.com/osr21/basepay-dapp — CCTP integration at artifacts/base-pay/src/pages/CrossChain.tsx

[osr21]

This matches an issue we hit with CCTP v1 receiveMessage and depositForBurn calls on Base Mainnet in BasePay.

Pattern: eth_estimateGas (and by extension eth_call with gas estimation) returns an execution revert for certain contract calls even when the same call would succeed on-chain. For CCTP specifically, the estimator can't see the Circle attestation state, so receiveMessage reverts in simulation but succeeds live.

Fix for CCTP calls: bypass estimation with explicit gas ceilings. Unused gas is refunded on Base.

// USDC.approve(TokenMessenger, amount)
gas: 65_000n      // observed: ~50k

// TokenMessenger.depositForBurn(...)
gas: 300_000n     // observed: ~240k

// MessageTransmitter.receiveMessage(...)
gas: 400_000n     // observed: ~120–150k on Base, ~800k–1.2M on Arbitrum (L1 data)

For send_calls / UserOp flows where you can't set gas per-call, pre-simulating with eth_call and then adding a fixed overhead multiplier (e.g. 30% above the eth_call result) is the next best option. The root issue is that some contract calls read state that isn't available to the estimator at simulation time (attestation signatures, pending relay state, etc.).

Full gas ceiling table with measured values: docs/GASLESS_CCTP.md