Finding bugs in larger and more complex codebases with an incredible large amount of different state transitions and many different states which can have an impact on each other.
It’s CryptoAlgebra’s position update, specifically, the fee update for a position and the corresponding claimable fee, let's take a look at the function itself first
It’s CryptoAlgebra’s position update, specifically, the fee update for a position and the corresponding claimable fee, let's take a look at the function itself first
I
t’s pretty easy to understand what is happening here:
Now for this function, it might be an interesting exploit idea to somehow manipulate the received fee. The idea behind this tweet is to increase awareness and creativity, to not only take care of how the fee is calculated but also which other states could be potentially manipulated in an effort to create a working exploit. In our scenario, the following ideas might come to mind:
1. Manipulate the feeGrowth distribution itself:
t’s pretty easy to understand what is happening here:
- Update the liquidity for the specific position, can be either increased or decreased depending if its a mint or burn.
- Update the innerFeeGrowth for both tokens, which are given as function parameters and do reflect the updated innerFeeGrowth values.
- Calculate the accumulated fees since the last innerFeeGrowth.
- Increase the claimable fees.
Now for this function, it might be an interesting exploit idea to somehow manipulate the received fee. The idea behind this tweet is to increase awareness and creativity, to not only take care of how the fee is calculated but also which other states could be potentially manipulated in an effort to create a working exploit. In our scenario, the following ideas might come to mind:
1. Manipulate the feeGrowth distribution itself:
During a swap, the feeGrowth is increased as follows, with the currentLiquidity as divisor - is the currentLiquidity is manipulatable?
Another mechanism is responsible for ensuring the currentLiquidity - can this mechanism be manipulated in favor of creating a working fee exploit?
2. Manipulate the initial setting of innerFeeGrowthToken upon the creation of the position; is it possible to add liquidity to an unupdated state, which would then allow for flash-thefting fees?
3. Manipulate the multiplier, liquidityBefore, such that one receives more fees - is it possible to increase my own liquidity without updating the positions fee state?
2&3 are kind of the same but there might be still differences in the methodology.
Now, you got a pretty good understanding of how many different state transitions play a role for the correctness of the fee calculation, and these were just a few examples. Generally speaking, when it comes to fee accumulation, accounting and distribution, there are often endless possibilities which might pave a way for an exploit.
Especially if fees are accumulated via different ways besides swaps, such as flashloans and other features. For every single feature which is added to such a protocol, the risk of an exploit increases *EXPONENTIALLY*.
Smart contract auditing is hard - don’t let anyone tell you otherwise. Specifically identifying all possible state transitions which can have impact on certain calculations as above, can be very hard. Most recent exploits have discovered that a codebase can never have enough audits and staying humble and cautious is one of the most important thing in the web3 security space.
