HELLO Labs security record

There is a `return` before the `emit` so that the event will never be emitted.

The functions which are never called internally within the contract should have external visibility for gas optimization. ```solidity function tradingStatus(bool _status) public onlyOwner { function getCirculatingSupply() public view returns (uint256) { function rescueToken(address tokenAddress, uint256 tokens) function clearStuckBalance(uint256 amountPercentage, address adr) public onlyOwner { function setWhitelisted(address _wallet, bool status) public onlyOwner { ```

The function `totalSupply()` does not read or modify state and is declared as `view`.

The function `clearStuckBalance()` uses Solidity's built in `transfer()` function. There are potential issues with this as this forwards exactly 2300 gas and if the receiving contract has a `fallback` function or gas prices are changed, then the transaction may be reverted. See this [doc](https://ethereum.stackexchange.com/questions/19341/address-send-vs-address-transfer-best-practice-usage) for more details.

The functions `takeFee`, `shouldTakeFee`, and `checkTxLimit` are all declared as `internal`. The naming convention for `internal` functions is that they start with `_`.

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

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

Any user with the `authorized` role can set `_liquidityFee`, `_marketingFee`, `_developmentFee`, `_burnFee`, and `_feeDenominator`, but the upper limit is just that the total sum of fees is less than `feeDenominator`. In the extreme case this means the total fee can be as high as 99.9999...%.

Although `totalFee` is a public variable, the fees that go into it are not made public. Users may want to know exactly how much of the `totalFee` is used for liquidity, marketing, development, and burning as well as what the denominator for `totalFee` is.

The `approve` function could be used in a Front-Running attack that allows a spender to transfer more tokens than the owner of the tokens ever wanted to allow the spender to transfer. Here is a possible attack scenario: Alice allows Bob to transfer N of Alice's tokens (N>0) by calling approve method on Token smart contract passing Bob's address and N as method arguments After some time, Alice decides to change from N to M (M>0) the number of Alice's tokens Bob is allowed to transfer, so she calls approve method again, this time passing Bob's address and M as method arguments Bob notices Alice's second transaction before it was mined and quickly sends another transaction that calls ·transferFrom· method to transfer N Alice's tokens somewhere If Bob's transaction will be executed before Alice's transaction, then Bob will successfully transfer N Alice's tokens and will gain the ability to transfer another M tokens Before Alice noticed that something went wrong, Bob calls ·transferFrom· method again, this time to transfer M Alice's tokens. So, Alice's attempt to change Bob's allowance from N to M (N>0 and M>0) made it possible for Bob to transfer N+M of Alice's tokens, while Alice never wanted to allow so many of her tokens to be transferred by Bob. ERC20 API: An Attack Vector on [Approve/TransferFrom Methods](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit#heading=h.m9fhqynw2xvt)