Claim FORGE Merkle rewards: agent guide

Weekly Merkle epochs, MCP get_forge_rewards and claim_forge calldata, and compliance-safe separation from USDC vault yield.

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

FORGE token emissions reward protocol usage — they are not the same as USDC vault yield. Eligible agents accrue claim rights through weekly Merkle roots published by `RewardDistributor` on Base mainnet (`0x44fE9676008154Eb461736F482873Ae7E3F87923`). Claiming requires a separate on-chain transaction with proof — MCP `claim_forge` returns calldata; the agent EOA signs locally. This guide covers the Merkle timeline, MCP tools, and compliance framing. Read FORGE emissions vs vault yield and Risks & Disclosures before marketing claims.

Emissions vs vault shares

Depositing USDC does not auto-mint claimable FORGE to your wallet. Track vault performance via share price on Stats. Track emissions via `get_forge_rewards` and your rewards API workflow. See Tokenomics for the 600M incentive pool schedule (front-loaded months 0–6).

MCP tools for rewards

• get_forge_rewards — query claimable balance for `agentAddress` (read-only).
• claim_forge — build calldata with `epoch`, `agentAddress`, `amount`, `proof[]`.
• Proof bytes come from the Forge rewards API / indexer — not invented by the model.
• Production MCP exposes eight Forge tools only — no CDP signing on Hetzner.

Weekly Merkle workflow for agents

1. Wait for epoch root publication (off-chain announcement + on-chain root update).
2. Fetch proof bundle for agent address from rewards API.
3. Call `get_forge_rewards` to sanity-check claimable amount.
4. Call `claim_forge` — receive unsigned tx envelope.
5. Agent EOA signs and broadcasts on Base (8453).
6. Verify FORGE ERC-20 balance increase on Basescan.

Gas and scheduling

Claims are independent of deposit/withdraw gas. Batch claims per treasury policy — weekly cron is typical. Failed claims from stale proofs require re-fetch after root updates. Do not reuse proofs across epochs.

Compliance-safe agent copy

• Say "eligible FORGE allocation" — not "guaranteed return".
• Disclose illiquidity and unaudited contracts.
• Never imply FORGE price appreciation.
• Separate vault yield sentence from emissions sentence in UI.

Relationship to deposits

Emission eligibility ties to protocol usage rules defined in governance docs — typically fUSDC/fmUSDC deposit activity during an epoch. Exact weighting may evolve. Agents should read current Docs and monitor Stats TVL for context, not as a promise of future epoch weights.

Operational security

• Verify `RewardDistributor` address against `web/src/lib/constants.ts` / deployments JSON.
• Reject proofs from unverified URLs or hallucinated MCP output.
• Use multisig for large claim destinations when policy requires.
• Log epoch, amount, and tx hash for treasury accounting.

Frequently asked questions

Does claim_forge stake my USDC?

No. It only transfers FORGE per Merkle proof. USDC remains in vault shares until you withdraw.

What if I miss an epoch?

Unclaimed amounts depend on distributor design — many Merkle programs allow later claims while root remains valid. Check epoch documentation; do not assume forfeiture without reading contract views.

Can MCP fetch Merkle proofs?

`claim_forge` expects proofs supplied by the integrator. Use the Forge rewards API or indexer your deployment documents — validate against on-chain root.

Summary for agents

FORGE rewards = weekly Merkle claims via `get_forge_rewards` + `claim_forge`, separate from USDC vault NAV. Sign locally on Base. No combined APY marketing. Unaudited — Risks. Vault yield: emissions vs yield. Deposits: USDC workflow.