Yearn is a DeFi Yield Optimization Protocol Using Tokenized Vault Shares

Yearn is a vault deposit workflow in which a connected EVM wallet authorizes an ERC-20 asset, submits a second transaction to the selected vault and receives transferable yvToken shares after execution. Before confirming, match the network, asset contract, vault contract, amount, allowance target and quoted shares. An approval receipt alone isn't a deposit: completion requires the deposit transaction, a successful receipt and an on-chain increase in the wallet's vault-share balance.

It is a DeFi vault interface where users approve an asset, confirm its deposit, retry failed approvals, and verify minted yvToken shares on-chain.

An Approval Receipt Without a Deposit

An ERC-20 approval changes an allowance; it doesn't transfer assets into a Yearn vault or mint shares.

The deposit panel separates the two states by displaying an existing approval and a projected deposit outcome. With a 0 allowance, the wallet first calls approve on the underlying token. A successful receipt changes only the owner-spender allowance. The asset remains in the wallet, the vault's total assets stay unchanged and the yvToken balance stays unchanged. The spender is the vault for a direct ERC-4626 route or the routing contract for an Enso path. Deposit becomes available after the interface reads an allowance equal to or above the entered amount.

A rejected wallet prompt creates no transaction. A mined approval with failed status creates no usable allowance. A pending approval occupies its account nonce until it confirms or is replaced, so a later deposit with the next nonce waits behind it.

After approval succeeds, refresh the allowance before retrying the deposit action. The Token Approval panel exposes Revoke and Set Unlimited controls: Revoke writes 0, while an unlimited uint256 allowance commonly writes 2^256 − 1. That allowance stays separate from the asset balance and the vault-share balance.

Direct and Routed Deposit Paths

The chosen Yearn input path decides the spender, call sequence and number of wallet confirmations.

A direct deposit uses the vault's accepted underlying token and calls its ERC-4626 entry point. Starting with sufficient allowance leaves 1 on-chain transaction: deposit. Starting at 0 adds an approval first, producing 2 transactions. An Enso-routed path is different because an input token is approved to the route, converted if required and deposited into the selected vault within the routed call. The review screen should therefore show a different spender and more contract actions, even when both paths end with the same yvToken shares in the receiver's wallet.

The direct underlying-asset path gives the shortest call trace. A routed input reduces the need to hold the exact vault asset, while adding route data, conversion steps and an Enso spender to the confirmation review.

Network, Asset and Amount Checks

A Yearn confirmation is ready only when network, asset, vault, amount, allowance and receiver agree.

The network check is exact: Ethereum uses chain ID 1, OP Mainnet uses 10, Arbitrum One uses 42161 and Base uses 8453. A vault address belongs to one chain even when the ticker matches elsewhere. Each EVM address holds 20 bytes, rendered as 40 hexadecimal digits or 42 characters with the 0x prefix. Match the full token and vault addresses from the selected vault view, not only the shortened characters a wallet displays. MetaMask and Rabby expose the active network before signing, and the receiver should match the connected account unless the call explicitly names another address.

The amount selector offers 4 controls: 25%, 50%, 75% and Max. After entry, read You Will Deposit, You Will Receive, Vault Share Value and Existing Approval together. The asset line identifies what leaves the wallet; the share line estimates what arrives. Existing Approval must cover the entered raw amount for the active spender, not a similarly named vault on another chain.

The gas estimate belongs to the selected network and is paid in its native gas asset. It doesn't reduce the ERC-20 amount encoded as the deposit unless the chosen routed path explicitly starts from a native asset.

What Changes On-Chain After a Yearn Deposit?

A successful Yearn deposit transfers the underlying ERC-20 asset, updates vault accounting and mints ERC-20 shares to the receiver.

The ERC-4626 Call

A direct call uses deposit with 2 arguments: assets and receiver. Standard EVM calldata contains a 4-byte function selector followed by 2 ABI words of 32 bytes each, for 68 bytes in total. A router call is longer because it bundles route instructions, so decode the actual method rather than expecting every confirmation to resemble the direct form.

Asset Movement

The vault invokes transferFrom against the underlying token. Sufficient balance and allowance let the token move from sender to vault, after which Yearn increases its recorded idle assets. A request for 0 assets reverts, as does a deposit producing 0 shares or exceeding the receiver's maxDeposit value.

Share Minting

For Yearn V3, deposit computes shares as assets multiplied by total supply and divided by total assets, rounding down; an empty vault starts at 1:1 in raw units. The minted shares increase total supply and the receiver's balance in the same successful transaction. If any required step reverts, none of those state changes persist.

The Receipt Logs

The ERC-4626 Deposit event records 4 values: sender, owner, assets and shares. Share issuance also emits an ERC-20 Transfer event with 3 values, showing the zero address as sender, the receiver as destination and the minted share quantity as value. The asset token separately emits its own Transfer from the wallet into the vault contract. Together, those logs connect the asset movement to the new yvToken balance.

Share Calculation at Execution

Yearn share verification starts with the execution-time ratio, not the number shown before the wallet signs.

previewDeposit provides the pre-signing estimate, while the mined deposit uses vault totals from its execution block. Reports, other deposits and share unlocking can change total assets or effective total supply before inclusion. The receipt's assets and shares fields therefore own the final answer. A successful deposit isn't expected to mint one share for every displayed asset unit once the vault has a non-unit price per share.

Raw-unit comparison requires token decimals. Ethereum USDC uses 6 decimals, so 10^6 raw units represent 1 USDC; Ethereum DAI and WETH use 18 decimals, so 10^18 raw units represent 1 token. Yearn V3 sets vault-share decimals from the underlying asset, keeping raw asset and share precision aligned even when their economic ratio differs.

previewDeposit and convertToShares round down, while previewMint rounds the required assets up. One smallest raw unit can disappear from a hand calculation when integer division has a remainder. Compare raw units for contract reconciliation and human-readable units for the wallet display.

Receipt and Balance Verification

A Yearn deposit is verified when receipt logs, vault balance and share balance describe the same state change.

Start with the transaction hash, a 32-byte identifier rendered as 64 hexadecimal digits or 66 characters including 0x. On Ethereum, Etherscan decodes the receipt; Arbiscan serves Arbitrum One, while Blockscout covers several EVM networks. Confirm successful status, then inspect the underlying token Transfer into the vault, the vault's Deposit event and the yvToken Transfer from the zero address. The receiver and minted quantity should match the Deposit event. This sequence distinguishes a completed deposit from an earlier approval receipt without relying on an interface refresh.

Next, read balanceOf on the vault-share token for the receiver. convertToAssets translates that share balance into the underlying denomination at the latest recorded ratio. A wallet may omit the yvToken until its contract is added manually, and an indexer may lag a block, yet neither display issue changes the contract balance.

The interface position, the explorer receipt and the direct contract read form 3 independent views. Agreement across all 3 is stronger evidence than a single dashboard number, especially immediately after execution.

Stale and Failed Approval Recovery

A stale Yearn allowance is recoverable once the wallet re-reads the active spender and confirmed on-chain value.

When an approval receipt succeeded but the deposit control still requests approval, reconnect the wallet, confirm the network and reload allowance for the token-owner-spender tuple. Direct and Enso paths use different spenders, so an allowance written for one doesn't authorize the other. If the receipt failed, submit a fresh approval with a viable network fee; a failed transaction writes no partial allowance.

Some ERC-20 implementations enforce a zero-first allowance change. Ethereum USDT is a known case: moving from one nonzero allowance to another requires an intervening approval of 0. That sequence creates 3 on-chain steps from a stale nonzero allowance to a completed deposit: reset, approve and deposit. If the current allowance already covers the amount, resetting it only adds work.

A pending transaction needs nonce resolution rather than another unrelated approval. Use the wallet's replace control for the same nonce or wait for the original receipt, then read allowance again. Once the active spender has enough confirmed allowance, the deposit retry follows the normal call path.

The Wallet Setups This Workflow Fits

The Yearn workflow fits wallets with the selected asset, native gas token, correct network and reliable transaction signing. MetaMask and Rabby provide direct confirmation screens, while a Safe account applies its owner threshold before execution. Hardware-wallet users also need readable contract data for the approval target and deposit receiver. A direct asset deposit offers the smallest review surface; an Enso route suits a supported input token when its extra conversion calls and routing spender are acceptable.

Practical questions about Yearn