Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

ERC4626 is a specification for a vault. This vault gives out shares in return for assets. The shares determine the underlying assets that can be redeemed (in terms of assets) from the protocol.

The number of shares that are gained is dependent on the vaults exchange rate. This rate is dependent on the vaults liquidity. For instance, if 100 tokens give 200 shares, then the share is worth 0.5 of a token.

When depositing tokens, the user receives a slightly rounded down number of shares. This often doesn't matter... but, in the case where small amounts of assets and shares are being used, this can cause major havoc. For instance, if the exchange rate for is 1 share for 100 tokens. Then depositing 99 tokens would result in a drastic loss with the user getting zero shares.

When the vault is empty, an attacker can abuse this rounding to steal money from other users. For instance, take the following scenario:

1. The attacker buys a single share for virtually no money.
2. A regular user decides to add in a large amount of the asset. They send the transaction.
3. The transaction is frontran by an attacker who donates the same amount of funds as the user is about to add in.

Why does this matter? The contract currently has 1 share for a large amount of assets. So, the cost of 1 share is the amount of assets added in (assets worth/1 share). The user deposits in the token. If it's less than the worth of the one share, then they will get 0 shares even though they liquidity is added. The attacker can then withdraw their share for a massive profit.

This is a known limitation of the specification that was first realized by a Trail of Bits audit of Yearn. How do we prevent this? Two obvious ways are forcing a large deposit at the beginning of the contract and forcing a minimum amount of shares.

The new concept being used to prevent this by Amxx and Open Zeppelin is a virtual offset. The issue occurs because of an inflation attack on the contract and rounding errors with a small amount of shares. The goal of the virtual offset is to artificially increase the number of shares by adding more decimals to the shares. This mitigates the attack since the rounding error is what made the attack possible

The second remediation strategy is including the virtual shares and virtual assets in the exchange rate computation. By doing this artificial increase, the donation is somewhat put into the virtual components, making it not profitable.

Overall, an interesting attack that is possible because of frontrunning and the EVM not supporting floating point numbers. The solution to the problem is clever and does cost very much money for the users of the vault.