Vesting Update

In the contract `LinearVesting` the role `_owner` has authority over the functions shown below. - `pause()`: Pauses all vesting activities, preventing users from claiming tokens. Only the contract owner (`onlyOwner`) can call this function. - `unpause()`: Unpauses all vesting activities, allowing users to resume claiming tokens. Only the contract owner (`onlyOwner`) can call this function. - `update(bytes32 merkleRoot_, uint32 startTime_, uint32 endTime_, uint256 toClaim)`: Updates the vesting schedule settings, including the Merkle root, start time, end time, and the amount of tokens to be claimed. It also allows the transfer of additional tokens to the contract for vesting. Only the contract owner (`onlyOwner`) can call this function. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and update the sensitive settings and execute sensitive functionalities of the project.

In the `update()` function of the `LinearVesting` contract, there is a lack of validation for the `startTime_` parameter. Specifically, the function does not check whether `startTime_` is greater than the current block timestamp (`block.timestamp`). This omission allows for the possibility of setting a start time in the past, which could lead to unexpected behavior in the vesting logic and potentially enable exploitation by malicious actors. Similarly, updating `endTime_` without considering the current claimed tokens may bring unexpected result.

When transferring deflationary ERC20 tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee), only 90 tokens actually arrived to the contract. However, a failure to discount such fees may allow the same user to withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction. Reference: https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f ```solidity=82 ERC20Interface.safeTransferFrom( msg.sender, address(this), toClaim ); ``` - Transferring tokens by `toClaim`. ```solidity=87 totalVested += toClaim; ``` - The `toClaim` appears to be used for bookkeeping purposes without compensating the potential transfer fees.

The `LinearVesting` contract uses a Merkle root to verify user allocations for token vesting. If the same Merkle root is deployed in identical vesting contracts across multiple chains, there is a risk of a cross-chain replay attack. In such a scenario, a user could use the same Merkle proof to claim tokens on each chain, potentially leading to unauthorized token acquisition or double-spending.

Performing integer division before multiplication truncates the low bits, losing the precision of calculation. ```solidity=137 uint256 timePassedRatio = (timePassed * 1e18) / timeLeft; ``` ```solidity=139 claimableAmount = (((amount - startAmount) * timePassedRatio) / 1e18) + startAmount; ```

The `getClaimableAmount()` function in the `LinearVesting` contract calculates the amount of tokens that a user is eligible to claim based on a linear vesting schedule. The calculation involves division operations that can introduce rounding issues due to Solidity's integer arithmetic, which always rounds down. These rounding issues can result in small discrepancies in the calculated claimable amount.

The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=29 IERC20 public immutable ERC20Interface; ``` - The contract `LinearVesting` interacts with third party contract with `IERC20` interface via `ERC20Interface`.