Read the findings of the 2022 Web3 Security Report

According to the logic, when the accounts of both parties to the transaction are not in `_isExcludedFromFees`, the transaction will be charged 12% of the transaction amount as a fee. The fee includes three parts:
* 6% as burnFee will be destroyed
* 4% as raceFee will be transferred to `racePool`
* 2% as rewardFee will be kept in the contract for accumulation, the fee will be transferred to `rewardPool` after the threshold is reached

We noticed that the addresses of `racePool` and `rewardPool` are currently set to `0x37043d86d59c43a0bef9c652c3cf3e1acfbd2dce`, which seems like an EOA account. Since `_transfer()` calls `rewardPool.addReward()`, this may cause the transaction to fail.

Incorrect Pool Addresses

In the contract `RACE`, the role `owner` has authority over the following functions:
- `excludeFromFees()`: exclude account from charge list or add account to the charge list
- `setRewardAtAmount`: update the threshold of transfer amount from contracts to `rewardPool`
- `updateRewardPool()`: update the address of `rewardPool`
- `updateRacePool()`: update the address of `racePool`
- `migrate()`: the owner can transfer any token from contract to any account 

Any compromise to the `owner` account may allow a hacker to take advantage of this authority.

Centralization Related Risks

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

Initial Token Distribution

Addresses should be checked before assignment or external call to make sure they are not zero addresses. Although these addresses can be modified to a non-zero address through `updateRacePool()` and `updateRewardPool()`, but set these addresses to zero address may cause the transaction to fail to execute.

Missing Zero Address Validation

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects.

Potential Reentrancy Attack 

State variables that never change should be declared as `constant` to save gas.

State Variable Should Be Declared Constant

`public` functions that are never called by the contract could be declared as `external`. `external` functions are more efficient than `public` functions.

Improper Usage Of `public` And `external` Type

The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

Unlocked Compiler Version

Race Token

RACE.sol

Race

Binance proof-of-reserves audit shows BTC is overcollaterised

Race

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

8

0

3

0

5