T-Swap Handler Stateful Fuzz

[michael-lucas38]

Hi, I just started the handler stateful fuzz course on the T-Swap chapter.

I wonder why we call handlerStatefullCatchesFuzz.withdrawToken() directly without depositing first? I assume the forge invariant test do it for us?
If so then what's the order of the function call? Will the invariant test call the withdrawToken() first before even depositing?

Thank you

[EngrPips]

Hello @michael-lucas38 , I also wonder why we was withdrawing without depositing handlerStatefullCatchesFuzz.withdrawToken() but then i realize that the moment we defined our targetContract in our testSetup the fuzzer starts making random function calls to the contract base on what we have defined as targetSelector , so it only makes call to the selector we included in our targetSelector and the order of which it makes the call is random and that is why it is fuzzing. so at the end of any random call that the fuzzer have made to our targetContract we want to withdraw any money in the contract since we want to assert that the balance of the contract is 0 and starting balance of the user is equal to their ending balance. so in a scenario where the last call the fuzzer made to our contract is a deposit call then we would have withdrawn the money before making the asserts and if the last call the fuzzer made to our contract is a withdraw call then we would just return when we try to withdraw as the user won't have any balance. either ways our assert would make sense.

I really hope i explained enough to make you understand.

[michael-lucas38]

If the last call the fuzzer made is withdraw then calling withdraw again with balance = 0 will throw an error right?

[EngrPips]

Actually both the YieldERC20 and MockUSDC that we used in the contract inherited from an ERC20 contract from the openzeppelin library. and below is the implementation that handle token movements which include withdrawal

function _update(address from, address to, uint256 value) internal virtual {
        if (from == address(0)) {
            // Overflow check required: The rest of the code assumes that totalSupply never overflows
            _totalSupply += value;
        } else {
            uint256 fromBalance = _balances[from];
            if (fromBalance < value) {
                revert ERC20InsufficientBalance(from, fromBalance, value);
            }
            unchecked {
                // Overflow not possible: value <= fromBalance <= totalSupply.
                _balances[from] = fromBalance - value;
            }
        }

        if (to == address(0)) {
            unchecked {
                // Overflow not possible: value <= totalSupply or value <= fromBalance <= totalSupply.
                _totalSupply -= value;
            }
        } else {
            unchecked {
                // Overflow not possible: balance + value is at most totalSupply, which we know fits into a uint256.
                _balances[to] += value;
            }
        }

        emit Transfer(from, to, value);
    }

From the logic above i don't see where it reverts if the amount we want to withdraw is zero, i was actually suspecting the below line of the function

_balances[from] = fromBalance - value;

Thinking maybe if you subtract zero from zero the EVM might revert but that is not the case as i did a quick test using Remix and i just got back zero. and we also didn't have a check to revert if user tries to withdraw zero in our contract HandlerStatefulFuzzCatches.sol. so i think it would just add zero to your balance and not revert

[michael-lucas38]

Got it now, thanks!

[EngrPips]

I am glad you get it now buddy