The issue addresses the protocol's potential to overlook profitable trades due to its search range limitations. The bisection search method employed by the protocol might miss profit opportunities when the pools are balanced and a user wants to swap an amount of one token for another. This is crucial since arbitrage is a key feature that should always be available to users for capitalizing on price differences across various liquidity pools.
The provided formulas are part of a strategy to improve arbitrage calculations, making sure that profitable values are not missed by the protocol’s search algorithm. The goal is to ensure that the built-in arbitrage feature of the protocol can be utilized optimally, allowing for the capture of profits that would otherwise be lost due to the constraints of the current computational methods in use.
The mitigation for this issue revolved around updating the ArbitrageSearch algorithm to follow suit with the math and also example code provided in the issue, but making sure overflow risk is reduced.
After careful review it seems the implementation is sound and is consistent with the math in issue. The handling of overflow is also done in a proper way that does not interfere with the original intention of the math. For example, in the example code the calculation of z was done as such :
uint256 z = Math.sqrt(reservesA0 * reservesC1);
z *= Math.sqrt(reservesA1 * reservesB0);
z *= Math.sqrt(reservesB1 * reservesC0);
but to avoid the risk of overflow the actual implementation does this:
uint256 z = Math.sqrt(n0) * Math.sqrt(n1);
which is essentially the same math as intended either compared to the example code or the original intent of the math since n1 and n0 are equal to:
Lines of code
Vulnerability details
C4 Issue
https://github.com/code-423n4/2024-01-salty-findings/issues/419
Comments
The issue addresses the protocol's potential to overlook profitable trades due to its search range limitations. The bisection search method employed by the protocol might miss profit opportunities when the pools are balanced and a user wants to swap an amount of one token for another. This is crucial since arbitrage is a key feature that should always be available to users for capitalizing on price differences across various liquidity pools.
The provided formulas are part of a strategy to improve arbitrage calculations, making sure that profitable values are not missed by the protocol’s search algorithm. The goal is to ensure that the built-in arbitrage feature of the protocol can be utilized optimally, allowing for the capture of profits that would otherwise be lost due to the constraints of the current computational methods in use.
Mitigation
https://github.com/othernet-global/salty-io/commit/53feaeb0d335bd33803f98db022871b48b3f2454
The mitigation for this issue revolved around updating the ArbitrageSearch algorithm to follow suit with the math and also example code provided in the issue, but making sure overflow risk is reduced.
After careful review it seems the implementation is sound and is consistent with the math in issue. The handling of overflow is also done in a proper way that does not interfere with the original intention of the math. For example, in the example code the calculation of z was done as such :
but to avoid the risk of overflow the actual implementation does this:
which is essentially the same math as intended either compared to the example code or the original intent of the math since n1 and n0 are equal to:
Tests
Tests were added and all are passing
Conclusion
LGTM