W3binfinity security record

In the contract `WBYToken` the role `owner` has authority over the functions shown in the diagram below. - `setFee()`: Set fees for each transfer. - `setExcludeFee()`: Exclude an address from the fees. - `setMarketingAddress()`: Set the `marketAddress` to receive the fees from transfer. - `multiBlacklist()`: Add multiple addresses to the blacklist of the WBY contract. - `multiRemoveFromBlacklist()`: Remove multiple addresses to the blacklist of the WBY contract. - `wiToken()`: Withdraw all tokens from the contract. - `wiBNB()`: Withdraw all the BNB of the contract `WBYToken`. - `wiAmountBNB()`: Withdraw a certain amount of BNB from the `WBYToken` contract. - `wiAmountToken()` Withdraw any tokens from the contract. - `renounceOwnership()`: Set the owner to the address null. - `transferOwnership()`: Transfer the owner to another address. Any compromise to the `owner` account may allow a hacker to take advantage of this authority and these functions. The attacker will be capable of modifying the **fees functions** or withdrawing all the tokens inside the `WBYToken` contract.

Upon contract deployment, all of the tokens are sent to the contract deployer when deploying the contract. This could be a **centralization risk** as the deployer can distribute the tokens without obtaining the consensus of the community. ```solidity=1257 ERC20._mint(_msgSender(), maxSupply); ```

The `fee` is set to 100% by default. This could lead to unexpected behavior. ```solidity=1247 uint256 fee = 100; ``` In this case, the action will disable the `transfer` function and thus **freeze** the contract until the `owner` decreases the value of the `fee`. Otherwise, there is no explicit restriction on the upper limit of the fee. Therefore, mistakenly setting the fee to 100 might lead to a Denial-of-Service situation. The auditors would like to know if this is the intended schema of the fee mechanism.