CertiK reviewed Rangers Protocol (Rangers Protocol III) on 16 Oct 2023: 8 findings, 0 critical; 3 marked fixed, 5 acknowledged.
Report hosted on skynet.certik.com.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 1 | 0 |
| Medium | 0 | 0 | 1 |
| Low | 0 | 4 | 2 |
In `RPGTokenWithProtection` contract, the `owner` has the authority over the following functions: - LiquidityProtection_setLiquidityProtectionService(IPLPS _plps) - revokeBlocked(address[] calldata _holders, address _revokeTo) - LiquidityProtection_unblock(address[] calldata _holders) - disableProtection() Any compromise to the account may allow the hacker to do the following (but not limited to): - damage the protection mechanism. In `RPGVestingF` contract, the `owner` has the authority over the following functions: - init(IERC20 token, uint256 total,address[] calldata beneficiarys,uint256[] calldata amounts) - setStart(uint256 newStart) - changeaddress(address oldaddr,address newaddr) Any compromise to the account may allow the hacker to do the following (but not limited to): - disrupt the vesting mechanism. In `RPGToken` contract, the `DEFAULT_ADMIN_ROLE` has the authority over the following functions: - setMintRole(address to) - removeMintRole(address to) - setOperatorRole(address to) - removeOperatorRole(address to) - grantRole(bytes32 role, address account) - revokeRole(bytes32 role, address account) - renounceRole(bytes32 role, address account) In `RPGToken` contract, the `MINTER_ROLE` has the authority over the following functions: - mint(address to, uint256 amount) - renounceRole(bytes32 role, address account) In `RPGToken` contract, the `OPERATOR_ROLE` has the authority over the following functions: - renounceRole(bytes32 role, address account) - addTransferBlacklist(address addr) - removeTransferBlacklist(address addr) - addReceiveBlacklist(address addr) - removeReceiveBlacklist(address addr) Any compromise to these accounts may allow the hacker to do the following (but not limited to): - mint token to any accounts. - block token transfer, mint operations. - role management operations.
The `totalSupply` function in contract **RPGToken** does not return the value that is held in the corresponding state variable of contract **RPGToken**.
According to the documentation of Uniswap V3, the `uniswapFactory` address passed by the `computeAddress` function should be the `uniwapFactory` address of the V3 version. The current uniswap version used in the contract is V2, although there is no problem using the V2 version, but there will be problems if the uniswap version used in the contract is V3.
The variable `HUNDRED_PERCENT` is never used.
The contracts `RPG_ALL_BSC.sol` and `RPG_ALL_ETH.sol` are serving as the underlying entity to interact with third party `PLPS`,`Uniswap` protocols. The contract `RPGToken.sol` is serving as the underlying entity to interact with third party `_mintcontract`. The scope of the audit treats 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.
| Address | Chain | Source code |
|---|---|---|
| 0x1f16…c1030x1f16d41f9b3db03b462bdd6c92245ee708d1c103 | Chain: Ethereum | Source code: Verified source |
1,044 projects reviewed · 1,375 reports · latest May 2025
See CertiK’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us