1ex Audit

Some stable coin contract like [USDT](https://etherscan.io/token/0xdac17f958d2ee523a2206206994597c13d831ec7#code) is not compatible with the Openzeppelin ERC20 template, for example, it will not return bool value when transfer operation finished, which may cause the require statement always revert. **[Note]**: Since the `_usdContract` is unknown during the auditing and is a third-party dependency, the team should be careful with this issue.

The linked function allows the `ADMIN` role to revoke vesting schedules. However, this function does not check whether `_revokableVestings` has contained the input `vestingContract`. Invoking functions on an unverified third-party address may introduce significant risks.

The provided code snippet lacks a validation check to ensure that the input address is not `address(0)`. This input `address` is utilized to create a new `Schedule`: ```solidity schedule = Schedule( account, amount, 0, startTime, startTime + (cliffDays * 1 days), startTime + (cliffDays * 1 days) + (vestingDays * 1 days), asset, revokable, false ); ``` This address is designated to receive the vested `amount` in the `claim()` function. If `schedule.account` is set to the zero address, the `claim()` function will always fail. ```solidity require(IERC20(schedule.asset).transfer(schedule.account, amountToTransfer), "Vesting: transfer failed"); ```" It's crucial to add a validation check for the input address to prevent such issues.

The smart contract does not check or store the return value of an external call in a local or state variable, which may introduce vulnerabilities due to the unhandled outcome. ```solidity=203 _allVestings.add(_contract); ``` --- ```solidity=204 if (revokable) { _revokableVestings.add(_contract); } ``` --- ```solidity=260 _revokableVestings.remove(vestingContract); ```