ERC-4626 explained: the standard that made tokenized yield vaults safe and composable

If you've used a yield vault in the last two years, you've probably interacted with an ERC-4626 contract without knowing it. The standard is invisible by design — that's the point. It made tokenized yield-bearing positions behave the same way across every protocol, which sounds boring and turns out to be one of the most consequential standards Ethereum has adopted.

This piece explains what ERC-4626 does, what it prevents, and why VXUSD is built on it.

The problem ERC-4626 solved

Before 2022, every yield vault built its own deposit and withdraw interface. Yearn vaults had one shape. Convex vaults had another. Beefy vaults yet another. The mechanics were similar — deposit a token, receive a share, share appreciates as yield accrues, redeem the share for more of the original token — but the function signatures, the rounding behavior, the share-price calculation, and the events emitted were all different.

This caused three concrete problems:

1. Wallet and tooling support was fragmented. Every wallet that wanted to display "you own 1,000 vault shares worth $1,020" had to integrate each vault individually. Most didn't bother.
2. Composability was hand-rolled. A protocol that wanted to use a yield-bearing position as collateral had to write custom adapters for each vault standard. Most didn't bother.
3. Subtle bugs. Inflation attacks, share-price manipulation on first deposit, rounding errors in tiny redemptions — every team rediscovered these the hard way, often after deployment.

ERC-4626 (finalized in late 2022) standardized the interface for "tokenized vaults" and codified the mitigations for the most common bug classes. Every conforming vault behaves the same way for the operations that matter.

What the standard specifies

ERC-4626 is itself an extension of ERC-20 — a vault share is just an ERC-20 token. On top of the standard ERC-20 functions, it adds:

• asset() — what underlying token the vault holds (e.g., USDC).
• totalAssets() — total underlying assets in the vault.
• deposit(assets, receiver) — deposit underlying, mint shares.
• mint(shares, receiver) — mint a specific share amount, pay corresponding assets.
• withdraw(assets, receiver, owner) — withdraw a specific asset amount, burn corresponding shares.
• redeem(shares, receiver, owner) — burn shares, receive corresponding assets.
• convertToShares(assets) / convertToAssets(shares) — pure math functions for converting between asset and share units.
• previewDeposit, previewMint, previewWithdraw, previewRedeem — simulate the result of each action without executing.
• maxDeposit, maxMint, maxWithdraw, maxRedeem — limits on each action for a given address.

That last set — the preview and max functions — is where most of the safety lives. Any UI built on an ERC-4626 vault can show users exactly what they'll receive before they sign, by calling the preview function. There's no guessing.

The rounding rule

The standard specifies the rounding direction for every conversion explicitly:

• Conversions that grant shares to the user round down (against the user).
• Conversions that grant assets to the user round down (against the user).
• Conversions that charge the user round up (against the user).

This is deliberately user-conservative. It means the vault never accidentally hands out one extra wei of shares due to rounding, which prevents a class of "drain by repeated tiny deposits" attacks that hit early non-standard vaults.

The inflation attack and how the standard handles it

One famous vault bug: on a brand-new vault with zero total supply, the first depositor can deposit 1 wei, get 1 share, then donate a large amount of the underlying asset directly to the vault contract. Now the share price is artificially huge. The next depositor who deposits 100 wei gets 0 shares (rounded down), and the attacker walks off with the deposit.

ERC-4626 doesn't prevent this directly — it's a convention, not an enforcement layer — but the standard puts it on every implementer's radar. Mitigations include:

• Burning the first N shares to a dead address on vault deployment.
• Maintaining an internal "virtual offset" so the share price never starts at zero.
• Requiring a minimum first deposit large enough that the rounding loss is bounded.

vildX uses the virtual offset approach, which is the cleanest and is recommended by OpenZeppelin's reference implementation.

Why composability is the unlock

Because every ERC-4626 vault speaks the same interface, downstream protocols can build on top of any of them generically. A lending protocol that accepts ERC-4626 shares as collateral can list every vault on the network with one integration. A wallet that displays vault positions can support every vault with one parser. A risk-monitoring tool can index utilization across the entire ecosystem.

For users, this matters because it means a vault share like VXUSD isn't a proprietary token trapped inside one app — it's a token that fits into the broader DeFi stack. Today the most important property is that wallets read it correctly; tomorrow it might mean VXUSD can be used as collateral inside another protocol. The optionality is structural.

What ERC-4626 doesn't fix

A few honest limits.

• It doesn't audit the strategy. A vault can implement the interface perfectly and still hold a terrible underlying portfolio. The standard governs the wrapper, not the assets.
• It doesn't guarantee withdrawability. A vault can correctly implement maxWithdraw() returning zero — that's still standard-compliant. Users have to read what the function returns.
• It doesn't standardize fee structures. Performance fees, platform fees, exit fees — each implementation handles these differently, often inside the conversion math, often not. Read the docs.

The standard is necessary, not sufficient. For VXUSD, ERC-4626 is the foundation — but the harder work is the strategy underneath. We talk about that in the case for a blended multi-protocol stablecoin strategy.