1 Exchange security record

In the contract `OneExVesting`, the role `owner` has the authority over the following functions(Note: In the context of the auditing, the `OneExVesting` owner is supposed to be the `OneExVestingFactory`): - `vest()`: Set up a vesting schedule for a set user. (Note: the functionality can also reset the schedule if the `OneExVesting` is using separately instead of working with the factory contract.) - `claim()`: Claim vested tokens from VestingFactory. - `revoke()`: Cancel a vesting schedule. --- In the contract `OneExVestingFactory`, - the role `ADMIN` has the authority over the following functions: - `vest()`: Set up a vesting schedule for a set user. - `revoke()`: Revoke tokens from vesting schedule. - the role `DEFAULT_ADMIN_ROLE` has the authority over the following functions - `grantRole()`: Assign `ADMIN` and `DEFAULT_ADMIN_ROLE` to new address. - `revokeRole()`: Revoke `ADMIN` and `DEFAULT_ADMIN_ROLE` from address. --- In the contract `OneExTokenV1`, - the role `SNAPSHOT_ROLE` has the authority over the following functions: - `snapshot()`: Create a new snapshot and returns its snapshot id. - the role `PAUSER_ROLE` has the authority over the following functions: - `pause()`: Pause the state of the contract. - `unpause()`: Resume the state of the contract. Any compromise to the privileged roles may allow a hacker to take advantage of this authority and maliciously revoke the vesting schedules and transfer the vested amount to unauthorized accounts. --- In updated version [Ethereum Address](https://etherscan.io/address/0xEe1D8a1556E89c6E44702878f1dF0BF54cf72bE0), the following privileged function was added for the `ADMIN` in `OneExVestingFactory`: - `addAsset`: Add a new asset to `_supportedAssets` list. - `removeAsset`: Remove an asset from `_supportedAssets` list.

In the contracts `OneExTokenV1`, the proxy admin has the authority to update the implementation contract behind the proxy contracts. Any compromise to the admin account may allow a hacker to take advantage of this authority and control the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.

Within the constructor of the `OneExTokenV1` contract, the deployer mints `1000000000 * 10 ** decimals()` `1ex` tokens directly to its own account. This poses a centralization risk, as it grants the deployer the capability to allocate tokens without community consensus. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

In the contract `contractV1.sol`, the `PAUSER_ROLE` has the authority to update the status of the `_paused` and further pause/resume the functionality of the token transfers. Any compromise to the private key of the `PAUSER_ROLE` may allow hackers to take advantage of this authority and allow/prevent user access to token transfer functionalities.

In the provided code snippet, the current contract transfers a specified `amount` of `asset` tokens to the target `_contract`. However, if the `asset` is a deflationary ERC20 token, the `_contract` will receive an amount less than the specified `amount` due to transaction fees. For example, consider a deflationary ERC20 token named Ftoken that charges a 10% transaction fee on the total amount sent. If a user sends 100 Ftokens, the recipient will only receive 90 Ftokens. ```solidity require(IERC20(asset).transferFrom(msg.sender, _contract, amount), "VestingFactory: transfer failed"); ``` In this context, the recipient is `_contract`, which represents a newly instantiated vesting contract. The tokens received by this vesting contract are then verified against the original `amount` sent. Consequently, if `asset` is a deflationary token, the received amount will always be less than the sent amount, causing the following validation to consistently fail: ```solidity require(IERC20(asset).balanceOf(address(this)) == amount, "Vesting: not enough tokens"); ```