Base gas limits for your first Forge vault deposit

Why Forge multi-adapter deposits need explicit gas limits on Base — 2.5M, 4M, and 6M ceilings for Core and Middle vault smoke tests.

Last updated: May 26, 2026 · Published 2026-05-26

Base L2 gas is cheap compared to Ethereum mainnet, but Forge vault deposits are not simple ERC-20 transfers. An ERC-4626 deposit routes USDC through multiple yield adapters — Spark Savings, Morpho curated vaults, Aave V3 on Core; additional swap paths on Middle. Each leg executes external calls in one transaction. Wallet default gas estimation often reverts during simulation, leaving agents with failed broadcasts or stuck pending txs. Forge operational canon specifies explicit `--gas-limit` values: ~2.5M for Phase 1 three-leg Core, ~4M after P2-C0 five-leg expansion, and ~6M+ for Middle vault first deposits. This guide explains why, how to simulate safely, and what to put in agent UX.

Why default estimation fails

Ethereum clients estimate gas by simulating the tx at latest block. Multi-adapter `deposit` loops call each adapter's `deposit` → external protocol → token transfers. Some paths (Spark mint, Morpho share conversion, Aave supply) consume variable gas depending on pool state. Estimators that cap iteration depth return errors or undershoot. Forge Phase 1 mainnet smoke explicitly required `--gas-limit 2500000` because default estimation reverted during Spark/Morpho/Aave routing (see contracts handoff A1 execute notes).

• Multiple external calls — each adapter is a separate contract call tree.
• Cold storage writes — first deposit to an adapter touches new slots.
• Token approvals inside adapters — some paths approve upstream protocols inline.
• Revert bubbling — estimator treats any revert as "cannot estimate".
• Post-timelock book changes — more adapters = higher gas ceiling.

Canonical gas limits by vault phase

These are ceilings, not exact usage. Actual consumption may be 1.2M–3.5M depending on adapter state. Setting limit to 4M leaves headroom; setting exactly at estimate risks failure on state drift between simulation and mining.

P2-C0 Core expansion impact

Track P2-C0 adds Gauntlet Prime and Steakhouse HY Morpho legs to Core — five active adapters vs three. First deposit after timelock execute touches more cold paths. MCP docs and some handoffs still mention 2.5M in places; post-P2-C0 integrators must use 4M for deposit and redeem on Core. Re-verify after every adapter timelock execute — see 48-hour timelock guide.

Middle vault — higher ceiling

Middle vault adapters include wstETH and cbETH routes with Aerodrome swaps, plus avUSDC and Moonwell legs. Fork tests and redeploy smoke used `--gas-limit 6000000` or higher. Balanced strategy agents executing two deposits (Core + Middle) should budget gas for both transactions separately — ~4M + ~6M ETH headroom on the agent EOA. Read Balanced strategy for split math.

Step-by-step first deposit flow

1. Fund agent EOA with USDC + ETH on Base (chain ID `8453`).
2. Simulate `approve( vault, amount )` — note gas ~50k–65k.
3. Broadcast approve with standard limit (100k safe).
4. Build `deposit(assets, receiver)` calldata via MCP or ABI encode.
5. Simulate deposit with `gas: 4000000` (Core post-P2-C0) via `eth_call` or wallet.
6. If simulation succeeds, broadcast with same limit — do not lower.
7. Confirm fUSDC balance increase and log tx hash for Stats reconciliation.

USDC on Base mainnet: `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913`. Core vault: `0x2C9a3922b426005B979FDD1A8F43Eb61B309193B`. Never use Ethereum Sepolia USDC or wrong chain ID — common agent failure mode.

ETH buffer sizing on Base

Base gas prices are typically sub-gwei, but multi-million gas limits multiply total ETH cost. Budget 0.001–0.005 ETH on the agent EOA for approve + deposit + future withdraw under normal conditions — more during gas spikes or if retrying failed txs. Monitor Base gas tracker. L1 ETH bridge delays are separate operational concern.

Simulation tools — cast, viem, wallets

Foundry `cast call` with explicit gas: `cast call $VAULT "deposit(uint256,address)" $AMOUNT $RECEIVER --gas-limit 4000000 --rpc-url $BASE_RPC`. In viem, pass `gas: 4_000_000n` on `simulateContract`. MetaMask and Coinbase Wallet often let advanced users set gas limit manually when estimation fails. Agents should never rely on wallet auto-estimate alone for first Forge deposit.

Withdraw and redeem gas

Withdraw pulls USDC from adapters in governance-defined order (Aave last on Core). Phase 1 smoke found default gas often sufficient for withdraw — fewer state writes than inaugural deposit. Post-P2-C0 redeem may still benefit from 4M if multiple adapters unwind. Partial withdraws touch subset of legs — simulate if near limit failures appear.

Sepolia testnet differences

Base Sepolia (chain ID `84532`) uses MockYieldAdapter or shorter adapter books for testnet — gas profiles differ from mainnet. Sepolia is for functional testing, not gas benchmarking. Timelock is zero on Sepolia; mainnet gas docs apply to production agents only.

MCP and agent UX recommendations

• Hard-code recommended gas limits in MCP client configs per vault phase.
• Surface warning when `adapterCount` increases since last deposit — trigger re-simulate.
• Show "first deposit may need ~4M gas" in Conservative onboarding copy.
• Log `gasUsed` from receipts to refine ceilings over time — do not publish as guarantees.
• Pair deposit docs with agent EOA custody guide — CDP wallet is not the deposit signer on prod MCP.

Failure recovery

If deposit reverts with out-of-gas, USDC remains in EOA — no vault exposure. Increase limit and retry. If revert is `InsufficientAssets` or adapter-specific, gas is not the issue — check approvals, pauses, and adapter liquidity. `AdapterWithdrawFailed` events on withdraw indicate partial leg failure — see vault audit fix F-C-04 behavior.

Frequently asked questions

Can I use EIP-1559 maxFeePerGas only without explicit limit?

You still need sufficient gas limit (units of computation). maxFeePerGas controls price per unit, not the unit cap. Forge deposits require explicit high limit.

Why did my second deposit use less gas?

Warm storage slots and already-initialized adapter paths cost less. First deposit is the stress test.

Does approve need 4M gas?

No. Standard ERC-20 approve ~50k–100k is sufficient. Only vault deposit/redeem needs multi-million limits.

Approve patterns and repeat deposits

Many agents set USDC `approve` to `type(uint256).max` once per vault to skip repeat approve txs — document this in security review (infinite allowance to unaudited vault). Alternative: approve exact deposit amount each time — two txs but smaller blast radius if vault compromised. Allowance does not affect deposit gas limit; only `deposit` needs multi-million cap. After successful first deposit, second deposit often succeeds with same 4M limit but may consume less `gasUsed` — do not reduce limit below simulation result.

Hardware wallet and Safe considerations

Ledger/Trezor users must manually set gas limit in advanced fields when estimation fails — UI varies by wallet connect stack. Safe multisig proposals should include explicit gas in the transaction JSON generated by your bundler. Reject proposals where gas limit defaults to 21000 or standard ERC-20 transfer values. For Balanced strategy, submit two separate Safe txs (Core + Middle) with independent limits.

Breakeven vs keeping USDC idle

Gas cost is one-time per deposit path initialization; yield accrues daily on share price. For tiny balances ($10 smoke), gas may exceed short-horizon yield — acceptable for integration testing, not for production treasury optimization. Agents should compute breakeven: `(approve_gas + deposit_gas) * eth_price / daily_yield_on_principal` before automating micro-sweeps. Pair with idle USDC management for policy context.

Cast and Foundry smoke snippet

Engineers mirroring CTO smoke tests: export `BASE_RPC_URL`, set `VAULT=0x2C9a3922b426005B979FDD1A8F43Eb61B309193B`, `USDC=0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913`, approve then `cast send $VAULT "deposit(uint256,address)" $AMOUNT $RECEIVER --gas-limit 4000000 --rpc-url $BASE_RPC_URL --private-key $SMOKE_KEY`. Never commit smoke keys. Verify fUSDC balance with `cast call` on share token after mine.

MCP gas documentation drift

Some MCP handoffs and older docs still cite 2.5M gas — correct for Phase 1 three-leg Core only. Post-P2-C0 and Middle vault docs require 4M and 6M respectively. Agents should treat this Learn article and CTO Persistent state as overriding stale tool description strings until MCP metadata refresh ships. When in doubt, simulate at 4M and inspect `gasUsed` from receipt before lowering ceiling on production agents.

Does Base sequencer downtime affect gas limits?

Sequencer outages delay inclusion but do not change per-op gas unit requirements. Retry same limit after outage clears. Failed txs that never land consume no gas — safe to rebroadcast with identical parameters if nonce unchanged. Track Base network status channels if automating deposit cron jobs.

Summary for agents

Set explicit gas limits on Forge vault deposits — ~4M for Core post-P2-C0, ~6M+ for Middle first deposit, ~2.5M for legacy three-leg Core. Default wallet estimation often fails; simulate with headroom. Keep ETH buffer on agent EOA. Verify adapter count after timelock executes. Read Conservative strategy, MCP-native treasury, and Risks & Disclosures. Log `gasUsed` from every smoke receipt to refine agent defaults over time.