Due to lack of approve in the withdraw function, user's funds can be frozen.
If a user creates an offer with the token not wrappedNativeToken in the TokenManager, he couldn't withdraw funds because there is no approve of that token in the contract.
Suppose a user withdraw TaxIncome by USDC token. He calls follow statement.
But in the withdraw function, there is insufficient allowance when capital pool sends tax income to user(see _safe_transfer_from()). Because there is no approve of this USDC token for capital pool in the contract.
Manual Review
Improve _updateTokenWhiteListed(), so capital pool approve white listed tokens.
This issue's severity has similar reasonings to #252, whereby If we consider the correct permissioned implementation for the `approve()` function within `CapitalPool.sol`, this would be a critical severity issue, because the withdrawal of funds will be permanently blocked and must be rescued by the admin via the `Rescuable.sol` contract, given it will always revert [here](https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/CapitalPool.sol#L36-L38) when attempting to call a non-existent function selector `approve` within the TokenManager contract. Similarly, the argument here is the approval function `approve` was made permisionless, so if somebody beforehand calls approval for the TokenManager for the required token, the transfer will infact not revert when a withdrawal is invoked. I will leave open for escalation discussions, but based on my first point, I believe high severity is appropriate. It also has a slightly different root cause and fix whereby an explicit approval needs to be provided before a call to `_safe_transfer_from()`, if not, the alternative `_transfer()` function should be used to provide an approval, assuming a fix was implemented for issue #252
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.