DRX Token security record

The contract `DRX` contains a conditional check that is intended to restrict trading when `tradingActive` is set to false. However, the current implementation has a flaw where wallets that are marked as `_isExcludedFromFees` can still initiate trades regardless of the `tradingActive` status. This creates a scenario where certain privileged wallets can trade while the feature is ostensibly disabled for the rest of the users.<br>

The function `clearStuckTokens()` allows the `deployerWallet` to withdraw any tokens in the contract and keep a `toKeep` amount in it. If the input variable `toKeep` is equal to zero the function will fail because it will try to send to the `deployerWallet` the total balance of the contract two times. ```solidity=722 uint256 tokensToClear = totalBalance - tokensToKeep; if (tokensToClear > 0) { tokenContract.transfer(deployerWallet, tokensToClear); } if (toKeep == 0) { tokenContract.transfer(deployerWallet, totalBalance); } ```

The comment at the pointed location the comment `"WAGMI20: burn from the zero address"` is obsolete since it uses a different project name.

The contract uses logical AND (`&&`) to connect multiple conditions within a single `require` statement, which is less gas-efficient than separate `require` statements for each condition. This practice results in higher gas consumption for transactions. For example, replacing one single `require` statement with two conditions connected by `&&` with two separate `require` statements can save 16 gas.

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

The function `withdrawToken()` and the function `clearStuckTokens()` both allow the owner or the deployer to withdraw any token held by the contract at any time. However, the `owner` and the `deployerWallet` are the same address when the contract is deployed making those two functions redundant.

Solidity version >=0.8.0 includes checked arithmetic operations and underflow/overflow by default, making SafeMath redundant.

The `require()` function validates conditions and throws an exception if the condition fails. It is advisable to include a descriptive error message, which will be returned to the caller, providing details about the failure.

State variables that never change should be declared as `constant` to save gas. ```solidity=529 uint256 public initialTotalSupply = 50000000000 * 1e18; ``` - `initialTotalSupply` should be declared `constant`. ```solidity=533 uint256 public swapTokensAtAmountPercent = 1; ``` - `swapTokensAtAmountPercent` should be declared `constant`. ```solidity=522 address private marketingWallet = payable(address(0xA733654C456066E1c0933E8C2d18945531daac44)); ``` - `marketingWallet` should be declared `constant`. ```solidity=532 uint256 public maxWalletPercent = 2; ``` - `maxWalletPercent` should be declared `constant`. ```solidity=531 uint256 public maxTransactionAmountPercent = 2; ``` - `maxTransactionAmountPercent` should be declared `constant`.

Literals with many digits are difficult to read and review. ```solidity=529 uint256 public initialTotalSupply = 50000000000 * 1e18; ```