Retik Finance

The Anti-Bot mechanism is unable to protect against the initial entry of bots. In lines 292 to 296 of the code, it identifies and flags the "from" and "to" addresses as Bots. Due to the order of operations, where the check for whether an address is a bot occurs prior to this section, it can result in a situation where even if the "from" or "to" address is flagged as a bot during the current transaction, the transaction can still proceed normally. ```solidity=283 require(!isBot[from], "RETIK: Bot detected"); if (from != owner() && to != owner()) { // trading disable till launch require(trading, "RETIK: trading is disable"); // antibot if ( block.timestamp < launchedAt + snipingTime ) { if (dexPair == from) { isBot[to] = true; } else if (dexPair == to) { isBot[from] = true; } } } ``` The question we want to discuss is whether we need to penalize bots or block transactions the first time they enter.

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

The change of `owner` by function `transferOwnership()` overrides the previously set `owner` with the new one without guaranteeing the new `owner` has the ability to actuate transactions on-chain.

Solidity version >=0.8.0 includes checked arithmetic operations and underflow/overflow by default, making SafeMath redundant.

The event `SwapAndLiquify` is declared but the current code logic does not use this information.

The values of `_name`,`_symbol`,`_decimals`,`_totalSupply` and `snipingTime` are never changed after assignment, so they can be declared as `constant`. A big advantage of constant variables is that reading them is significantly cheaper than reading from regular state variables.