Decentralized United security record

In the contract `DecentralizedUnited` the role `_owner` has authority over the functions shown in the diagram below. The `_owner` can also call the centralized functions described in `DUC-04`.  In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below.  In the contract `Ownable` the role `_previousOwner` has authority over the functions shown in the diagram below.  Any compromise to the privileged accounts may allow the hacker to take advantage of this authority and users' assets may suffer loss.

To the best of our understanding, the reward of a specific account should stop accumulating while in the range of being excluded from reward after calling `excludeFromReward()`. In L599, the current `_tOwned` balance of the `account` is recorded and any reward starting from this point should not be accumulated after calling the function `excludeFromReward()`. However, when calling the function `includeInReward()` to include the excluded `account` for reward, `_rOwned` should be calculated with current `_tOwned` value. Details of this finding can be seen in this article from Pera Finance: [Link]https://perafinance.medium.com/safemoon-is-it-safe-though-a-detailed-explanation-of-frictionless-yield-bug-338710649846

One or more internal functions are not used. ```solidity=1030 function swapETHForTokens(uint256 amount) private ```

In the function `_transfer()`, the `maxTransactionAmount/maxWallet` checks and call to the `swapAndLiquify()` function will be skipped when either of the `from` or `to` address is set `_isExcludedFromFee`.

The approval function of the ERC20 standard possesses a well-known vulnerability whereby two consecutive approvals can be exploited to instead “reset” the approval by consuming the approval that is meant to be replaced with a new one.

The functions which are never called internally within the contract should have external visibility for gas optimization. ```solidity=119 function renounceOwnership() public virtual onlyOwner { ``` --- ```solidity=130 function getUnlockTime() public view returns (uint256) { ``` --- ```solidity=134 function getTime() public view returns (uint256) { ``` --- ```solidity=138 function lock(uint256 time) public virtual onlyOwner { ``` --- ```solidity=145 function unlock() public virtual { ``` --- ```solidity=517 function name() public pure returns (string memory) { ``` --- ```solidity=521 function symbol() public pure returns (string memory) { ``` --- ```solidity=525 function decimals() public pure returns (uint8) { ``` --- ```solidity=538 function transfer(address recipient, uint256 amount) public override returns (bool) { ``` --- ```solidity=543 function allowance(address owner, address spender) public view override returns (uint256) { ``` --- ```solidity=547 function approve(address spender, uint256 amount) public override returns (bool) { ``` --- ```solidity=552 function transferFrom(address sender, address recipient, uint256 amount) public override returns (bool) { ``` --- ```solidity=558 function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) { ``` --- ```solidity=563 function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) { ``` --- ```solidity=568 function isExcludedFromReward(address account) public view returns (bool) { ``` --- ```solidity=573 function minimumTokensBeforeSwapAmount() public view returns (uint256) { ``` --- ```solidity=649 function excludeFromMaxTransaction(address updAds, bool isEx) public onlyOwner { ```

The first linked error message in `require(_isExcluded[account], "Account is already excluded")` does not describe the error correctly. Also, the second and third linked error messages in `require(newNum >= (totalSupply() * 1 / 100)/1e9, "Cannot set maxTransactionAmount lower than 0.5%")` does not describe the error correctly. The require condition is 1% but the error message is 0.5%. The third error message is `maxTransactionAmount` while the function is changing `maxWallet`.

In the function `_transfer()`, when `inSwapAndLiquify` is set to true in the function `swapAndLiquify()`, other transfer transaction will not check the `maxTransactionAmount` maximum transfer limitations. Also `maxWallet` check for the `to` address will be skipped. Thus, malicious users can skip these limitations when observing the `swapTokens()` transaction. ```solidity=675 if (limitsInEffect && !(_isExcludedFromFee[from] || _isExcludedFromFee[to]) && !inSwapAndLiquify){ ```

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 is attacked) a transaction to purchase one of the assets and make profits by back running (after the transaction is 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: - `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens()` - `uniswapV2Router.addLiquidityETH()` - `uniswapV2Router.swapExactETHForTokensSupportingFeeOnTransferTokens()`

The owner is exempt from fees by default. Yet when ownership is reset through `renounceOwnership()` or `transferOwnership()`, the exemptions are not granted to the new owner nor are they revoked from the previous owner.