Security Considerations in EIP-4626 by Fairyproof
Led by DeFi application Fei Protocol’s co-founder Joey Santoro, recently an EIP to create a new token standard for tokenized vaults was…
Led by DeFi application Fei Protocol’s co-founder Joey Santoro, recently an EIP to create a new token standard for tokenized vaults was proposed. And it is EIP-4626[1].
Although it was just proposed in December 2021, it soon garnered significant attention and great support from the Ethereum community and has been reported to be adopted by a few DAOs [2] including Tribe DAO [3] and Rari Capital DAO [4].
This EIP is intended to solve a pain point in the existing implementations of tokenized vaults, that is “tokenized vaults have a lack of standardization leading to diverse implementation details” [1]. This pain point makes integration of tokenized vaults “difficult at the aggregator or plugin layer for protocols which need to conform to many standards and forces each protocol to implement their own adapters which are error-prone and waste development resources” [1].
This EIP is based on ERC-20[5] which is a widely adopted standard in Ethereum’s DeFi applications and has considerable security issues or risks that need smart contract developers’ awareness.
As a blockchain security company, Fairyproof’s research team is quite interested in whether the issues or risks of ERC-20 implementation might be introduced in ERC-4626 as well. We studied this EIP, explored possible security checkpoints, and would like to share some ideas on these checkpoints.
This EIP requires that a tokenized vault MUST implement ERC-20 to represent shares and add new interfaces to convert shares to tokens or tokens to shares in both viewable functions and transfer functions. And these newly added functions introduce security considerations that need our awareness.
Here is a list of security considerations when implementing a tokenized vault based on this EIP:
- Implementation of Malicious Functions
Consider a vault’s implementation which conforms to the interfaces defined by this EIP but doesn’t conform to the specification. This happens quite often in rug-pulls where a proxy mechanism is used, and the proxy interface seems to conform to a token standard but actually, the real implementation is a malicious contract.
So, auditors or users need to carefully check its real implementation before taking further actions.
- Support for EOA Accounts
The EIP states that “If implementors intend to support EOA account access directly, they should consider adding an additional function call for deposit/mint/withdraw/redeem with the means to accommodate slippage loss or unexpected deposit/withdrawal limits” [1].
Besides the slippage loss and the unexpected deposit/withdrawal limits, there is another case that is commonly seen as well: a token burns on its transfers. This mechanism is used by some DeFi applications to decrease their tokens’ circulation supplies and inflate the tokens’ prices.
We would suggest ERC-4626 vaults disallow tokens of this kind to be deposited in the vaults.
- Using Interfaces as Oracles
The EIP states that “The preview methods return values that are as close as possible to exact as possible. For that reason, they are manipulable by altering the on-chain conditions and are not always safe to be used as price oracles.” [1], and “it would be correct to implement the convert methods as using a time-weighted average price in converting between assets and shares.” [1]
The most popular use case of oracles in the crypto space is to use them to obtain a token’s price, but any information that a smart contract needs may rely on an oracle. Hence, the preview methods which return information may be used as oracles as well. Although this may not seem to have significant use cases, for now, this listed potential issue needs our awareness. And a popular method to mitigate the risk of on-chain information being manipulated is to use a time-weighted average algorithm introduced by Uniswap[6].
- Rounding Issues
Vault implementers need to handle rounding directions carefully for the interfaces that calculate the vault shares or the number of tokens, and that convert shares to assets or assets to shares.
The specification suggests that when calculating the shares issued to a user for the amount of the underlying tokens, he/she supplies or the amount of the underlying tokens sent to him/her for a certain number of shares returned by him/her, it should round down.
When calculating the number of shares a user has to supply to receive a specific amount of the underlying tokens or the number of underlying tokens a user has to provide to receive a specific number of shares, it should round up.
When calculating the amour of shares or the underlying tokens in the converTo functions, the specification requires vault implementers to round down to ensure consistency across all ERC-4626 vault implementations.
These suggestions and requirements ensure there are always a sufficient number of underlying tokens reserved for transfers. This is what auditors need to be aware of when auditing vault implementations based on this EIP.
- Token Compatibility Issues
This EIP specifically mentions the ERC-20 token standard. It is the most widely adopted token standard for implementing fungible tokens. However, in our past audit experience, we audited some fungible tokens which were implemented based on alternative Ethereum tokens standards such as EIP-777[7] as well.
These alternative token standards are compatible with ERC-20 tokens but have some differences.
Let us take the EIP-777 token standard as an example. The token standard allows implementers to use a registry to look up the interfaces. If the registry has bugs, anything depending on it will have an adverse impact. A commonly seen issue that is introduced by this feature is a re-entrancy risk [8].
So, there might exist two kinds of scenarios that we need to pay attention to.
The first scenario is a vault is implemented based on an ERC-20 compatible but alternative standard. The second is an ERC-4626 value that interacts with a token that is ERC-20 compatible but is implemented based on an alternative token standard.
In both scenarios, the alternative token standard may introduce issues or risks. And the implementations based on the alternative standard should be carefully reviewed and audited.
Closing Thoughts:
In this paper, we list some possible security considerations when auditing an ERC-4626-based vault. Some of these considerations are already mentioned in the EIP and others are listed based on our audit experience.
We wish our tentative suggestions would give implementers, users, and auditors some rough ideas on how to handle ERC-4626 vaults securely and safely.
References:
[1] EIP-4626: Tokenized Vault Standard, https://eips.ethereum.org/EIPS/eip-4626 Dec 22, 2021
[2] Decentralized Autonomous Organizations, https://ethereum.org/en/dao/
[3] Tribe, https://docs.fei.money/governance/tribe
[4] Rari Capital, http://rari.capital/
[5] ERC-20 Token Standard, https://ethereum.org/en/developers/docs/standards/tokens/erc-20/
[6] Uniswap, https://uniswap.org/
[7] EIP-777: Token Standard, https://eips.ethereum.org/EIPS/eip-777
[8] Samreen N F, Alalfi M H. Reentrancy vulnerability identification in Ethereum smart contracts[C]//2020 IEEE International Workshop on Blockchain Oriented Software Engineering (IWBOSE). IEEE, 2020: 22–29.
Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing