> For the complete documentation index, see [llms.txt](https://gotts.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gotts.gitbook.io/docs/gotts-vaults/vault/14-milestones.md).

# Milestones

> **Part of**: [Vault PRD](/docs/gotts-vaults/vault.md) | **Last Updated**: 2026-02-16

***

## Milestones and Phases (Core-First)

This milestone plan is intentionally sequenced for a **core-first v1** release:

1. Factory + vault core (including inflation attack mitigation, linear profit unlock)
2. Core MCP + SDK ergonomics (unified server with vault profile)
3. Safety and operational hardening + am-AMM strategy auctions
4. Reputation engine + adapter architecture
5. Mainnet readiness

CCA lifecycle and viral growth mechanics are explicitly deferred until after v1 acceptance gates are met. The am-AMM StrategyAuctionModule has been promoted from deferred to Phase 3 (D-012).

***

### Phase 0: Baseline Lock (Week 0-1)

**Goal**: Align PRD, implementation baseline, and acceptance criteria before feature work.

**Deliverables**:

* [ ] `DRIFT-MATRIX.md` updated and approved
* [ ] `IMPLEMENTATION-STATE.md` baseline refreshed to core-first tool/agent counts
* [ ] Canonical/legacy file mapping validated in `README.md`
* [ ] Core-v1 tool inventory frozen in `08-mcp-tools.md`

**Acceptance Gate P0**:

* No unresolved cross-doc count conflicts for tools, agents, skills, or phases.
* Every legacy duplicate file is marked non-authoritative.

***

### Phase 1: Factory and Vault Core (Weeks 1-5)

**Goal**: Ship permissionless vault creation and core ERC-4626 operations with identity gating.

**Deliverables**:

* [ ] `AgentVaultFactory.sol` with CREATE2 deployment and on-chain registry
* [ ] `AgentVaultCore.sol` with ERC-4626 behavior, ERC-8004 gate checks, `_decimalsOffset(6)` (D-017), and linear profit unlock (D-018)
* [ ] `RiskEngine.sol` with unified risk parameters: adapter exposure caps, drawdown thresholds, oracle freshness, share price bounds (D-056)
* [ ] `ParameterDecisionTable.sol` with per-parameter authority, timelock, bounds, and justification hash (D-059)
* [ ] Core risk parameters in vault config (per-agent cap, TVL cap, reserve floor, breaker) consolidated into RiskEngine
* [ ] Internal asset accounting (bookkeeping, not `balanceOf`) for inflation attack resistance
* [ ] `NAVAwareHook.sol` with NoOp NAV pricing, asymmetric fees, and NAV guardrail system (D-062): discrete snapshots at configurable cadence, rate-of-change clamp (`navMaxChangeBps`), oracle staleness gates with spread widening, and market safety mode on circuit breaker triggers
* [ ] Auto-market creation: factory calls `PoolManager.initialize()` to create share/base V4 pool on vault deployment
* [ ] `LaunchFeeHook.sol` with parabolic descending-fee MEV protection (deployed alongside NAVAwareHook)
* [ ] Deployment scripts for local and test environments
* [ ] Core contract tests for factory + vault lifecycle + share pool creation

**Acceptance Gate P1**:

* `createVault -> registerAgent -> deposit -> withdraw` passes on local testnet.
* Auto-created share pool is tradeable on Uniswap V4 after vault creation (when `autoPoolEnabled=true`).
* NAVAwareHook prices shares within configured spread of `vault.convertToAssets(1e18)`.
* NAV guardrails: snapshot cadence produces expected update frequency; rate-of-change clamp rejects NAV jumps exceeding `navMaxChangeBps`; staleness gates widen spread at 80% staleness and disable NAV pricing at 100%.
* Market safety mode: NAV pricing disables and spreads maximize when Tier 2+ circuit breaker triggers.
* LaunchFeeHook descending fees decay correctly from max to base over configured duration.
* Unauthorized/non-registered agent interactions are rejected on-chain.
* RiskEngine correctly enforces adapter exposure caps and oracle freshness checks.
* ParameterDecisionTable correctly timelocks parameter changes and enforces bounds.
* Contract test suite passes with deterministic outputs across two clean runs.

***

### Phase 2: Core MCP + SDK Path (Weeks 6-9)

**Goal**: Make core functionality usable by external agents and builders.

**Deliverables**:

* [ ] Core MCP vault tools implemented (factory, deposit, read, identity/reputation basics, rankings)
* [ ] Core SDK clients implemented (`VaultFactoryClient`, `VaultClient`, `ReputationReader`, `SharePoolClient`)
* [ ] 4-step explicit quickstart validated end-to-end
* [ ] `OnboardRouter.sol` contract deployed — batches identity registration + Permit2 approval + reputation enrollment + deposit into single call
* [ ] `vault_onboard_and_deposit` MCP tool implemented — ERC-4337/EIP-7702 batch onboarding path
* [ ] ERC-7677 paymaster integration validated for gasless batch onboarding on Base
* [ ] Local swarm path (`pnpm testnet:swarm`) updated for core-first scope

**Acceptance Gate P2**:

* Core tool calls succeed through stdio and HTTP+SSE transports.
* Explicit quickstart from clean environment to first deposit completes in under 5 minutes.
* Single-UserOp onboarding via `OnboardRouter` completes in under 30 seconds with paymaster sponsorship.
* At least one external integration script can execute full core lifecycle only via MCP tools.

***

### Phase 3: Safety, Proxy Hardening, and am-AMM (Weeks 10-15)

**Goal**: Enforce role-based safety policy, operational controls, and launch am-AMM strategy management auctions.

**Deliverables**:

* [ ] Proxy enforcement matrix implemented in docs/config/policy templates
* [ ] Required proxy path for manager/admin-class operations
* [ ] Variable-delay policy defined by risk tier and operation class
* [ ] Clear simulation/execute/cancel ownership model documented
* [ ] Monitoring/cancel workflows and fail-mode behavior specified
* [ ] `StrategyAuctionModule.sol` deployed with Harberger lease auction for vault management rights (D-012)
* [ ] am-AMM MCP tools: `vault_bid_management`, `vault_topup_rent`, `vault_withdraw_rent`, `vault_get_manager`, `vault_evict_manager`
* [ ] Four-role governance model (Owner/Curator/Allocator/Sentinel) integrated with vault core (D-020)
* [ ] `vault-auctioneer` agent and `bid-vault-management` skill
* [ ] ERC-7265 three-tier circuit breakers (slow mode / agent pause / full pause)
* [ ] `HookKillSwitch` extension deployed on all factory hooks — Sentinel-callable `disableHook()` with Owner+Curator `longTimelock` re-enable (D-058)
* [ ] Adapter data attestation hashing in adapter registry — `allocate()`/`deallocate()` accept only pre-registered `dataHash` values (D-060)

**Acceptance Gate P3** (proxy is a **mainnet-blocking gate**):

> **Phase 3 is the proxy gate.** The simplified v1 proxy (announce + fixed delay + cancel) MUST be functional before Phase 5 mainnet launch. Without it, the security model relies on TEE + policy engine alone, which has a documented 12% prompt injection bypass rate (D-036). See [10-safety.md](/docs/gotts-vaults/vault/10-safety.md) Section "v1 Minimum Proxy" for the simplified v1 specification.

* High-risk operations cannot bypass required proxy path.
* Cancel authority can block queued high-risk operations during delay window.
* Fail-closed behavior is validated for required proxy routes under monitor degradation.
* am-AMM bid submission, management transition, and eviction lifecycle passes on local testnet.
* Reputation-gated bidding rejects agents below Verified tier (score < 50).
* ERC-7265 circuit breakers trigger at correct NAV drawdown thresholds.
* Hook kill-switch: `disableHook()` correctly bypasses all hook logic; pool continues as standard V4 pool.
* Hook re-enable: requires executed ParameterDecisionTable change with `longTimelock`.
* Adapter data attestation: adapters reject calls with unregistered `dataHash`.
* Governance control loop: parameter changes above `shortTimelock` require simulation artifact hash (D-059a) — changes without simulation reference are rejected by ParameterDecisionTable.
* Rollback plans: critical parameter changes (adapter/hook/oracle) must include rollback trigger conditions stored in justification blob.

***

### Phase 4: Reputation Engine + Adapter Architecture (Weeks 16-20)

**Goal**: Deliver minimal, anti-gaming reputation progression and pluggable adapter architecture for strategy extensibility.

**Deliverables**:

* [ ] `vault_enroll_reputation`, `vault_get_milestones`, `vault_claim_milestone`
* [ ] Milestones focused on verifiable core participation events
* [ ] Anti-gaming controls (self-attribution guardrails, minimum meaningful activity thresholds)
* [ ] Quickstart includes reputation enrollment path
* [ ] Agent0 SDK integration (`@agent0/sdk`) with Privy EIP-1193 provider wrapper (D-080, D-081)
* [ ] ERC-8004 registration file with `services` array (MCP/A2A/OASF endpoints) for all vault participants (D-086)
* [ ] Continuous yield feedback track: `vault_submit_yield_feedback` tool using `tradingYield` tag (D-082, D-087)
* [ ] Qualitative feedback track: `vault_submit_qualitative_feedback` tool (D-082)
* [ ] `search_yield_opportunities` tool combining identity + reputation + metadata (D-082)
* [ ] A2A Agent Card specification for vault-manager (yield\_strategy\_consultation, vault\_risk\_assessment, rebalance\_proposal skills) (D-083, D-086)
* [ ] `StrategyAdapter` interface and adapter registry (D-019)
* [ ] First adapter implementations: `MorphoSupplyAdapter`, `AaveV3SupplyAdapter`
* [ ] `forceDeallocate()` in-kind redemption with 2% penalty
* [ ] RedStone oracle integration as primary price feed (D-021)
* [ ] Multi-oracle aggregation with auto-pause on >2% divergence

**Acceptance Gate P4**:

* New agent can enroll, complete first milestone, and claim successfully.
* Duplicate or manipulated milestone claims are rejected.
* Milestone outputs are deterministic for the same on-chain state snapshot.
* Adapter registration, capital deployment, and withdrawal lifecycle completes on testnet.
* `forceDeallocate()` correctly distributes underlying positions pro-rata with 2% penalty.
* Agent0 SDK registers a vault manager with correct on-chain metadata and registration file.
* Yield feedback submission via `tradingYield` tag appears in Reputation Registry and is queryable.
* `search_yield_opportunities` returns ranked results combining identity, reputation, and metadata filters.
* A2A Agent Card for vault-manager resolves correctly from ERC-8004 registration file `services` array.

***

### Phase 5: Mainnet Readiness and Launch (Weeks 18-22)

**Goal**: Launch the core-first protocol safely on Base.

**Deliverables**:

* [ ] Audit scope finalized for vault core and required safety controls
* [ ] Critical findings resolved with regression tests
* [ ] Base deployment scripts finalized and reproducible
* [ ] Production runbooks for incident response and safety controls
* [ ] SDK and MCP docs published for core-first scope
* [ ] MCP server registered as ERC-8004 entity with `role: "infrastructure"` metadata (D-084)
* [ ] SIWE + JWT authentication for remote MCP server deployments (D-085)
* [ ] Role-based tool authorization matrix (vault\_manager/investor/infrastructure roles) (D-085)
* [ ] Yield leaderboard subgraph deployed indexing `NewFeedback` events by `tradingYield` tag (D-087)
* [ ] `vault_get_yield_leaderboard` tool returning ranked vault managers by yield/Sharpe/drawdown (D-087)
* [ ] Infrastructure feedback track: automated uptime/response time monitoring for MCP server identity (D-084)
* [ ] Production monitoring dashboards deployed covering 4 categories: vault health, share pool integrity, strategy/adapters, governance (see [10-safety.md](/docs/gotts-vaults/vault/10-safety.md) Production Monitoring Dashboards)
* [ ] Alert threshold configuration for Forta + OpenZeppelin Monitor stack with all signal/warning/critical thresholds from the alert table
* [ ] Canonical event schema deployed (D-066): all vault contracts emit standardized events (`VaultHealthSnapshot`, `NAVUpdate`, `RiskWarning`, `ParameterChanged`, `CircuitBreakerTriggered`, `HookStateChanged`, `WithdrawalQueued`)
* [ ] On-chain health attestation view functions deployed (D-066): `riskEngine.getHealthAttestation(vault)` returns composite health status queryable by external protocols
* [ ] Adapter conservation invariant test suite: property-based tests for all four mandatory invariants (totalAssets monotonicity, balance conservation, in-kind exit safety, data attestation)
* [ ] **a16z ERC-4626 property test suite** (`a16z/erc4626-tests`) passes for all vault templates — validates round-trip properties (no free profit from deposit→withdraw), preview function accuracy, caller independence, and functional correctness
* [ ] **Handler-based invariant tests** (Foundry `forge test --invariant` with handler contracts and `useActor` modifier for multi-depositor simulation):
  * `totalSupply == sum of all individual balanceOf entries`
  * `totalAssets >= totalSupply * exchange_rate` (solvency)
  * Share price monotonicity (only increases from yield, never decreases except from explicit losses)
  * `previewDeposit(x) <= actual deposit(x)` (preview never overestimates shares)
  * No free profit from deposit→withdraw roundtrip
* [ ] **Slither static analysis** with zero high/critical findings on all core contracts
* [ ] **Formal verification scope** defined and executed (Certora Prover or Halmos):
  * Total supply consistency
  * Solvency invariants
  * Access control correctness (role boundaries, onlyPoolManager enforcement)
  * Fee calculation properties (caps enforced, preview accuracy)

**Acceptance Gate P5**:

* No unresolved critical/high audit findings in core scope.
* Mainnet deployment dry run reproduces expected contract addresses/config.
* Post-deploy smoke tests pass for factory creation, registration, deposit, and withdrawal.
* All monitoring dashboards are live and alert thresholds fire correctly in staging environment.
* Canonical event schema: all events from the standard taxonomy are emitted at correct cadences and contain expected fields.
* Health attestations: `getHealthAttestation()` returns correct composite results for healthy vaults and correctly flags unhealthy vaults (failed oracle freshness, breached adapter caps, etc.).
* Adapter conservation invariant test suite passes for all shipped adapters.
* a16z ERC-4626 property test suite passes for all vault templates (Simple Yield, CCA Hunter, LP Manager, Full Stack, Meta-Vault).
* Handler-based invariant tests pass with >= 10,000 runs per invariant.
* Slither reports zero high/critical findings; medium findings documented with rationale if accepted.
* Formal verification properties proven for total supply, solvency, access control, and fee calculations.

***

## Deferred Tracks (Post-v1)

### Track A: CCA Expansion

Deferred MCP/tooling and contract surface:

* `submit_cca_bid`
* `exit_cca_bid`
* `claim_cca_tokens`
* `deploy_liquidity`

Entrance criteria:

* Core safety gates (P3+) stable in production-like staging
* Additional valuation and auction-risk model validated

### Track B: Viral Growth Mechanics

Deferred mechanics:

* Multiplier points
* Referrals and recruitment trees
* Streak mechanics and welcome bonus pools
* One-click growth-oriented bundled deposit paths

Entrance criteria:

* Core retention and reliability targets hit for two consecutive measurement windows
* Anti-abuse model validated for Sybil and referral farming scenarios

***

### Phase 6: V4 Integration Expansion (Post-v1)

**Goal**: Expand V4 integration with advanced strategy modules that increase vault yields and Uniswap volume.

**Deliverables**:

* [ ] `RehypothecationAdapter.sol` with Morpho, Aave V3, and Seamless lending venue adapters
* [ ] TWAMM rebalancing integration — `RebalanceParams.useTWAMM` flag and `twammDuration` parameter
* [ ] Permit2 agent delegation pattern — bounded, time-limited agent authority via `SignatureTransfer`
* [ ] Universal Router batch rebalancer — atomic multi-step rebalance in a single transaction
* [ ] `vault_configure_rehypothecation` MCP tool
* [ ] `StrategyEngine.recommendTWAMM()` and `estimateRehypothecationYield()` SDK methods
* [ ] Share pool monitoring skill (`monitor-share-pools`)

**Acceptance Gate P6**:

* Rehypothecation deploys idle tokens and withdraws JIT before incoming swaps.
* TWAMM rebalance achieves lower slippage than immediate swap for operations >1% of pool TVL.
* Permit2 delegation reverts when agent exceeds configured bounds.
* Cross-vault arbitrage detection produces actionable signals from share pool event data.

**Entrance criteria**:

* Phase 5 (mainnet) stable for at least 4 weeks
* Lending protocol adapters audited independently
* TWAMM hook deployed on Base and validated with real pools

### Track C: Advanced V4 Hooks and Self-Learning Vaults

Deferred hooks requiring complex economic design or external infrastructure:

* Agent strategy auction (am-AMM) — auction vault management rights to highest-bidding ERC-8004 agent
* Reputation-tiered LP access — gate concentrated LP range widths by agent reputation score
* JIT liquidity vault strategy — professional JIT LP provision with depositor revenue sharing
* `PolicyCage.sol` deployment — on-chain hard boundaries for AI agent strategy (D-053). Approved asset list, max position sizes, strategy whitelists, max drawdown, rebalance frequency limits. Maps to Yearn V3 role system with `DEBT_MANAGER` caps.
* Debt Allocator with APR oracles — automated strategy rotation across adapters within policy cage constraints
* Numerai-inspired competing strategy models (deferred R\&D) — stake-weighted ensemble allocation across external strategy submissions

Entrance criteria:

* Phase 6 V4 integration modules stable in production
* ERC-8004 reputation ecosystem has sufficient depth (>10K agents with reputation >50)
* am-AMM economic model validated via simulation/testnet
* Policy cage contract audited independently

### Track D: Cross-Vault Ecosystem and Automation

Deferred infrastructure for multi-vault coordination and native automation:

* Cross-vault arbitrage router — multi-hop arbitrage across vault share pools via Universal Router
* Indexing infrastructure — real-time NAV vs pool price monitoring across all factory vaults
* Vault share CCA launches — fair initial pricing for new vault strategies via Continuous Clearing Auctions
* `LiquidityRouter.sol` deployment — inter-vault lending of idle capital at utilization-curve-determined rates (D-054). Vaults borrow from peers during withdrawal spikes or rebalancing instead of holding excessive idle reserves. Max 20% of TVL borrowable, 24h max duration.
* `ExecutionMarket.sol` deployment — native on-chain bonded keeper registry wrapping the `IExecutable` interface (D-057). Upgrades the Permissionless Executor Framework (D-061, shipped with core v1) with bonding, slashing, and a structured job registry. Initial bonded job scope: `harvest`, `reportProfit`, `processWithdrawalBatch`. Permissionless executor entry with bonding (0.1-5 ETH equivalent by job VAR). Slashing for provable misbehavior (10-50%). The existing Tier 1 permissionless fallback remains — anyone can still execute after max delay. Agents who were already executing v1 permissionless jobs can bond and upgrade to Tier 2 with no interface migration. Replaces external Gelato/Chainlink Keepers dependency.
* `RebalanceIntentModule.sol` deployment — intent-based solver competition for large vault rebalances (D-064). Vault manager posts intent (target positions, max slippage, deadline); permissionless solvers submit sealed bids (commit-reveal) with execution calldata and anti-grief bond; best valid bid wins with surplus credited to vault. TWAMM fallback if no valid winner. Parameters: `auctionDurationBlocks` (default 3 on L2), `defaultSlippageBps` (default 30), `minRebalanceBpsForAuction` (default 100 = 1% of TVL). Forward-compatible with D-061 `IExecutable` interface.

**Note**: The Permissionless Executor Framework (D-061) ships with core v1, providing day-one execution for CrossVaultCoordinator, LVR-theta calibration, behavioral classification, and proxy execution via the `IExecutable` interface. Track D's ExecutionMarket adds the bonded tier on top — it does not replace the permissionless base layer. See [06-contracts.md](/docs/gotts-vaults/vault/06-contracts.md) Section 10.1b for the v1 framework and [16-synergies.md](/docs/gotts-vaults/vault/16-synergies.md) Section 21.8 for the two-tier synergy narrative.

Entrance criteria:

* Factory has >50 active vaults with auto-created share pools
* Share pool trading volume justifies indexing infrastructure investment
* CCA track (Track A) promoted and stable
* Sufficient idle capital diversity across factory vaults to make inter-vault lending viable
* Keeper profitability backtested against job frequency; executor competition simulated (for ExecutionMarket)
* Permissionless executor ecosystem (D-061) demonstrated healthy: executor diversity above thresholds, escalation rates acceptable, gas pools self-sustaining

### Track E: Infrastructure Composability

Share token composability integrations, am-AMM management auctions, and DeFi primitive adapters:

* Share token listing on Pendle (PT/YT splitting for fixed-yield products)
* Share token qualification as collateral on Morpho (enabling leverage loops)
* `StrategyAuctionModule.sol` deployment — am-AMM Harberger lease auctions for vault management rights (see [06-contracts.md](/docs/gotts-vaults/vault/06-contracts.md) Section 10.16)
* Cross-vault factory-level insurance activation (Ease.org uninsurance model, see [10-safety.md](/docs/gotts-vaults/vault/10-safety.md))
* Agent-to-agent referral module activation with on-chain attribution
* `RecursiveLendingAdapter.sol` deployment — atomic flash-loan leverage loops via Morpho Blue and Aave V3 E-Mode (D-048). 5-8x max leverage on Base with continuous HF monitoring.
* `PendleAdapter.sol` deployment — PT/YT yield tokenization with fixed-rate capture and yield stripping strategies (D-051). Includes Pendle Prime auto-listing for vault share tokens.
* `CreditDelegationAdapter.sol` deployment — reputation-gated uncollateralized borrowing via Aave V3 credit delegation (D-052). Trust progression from insurance → reputation → delegation → leverage.

Entrance criteria:

* Phase 5 (mainnet) stable for at least 4 weeks
* 100+ active depositing agents
* am-AMM economic model validated via testnet simulation
* Pendle/Morpho integration partnerships confirmed
* Lending protocol adapters audited independently (for RecursiveLending and CreditDelegation)

### Track F: Structured Products

Structured DeFi products built on the vault factory:

* `TrancheModule.sol` deployment — Perpetual Yield Tranches (PYT) splitting vault shares into Senior (AA, protected yield) and Junior (BB, first-loss/boosted yield) tokens (D-049). Vault creators required to hold 5%+ of TVL in Junior shares as skin-in-the-game. Adaptive yield split based on Senior/Junior liquidity ratio.
* `BondMMHook.sol` deployment — V4 hook implementing BondMM-A for fixed-rate lending across arbitrary maturities (1 week to 1 year) in a single liquidity pool (D-055). AI agents determine optimal maturity allocation based on yield curve shape.
* Tranche token composability — Senior AA tokens as conservative Morpho collateral, Junior BB tokens as leverage collateral
* Fixed-rate vault strategies combining BondMM lending with Pendle PT capture

Entrance criteria:

* Phase 6 V4 integration stable for at least 4 weeks
* Track E lending adapters audited and operational
* Sufficient depositor demand for risk-segmented products (survey or waitlist validation)
* BondMM-A hook audited by V4-specialized firm