Red Light District Metaverse Token - Audit

In the contract `Token` 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 transfer or renounce ownership, change the buy or sell tax, set who is excluded from fees, change what market pairs are taxed, change when `swapAndLiquify()` is enabled, change the minimum number of tokens needed to call `swapAndLiquify`, change the router address, and withdraw BNB from the contract. It is possible for the hacker to set the new router address to be a malicious smart contract that can collect the `RLDM` tokens that would have been added to the liquidity when `_swapAndLiquify()` is called to then sell for a profit. 

The `addLiquidity` function calls the `addLiquidityETH()` function with the `to` address specified as `owner()` for acquiring the generated LP tokens from the `RLDM-WBNB` pool. As a result, over time the `_owner` address will accumulate a significant portion of LP tokens. If the `_owner` is an EOA (Externally Owned Account), mishandling of its private key can have devastating consequences to the project as a whole.

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

The contract is serving as the underlying entity to interact with third party Automated Market Maker protocols. The scope of the audit treats 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.