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!

Aave is a very common loan protocol in the web3 space. Liquidation is the process of getting back the tokens of a loan in exchange for a discounted rate on the users collateral.

For instance, imagine I took out a loan for 1 ETH for 2000 USDC with a threshold of 10% (USDC to ETH is probably around 1800). If I wasn't repaying my interest or the cost of USDC dropped,another user could come in to supply the 1ETH and get 1850 USDC back for this. This keeps the protocol solvant.

e-mode (efficiency mode) is an asset that is consistent in price with a pegged value, like USDC. When getting the price of user assets, the program will check to see if the price should be gotten from the default location or the e-mode location. This is done by passing in the collateralPriceSource and debtPriceSource variables.

The assumption is that the debtPriceSource should be the price source for the e-mode category. This is imposed by the restriction that if a user is in e-mode, they should only be able to borrow assets that belong to this users e-mode. Can this be violated?

If the following situation occurs, this can be violated:

• E-mode is using a custom oracle.
• The debt asset that is liquidated has been removed from e-mode.

What's the consequence of this? The calculations get messed up on the liquidation process. Because the user being in an e-mode state is checked while adding the tokens, the logic explained above takes a weird turn. It will get the wrong price as a result. The e-mode price returns a nice pegged value, which is much cheaper than using an oracle like chainlink.

If USDC was depegged from $1 to $2, then the liquidator would only get half of what they deserve. If it depegged from $1 to $0.5, they would get double they deserve. This is a pretty drastic consequence, especially with large loans.

To fix this issue, the e-mode price should only be used if the e-mode flag on both the user and the oracle is set. This felt like a reasonable optimization but the complicated system led to this issue.

To me, a single thing stands out: this is a completely crazy situation that the author of this conjured up. However, this is a legit scenario that could happen with an admin acting in a sane manner. Did they see the separation between the user e-mode flag and the oracle e-mode flag and come up with this?