# safeApprove(...) reverts if approval is different than 0, use safeIncreaseAllowance(...) instead Crit/High · Three Sigma · Lending aggregator · 6th May, 2023 Finding 3S-FUJI-H06 of the Fuji Finance security review. - Report: /reports/fuji-finance - Source: https://cdn.sanity.io/files/qoqld077/staging/32181a28eac3175d15fb8924d249bb0d91ca350c.pdf --- ### Description The BaseRouter interacts with the vault and some actions require tokens being pulled from the BaseRouter to the vault, which means that the BaseRouter must first approve the vault. This approval is using SafeERC20 safeApprove(...), which is deprecated and should not be used due to the fact that it reverts if the allowance of pair owner and spender is not 0. This allowance should always be 0 for most tokens and situations when safeApprove(...) is called, given that the tokens are spent right after the approval is emitted. However, some weird tokens or behaviour could lead to not all tokens being spent, which would freeze the BaseRouter actions that require approval. ### Recommendation Use safeIncreaseAllowance(...) instead of safeApprove(...). ### Status Addressed here: [Fujicracy/fuji-v2#623](https://github.com/Fujicracy/fuji-v2/pull/623) --- Related findings: - [Consider using forceApprove instead of safeApprove in OstiumTraidingCallbacks](https://0xsimao.com/findings/ostium-force-approve-traiding-callbacks): Ostium - [transferFrom in ERC20Extended will always emit an Approval event if the allowance changes](https://0xsimao.com/findings/m-0-transfer-erc20-approval-allowance): M^0 Minter Gateway - [Use a flag to increase or decrease the index of the pool instead of a heuristic](https://0xsimao.com/findings/nftperp-ii-flag-decrease-index-heuristic): Nftperp Matching Engine