The Debt Box (BGLD, NATG, ALUM, XPLR)

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.

The linked code is to transfer the "liquidityFee" to the "liquidity" address, but the value used in the `Transfer` event is "miningFee" instead of the "liquidityFee". ```sol=537 _balances[sender] = _balances[sender] - liquidityFee; _balances[liquidity] = _balances[liquidity] + liquidityFee; emit Transfer(sender, liquidity, miningFee); ```

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

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