Ancient Raid security record

#### Centralization Risks In `RaidContract.sol` In the contract `AccessControlUpgradeable` the role `DEFAULT_ADMIN_ROLE` has authority over the functions listed below: - `grantRole()`: grant `role` to `account`; - `revokeRole()`: revoke `role` from `account`. Any compromise to the `DEFAULT_ADMIN_ROLE` account may allow the hacker to take advantage of this authority and grant a role to an account or revoke a role from an account. In the contract `OwnableUpgradeable` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and update the ownership of the contract.  In the contract `RaidContract` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and update the configuration of the contract.  In the contract `RaidContract` the role `master` has authority over the functions shown in the diagram below. Any compromise to the `master` account may allow the hacker to take advantage of this authority and update the configuration of the `master`.  In the contract `RaidContract` the role `PAUSER_ROLE` has authority over the functions listed below: - `pause()`: pause all token transfers; - `unpause()`: unpause all token transfers. Any compromise to the `PAUSER_ROLE` account may allow the hacker to take advantage of this authority and pause/unpause the token transfer. In the contract `RaidContract`, the `mainWallte`, `zhiWallte`, and `rewardWallte` are used to receive the fee. If they are the EOA (Externally Owned Account), the mishandling of their private key can have devastating consequences to the project as a whole. --- #### Centralization Risks In `Proxy.sol` In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change the ownership of the contract.  In the contract `ProxyAdmin` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority, change the admin of the proxy, and upgrade the implementation of the contract.  In the contract `TransparentUpgradeableProxy` the role `admin_` has authority over the functions listed below: - `changeAdmin()`: change the admin of the proxy; - `upgradeTo()`: upgrade the implementation of the proxy; - `upgradeToAndCall()`: upgrade the implementation of the proxy and call a function. Any compromise to the `admin_` account may allow the hacker to take advantage of this authority, change the admin of the contract, and upgrade the implementation of the contract. There are three fee collectors, `mainWallte`, `zhiWallte`, and `rewardWallte`, over time, they will gain many fees. Any compromise to the fee collectors' account may allow the hacker to take advantage of them. --- The following content is based on the commit [cfa0b7e8d196ae71df0ba2a403a7f189114bbbbf](https://github.com/ancient-raid/contracts/tree/cfa0b7e8d196ae71df0ba2a403a7f189114bbbbf). The role `PAUSER_ROLE` and related functions are removed: - `pause()` - `unpause()` In the contract `RaidContract`, the privileged functions listed below are removed: - `updateMaster()` - `migrateData()` - `mint()` - `setPauser()` The role `master` and the related function are removed: - `updateMaster()` --- The following content is based on the commit [623b6ca4ef8499740e52c2b3a584dfc3dedde5e0](https://github.com/ancient-raid/contracts/tree/623b6ca4ef8499740e52c2b3a584dfc3dedde5e0). In the contract `RaidContract`, the role `_owner` has authority over the newly added functions listed below: - `pause()`: pause all token transfers; - `unpause()`: unpause all token transfers.

The `RaidContract` and `AdminUpgradeabilityProxy1` are upgradeable contracts, the owner can upgrade the contract without the community's commitment. If an attacker compromises the account, he can change the implementation of the contract and drain tokens from the contract.

All of the RAID tokens are sent to the contract deployer when deploying the contract. This could be a centralization risk as the deployer can distribute RAID tokens without obtaining the consensus of the community.

The linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.

The contract is serving as the underlying entity to interact with the 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=3478 IPancakeRouter02 public pancakeRouterV2; ``` - The contract `RaidContract` interacts with third party contract with `IPancakeRouter02` interface via `pancakeRouterV2`. ```solidity=3595 pancakeV2Pair = IPancakeFactory(pancakeRouterV2.factory()) .createPair(address(this), pancakeRouterV2.WETH()); ``` - The contract `RaidContract` interacts with third party contract with `IPancakeFactory` interface via `pancakeRouterV2`.