Read the findings of the 2022 Web3 Security Report

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.
![](https://accelerator-tasks-prod.s3.amazonaws.com/73ffca46ee5f49e7a4c58e58c249dc37/diagrams/centralization_Ownable__owner.svg)

In the contract `P202` 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/73ffca46ee5f49e7a4c58e58c249dc37/diagrams/centralization_P202__owner.svg)

In the contract `P202Presale`, the role `_owner` has authority over the following functions:
- `withdraw()`
- `setPrice()`

As of May-18-2022, the `_owner` of `P202` is an EOA address [0x81cad1d25daedc4250aa06ff831978aae03984e2](https://bscscan.com/address/0x81cad1d25daedc4250aa06ff831978aae03984e2).

Centralization Related Risks

**500,000,000** * 10e18 `P202` tokens are sent to the contract deployer when deploying the contract. This could be a centralization risk as the deployer can distribute `P202` tokens without obtaining the consensus of the community.

According to the [tx](https://bscscan.com/tx/0x9811b3edf7518444953e804d8feb999a3e69235342251f39bcec826674bd8ea9), all the `P202` tokens were transferred to the [deployer address](https://bscscan.com/address/0xfb46c2a8c5deb7b5a8f0e8ef7be5c6c860280706) during the contract deployment.
After that, the deployer transferred **25,000,000 * 10e18** tokens to the address [0xd3c1ed1e263bb16951b054d670ff9eaf6b8391df](https://bscscan.com/address/0xd3c1ed1e263bb16951b054d670ff9eaf6b8391df) in [tx](https://bscscan.com/tx/0x32ba9a28c68d7f27cbb5f182583556f8b67f0915b717a3f889bd488877a656f5) and **475,000,000 * 10e18** tokens to the address [0x81cad1d25daedc4250aa06ff831978aae03984e2](https://bscscan.com/address/0x81cad1d25daedc4250aa06ff831978aae03984e2) in [tx](https://bscscan.com/tx/0x0c76e0996b3a0f877796f01d470ad3ea7e29be16b2a93ddae18d43bc8b9d1268).

As of May-18 2022, the balance of the address [0x81cad1d25daedc4250aa06ff831978aae03984e2](https://bscscan.com/address/0x81cad1d25daedc4250aa06ff831978aae03984e2) is **398,911,002 * 10e18** and the balance of the address [0xd3c1ed1e263bb16951b054d670ff9eaf6b8391df](https://bscscan.com/address/0xd3c1ed1e263bb16951b054d670ff9eaf6b8391df) is **24,782,266 * 10e18**.

Initial Token Distribution

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

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

Proper Usage of `public` and `external` type

The contract `P202` implements the` airdrop` function to distribute tokens with lock records.
There are three mappings holding the `lock` logic:
- `isLocked`: the recipient will be set to true once the recipient gets an airdrop.
- `locked`: the amount of token that the user locked.
- `lockedAt`: the time that the tokenlock starts for the user.

The concern is, that the current `airdrop` allows users get airdropped multiple times due to the else branch is not handled:
```solidity=39
            if (!isLocked[recipients[i]]) {
                isLocked[recipients[i]] = true;
                lockedAt[recipients[i]] = block.timestamp;
            }
            locked[recipients[i]] += values[i];
            transfer(recipients[i], values[i]);
```
In addition, when the user gets multiple airdrops, the `lockedAt` timestamp is not updated and the user can use the unupdated `lockedAt` record to get a shorter token locking period.



Disscussion about `isLocked`

There should always be events emitted in the sensitive functions that are controlled by centralization roles.
- `P202Presale.withdraw()`
- `P202Presale.setPrice()`
- `P202Presale.buy()`

Missing Emit Events

In function `_buy`, the `tokenAmount` is calculated with `(ethValue * 1 ether) / price`, which means it assumes the decimal of the token is 18 (same with ether).
The concern is, in single contract scope, we cannot make assumptions about a given input, such as `token`.
If the decimal value of the token is greater or less than 18, it will result in an unexpected `tokenAmount`.

Lack Of Check The Token's Decimal

The contract "P202Presale" will provide the ability to buy sales tokens at a price determined by the owner.
Based on the logic in the presale contract, the owner needs to deposit the token to the presale contract first, and after the sale, the owner will withdraw the ether from the contract.
The concern is that there is no ability to withdraw the remaining tokens if the sale cannot be completed.

Discussion on Token Flow in `P202Presale`

P202

P202

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

7

0

1