Read the findings of the 2022 Web3 Security Report

To bridge the gap in trust between the administrators need to express a sincere attitude regarding the consideration of the administrator teamʼs anonymity.

The `owner` of `RoraPro` has the responsibility to notify users about the following capabilities:
- renounce ownership through `renounceOwnership()`
- transfer ownership to an address through `transferOwnership()`
- set `_releaseControl` through `releaseControl()`
- withdraw BNB/ETH through `claimTokens()`
- set `pancakeV2Pair` through `changeRouter()`
- set `_mintControlAddress` through `changeMintControl()`
- set `_whiteList` through `setWhiteList()` and `unSetWhiteList()`
- set `_escapeFee` through `setEscapeFee()` and `unSetEscapeFee()`
- set `inviter` through `setInviter()`
- set `USDT` through `setUSDTAddress()`

The `_mintControlAddress` of `RoraPro` has the responsibility to notify users about the following capabilities:
- set `_researchMap` through `researchAdd()`
- release tokens of `_researchAddress` through `researchRelease()`
- set `_researchMap` through `playAdd()`
- release tokens of `_playAddress` through `playRelease()`
- set `_placementMap` through `placementAdd()`
- release tokens of `_placementAddress` through `placementRelease()`
- release tokens of `_nftAddress` through `nftRewardRelease()`
- release tokens of `_liquidityAddress` through `liquidityMintAll()`
- set `_pledgeMap` through `pledgeAdd()`
- set `_totalPledge` through `pledgeTotal()`
- release tokens of `_rewardAddress` through `pledgeRelease()`
- view the length of `_activeArray` through `getActiveLength()`
- set `_activeArray` through `addActiveArray()`

Centralization Risks in RoraPro.sol

A total of `500000 * 10**18` tokens were sent to the `_airdropAddress`, `_researchAddress`, `_playAddress`, `_placementAddress`, `_liquidityAddress` and `_nftAddress`, when deploying the contract. 
This could be a centralization risk as these addresses hold a large number of tokens.

Initial Token Distribution

If the coe L304 returns `false`, the operation still can be successed.

Function Call Not Revert on Failure

There is no check on the input value, so when the function `buyNFTCard()` is called, the input value can be arbitrary. Problems may also occur if the same `random` is used twice.

Lack of Input Validation

In the `tranfer()` function, the `_transfer()` function is executed if `msg.sender` is `pancakeV2Pair`, but in `transferFrom()` it is executed when the recipient is `pancakeV2Pair`.

Inconsistent Code Logic

When the function `_transfer` is called to transfer tokens, if the variable `amount` is small, then no addresses may receive tokens.

Potential Tokens May Be Lost

The function `pledgeRelease()` is called to distribute the tokens from address `_rewardAddress`, and the variable `_balanceOf[_rewardAddress]` is set to 0, but the tokens may not all be distributed.

Potential Tokens Not Distributed

According to the logic, when the contract is deployed, `10*10000` tokens are distributed to `liquidityMintAll` and the daily reward is `200`.
In the function `liquidityMintAll`, there is a check in code L529 that the balance of `_liquidityAddress` must exceed `200`, so the `200` tokens will end up being left behind.

Leftover Liquidity Reward

The contract serves as the underlying entity to interact with third-party DEX protocols. The scope of the audit treats 3rd party entities as black boxes and assumes their functional correctness. However, in the real world, 3rd parties can be compromised, which may lead to lost or stolen assets.

Third Party Dependencies

The return values `rora` and `usd` are not used.

Unused Return Values

After calling the `*Release()` function, all the data is not cleared, which may lead to a secondary distribution of these addresses.

Lack of Clear Data

`public` functions that are never called by the contract could be declared `external`. When the inputs are arrays, `external` functions are more efficient than `public` functions.

Function Visibility Optimization

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.

Set `immutable` to Variables

The linked variables could be declared as `constant` since these state variables are never modified.

Set `constant` to Variables

Functions that affect the status of sensitive variables should be able to emit events as notifications to customers.

Missing Emit Events

There are many hardcode addresses in this codebase.

Hardcode Address

The function `buyNFTCard()` can be called by anyone to modify the variables `_randomRora` and `_randomUsd`.

Discussion For Function `buyNFTCard()`

According to the code logic, the function `require` returns true when the variable `_whiteList[from]` is equal to false, so only users who are not in the variable `_whiteList` can transfer tokens, which should be blacklist.

Discussion about `_whiteList`

The input address should be checked before assignment to make sure it is not zero addresses. 

Missing Zero Address Validation

The linked variable declarations do not have a visibility specifier explicitly set.

Visibility Specifiers Missing

According to the comments in L432 and L435, 40% of the transferred tokens are burned and 30% are transferred to `_rewardAddress`, but only 4% and %3 are actually transferred.

Rora Play

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

21

0

15

0

6