In the contract `Kodi` 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 claim the `BUSD` stored in the contract by calling the function `claimBNBOverflow()`.

![](https://accelerator-tasks-prod.s3.amazonaws.com/81d102b70a27411ebd00e7198cdde15a/diagrams/centralization-Kodi-_owner.svg)

In the contract `Ownable` 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 leave the contract without an owner by calling the function `renounceOwnership()`. This would cause a huge issue since many functions in the contract require an external call from a user. A compromised owner can call the function `setCustomSellTaxPeriod()` and `setCustomBuyTaxPeriod()` to maximize all fees and have them directed to the `marketingWallet`. This attack would allow the owner to steal nearly 100% of every single transaction. 

![](https://accelerator-tasks-prod.s3.amazonaws.com/81d102b70a27411ebd00e7198cdde15a/diagrams/centralization-Ownable-_owner.svg)

Centralization Risk in Kodi-V2.sol

All of the [Kodi] tokens are sent to the contract deployer when deploying the contract. This could be a centralization risk as the deployer can distribute [fixme] tokens without obtaining the consensus of the community.

Initial Token Distribution

```solidity=706
uint256 public gasForProcessing = 300000;
```

```solidity=1230
try dividendTracker.process(gas) returns (uint256 iterations, uint256 claims, uint256 lastProcessedIndex) {
  	emit ProcessedDividendTracker(iterations, claims, lastProcessedIndex, true, gas, tx.origin);

catch{}
}
```

At the last step of function `_transfer()` will call `dividendTracker.process()` with constant gas limitation `300000`. But there may be not enough gas till this step. EVM may revert this call and return the out-of-gas exception.

Potential Out-of-Gas Exception

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. 
If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects. 

The function `_withdrawDividendOfUser()` makes an low level call via the following line
```solidity 
(bool success,) = user.call{value: _withdrawableDividend, gas: 3000}("");
```
which introduces a re-entrancy. This re-entrancy risk is not critical since the gas is limited to `3000` and the check-effects pattern is obeyed via the following line 

```solidity
withdrawnDividends[user] = withdrawnDividends[user].add(_withdrawableDividend);
```

Potential Reentrancy Attack

A state variable is shadowing another component defined in a parent contract.
For example the variable `_symbol` in `Kodi` shadows the variable `_symbol` in `ERC20`.

This variable below
```solidity
	string private constant _symbol = "KODI";
```

shadows this variable in the ERC20 contract.
```solidity
	string private _symbol;
```



Shadowing State Variable

In the Kodi contract a low-level call is used to sent ether to different addresses. This is not a secure way to transfer ether because it leaves re-entrancy attacks as a possibility.

Low-Level Call

The first line in the body of the `_transfer()` function is 
```solidity
require(false)
```
The statement above will automatically revert any transaction that calls the this `_transfer()` function. The confusion is that body of the function still contains logic after the `require` statement. Therefore the code will never be executed. It is not entirely clear what the teams intentions are. 

Inconsistency in a Function Definition 

A sandwich attack might happen when an attacker observes a transaction swapping tokens or adding liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (before the transaction being attacked) a transaction to purchase one of the assets and make profits by backrunning (after the transaction being attacked) a transaction to sell the asset.

The following functions are called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large:

- `addLiquidity()`
- `_swapTokensForBNB()`

Potential Sandwich Attacks

The `Kodi` contract contains a `_transfer()` function that does not seem to be called. This is a major issue since `_transfer()` checks when the contract should `swapAndLiquify` or `addLiquidity`.

Unused `internal` Function

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

Third Party Dependencies

Literals with many digits are difficult to read and review.

Too Many Digits

Solidity frequently releases new compiler versions. Using an old version prevents access to new Solidity security features. Also, recent versions may be too early to be trusted.

```solidity
solc-0.8.11 is not recommended for deployment
```




Solidity Version Not Recommended

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

Missing Emit Events

The following functions are declared as `public` and are not invoked in any of the contracts contained within the project's scope. The functions that are never called internally within the contract should have external visibility. 

Function Visibility Optimization

The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

Missing Error Messages

The function `cancelLaunch()` does not deactivate trading.

KODI

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Audit History