Introduction to Vault Aggregators

Welcome to the Module

You built Compound V2. You know how share-tokens work via exchange-rate accrual: the cToken balance never changes, but each cToken becomes worth more underlying as borrowers pay interest. Yearn V2 generalizes that idea. A vault holds an underlying asset, deploys it across many strategies, and the share-token's pricePerShare grows as strategies report gains. Same accrual pattern, different source of yield.

By the end of this module you will have written every core function of the Yearn V2 vault and BaseStrategy: deposits, withdrawals, share math with first-depositor and donation defenses, the strategy registry, dynamic debt allocation, the report cycle that nets gain and loss against debt, locked profit degradation that defeats just-in-time deposits, fees paid via share dilution, the multi-strategy withdrawal queue, and the harvest cycle on the strategy side. Every function. Every invariant. Modernized to Solidity 0.8.x.

What is a Vault Aggregator?

A vault aggregator is a smart contract that pools deposits and routes them to one or more yield-earning strategies. Users deposit a single underlying asset and receive a share token. Strategies (separate contracts) take some of that capital, do something productive with it (lend on Aave, provide liquidity on Curve, deposit into a real-world asset position, whatever), and periodically report gain or loss back to the vault. The vault updates accounting and the share token's value changes accordingly.

The reason this category exists is composability of yield. A naive depositor cannot constantly chase the highest yield across protocols; gas costs, complexity, and risk awareness all stop them. A vault aggregator lets a strategist team do that work professionally and shares the upside. Yearn V2 was the design that made the multi-strategy version of this work in production at scale.

The harvest cycle is the heartbeat. A keeper calls harvest() on a strategy. The strategy realizes pending P&L, hands gain back to the vault, optionally takes new credit, and reinvests. The vault charges performance and management fees by minting fresh shares to the fee recipients (dilution rather than direct transfer). Every active depositor's pricePerShare ticks up by the net gain.

Yearn V2 vs Yearn V1, Yearn V3, ERC-4626

Yearn V1 (2020) was a single-strategy design: one vault, one strategy, all-or-nothing. It worked but the strategist was a bottleneck and there was no risk diversification.

Yearn V2 (2021) introduced multi-strategy vaults. A vault could allocate capital across N strategies (up to 20) with per-strategy debt ratios, dynamic rebalancing on harvest, and a withdrawal queue ordering. This is the design you are building.

Yearn V3 (2024) re-architected on top of ERC-4626 (which itself was standardized FROM Yearn V2's design) and split governance into modular roles. V3 is more flexible but also more complex; we teach V2 because the core mechanics are clearer and the audit history is rich.

ERC-4626 standardized the vault interface (asset, convertToShares, convertToAssets, deposit, mint, withdraw, redeem, previewDeposit, etc.). Anyone who understands the V2 mechanics you build here also understands ERC-4626 and every modern vault inheriting from it.

Audit History You Will Encounter

Every Yearn V2 fork that has been exploited failed at one of the defenses you will build in this module. Beefy Wrapper (Zellic 2022 report): first-depositor inflation. Reaper Farm (August 2022, ~$1.7M): a recipient-account verification gap in the withdraw flow. Pickle Finance: cToken interaction error in the strategy. Yearn V1 (Feb 4, 2021, $11M): permissionless earn() plus loose slippage tolerance let an attacker flash-loan from Aave, manipulate Curve 3pool prices, and force the vault to repeatedly deposit and withdraw at unfavorable rates. The V2 design fixed this by making harvest keeper-only and tightening per-strategy bounds.

The pattern: vaults rarely die from bugs in deposit or transfer. They die from share-math edge cases (first depositor, donation), reporting bugs (gain reported greater than realizable), or queue-order bugs (withdrawals from a strategy that reverts). You will build the defense for each.

What This Module Does Not Cover

This module covers the Vault and BaseStrategy contracts. It does not cover:

• Concrete strategy implementations (e.g. an Aave-lender strategy or a Curve-LP strategy). BaseStrategy is the abstract parent; concrete strategies are out of scope.
• The Yearn governance framework (yveCRV, the YFI staking, the Multisig structure). We use a simple governance/management/guardian/strategist role hierarchy.
• Vyper-side tooling. The original Vault.vy is in Vyper; we modernize to Solidity 0.8.x. Brief mentions of Vyper appear, but you do not need to read or write Vyper.
• ERC-4626 conformance as such. Section 6 names the ERC-4626-compatible aliases (convertToAssets, convertToShares) but we do not implement the full ERC-4626 surface (preview functions, etc.).
• Yearn V3. The V3 redesign is its own module (not yet built).

The Question to Carry Through

Throughout this module, hold one question: what is the core mechanism that allows Yearn V2 vault depositors to earn yield without their share balance changing? You answered the same question for Compound V2 in the introduction to that module. The answer for Yearn V2 is three words and is the canonical Yearn API. Submit that as the answer when you complete this section.