DEBT Box security record

In the contract `GROW` 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 modify different token settings such as the UniSwap (PancakeSwap) router, dividends and fees.  Furthermore, the role `_owner` has authority over the functions `renounceOwnership()` and `transferOwnership()`. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and renounce and transfer ownership at any time.

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

In the contract `DigitalLinkedGold` the role `_owner` has authority over the functions: * `mint()` Any compromise to the `_owner` account may allow the hacker to take advantage of this authority

In the contract `Explore` 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 modify the configuration of the contract and mint tokens to himself.  In the contract `Aluminum` 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 modify the configuration of the contract and mint tokens to himself.  In the contract `BlackGold` 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 modify the configuration of the contract and mint tokens to himself.  In the contract `NaturalGas` 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 modify the configuration of the contract and mint tokens to himself. 

The contract owner can set the liquidity address to any address. The target address can be an EOA address or a smart contract. The implementation of the liquidity address is unknown, and whether the collected tokens will be used to provide liquidity is unknown.

The audited token contracts burn additional tokens from the sender's address during a token transfer. This behavior can potentially be exploited if the token's liquidity exists in Uniswap V2 (and its forks), and the liquidity pair address is not excluded from such a fee. The unique 'Skim()' and 'Sync()' functions in the Uniswap V2 pair contract enable such an attack. Please see the 'Scenario' section to understand how this issue can be exploited.

The contract uses the `pragma solidity 0.5.17` directive. This indicates that an outdated version of the compiler is used, which is prone to several disclosed bugs.

10% of the transfer fee will deduct from the sender's wallet, on top of the transfer amount. If user A approves user B 200 tokens and user B uses the "TransferFrom" function to transfer 100 A's tokens, A's balance will deduct by 110, and the "allowance" will only deduct by 100. The allowance reduction in the "TransferFrom" function doesn't put the "Fee" into consideration.

Mathematical operations in the aforementioned function perform divisions before multiplications. Performing multiplication before division can sometimes avoid loss of precision.

Line 646 only checks if the sender is excluded from the fee: ```sol=646 " if (!_isExcludedFromFee[sender]) {" ``` But line 661 checks if both the sender and recipient are excluded from the fee: ```sol=661 if (!_isExcludedFromFee[sender] && !_isExcludedFromFee[recipient]) { ``` The fee check logic is inconsistent across two "if" statements.