Read the findings of the 2022 Web3 Security Report

In the contract `WinnerBlock` 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 and perform the following actions:

* Set an high `burnFee`, burning all the tokens of the users when trying to sell.
* Set a very low `maxTxAmount` making it impossible for normal users to transfer tokens.
* Ban a user via `blacklist` making it impossible to use tokens.

![](https://accelerator-tasks-prod.s3.amazonaws.com/b867f28b75fa436781c0a763bd568f37/diagrams/centralization_WinnerBlock__owner.svg)

In the contract `WinnerBlock` the role `admin` has authority over the functions shown in the diagram below.
Any compromise to the `admin` account may allow the hacker to take advantage of this authority and add to the blacklist all the users making it unable for them to transfer tokens or increasing the `SellCoolDownAmount` and `sellCoolDownTime` disabling the sell for normal users.
![](https://accelerator-tasks-prod.s3.amazonaws.com/b867f28b75fa436781c0a763bd568f37/diagrams/centralization_WinnerBlock_admin.svg)

Centralization Risks in WinnerBlock.sol

Addresses should be checked before assignment or external call to make sure they are not zero addresses.

Missing Zero Address Validation

After [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884) was included in the Istanbul hard fork, it is not recommended to use `.transfer()` or `.send()` for transferring ether as these functions have a hard-coded value for gas costs making them obsolete as they are forwarding a fixed amount of gas, specifically `2300`. This can cause issues in case the linked statements are meant to be able to transfer funds to other contracts instead of EOAs.

Usage of `transfer()` for sending Ether

`burnFee` value has no boundaries in `setBurnFee()`. Unexpected high value can be set.

`setBurnFee` Should Be Bounded

The AntiWale mechanism can be easily avoided by selling in several chunks, without activating the sell cooldown. Moreover, the funds could be transferred from a "blocked" account to another to sell.

AntiWale Sale Cooldown Can Be Easily Avoided

The local variable `_owner` is shadowing the state variable `_owner` defined in the `Ownable` contract.

Shadowing State Variable

The variable `maxTxAmount` is supposed to bound the transaction amount (i.e. AntiWhale). Instead, it checks only if a transaction is lower than the maximum allowed, which can be avoided by transferring the desired amount in different chunks (transactions).

`maxTxAmount` Can Be Easily Avoided

The ownership is assigned automatically by the `Ownable` constructor. Calling `transferOwnership()` in the constructor of the token contract is redundant.

`transferOwnership()` Call is Redundant

Considering that the contract is not intended to hold any BNB, there is no reason to have the `receive()` function. 

Contract is Not Intended to Hold BNB

```solidity=822
 if (listedAt + 5 minutes >= block.timestamp) {  

            //@dev AntiBot for sales & only permit marketingWallet to add liquidity during 5 minutes after public launch
            require(recipient != pancakeSwapV2Pair || sender == marketingWallet, "AntiBot: Forbidden transaction!");
        }
```
The check highlighted in the above snippet from the code shows that for the first five minutes after the listing only the `marketingWallet` can sell, while the rest of accounts can buy only. This allows the `marketingWallet` to dump the tokens.
This is not aligned with what is stated in the comment.

Misleading Check on `transfer()`

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

Variables That Could Be Declared as `constant`

The linked functions are equivalent to the compiler-generated getter functions for the respective variables.

User-Defined Getters

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

Missing Emit Events

The functions which are never called internally within the contract should have external visibility for gas optimization.

Function Should Be Declared External

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

The defined variable **decimals** is not used. Instead, its value is hard-coded in the calculation of the following variables:
```solidity=662
    uint256 internal _tokenTeam = 20 * 10**9 * 10**9;
    uint256 internal _tokenMarketing = 40 * 10**9 * 10**9;
    uint256 internal _tokenPreSale = 30 * 10**9 * 10**9;
    uint256 internal _tokenPrimo = 10 * 10**9 * 10**9;
```

The value **9** is used instead of **_decimals**.

Use of Magic Numbers Instead of Constant Variable 

The usage of `burnDecimal` is not clear. When used, a `2` is added to the value of it and the burn fee denominator is calculated. This makes the code hard to read and unclear.

`burnDecimal` is Ambiguous

The function `autoBurn()` is `private`, but the name doesn't start from `_`.

`autoBurn` Should Be Renamed

The big number `10000000` makes it not straightforward to count the number of zeroes. This decreases the readability of the code.

Big Numbers Could Be Written In a Clearer Way

The function `setTeamWallet()` changes the address of the `teamWallet`. Although, this address is only used in the constructor and never again. Making this function useless.

Also, the function `setPancakeSwapV2Router()` is used to change the value of the public variable `pancakeswapV2Router`, but it has no effect considering that the `pancakeswapV2Router` is used only in the constructor to create the pair.

Useless Functions `setTeamWallet()` and `setPancakeSwapV2Router()`

The declaration of `IPancakeSwapV2Pair` interface is redundant.

Redundant Declaration of `IPancakeSwapV2Pair`

```solidity=818
        if (amount >= maxTxAmount) {
            require(sender == owner() || sender == admin || sender == marketingWallet || sender == presaleWallet || sender == primoWallet, "Maximum of token transfer exceeded !"); 
        }
```
From the above snippet of code it is clear that the `teamWallet` is not excluded explicitly from the `maxTxAmount` constraint. Instead, is implicitly considered that `teamWallet == owner()`. If the `owner` will be changed, `teamWallet` will not be excluded anymore from this check.

Winner Block

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

22

0

22

0

0