USDC approve and deposit on Base: agent workflow

Step-by-step approve → simulate → deposit flow for AI agents using Forge MCP on Base mainnet — non-custodial calldata signing.

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

Depositing USDC into Forge on Base mainnet (chain ID `8453`) is a two-step on-chain pattern for most agents: ERC-20 approve then ERC-4626 deposit. The public Forge MCP server returns unsigned calldata for both steps; your agent EOA signs locally. Forge production MCP does not hold private keys or USDC — see MCP-native treasury. This workflow applies to Core (fUSDC) today; Middle (fmUSDC) adds a second vault when Balanced routing is live. Always read Risks & Disclosures first: contracts are unaudited, TVL is early-stage, yield is variable.

Prerequisites

• Agent EOA with ETH on Base for gas.
• USDC balance on Base mainnet (Circle native).
• MCP client pointed at `https://mcp.forgetreasury.com/mcp` or local dev stack.
• Policy: read Stats for live adapter state before deposits > smoke size.

Step 1 — USDC approval

Call `approve(spender, amount)` on the USDC contract with spender = vault address and amount ≥ deposit size. Many agents use exact allowance per deposit to reduce allowance-risk; others use incremental caps per treasury policy. MCP `deposit` tool responses typically include approval calldata when allowance is insufficient. Never approve unlimited USDC from a hot agent wallet without explicit operator consent.

1. Read current `allowance(owner, vault)` via RPC.
2. If allowance < deposit amount, broadcast approve tx and wait for confirmation.
3. Re-check allowance before deposit — race-safe automations should serialize txs.

Step 2 — simulate before deposit

Call MCP `simulate_deposit` with `{ amount: "<usdc>", profile: "conservative" }` (default profile). The tool returns 30/90/365-day illustrative projections, target allocation weights, gas hints, and disclaimers. This is planning UX — not promised returns. Underlying Spark, Morpho, and Aave rates move daily. Full tool walkthrough: Simulate deposit via MCP.

Step 3 — deposit calldata and broadcast

Call MCP `deposit` with amount and profile. Response includes `to`, `data`, `value`, and chain context for `ForgeVault.deposit(assets, receiver)`. Set receiver to the agent EOA (or treasury multisig) that should hold fUSDC shares. Sign with the same EOA that holds USDC. Recommend elevated gas (~4M) on first deposit after multi-adapter timelock expansions (P2-C0).

Balanced routing (two vaults)

Balanced strategy targets Core + Middle. Until MCP Phase 2 multi-vault calldata ships, agents perform two approve/deposit sequences — one per vault address. Middle may return `PROFILE_NOT_LIVE` until adapters execute post-timelock. See Balanced strategy and verify Middle on Stats. Infra vault is not deployed; 10% Infra weight redirects to Middle in canon.

Post-deposit monitoring

• Track fUSDC balance and implied USDC via MCP `get_balance` or Stats.
• Share price accrues with adapter yield — separate from FORGE Merkle claims.
• Withdraw path: MCP `withdraw` calldata; 15% performance fee on profits above HWM.
• Claim FORGE only via separate `claim_forge` flow — Merkle rewards guide.

Common failure modes

Security practices for agent operators

• Never paste private keys into MCP or browser docs pages.
• Simulate every new amount tier — adapter books change on timelock.
• Cap per-tx deposit size in agent policy until audit milestones.
• Log tx hashes and vault addresses for treasury reconciliation.

Frequently asked questions

Can MCP sign the deposit for me?

No on production Forge MCP (Option A). The server returns calldata only. Local AgentKit + CDP experiments may sign on engineer machines — never route production user deposits through CDP custody. See Docs and custody rules in repo handoffs.

Do I need approve every time?

Only when remaining allowance is below the next deposit amount. Exact-approve workflows need one approve per deposit; standing allowances amortize gas but increase allowance risk if the vault address were ever compromised.

What receiver address should I use?

Typically the same agent EOA that deposits. Using a multisig receiver is valid for DAO treasuries — ensure your accounting system tracks shares held by that contract.

Summary for agents

Workflow: fund Base ETH → hold Base USDC → `simulate_deposit` → `approve` if needed → sign MCP `deposit` calldata → monitor fUSDC on Stats. Chain 8453 only. Unaudited, variable yield — Risks. Share semantics: ERC-4626 explainer.