Understanding ERC-4626 in one article: the new standard for DeFi tokenized vaults

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

Before the introduction of ERC-4626, each vault had its own specification and implementation details. This makes integration difficult, error-prone, and wasteful of resources.

ERC-4626 tries to solve this problem with a standard specification to reduce the integration effort and create a more consistent and robust implementation model, just like ERC-20.

What is ERC-4626?

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

Tokenized vaults have become an extremely common model in DeFi. Yield aggregators, lending markets, staking derivatives, and many other dApps leverage and rely on tokenized vaults. Examples of tokenized vaults include Yearn and Balancer. As a yield aggregator, Yearn Vault enables users to deposit digital assets and earn yield. Balancer is an automated portfolio manager and liquidity provider that relies on vaults at the core of its business logic. These vaults manage tokens in various pools. At the same time, they separate token management from the logic of the pool itself.

The protocol enhances liquidity and flexibility by tokenizing its vaults. Tokenized vaults make it easy to transact and use assets on DeFi platforms. Additionally, they enable the creation of diverse, interconnected financial products. The industry has been championing this paradigm, often referred to as "money Lego."

However, composability without proper adaptability or standardization presents challenges. Not only does it make it difficult for developers to comply with industry standards like ERC-20, but it can also confuse new developers. Without proper adaptation or standardization, it is difficult to review new changes and verify the implementation details of integrations.

So ERC-4626 was proposed to solve this problem and simplify integration, while allowing DeFi participants to finally adopt a more secure and robust unified vault specification. This in turn will reduce the protocol’s possible attack surface while integrating tokens across multiple protocols.

What security issues can ERC-4626 prevent?

By providing a unified standard, ERC-4626 accelerates the construction of cross-protocol integration. Familiar, consistent standards are also easier for developers to understand, reducing the likelihood of coding errors. This helps prevent composability issues. Standardization also prevents duplication of effort, as the community only needs to design the vault once, rather than individually for each protocol. Since this design effort is often error-prone, it helps avoid duplicating established but pervasive design flaws.

We will present two case studies here to show what problems ERC-4626 can prevent.

Rari Capital event

Approximately $11 million worth of tokens were stolen from Rari Capital, which is equivalent to 60% of all user funds in the Rari Capital Ethereum pool.

Overall, Rari Capital was hacked due to an insecure cross-protocol implementation. Its Ethereum pool takes ETH into Alpha Finance's ibETH token contract as an output strategy. This specific strategy tracks the value of its ibETH/ETH exchange rate through certain contracts and formulas (specifically, the ibETH.totalETH / ibETH.totalSupply function), which may have erroneous outputs in this attack scenario, for example, when calling ibETH.work( ) function, debt values may be artificially inflated.

An attacker can exhaust the Rari Fund Manager simply by repeatedly calling the deposit and withdraw functions in the RariFundManager contract. The deposit and withdraw functions need to obtain the balance of the pool to calculate the number of REPT tokens to be issued to the caller, or the amount of ETH to be issued to the caller. This operation will call the getBalance function of the Alpha pool, call the ibETH contract and its totalETH function . Rari is not aware of the possibility of manipulating this function.

There is another function in the ibETH contract: ibETH.work. This function can call any contract specified by the user. This allows Rari's deposit and withdraw functions to be reentrant and be called multiple times.

The work function is a paid function, which means that the user can control the amount of ETH in the ibETH contract through the work function, thereby changing the value returned by the totalETH function. To make matters worse, the work function also supports calling any other contract, such as RariFundManager.

Through this function, the attacker can send ETH again and increase the totalETH amount in the ibETH contract, and at the same time call withdraw in the RariFundManager contract to redeem more assets.

This incident highlights the significant risks posed by insufficient integration and incompatible designs in DeFi contracts. It highlights how standards like ERC-4626 can prevent such attacks by adding a critical layer of security and predictability, and promote uniform behavior and mutual understanding.

Cream Finance case

Cream Finance suffered a sophisticated attack that exploited two fundamental weaknesses in the platform: a manipulated mixing oracle and an uncapped token supply. A key part of the attack was the manipulation of the mixing oracle, which affected the perceived value of the yUSD token. When the attacker sent a large amount of Yearn 4-Curve tokens to the yUSD vault, he changed the exchange rate reported by the vault and therefore also affected the perceived value of the yUSD tokens to the oracle.

The key lesson here is that a robust and unmanipulable price oracle is critical to the stability of a DeFi protocol. Time-weighted average price (TWAP) oracles can help prevent such hacks because they are more resilient to sudden price manipulation.

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

Potential security risks in ERC-4626

There are always some trade-offs with using a new protocol. For tokenized vaults, there may be potential issues integrating them into smart contracts that require special attention.

Manage feeOnTransfer tokens

If the vault is designed to support feeOnTransfer tokens, check that the amount and shares in the vault are within the expected range when transferring assets.

Appropriate use of the decimals variable

Although the convertTo function should not need to use the EIP-4626 vault's decimals variable, it is still strongly recommended to mirror the underlying token's decimals where feasible. This practice helps remove potential sources of confusion and simplifies integration for various front-end and off-chain users.

rounding

According to the specification, vault implementers should be aware that specific and opposite rounding directions are required in different mutable and view methods, as it is safer to prioritize the vault itself over its users during calculations:

• If it is calculating the number of shares to be issued to a user for the amount of some underlying token they offer, or if it is operating to transfer a specific share of the underlying token to a user, it should be rounded down.

• If it is calculating how many shares a user has to give in order to get a certain amount of base tokens, or if it is calculating how many base tokens a user has to give in order to get a certain number of shares, it should be rounded up.

Where the preferred rounding direction will be ambiguous is the convertTo function. To ensure consistency across all EIP-4626 vault implementations, specify that these functions must always round down. Integrators can mimic the round-up version themselves, for example by adding a Wei to the result.

The amount of underlying assets a user receives by redeeming their stake in the vault (previewRedeem) can vary significantly from the amount that would have to be paid to issue the same amount of stake (previewMint). These differences can be small (e.g. due to rounding errors) or large (e.g. a vault implements withdrawal or deposit fees). Therefore, integrators should take care to use the preview functions that best suit their use case, and never assume that they are interchangeable.

Override core functionality

In order to implement or extend the intended functionality, it is recommended to use existing hooks instead of changing the core functionality. This practice ensures a more manageable trail for efficient code testing and auditing.

Zero share

The original specification for ERC-4626 did not outline how to handle the corner case of no shares in the vault, and whether the vault should behave as normal or roll back. This can be a potential source of confusion and errors.

Vaults as price oracles

With regard to the risk of oracle price manipulation attacks, the values returned by these preview methods are as close to accurate as possible. As such, they can operate by changing on-chain conditions and are not always safe to use as price oracles. The ERC-4626 specification includes a convert method and a totalAssets method that allow imprecise, and thus can be implemented as a powerful price oracle. For example, when converting between assets and shares, it is correct to use the time-weighted average price to implement the convert method.

Concrete implementation issues

Integrators must review any tokenized vault implementation before further integration, as there may be malicious implementations that appear to conform to the interface specification, but whose core functions consist of completely different design specifications.

EOA Direct Access

If a vault is to be accessed directly, its implementation needs to have features that can be used to accommodate slippage losses or accidental deposit/withdrawal limits. Unlike smart contracts, EOA does not have a failsafe mechanism for transaction rollback. If the precise output is not achieved when calling the core function, there is no way to roll back.

Extended Vault

As more players start to adopt the ERC-4626 standard, we will see more extensions implemented for the standard. For example, Superform developed an experimental Multi Vault extension that supports the use of different computations within a single Vault contract. Naturally, the more the implementation deviates from the original standard, the higher the possibility of introducing new vulnerabilities. Developers and auditors can find their best option based on use case to determine the actual value at risk.

It is important to note that it is not the smallest addition of each protocol that leads to catastrophic events, but the sum of them when integrated.

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