1 Exchange security record

Users may query the claimable amount via the function `claimableAmount` with `OneExVestingFactory`. However, each vesting plan may refer to a different asset, the return value of the `claimableAmount` will refer to the sum of different assets, for example a mix of USDC, WETH, etc. As a result, the return value may cause confusion.

According to the comment, `startTime` is the timestamp for when this vesting should have started. But this field is never used to check whether the vesting has been started. We would like to discuss this finding with the team to make sure this design is intended.

For each vesting schedule, there are two ways to claim: - via `claim` function - via `receive` function by sending zero amount of native token. However, the `claim` function is subjected to the `onlyOwner` modifier, but the `receive` function is not limited by the owner role.

The `revoke()` function permits the `ADMIN` to cancel a vesting schedule. Upon invocation, it resets the attributes within the `schedule` struct and removes the corresponding vesting schedule from the `_revokableVestings` list. However, it does not modify the user's individual vesting schedule in `accountVestings[msg.sender].vestings`. Once a vesting schedule is revoked, it cannot be reused, yet it persists in the user's vesting list. If all of a user's vesting schedules are revoked, these outdated schedules remain stored within the contract, leading to storage and computational overhead.

In the `OneExVestingFactory` contract, the user may claim all reward with `claimAll()` and query the information about claimable amount via `claimableAmount`. However, since the vesting list for specific user will keep increasing during the time, which may cause the DoS issue on aforementioned functions.

The linked function `calcDistribution()`function is designed to compute the quantity of tokens to be distributed over time. In Solidity, the division operation inherently rounds down to the nearest integer. ```solidity return (schedule.totalAmount * (time - schedule.cliffTime)) / (schedule.endTime - schedule.cliffTime); ``` This behavior may lead to a potential loss of precision during the initial distribution rounds for the specified recipient at `schedule.address`.