Forge vault 48-hour timelock for adapter changes

How Forge schedules and executes adapter additions on Base mainnet — 48h delay, pending ops, P2-C0 Core expansion, and Middle vault activation.

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

Every ForgeVault on Base mainnet routes USDC through modular adapters — Spark Savings, Morpho curated vaults, Aave V3, and (on the Middle bucket) LST and avUSDC legs. Changing that adapter book is not a hot-swappable admin call. The vault owner must schedule adapter additions, weight changes, or removals on a 48-hour timelock, wait for the delay to elapse, then execute on-chain. Integrators, agents, and treasury operators who treat adapter lists as static will mis-price risk. This guide explains how Forge timelock governance works, what appears on-chain during the waiting period, and how to monitor pending changes before you deposit.

Why a 48-hour delay exists

Yield vaults that can reallocate capital instantly create information asymmetry: the owner could schedule a risky adapter milliseconds before a large deposit lands. Forge inherits a Compound-style timelock pattern via `TimelockController` mixed into `ForgeVault`. On Base mainnet (chain ID `8453`), `_delay()` returns 172800 seconds — exactly 48 hours. Base Sepolia testnet (chain ID `84532`) uses zero delay for engineering velocity; do not extrapolate Sepolia behavior to mainnet.

• Transparency — pending ops are visible in contract storage and events before execution.
• Exit window — depositors who disagree with a scheduled change can withdraw before execute (subject to liquidity and gas).
• Integrator lead time — MCP clients and dashboards can warn users when `adapterCount` is about to change.
• Operational discipline — owner batches (P2-C0 Core expansion, Middle four-adapter book) follow the same cadence.

Schedule vs execute — the two-step flow

Adapter governance uses paired functions: `scheduleSetAdapter` / `executeSetAdapter` and `scheduleRemoveAdapter` / `executeRemoveAdapter`. Scheduling writes a `PendingAdapterChange` struct keyed by an `opId` bytes32 hash that includes the vault address (post audit fix F-L-01) so multiple ForgeVaults on the same chain cannot collide. Execution checks that `block.timestamp >= scheduledAt + delay` before mutating the live adapter array.

What integrators see during the waiting period

Between schedule and execute, `adapterCount` and live allocation bps do not change. A Middle vault with `adapterCount = 0` remains empty until execute — even if four adapters were scheduled days earlier. This is the most common integration bug: reading MCP vault info or Stats and assuming scheduled adapters are already routing deposits. Cross-check Basescan for `AdapterScheduled` events and pending op mappings.

1. Owner broadcasts `scheduleSetAdapter` with target adapter address and basis-point weight.
2. Forge emits `AdapterScheduled(opId, adapter, allocationBps)`.
3. Subgraph and Stats may show target rows separately from live rows when wired.
4. After 48h, owner calls `executeSetAdapter(opId)`.
5. Forge emits `AdapterUpdated(index, adapter, allocationBps)` — book is live.
6. First deposit after expansion may need elevated gas (~4M on Core post P2-C0) — see Base gas limits.

P2-C0 Core expansion (reference timeline)

Track P2-C0 expands the Core vault from three adapters (Spark / Morpho Steakhouse / Aave) to five legs including Gauntlet Prime and Steakhouse HY. Scheduling occurred in May 2026 with execute windows around May 27, 2026 UTC. Until Batch B execute completes, live weights remain Phase 1. Agents running Conservative strategy should re-read adapter bps on every deposit — the book changes without a frontend deploy.

Middle vault timelock (Balanced strategy dependency)

The Middle vault at `0x7c77a29f761C9Bf4fA4Be5Ae3fa527690DE60307` on Base mainnet deployed with four adapters scheduled — wstETH, cbETH, Avantis avUSDC, and Moonwell Flagship. Until execute, `adapterCount = 0` and fmUSDC deposits route nowhere useful. Balanced strategy agents must verify Middle execution before splitting USDC across Core + Middle. Do not confuse this address with legacy Sepolia docs — always label Base mainnet Middle.

• WstETH adapter — LST exposure via Lido + Aerodrome swap path.
• CbETH adapter — Coinbase LST leg with similar swap mechanics.
• Avantis avUSDC — perp LP ERC-4626; higher complexity and counsel review for marketing.
• Moonwell Flagship — Morpho-curated USDC leg in the Middle book.

Withdraw ordering and timelock interaction

Adapter index order affects withdraw sequencing in `_redeemFromAdapters`. Product canon schedules Aave last on Core — deepest secondary liquidity and utilization buffer. Timelock changes that insert Aave at a lower index would alter withdraw priority; integrators should read post-execute index assignments, not just bps weights. A single adapter revert no longer bricks the entire vault (audit fix F-C-04 uses try/catch per leg), but partial liquidity can still delay full exits.

Monitoring pending timelocks

Use three layers: on-chain (Basescan events + `pendingAdapterChanges` reads), Forge subgraph (Adapter entities after `AdapterUpdated`), and **Stats** (human-readable adapter table + share price). Subgraph indexing lags blocks — for dispute resolution or large deposits, prefer direct RPC reads via viem or cast. MCP `forge_get_vault_info` should surface warnings when known pending ops exist; treat MCP as convenience, not sole source of truth.

Sepolia vs mainnet timelock behavior

Base Sepolia ForgeVault uses `_delay() == 0`, enabling `addAdapterForTestnet` for rapid iteration. Testnet adapter books can change in a single transaction block — never use Sepolia timelock assumptions when writing mainnet agent policies. Sepolia vault addresses and USDC (`0x036CbD53842c5426634e7929541eC2318f3dCF7e`) differ from mainnet. Full testnet handoff: `docs/SEPOLIA_DEPLOY.md` via site docs.

Agent policy templates

Production agents should encode timelock awareness in system prompts: (1) read `adapterCount` before deposit; (2) if Stats shows pending targets, surface a human-readable warning; (3) re-simulate gas after execute — multi-adapter first deposits need ~4M limit on Core; (4) block Balanced routing until Middle `adapterCount >= 4`. Pair with MCP-native treasury for calldata-only integration and monitor vault share price for ongoing NAV checks.

• Poll vault info at most once per block — respect RPC rate limits.
• Cache adapter bps with TTL ≤ 1 hour on mainnet during active timelock windows.
• Log `opId` when warnings fire — aids post-mortems if execute surprises users.
• Never auto-deposit maximum balance within minutes of detected `AdapterScheduled` unless policy explicitly allows.

Relationship to pause and emergency controls

Timelock governs structural changes (adapters, weights). Separate from timelock, the owner can `pause(expiresAt)` with a maximum 30-day bounded window (audit fix F-M-04). Pauses block deposits and withdraws until expiry or explicit unpause. Aave, Morpho, or Spark can also pause markets independently — Forge timelock does not control upstream protocol guardians. Risk disclosure: composability means multiple pause levers.

Frequently asked questions

Can the owner skip the 48-hour delay on mainnet?

No. Mainnet `_delay()` is fixed at 48 hours in the TimelockController mixin. Only chains with zero delay (Sepolia testnet) allow instant adapter adds via testnet helpers.

Do scheduled adapters earn yield before execute?

No. USDC routes only through executed, active adapters. Pending schedules are metadata until execute mutates the adapter array.

What happens if execute is never called?

The live book remains unchanged indefinitely. Pending ops occupy storage but do not affect deposit routing. Owner can abandon a schedule (no execute) without on-chain cancel in some versions — verify ABI for your deployment.

How does timelock interact with performance fees?

Adapter changes do not reset per-user cost basis. Withdraw fees apply on profit above entry price regardless of which adapter generated yield. See performance fee guide.

Batch operations and opId hygiene

Large governance batches (P2-C0 Core expansion, Middle four-adapter activation) may schedule multiple `scheduleSetAdapter` calls in separate transactions — each generates a distinct `opId`. Execute txs must match the scheduled op exactly; a typo in `opId` reverts with no state change. Owner operations use the Forge deployer key — not agent EOAs. Integrators do not execute timelocks, but should subscribe to `AdapterScheduled` logs filtered by vault address to update internal runbooks. After Batch A execute (adapter adds) and Batch B (removes/reweights), run Core smoke at 4M gas before announcing adapter stability to users.

Communicating timelock windows to end-users

If your agent serves DAO members, surface human-readable timelock copy: "Forge Core adapter weights may change on {execute_date} — live book unchanged until then." Link Stats and this guide. Do not promise APY stability across timelock boundaries — new Morpho legs change rate exposure. CMO-safe framing: "verify on-chain before deposit" not "guaranteed diversification."

Summary for integrators

Forge adapter governance is schedule → wait 48h → execute on Base mainnet. Live `adapterCount` and bps are unchanged until execute. Monitor Basescan events, Stats, and MCP warnings before deposits — especially during P2-C0 Core expansion and Middle vault activation. Sepolia has zero delay; mainnet does not. Contracts unaudited; timelock is transparency, not insurance. Read Conservative strategy for Core-specific parameters and Risks & Disclosures before moving production USDC.