ERC-4626: The Tokenized Vault Standard

A standardized interface for yield-bearing vaults that wraps tokens and represents shares proportional to deposited assets, making DeFi vault integrations consistent across protocols.

Published on 22 November, 2025

Categories:

Solidity Token

What ERC-4626 Actually Solves

Before ERC-4626, every yield protocol invented its own way to handle deposits and withdrawals. Yearn had yTokens, Compound had cTokens, Aave had aTokens. Each worked differently. Integration became a nightmare because developers had to write custom code for every single protocol.

ERC-4626 gives everyone the same blueprint. Deposit tokens, get shares. Redeem shares, get tokens back. The math stays consistent everywhere.

The Core Concept

Think of it like a coat check system. You give your coat (asset), get a ticket (share). The ticket's value changes based on how well the coat check business performs. Come back later, exchange ticket for coat plus any gains.

The vault holds the underlying assets. Your shares represent your portion of the total vault. If the vault grows through yield strategies, your shares become worth more of the underlying asset.

Depositor                    Vault
   |                           |
   |-- deposit(1000 USDC) ---->|
   |                           | (mints shares based on exchange rate)
   |<--- 950 shares -----------|
   |                           |
   |                           | (vault earns yield, 1000 USDC becomes 1100 USDC)
   |                           |
   |-- redeem(950 shares) ---->|
   |                           | (burns shares, returns assets)
   |<--- 1045 USDC ------------|

The Essential Functions

Every ERC-4626 vault implements these methods:

Asset Management

asset() returns the underlying token address
totalAssets() shows total underlying tokens held

Deposit Operations

deposit(assets, receiver) puts in tokens, mints shares
mint(shares, receiver) specifies exact shares to receive
maxDeposit(receiver) shows deposit limit

Withdrawal Operations

withdraw(assets, receiver, owner) burns shares, returns exact assets
redeem(shares, receiver, owner) burns exact shares, returns assets
maxWithdraw(owner) shows withdrawal limit
maxRedeem(owner) shows redeemable shares

Preview Functions

previewDeposit(assets) calculates shares you'll get
previewMint(shares) calculates assets needed
previewWithdraw(assets) calculates shares to burn
previewRedeem(shares) calculates assets you'll receive

Simple Implementation Example

contract BasicVault is ERC4626 {
    constructor(
        IERC20 _asset,
        string memory _name,
        string memory _symbol
    ) ERC4626(_asset) ERC20(_name, _symbol) {}
    
    function totalAssets() public view override returns (uint256) {
        return asset.balanceOf(address(this));
    }
}

This bare implementation just holds tokens. Real vaults add yield strategies inside totalAssets() or through separate harvest functions.

Deposit vs Mint, Withdraw vs Redeem

Two ways to enter, two ways to exit. Pick based on what you want to control.

Deposit: "I want to put in 1000 USDC, give me whatever shares that's worth" Mint: "I want exactly 500 shares, take whatever USDC that requires"

Withdraw: "I want exactly 1000 USDC back, burn whatever shares needed" Redeem: "I want to burn exactly 500 shares, give me whatever USDC that's worth"

The difference matters during price volatility or when deposit/withdrawal limits exist.

// Depositing 1000 tokens
uint256 shares = vault.deposit(1000e18, msg.sender);

// Or requesting exact shares
uint256 assets = vault.mint(500e18, msg.sender);

// Getting exact assets back
uint256 sharesBurned = vault.withdraw(1000e18, msg.sender, msg.sender);

// Or redeeming exact shares
uint256 assetsReceived = vault.redeem(500e18, msg.sender, msg.sender);

The Exchange Rate Mechanics

Share price starts at 1:1 on first deposit. After that, it floats based on vault performance.

Exchange Rate = totalAssets() / totalSupply()

If vault has 10,000 USDC and 8,000 shares:
Exchange Rate = 10,000 / 8,000 = 1.25 USDC per share

Depositing 1,000 USDC:
Shares Minted = 1,000 / 1.25 = 800 shares

This floating rate captures all yield automatically. No claiming, no harvesting for users. Your shares just become worth more over time.

Inflation Attack Protection

Early vaults had a problem. First depositor puts in 1 wei, gets 1 share. Attacker donates 1 million tokens directly to vault. Now exchange rate is 1 million:1. Next depositor puts in 999,999 tokens, gets 0 shares due to rounding.

Solutions:

Virtual Shares (common approach):

function totalAssets() public view returns (uint256) {
    return actualAssets + 1;
}

function totalSupply() public view returns (uint256) {
    return actualSupply + 1e9;
}

Dead Shares (OpenZeppelin):

constructor() {
    _mint(address(0), 1000);
}

Locks initial liquidity so exchange rate can't be manipulated cheaply.

Fee Structures

Vaults typically take fees through share dilution. Performance fee example:

function harvest() external {
    uint256 profit = calculateProfit();
    uint256 feeInAssets = profit * performanceFee / 10000;
    
    // Mint shares to fee recipient
    uint256 feeShares = convertToShares(feeInAssets);
    _mint(feeRecipient, feeShares);
}

Minting shares to the protocol dilutes everyone else proportionally. Clean, automatic, no asset transfers needed.

Integration Pattern

Protocols integrating ERC-4626 vaults use the same code everywhere:

interface IERC4626 {
    function deposit(uint256 assets, address receiver) external returns (uint256 shares);
    function redeem(uint256 shares, address receiver, address owner) external returns (uint256 assets);
    function previewRedeem(uint256 shares) external view returns (uint256 assets);
}

contract DeFiAggregator {
    function zapIntoVault(IERC4626 vault, uint256 amount) external {
        IERC20 underlying = IERC20(vault.asset());
        underlying.transferFrom(msg.sender, address(this), amount);
        underlying.approve(address(vault), amount);
        
        uint256 shares = vault.deposit(amount, msg.sender);
    }
}

Same code works for Yearn, Beefy, Curve, any ERC-4626 vault.

Real World Considerations

Slippage Protection: Always check preview functions first, add minimum output requirements:

uint256 expectedShares = vault.previewDeposit(amount);
uint256 minShares = expectedShares * 99 / 100; // 1% slippage

uint256 actualShares = vault.deposit(amount, receiver);
require(actualShares >= minShares, "Too much slippage");

Max Limits: Vaults can cap deposits. Check before transactions:

uint256 maxAmount = vault.maxDeposit(msg.sender);
require(depositAmount <= maxAmount, "Exceeds vault capacity");

Withdrawal Delays: Some strategies need time to unwind. Check max immediately available:

uint256 availableNow = vault.maxWithdraw(msg.sender);
if (desiredAmount > availableNow) {
    // Handle queue or partial withdrawal
}

Security Gotchas

Reentrancy: Deposit and withdraw functions transfer tokens. Always follow checks-effects-interactions or use reentrancy guards.

Price Manipulation: If vault's totalAssets() relies on external price oracles or AMM pools, it's vulnerable to flash loan attacks. Use TWAPs or manipulation-resistant pricing.

Rounding: Integer division rounds down. Vault implementations should round in favor of the vault on deposits, in favor of users on withdrawals.

// Depositing: round down shares (favors vault)
shares = assets * totalSupply() / totalAssets();

// Withdrawing: round up assets (favors user)
assets = (shares * totalAssets() + totalSupply() - 1) / totalSupply();

Testing Your Vault

Key properties to verify:

function testRoundTrip() public {
    uint256 depositAmount = 1000e18;
    uint256 shares = vault.deposit(depositAmount, user);
    uint256 assetsBack = vault.redeem(shares, user, user);
    
    // Should get back at least what you put in (minus tiny rounding)
    assertApproxEq(assetsBack, depositAmount, 2);
}

function testNoInflation() public {
    vault.deposit(1, attacker);
    token.transfer(address(vault), 1e18); // Direct transfer
    
    uint256 shares = vault.deposit(1000e18, victim);
    // Victim should still get meaningful shares
    assertGt(shares, 0);
}

When To Use ERC-4626

Good fits:

Yield aggregators pooling user deposits
Single-asset staking with auto-compounding
Lending protocols where deposits earn interest
Treasury management systems

Poor fits:

Multi-asset vaults (standard assumes single underlying)
NFT-based strategies (shares are fungible)
Vaults with complex withdrawal conditions standard can't express

ERC-4626 brought sanity to DeFi vault integrations by creating one standard interface that every protocol can implement and every aggregator can consume. The math stays consistent, the security properties are well understood, and developers can build once and integrate everywhere. It turned vault integration from a custom project into a commodity operation.