SHAUN INU security record

In the contract `SHAUN` 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 include or exclude addresses from reward and fees. 

All **Shaun Inu** tokens are sent to the contract owner when deploying the contract. This is a potential centralization risk as the deployer can distribute **Shaun Inu** tokens without the consensus of the community.

Variable `_rOwned[account]` is not updated in the function `includeInReward()`, which will make the accounts included siphon off the tokens out of the balances of all token holders. The Rate was higher at the moment of the `excludeFromReward(account)` call, so the `_rOwned[account] / _tOwned[account]` ratio is bigger than expected for accounts included in the reward.

In the `_transfer()` function, external call is triggered (interaction) before state variables are updated (effect), thus violating the checks-effect-interaction pattern. While reentrancy is mitigated to a certain extent by the `lockTheSwap` modifier in `swapAndLiquify()`, and the `if` statements that check the value of the `swapping` variable, it is still recommended to always follow the checks-effect-interaction pattern to prevent potential reentrancy. ### External call(s) ```solidity=228 _transfer(sender, recipient, amount); ``` * This function call executes the following external call(s). * In `Address.sendValue`, * `(success) = recipient.call{value: amount}("")` * In `SHAUN.swapTokensForBNB`, * `router.swapExactTokensForETHSupportingFeeOnTransferTokens(tokenAmount,0,path,address(this),block.timestamp)` * In `SHAUN.swapAndLiquify`, * `address(marketingWallet).sendValue(deltaBalance)` ### State variables written after the call(s) ```solidity=232 _approve(sender, _msgSender(), currentAllowance - amount); ``` * This function call executes the following assignment(s). * In `SHAUN._approve`, * `_allowances[owner][spender] = amount` --- ### External call(s) ```solidity=448 swapAndLiquify(); ``` * This function call executes the following external call(s). * In `Address.sendValue`, * `(success) = recipient.call{value: amount}("")` * In `SHAUN.swapAndLiquify`, * `address(marketingWallet).sendValue(deltaBalance)` * In `SHAUN.swapTokensForBNB`, * `router.swapExactTokensForETHSupportingFeeOnTransferTokens(tokenAmount,0,path,address(this),block.timestamp)` ### State variables written after the call(s) ```solidity=453 _tokenTransfer(from, to, amount, takeFee); ``` * This function call executes the following assignment(s). * In `SHAUN._takeMarketing`, * `totFeesPaid.marketing += tMarketing` * In `SHAUN._reflectRfi`, * `totFeesPaid.rfi += tRfi`

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

State variables that never change should be declared as `constant` to save gas. ```solidity=132 uint256 private _tTotal = 100 *10**15 * 10**_decimals; ``` - `_tTotal` should be declared `constant`. --- ```solidity=135 uint256 public swapTokensAtAmount = 1e14 * 10**_decimals; ``` - `swapTokensAtAmount` should be declared `constant`. --- ```solidity=137 address public deadWallet = 0x000000000000000000000000000000000000dEaD; ``` - `deadWallet` should be declared `constant`. --- ```solidity=138 address public marketingWallet = 0x3f65726D4E7C53D30A0dA9b69A0D13A910bbA237; ``` - `marketingWallet` should be declared `constant`.

The contract is serving as the underlying entity to interact with one or more third party protocols, including `router`, `pair`, and `factory`, etc.. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc.

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.