Comparing Yield Optimizers vs Direct Staking

Detailed Instructions

A user deposits assets like ETH, stETH, or stablecoins into the optimizer's vault contract. This contract acts as a single, large liquidity pool. The deposit mints a corresponding amount of vault tokens (e.g., yvDAI) to the user, representing their share of the pooled assets and future yield. The aggregator's efficiency stems from this scale; managing one large deposit is more gas-efficient than many small ones. Before depositing, users must approve the vault contract to spend their tokens via a standard ERC-20 approve() transaction.

solidityCopy
// Example interaction with a vault's deposit function
IERC20(daiToken).approve(vaultAddress, depositAmount);
IVault(vaultAddress).deposit(depositAmount, msg.sender);

Tip: Always verify the vault contract address from the project's official documentation to avoid phishing.

Detailed Instructions

The optimizer's core logic, often managed by off-chain keepers or governance, continuously monitors yield sources like Aave, Compound, Convex, or liquidity pools. It evaluates APY, liquidity depth, and risk parameters to allocate the vault's capital. A strategy is a smart contract that encodes the specific actions for a yield source. The vault may allocate funds across multiple strategies for diversification. For example, 60% to Aave for lending, 30% to Curve for LP rewards, and 10% held as liquidity for withdrawals. Strategy performance is tracked via on-chain oracles and off-chain analytics.

javascriptCopy
// Pseudocode for a strategy harvest function
function harvest() external onlyKeeper {
    uint256 crvRewards = IConvexBooster(booster).earned(strategyPid);
    if (crvRewards > minHarvestThreshold) {
        IConvexBooster(booster).getReward(strategyPid);
        swapCRVtoWantAsset();
        reinvestProfit();
    }
}

Tip: Review a vault's active strategies and their historical performance to understand its risk profile.

Detailed Instructions

Deployed funds generate yield in the form of protocol tokens (e.g., COMP, CRV, AAVE) or additional base assets. The optimizer's harvest function is called periodically, often by a bot incentivized by a performance fee. This function claims accrued rewards, swaps them for the vault's primary asset (the "want" token), and reinvests the profit. This auto-compounding effect significantly boosts effective APY over time compared to manual claiming. The frequency of harvests is a key optimization parameter, balancing gas costs against compounding efficiency. Profits increase the vault's total value, causing the price of each vault token to appreciate.

• Sub-step 1: Keeper calls strategy.harvest().
• Sub-step 2: Strategy claims rewards from external protocol (e.g., Minter.mint() for CRV).
• Sub-step 3: Rewards are swapped via a DEX aggregator like 1inch.
• Sub-step 4: Swapped assets are redeposited into the yield source.

Tip: High harvest frequency on low-gas networks can lead to better compounding, but monitor associated keeper fees.

Detailed Instructions

Yield optimizers charge fees to sustain operations. A common model includes a management fee (e.g., 2% annually) and a performance fee (e.g., 10-20% of yield). Fees are taken in vault tokens. The performance fee is typically assessed during harvests; a portion of the harvested yield is minted as new vault tokens and sent to a treasury or fee recipient. This dilutes vault token holders slightly but funds protocol development. The management fee is often implemented by slowly inflating the supply of vault tokens allocated to the treasury. Users should calculate the net APY after fees, which should still exceed direct staking due to optimization efficiency.

solidityCopy
// Simplified fee logic within a harvest
uint256 profit = totalAssetsNow - totalAssetsLastHarvest;
if (profit > 0) {
    uint256 performanceFee = (profit * PERFORMANCE_FEE) / MAX_BPS;
    // Mint fee shares to treasury
    _mint(treasury, shareValueOf(performanceFee));
}

Tip: Transparent protocols clearly display fee structures and treasury addresses on their frontend and in contract code.

Detailed Instructions

To exit, a user calls the vault's withdraw() or redeem() function, burning their vault tokens in exchange for their proportional share of the underlying assets. The vault may need to unwind positions from active strategies to meet the withdrawal request, which can involve multiple transactions (exiting liquidity pools, repaying loans). This can incur slippage and gas costs. Most vaults maintain a small liquidity buffer to handle routine withdrawals. In periods of high demand or illiquidity in underlying protocols, withdrawals may be delayed or incur higher slippage. The user receives the asset, plus all accrued yield up to that point (minus fees).

• Sub-step 1: User approves vault to burn their vault tokens (if using permit).
• Sub-step 2: User calls vault.withdraw(amountShares, recipient, maxLoss), where maxLoss is a slippage tolerance.
• Sub-step 3: Vault calculates share of total assets and withdraws from strategies if needed.
• Sub-step 4: Assets are transferred to the user's wallet.

Tip: Check a vault's totalAssets() and withdrawal queue status to estimate potential delays or slippage before exiting.