The protocol uses forceApprove function to handle the case when the asset requires firstly to be approved to zero. But there are also ERC-20 tokens that revert if they are approved to zero value.
The contracts SablierV2MerkleLT, SablierV2MerkleLT and SablierV2BatchLockup use the forceApprove function to approve the amount of required asset and to handle the case when the asset is USDT and this type of tokens reverts when the approve is not firstly set to 0.
SablierV2MerkleLT:
SablierV2MerkleLL:
SablierV2BatchLockup:
But there is also another problem. There are some ERC-20 assets that revert when the approval is 0:
Some tokens (e.g. BNB) revert when approving a zero value amount.
https://github.com/d-xo/weird-erc20?tab=readme-ov-file#revert-on-zero-value-approvals
The protocol can work with BNB token because in the documentation is written:
If the asset is a ERC-20 token that reverts by zero approval, the contracts SablierV2MerkleLT, SablierV2MerkleLT will be not sucessfully deployed and the SablierV2BatchLockup::_approve function will revert. This function is called in _handleTransfer function. That means the revert will disable the functionality of the important functions that rely on _handleTransfer function (createWithTimestampsLT, createWithDurationsLD, createWithDurationsLL, createWithDurationsLT, createWithTimestampsLL, createWithTimestampsLD)
Manual Review
Add a check for the type of asset and use forceApprove only for assets that revert when they are not firstly approved to 0.
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.