DCOREUM security record

Modifier `lockTheSwap` doesn't have a `require` statement to restrict the `_transfer()` from reentrancy when `inSwapAndLiquify` variable is `true`. ```solidity=36 modifier lockTheSwap { inSwapAndLiquify = true; _; inSwapAndLiquify = false; } ```

One or more parameters with `memory` data location are never modified in their functions and those functions are never called internally within the contract. Thus, their data location can be changed to `calldata` to avoid the gas consumption copying from calldata to memory. ```solidity=17 function bulkTransfer(address[] memory _users, uint256[] memory _value) public returns (bool success) { ``` `bulkTransfer` has memory location parameters: `_users`, `_value`.

Input parameters `_users` and `_value` are not validated. They may have zero length or have different lengths from each other. Elements of `_values` may be zeros as well.

Addresses should be checked before assignment or external call to make sure they are not zero addresses. ```solidity=54 lpAddress = _address; ``` - `_address` is not zero-checked before being used. --- ```solidity=19 owner = newOwner; ``` - `newOwner` is not zero-checked before being used.

According to the project design, there is a `lpAddress` that uses to track the address of the LP pool and when transferring tokens to the LP pool, a "marketing fee" will be charged. However, in the current implementation, the `lpAddress` variable can only hold one LP address. Therefore, if there is a multiple LP address pool on chain, at most one LP address is able to charge for marketing fees. The concern is, when multiple lp pools exist, users may choose the pool that does not charge fees and thus may cause the project loses some fees.

The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to different compiler versions. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

A state variable is shadowing another variable defined in a parent contract. The mapping `_balances` in `DCO.sol` shadows the mapping `_balances` in `ERC20`. ```solidity=17 mapping(address => uint256) _balances; ``` ```solidity=36 mapping(address => uint256) private _balances; ``` The mapping `_balances` in `DCO.sol` is also not used anywhere in the contract.

There are certain 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. An advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they are not located in storage. The following variables are defined in the constructor and are never re-defined elsewhere: * `superAdminAddress` * `splitAddresses` * `marketingFee`