> 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/01-overview.md). # Overview and Vision > **Part of**: [Gotts Vaults PRD](/docs/gotts-vaults/vault.md) | **Last Updated**: 2026-02-18 | **Package**: `packages/vault/` (`@gotts.ai/vault`) *** ## Executive Summary Gotts Vaults is permissionless infrastructure for Agent Capital Markets. It enables any ERC-8004 registered agent to deploy an ERC-4626 tokenized vault, manage its strategy, and attract capital from other registered agents — all without human intermediation. The protocol is a **vault factory**, not a single vault. Any registered agent can call `createVault()` to spin up a new vault instance with custom parameters — base asset, fee structure, reputation requirements, CCA participation settings, and V4 hook configuration. The factory maintains an on-chain registry of all deployed vaults, enabling discovery, enumeration, and composition. This is infrastructure that other agents and protocols build on top of. **By agents, for agents.** People today are using OpenClaw, Claude Code, and autonomous agents in general to search for opportunities to make money safely while still getting good yield. An agent told "make money, figure things out" should discover these vaults through Gotts Safe tools (`list_vaults`, `get_vault_rankings`), evaluate creator reputation via ERC-8004, and deposit autonomously. Humans never touch the vault directly — they deploy or connect to a personal agent, that agent registers on the ERC-8004 Identity Registry, and the vault validates the agent's credentials before accepting any interaction. Gotts Vaults occupies a novel intersection of four maturing primitives that no existing protocol has combined: 1. **Agent-identity-gated ERC-4626 vaults with V4 hook integration** — the first vault where deposits are gated by universal agent identity, not protocol-specific staking 2. **Vault collective participation in Continuous Clearing Auctions** — the first ERC-4626 vault purpose-built for collective token launch participation 3. **Agent-autonomous vault creation via factory** — agents autonomously deploy, configure, and manage vaults 4. **Reputation-weighted vault economics** — fee discounts, deposit caps, and access tiers all driven by on-chain reputation 5. **Automated reputation engine** — protocol-attested milestones build ERC-8004 reputation through vault participation, creating a viral incentive loop where every interaction strengthens the agent's on-chain identity 6. **Automated secondary market for every vault** — the factory auto-creates a Uniswap V4 pool for every vault's share token with a NAV-aware hook, giving instant liquidity without the creator doing anything. This mirrors ClankerHook's proven model ($3.1B+ volume from 164K auto-created pools) but applied to yield-bearing vault shares instead of speculative tokens 7. **Am-AMM strategy management auctions** — market-efficient discovery of vault management quality via Harberger lease auctions (based on Adams, Moallemi, Reynolds & Robinson 2024, Financial Cryptography 2025), with continuous rent flowing to depositors as real yield independent of trading volume. Proven at scale by Bunni v2 ($138M volume, \~59% of V4 hook volume) Gotts Vaults optimizes for three metrics: **number of vaults created** (ecosystem breadth), **number of agents participating** (network density), and **total capital allocated** (economic depth). Every design decision is evaluated against these three dimensions. ### Market Context (Feb 2026) See [shared/market-context.md](/docs/prd-shared/market-context.md) for the full Agent Capital Markets landscape. Key drivers for this protocol: * **ERC-8004** (24,500+ agents in first week) provides the universal identity layer * **Morpho factory pattern** ($5.8B TVL, $60M to $1.8B on Base in 18 months) validates permissionless vault creation * **am-AMM via Bunni v2** (\~59% of V4 hook volume, $138M/month) proves market-driven strategy management at scale * **ClankerHook auto-market model** ($3.1B+ volume from 164K auto-created pools) validates factory-level pool creation * **ERC-4626** ($16B+ TVL across 2,700+ deployments) confirms the vault standard * **Time-delayed execution** (Polkadot proxy pallet securing billions; Zodiac Delay Modifier in Gnosis Pay production) validates the reactive security layer *** ## Problem Statement ### 2.1 The Agent Capital Problem Autonomous agents are accumulating on-chain capital but lack native infrastructure to deploy it. The current DeFi stack was designed for human participants with wallets, browser extensions, and manual transaction approval. Agents face structural barriers: they cannot easily pool capital with other agents, they have no composable representation of shared positions, and they have no permissionless way to create and offer strategy to other agents. ### 2.2 The Identity Gap Every existing agent-DeFi protocol defines its own identity and trust layer. Theoriq requires 1,000 THQ staking. Amplified uses a proprietary 3-agent validation system. Olas has its own agent registry. This fragmentation means reputation is not portable, trust is not composable, and agents cannot move freely between protocols. ERC-8004 (mainnet January 29, 2026, 24,549+ agents in first week) establishes a shared identity standard — but no vault protocol has built on it yet. ### 2.3 The Liquidity Bootstrapping Gap New token launches face a cold-start problem. Projects need initial liquidity to become tradable, but liquidity providers have no mechanism to participate in bootstrapping collectively. Uniswap's Continuous Clearing Auctions solve price discovery, and the Liquidity Launcher handles DEX migration — but no vault has been purpose-built to aggregate capital for collective CCA participation. The ConstitutionDAO proved collective bidding works; ERC-4626 makes it composable. ### 2.4 The Secondary Market Gap ERC-4626 vault shares are standard ERC-20 tokens, but they have no guaranteed secondary market. A depositor who wants to exit must call `withdraw()` on the vault, which may be subject to withdrawal queues, locked capital in LP positions, or processing delays. No vault protocol automatically creates a DEX market for every vault's share token. An agent that deposits into a vault should be able to sell those shares instantly on Uniswap — priced at net asset value — without waiting for vault-level withdrawal processing. This requires auto-created V4 pools with NAV-aware pricing hooks at the factory level. ### 2.5 The Factory Gap Morpho Vaults ($5.8B TVL, 2,700+ vaults) and Yearn V3 proved that permissionless vault factories with zero-marginal-cost creation generate exponential ecosystem growth. But these factories are designed for human curators. No factory exists where the creator, manager, and participants are all autonomous agents operating under a shared identity standard. *** ## Design Principles **Infrastructure, not product.** The protocol is a factory and set of standards. It succeeds when other protocols build on it, not when it captures all activity directly. Zero protocol fees on the base layer. Revenue comes from ecosystem growth, not rent extraction. This follows the durable growth pattern established by Pendle, Ethena, and Morpho. The Morpho playbook is the clearest evidence: permissionless market creation, curator competition, and B2B adoption (Seamless migrated all liquidity from Aave V3 fork; Spark, Moonwell, and Compound Blue all build on Morpho infrastructure) drove 30x TVL growth on Base in 18 months. Each B2B integration onboards entire user bases without per-user acquisition cost. The protocol that becomes the infrastructure other agents build on captures durable network effects that no single-product vault can replicate. **Agent-native, not agent-compatible.** Every interface is designed for programmatic interaction. MCP tools are the primary interface. No human-facing UI is required for core operations. The debug UI exists for developer observability, not end-user interaction. When a user tells their agent "find yield" or "make money safely", the agent should be able to discover, evaluate, and participate in vaults entirely through MCP tools. **Identity as primitive.** ERC-8004 registration is the single gate for all protocol participation. No secondary staking, no proprietary identity layers, no KYC unless a vault creator explicitly configures it via validation hooks. Only ERC-8004 agents can participate — a human user or non-8004 entity cannot join. Reputation is read from the shared Reputation Registry, not maintained by the protocol. **Composability as strategy.** ERC-4626 share tokens are standard ERC-20s designed for day-one composability across the Base ecosystem: collateral on Morpho (largest lending protocol on Base, enabling leverage loops), PT/YT splitting on Pendle (fixed-yield products and maturity-based lock-in), and restaking via EigenLayer-compatible mechanisms. The stickiest flywheel is not token emissions — it is share token composability that creates switching costs across multiple protocols. Once vault shares are accepted as collateral on Morpho and listed on Pendle, removing integration would destroy user value — creating structural stickiness that no yield incentive can replicate. Internally, vault shares use ERC-6909 for gas-efficient multi-token accounting, with standard ERC-20 "claim" for external composability and ERC-7802 for Superchain portability. **Progressive complexity.** A vault with no CCA participation, no V4 hooks, and a simple hold strategy should be deployable in a single transaction. CCA integration, dynamic fee hooks, reputation-weighted allocation, perpetual yield tranches, and x402 monetization are all opt-in modules that vault creators activate based on their strategy. Risk-segmented vaults can enable the TrancheModule (D-049) to split shares into Senior (protected yield) and Junior (first-loss, boosted yield) tokens — vault creators are required to hold Junior shares as skin-in-the-game. The goal is a **spectrum of vaults** — from conservative yield to aggressive CCA hunting — giving agents a marketplace of risk/reward profiles to choose from. **Progressive reputation.** An agent starting at reputation 0 should have a concrete, automated path to reach each tier through vault participation alone. The protocol itself is a reputation source — verifiable on-chain milestones (first deposit, 30-day hold, profitable exit, vault creation) are automatically attested to the ERC-8004 Reputation Registry by the VaultReputationEngine contract. No subjective judgment, no manual review, no human intervention. Consistent participation over 3-6 months naturally moves an agent from Unverified through Basic and into Verified territory. This creates viral incentives: every interaction builds reputation, reputation unlocks better vaults, better vaults attract more participation. **Frictionless onboarding.** An agent should go from zero -- no wallet, no identity, no capital -- to earning yield in under 30 seconds. The protocol provides an explicit four-step quickstart path (see [00-quickstart.md](/docs/gotts-vaults/vault/00-quickstart.md)) and a single-UserOp batch path that collapses all steps into one gasless operation via ERC-4337 batching with paymaster sponsorship. The `OnboardRouter` contract (see [06-contracts.md](/docs/gotts-vaults/vault/06-contracts.md) Section 10.15) atomically handles identity registration, Permit2 approval, reputation enrollment, and vault deposit. Counterfactual smart account addresses allow agents to receive funds before onboarding. Wallet custody is delegated to battle-tested providers (Privy) -- the protocol never manages keys directly. Security is enforced by TEE-backed policy engines that prevent unauthorized transactions even if the agent's reasoning is fully compromised via prompt injection. See [03-custody.md](/docs/gotts-vaults/vault/03-custody.md) for the full wallet architecture. **Reactive defense, not just preventive.** Every existing agent wallet security mechanism (TEEs, session keys, spending limits) is preventive -- it tries to stop bad transactions from being authorized. But prompt injection is unsolvable at the LLM layer (12% bypass rate per Anthropic), and a successfully injected agent makes "legitimate-looking" requests that pass all preventive checks. Time-delayed proxies (`packages/agent-proxy/`) provide the missing reactive layer: a mandatory cancellation window between authorization and execution. This is analogous to the "hold period" in traditional finance -- deliberate friction that catches fraud. The proxy module is standalone and usable with any agent wallet, independent of the vault protocol. See [03-custody.md](/docs/gotts-vaults/vault/03-custody.md) Section 1.4 and Section 2.7 for architecture details. **Unified risk as queryable infrastructure.** All vault risk parameters -- adapter exposure caps, drawdown thresholds, oracle freshness bounds, leverage limits, share price rate-of-change bounds -- are consolidated into a single on-chain `RiskEngine` contract (D-056) implementing the ERC-7265 circuit breaker interface. This is not merely internal bookkeeping: the RiskEngine exposes read-only views that external protocols (Morpho, Pendle, rating agencies) can query to assess vault risk before accepting share tokens as collateral. Every parameter change routes through a `ParameterDecisionTable` (D-059) that enforces per-parameter authority roles, timelock durations, valid bounds, and justification hashes -- preventing the parameter drift and role confusion that has caused governance failures in other DeFi protocols. V4 hooks include a break-glass kill-switch (D-058) callable only by the Sentinel role, providing seconds-to-minutes emergency response instead of the hours that recent hook exploits have required. See [10-safety.md](/docs/gotts-vaults/vault/10-safety.md) "Risk Parameter Taxonomy (Normative)" for the unified taxonomy of required risk parameters, defaults, bounds, and governance rules. **Every vault lifecycle event is a Uniswap transaction.** Creation deploys a V4 pool. Share trading is V4 swaps. Rebalancing routes through V4 (optionally via TWAMM for large operations). Arbitrage corrects share price mispricings via V4. The protocol is not just a consumer of Uniswap liquidity — it is a generator of Uniswap volume. This flywheel (more vaults → more pools → more volume → more fees → more deposits → more vaults) is an explicit design goal. ClankerHook proved that automated pool creation generates massive volume ($3.1B from auto-created pools); the same pattern applied to yield-bearing vault shares produces more sustainable, yield-driven activity. **Modular primitives over monolithic solutions.** Every component should be independently deployable and useful outside its primary context. The proxy contracts, monitoring bot, SDK classes, and MCP tools are standalone primitives that compose into the vault protocol but work on their own. The factory pattern, identity gating, fee module, CCA adapter, V4 hooks, NAV-aware pricing, rehypothecation, TWAMM rebalancing, perpetual yield tranches, recursive lending adapters, policy cages, and cross-vault liquidity routing are all opt-in modules. This enables permutations not anticipated by this document -- developers can mix and match components to build novel agent infrastructure. **Policy cages for autonomous optimization.** AI agents manage vault strategy within hard on-chain boundaries (D-053). A `PolicyCage` contract defines exactly what the agent can do — approved asset list, maximum position sizes, strategy whitelists, maximum drawdown tolerance, and rebalance frequency limits. The agent optimizes freely within these constraints but cannot exceed them. This follows the Theoriq AlphaVault pattern (65M+ agent requests) and maps to Yearn V3's role system (`DEBT_MANAGER` with on-chain `max_debt` caps). A Numerai-inspired extension accepts competing strategy models from external data scientists with stake-weighted ensemble allocation — poor performers are slashed, good performers receive more allocation. The policy cage is what makes autonomous vault management safe: the LLM cannot exceed boundaries set by immutable smart contract logic. **Optional ve-token alignment.** For protocol-level coordination, an optional veVAULT module (D-050) enables vote-escrowed token governance following the ve(3,3) model. veVAULT holders vote on emission allocation across factory vaults and receive protocol fees, while vault creators bond protocol tokens to deploy vaults (slashed for poor performance). This is explicitly optional — the core protocol functions without a native token. The ve-token module is designed for activation when the factory reaches sufficient scale (100+ active vaults) to justify coordinated incentive alignment. *** ## Goals and Non-Goals ### Goals | ID | Goal | Rationale | | --- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | | G1 | Deploy a permissionless `AgentVaultFactory` via CREATE2 with on-chain vault registry | Core infrastructure for agent-native vault creation and discovery | | G2 | Implement ERC-4626 `AgentVaultCore` with ERC-8004 identity gating and tier-based limits | Enforces agent identity and bounded risk at the protocol boundary | | G3 | Implement core fee and risk primitives (fee caps, drawdown breaker, utilization/reserve controls) | Provides baseline economics and loss containment without feature bloat | | G4 | Ship a minimal `VaultReputationEngine` (enroll, milestone read/claim, anti-gaming basics) | Gives new agents a concrete path to build reputation from participation | | G5 | Expose a standalone vault MCP server with a **core-first tool surface** (factory/deposit/read/identity/reputation) | Makes the protocol usable by agent frameworks before expansion modules | | G6 | Publish core SDK surface (`VaultFactoryClient`, `VaultClient`, `ReputationReader`, core strategy helpers) | Enables direct integration without MCP lock-in | | G7 | Provide role-based safety with explicit proxy enforcement matrix and variable delay policy | Clarifies when proxy is required vs optional by operation class | | G8 | Maintain a <5 minute explicit onboarding flow and <30 second batch onboarding flow (single UserOp via OnboardRouter) | Minimizes drop-off for first-time agent operators | | G9 | Provide one-command local testnet and swarm simulation (`pnpm testnet`, `pnpm testnet:swarm`) | Accelerates iteration and integration testing for builders | | G10 | Achieve production-readiness quality gates for core scope (coverage, integration tests, deterministic scripts) | Reduces launch risk while keeping scope bounded | | G11 | Preserve modularity: vault core and proxy module are independently deployable | Supports ecosystem composability and independent adoption | | G12 | Launch core-first on Base with Ethereum ERC-8004 identity interoperability | Aligns with current agent liquidity and identity center of gravity | | G13 | Auto-create a Uniswap V4 share pool for every vault deployed through the factory, with NAV-aware pricing and optional descending-fee launch protection | Every vault gets instant secondary market liquidity; depositors can exit via Uniswap swap instead of withdrawal queue | ### Non-Goals | ID | Non-Goal | Reason | | ---- | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NG1 | Multi-protocol strategies (Aave, Compound, Maker) | Phase 1 is Uniswap-only. Multi-protocol integration is future work. | | NG2 | Cross-chain vault assets (vault on Base, LP on Arbitrum) | Phase 1 is single-chain. ERC-7683 cross-chain integration is Phase 5+. | | NG3 | Production-quality human-facing UI or dashboard | The debug UI is developer-only tooling. Production monitoring is via MCP tools and agents. | | NG4 | Custom token deployment for vault shares | Use standard ERC-4626 share token. Custom tokens add unnecessary complexity. | | NG5 | DAO governance for vault parameters | Phase 1 uses creator-controlled parameters. Governance is future work. | | NG6 | CCA lifecycle tooling in core v1 | CCA is an expansion track after core-factory and safety/reputation baseline are stable. | | NG7 | Flash loan support in the vault | Security risk; flash loan interactions with agent-gated vaults require careful analysis. | | NG8 | Production DeFi protocol (audited, insured, large TVL) | This is a reference implementation and working example. Production deployment requires audit. | | NG9 | Creation or deployment of CCA auctions or tokens | The vault is a participant in CCAs, not a launcher. | | NG10 | Front-end interfaces or user-facing applications | Agent-native by design. | | NG11 | Curation, governance, or cross-chain coordination modules | Covered in separate companion PRDs. | | NG12 | Viral gamification mechanics in core v1 (MP, referrals, recruitment, Farcaster growth loops) | Valuable but intentionally deferred until core reliability and safety gates are met. | | NG13 | x402 strategy marketplace in core v1 | Monetization endpoints are deferred until core protocol and operator UX are stable. | | NG14 | Active management of vault share pool liquidity by the protocol | The auto-created V4 share pool is seeded at vault creation; ongoing liquidity is market-driven. The protocol does not actively manage or incentivize share pool depth. | *** ## Canonical Fee Structure (Normative) > This is the single source of truth for vault fee types and caps. The `FeeModule` contract (see [06-contracts.md](/docs/gotts-vaults/vault/06-contracts.md)) enforces these caps immutably. All other documents must reference this section. | Fee Type | Cap (Immutable) | Collection Method | Notes | | ------------------- | ---------------------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------- | | **Management fee** | 500 bps (5%/year) | Accrued continuously, collected via explicit `report()` calls | Not per-transaction; Accountant pattern per D-069 | | **Performance fee** | 5,000 bps (50%) | Collected on profit above hurdle rate via `report()` | Only on net-new profit; high-water mark applies | | **Entry fee** | Configurable per vault (default 0) | Deducted at deposit time; `previewDeposit()` MUST account for entry fees per ERC-4626 spec | Aggregators (vaults.fyi, DefiLlama) rely on accurate preview functions | **Protocol fees**: Zero on the base layer. Vault creators keep 100% of their configured fees. This follows the Morpho pattern. **Three-tier fee waterfall** (D-020): protocol (2-5%) > curator/am-AMM winner (5-15%, market-driven via rent) > agent operator (variable from yield). **Reputation-based fee discounts**: Unverified 0%, Basic 5%, Verified 10%, Trusted 20%, Sovereign 30%.