Section 5: T-Swap Proof of Concept for incorrect fees - stateless fuzz or basic foundry unit test?

[SquilliamX]

``` Incorrect fee calculation in TSwapPool::getInputAmountBasedOnOutput causes protocol to take too many tokens from users, resulting in lost fees

Description: The getInputAmountBasedOnOutput function is intended to calculate the amount of tokens a user should deposit given an amount of tokens of output tokens. However, the function currently miscalculates the resulting amount. When calculating the fee, it scales the amount by 10_000 instead of 1_000. ```

Hello everyone! I've been looking into the bug we found in t-swap (above)and I'm considering writing a stateless fuzz test to tackle it. Do you think that approach would be effective? Additionally, I'm curious if in general there is a stateless and stateful fuzz test equivalent for each foundry test for contract bugs? Thanks!

[EngrPips]

Hello @SquilliamX, Actually stateless fuzzing test wouldn't catch most bugs that a stateful fuzzing test would catch and that was why we needed a stateful fuzzing test in the first place. If a stateless fuzzing test would equally catch a bug that a stateful fuzzing test would catch then there wouldn't be any need for writing a heavy, complicated stateful fuzzing test. but yeah I mean you can try out stuff, see the outcome, and learn deeply.

Also, I couldn't wrap my head around what you mean by is there a stateless and stateful fuzz test equivalent for each foundry test for contract bugs?, how would they be equivalent they work differently, one preserves contract state while the other doesn't

[SquilliamX]

I essentially meant, all bugs can be found through manual review and unit testing; but can all bugs in a smart contract be found through fuzzing?

[EngrPips]

Patrick would always say there is no silver bullet in security review; no one tool fits all.

[Chinwuba22]

For whether or not an issue would be caught from fuzzing would be dependent on your assertions/invariants. So if an issue like fee(or other issue) as you mentioned above would be caught by fuzzing or any other tool is highly dependent on your assertions/invariants. So this is why manual review is still important even after using any tool.