Author: Sina Pilehchiha

Translation: TechFlow

TLDR: ERC-4626 is a standard for tokenized vaults.

Before the introduction of ERC-4626, each vault had its own specifications and implementation details. This made integration difficult, error-prone, and resource-intensive.

ERC-4626 aims to solve this problem by introducing a standardized specification to reduce integration efforts and create more consistent and robust implementation patterns—similar to ERC-20.

What is ERC-4626?

ERC-4626 is a standard that improves the technical parameters of yield-bearing vaults. It provides a standard API for yield vaults that represent shares of a single underlying ERC-20 token.

Tokenized vaults have become an extremely common pattern in DeFi. Many dApps—including yield aggregators, lending markets, and staking derivatives—utilize and rely on tokenized vaults. Examples include Yearn and Balancer. As a yield aggregator, Yearn vaults allow users to deposit digital assets and earn returns. Balancer is an automated portfolio manager and liquidity provider whose core business logic depends heavily on vaults. These vaults manage tokens across various pools while separating token management from the pool’s own logic.

Protocols enhance liquidity and flexibility by tokenizing their vaults. Tokenized vaults can be easily traded and used as assets across DeFi platforms. Additionally, they enable the creation of diversified and interconnected financial products. The industry has long advocated for this paradigm, often referred to as "money legos."

However, composable systems without proper adaptability or standardization bring challenges. They not only make it difficult for developers to adhere to industry standards like ERC-20 but also confuse new developers. Without proper adaptation or standardization, reviewing new changes and verifying integration implementations becomes significantly harder.

This is where ERC-4626 comes in—to address these issues, simplify integration, and allow DeFi participants to ultimately adopt a safer and stronger unified vault specification. In turn, this reduces the attack surface protocols may face while integrating tokens across multiple platforms.

What security issues can ERC-4626 prevent?

By providing a unified standard, ERC-4626 accelerates the speed of cross-protocol integrations. Familiar, standardized interfaces are easier for developers to understand, reducing the likelihood of coding errors. This helps prevent composability issues. Standardization also prevents redundant work, as the community only needs to design vaults once instead of separately for every protocol. Since such design work is often error-prone, it helps avoid repeating established yet widespread design flaws.

We will now examine two case studies to illustrate the types of problems ERC-4626 can help prevent.

Rari Capital Incident

Rari Capital was hacked, resulting in the theft of approximately $11 million worth of tokens—equivalent to 60% of all user funds in Rari Capital’s Ethereum pool.

Overall, the Rari Capital hack stemmed from insecure cross-protocol implementation. Its Ethereum pool used Alpha Finance’s ibETH token contract as a yield strategy, depositing ETH into it. This particular strategy tracked the ibETH/ETH exchange rate using certain contracts and formulas (e.g., the function ibETH.totalETH / ibETH.totalSupply), which could produce incorrect outputs under attack conditions—for example, artificially inflating debt values when calling the ibETH.work() function.

Attackers simply repeated calls to the deposit and withdraw functions in the RariFundManager contract, draining the Rari Fund Manager. The deposit and withdraw functions needed to retrieve the pool's balance to calculate the number of REPT tokens to issue or the amount of ETH to disburse. This triggered calls to the Alpha pool’s getBalance function, which in turn invoked the ibETH contract and its totalETH function. Rari was unaware of the possibility of manipulating this function.

The ibETH contract contained another function: ibETH.work. This function could call any user-specified contract, making the deposit and withdraw functions in Rari reentrant and callable multiple times.

The work function was payable, meaning users could control the amount of ETH within the ibETH contract via this function, thereby altering the value returned by the totalETH function. Worse, the work function allowed calls to any other contract, including RariFundManager.

Using this function, attackers could send additional ETH to increase the totalETH amount in the ibETH contract while simultaneously calling withdraw in the RariFundManager contract to redeem more assets.

This incident highlights the significant risks posed by inadequate integration and incompatible designs in DeFi contracts. It underscores how a standard like ERC-4626 could have prevented such attacks by adding critical layers of security and predictability, promoting uniform behavior and mutual understanding.

Cream Finance Incident

Cream Finance suffered a sophisticated attack exploiting two fundamental weaknesses in the platform: a manipulable hybrid oracle and an uncapped token supply. The key part of the attack involved manipulating the hybrid oracle, which distorted the perceived value of the yUSD token. When the attacker sent a large quantity of Yearn’s 4-Curve token to the yUSD vault, they altered the exchange rate reported by the vault, thus affecting the oracle’s perception of the yUSD token’s value.

The key lesson here is that a robust, non-manipulable price oracle is crucial for the stability of DeFi protocols. Time-weighted average price (TWAP) oracles can help prevent such hacks, as they are more resilient against sudden price manipulation.

These issues, along with other fragile design patterns, can be mitigated through careful adoption and implementation of ERC-4626.

Potential Security Risks in ERC-4626

There are always trade-offs when adopting new protocols. For tokenized vaults, integrating them into smart contracts may introduce potential issues requiring special attention.

Handling feeOnTransfer Tokens

If a vault intends to support feeOnTransfer tokens, verify that the amounts and shares in the vault remain within expected ranges when transferring assets.

Proper use of decimals variable

Although the convertTo functions should not require the use of the decimals variable from EIP-4626 vaults, it is strongly recommended to mirror the underlying token’s decimals whenever feasible. This practice helps eliminate potential sources of confusion and simplifies integration for various frontends and off-chain users.

Rounding

According to the specification, vault implementers must be aware that specific and opposite rounding directions are required in different variable and view methods, prioritizing the vault’s safety over that of its users during calculations:

• When calculating the number of shares to issue in exchange for a given amount of underlying tokens, or when transferring a specific number of shares’ worth of underlying tokens to a user, round down.

• When calculating how many shares a user must provide to receive a given amount of underlying tokens, or how much underlying token a user must deposit to receive a given number of shares, round up.

The preferred rounding direction for the convertTo functions is ambiguous. To ensure consistency across all EIP-4626 vault implementations, these functions must always round down. Integrators can emulate an upward-rounding version themselves, for example, by adding one Wei to the result.

The amount of underlying assets a user receives by redeeming their shares in the vault (previewRedeem) may differ significantly from the amount required to mint the same number of shares (previewMint). These differences may be small (e.g., due to rounding errors) or large (e.g., if the vault implements withdrawal or deposit fees). Therefore, integrators should carefully choose the preview function most suitable for their use case and never assume they are interchangeable.

Overriding Core Functions

To implement or extend functionality, it is recommended to use existing hooks rather than modifying core functions. This approach enables more manageable tracking, facilitating effective code testing and auditing.

Zero Shares

The original ERC-4626 specification does not outline how to handle edge cases where there are zero shares in the vault—whether the vault should operate normally or revert. This could become a potential source of confusion and errors.

Vaults as Price Oracles

Due to the risk of oracle price manipulation attacks, the values returned by these preview methods are only approximate. As such, they can be manipulated by changing on-chain conditions and are not always safe to use as price oracles. The ERC-4626 specification includes imprecise convert and totalAssets methods, allowing them to be implemented as robust price oracles. For instance, correctly implementing the convert method using time-weighted average pricing when converting between assets and shares enhances resilience.

Specific Implementation Issues

Integrators must review the implementation of any tokenized vault before further integration, as malicious implementations may appear compliant with the interface specification while having core functions designed under entirely different principles.

Direct EOA Access

If a vault is accessed directly by an externally owned account (EOA), its implementation must include mechanisms to accommodate slippage losses or unexpected deposit/withdrawal limits. Unlike smart contracts, EOAs lack fail-safe rollback mechanisms; if precise output is not enforced during core function calls, transactions cannot be reverted.

Extending Vaults

As more participants adopt the ERC-4626 standard, we will see more extensions implemented for it. For example, Superform developed an experimental Multi-Vault extension supporting different computations within a single vault contract. Naturally, the more an implementation deviates from the original standard, the higher the likelihood of introducing new vulnerabilities. Developers and auditors should assess their optimal choices based on use cases to determine actual risk levels.

It’s important to note that catastrophic events are rarely caused by minor additions in individual protocols, but rather by the cumulative effect when these additions are integrated together.

The potential attack vectors mentioned above are some of the commonly discussed issues surrounding the ERC-4626 standard. As adoption grows, we will undoubtedly explore more implementation use cases and identify more appropriate scenarios for integrating with ERC-4626 vaults.