Read the findings of the 2022 Web3 Security Report

In the contract `InitializableOwnable` 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.

![](https://accelerator-tasks-prod.s3.amazonaws.com/74c84e933d8047d68bc6d7c268b441b3/diagrams/centralization-InitializableOwnable-_OWNER_.svg)

Centralization Related Risks

In the contract `XRushCars` 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.

![](https://accelerator-tasks-prod.s3.amazonaws.com/74c84e933d8047d68bc6d7c268b441b3/diagrams/centralization-XRushCars-_OWNER_.svg)


The given input `xox` is missing the sanity checks for ensuring non-zero value.

Lack of Input Validation

When the `bnb` sent by the user in `mintXCar` function is greater than `carNum.mul(BNBPRICE)`, the remaining part will not be returned to the user.

The Remaining `bnb`  Not Return Back

`public` functions that are never called by the contract could be declared `external`. `public` function arguments are copied to memory while `external` functions read from calldata, which is cheaper than memory allocation.

Proper Usage of “public” and “external” type

The given input `signer` and `xox` are missing the sanity checks for ensuring non-zero value.

Code lack sanity check for ecrecover. Raw ecrecover function will yield the zero address for any incorrect signature.

Lack of sanity checks on ecrecover

In the contract `XRacers` 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.

![](https://accelerator-tasks-prod.s3.amazonaws.com/74c84e933d8047d68bc6d7c268b441b3/diagrams/centralization-XRacers-_OWNER_.svg)

When the `bnb` sent by the user in `mintXRacer` function is greater than `XRacerBNBPrice.mul(numberOfRacers)`, the remaining part will not be returned to the user.

The given input `number` parameter is missing the check that it should greater than `minted_supply`.

In the contract `XRushToken` 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.

![](https://accelerator-tasks-prod.s3.amazonaws.com/74c84e933d8047d68bc6d7c268b441b3/diagrams/centralization-XRushToken-_owner.svg)

Current `XRushToken` implementation is vulnerable to [a known ERC20 race condition issue](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729), which could lead to token theft. When a user calls `approve()` for a second time on a spender that has already been allowed, the spender could call `transferFrom()` to transfer the previous value and still receive the authorization to transfer the new value.

Exploit scenario:
1. Alice calls `approve(Bob, 100)` to allow Bob to spend 100 tokens.
2. Alice changes her mind and calls `approve(Bob, 50)`.
3. Bob observes the second `approve(Bob, 50)` function call and calls `transferFrom(Alice, Bob, 100)` before the second `approve(Bob, 50)` call. 
4. The above scenario can be achieved by front-running. In this case, Bob can transfer another 50 tokens from Alice and in total, he transferred 150 tokens from Alice.

Potential Risk On `approve()`/`transferFrom()` Methods

```solidity=132
        uint256 burnAmount = amount * 5 / 100;
        
        if (_afterTokenTransferBurn[recipient]) {
            amount = amount - burnAmount;
            _balances[address(0)] += burnAmount;
            _totalBurn += burnAmount;
            emit Transfer(sender, address(0), burnAmount);
        }
        
        unchecked {
            _balances[sender] = senderBalance - amount;
        }
```
The above code shows that the sender's balance is decreased after the `burnAmount` is subtracted from the `amount`. In this case, the subtraction of the sender's balance is smaller than what it should be.

`burnAmount` Not Subtracted From Balance Of Sender

- The `XOX` tokens are sent to the recipients when calling the `distribute` function by the owner. This could be a centralization risk as the owner can distribute `XOX` tokens without obtaining the consensus of the community.

Initial Token Distribution

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

Variables That Could Be Declared as `constant`

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Missing Emit Events

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 different compiler versions. 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

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.

Variables That Could Be Declared as Immutable

It is now well understood that the difficulty or timestamp is not a source of randomness. They can be manipulated if the attacker is also a miner. For EVM compatible blockchains such as Binance smart chain and Polygon, the `block.difficulty` and `block.gaslimit` can be the same value across multiple blocks, making the situation even worse. 

X Rush

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

19

0

7

0

12