Red Light District Metaverse security record

The function `swapAndLiquify()` is used to distribute the fees to various wallets as well as to add liquidity. However, this function is `private` and never used in the contract. Thus it will never be called and cause the fees to not be distributed as designed.

The `_swapAndLiquify()` function converts half of the contracts `RLDM` token balance to `BNB`. The other half of `RLDM` tokens and part of the converted BNB are deposited into the RLDM-BNB pool on pancakeswap as liquidity. For every `swapAndLiquify()` function call, a small amount of BNB is leftover in the contract. This is because the price of `RLDM` drops after swapping the first half of `RLDM` tokens into `BNB`, and the other half of `RLDM` tokens require less than the converted BNB to be paired with it when adding liquidity. The contract doesn't appear to provide a way to withdraw those BNB, and they will be locked in the contract forever.

`_swapAndLiquify()` is called whenever there is a buy, `swapAndLiquifyEnabled = true`, and `inSwapAndLiquify != true`. This can cause an increase in sell pressure as it dramatically increases the number of sells. In addition, it may call `_swapAndLiquify()` when there is very little or no liquidity to be added.

The variables `_totalTaxIfBuying`, `_totalTaxIfSelling`, and `_totalDistributionShares` are assigned both when the variables are defined and in the constructor.

The time-lock of 48 hours is started with an event stating that there was an ownership transfer request which gives the address of the newOwner and the `block.timestamp` when the ownership can be transferred. However, after the 48 hours a different `newOwner` could be given as an input when `transferOwnership()` is called so that the time-lock was initiated for one owner, but then ownership is assigned to another.

Performing integer division before multiplication truncates the low bits, losing the precision of calculation. This is done when calculating all of the total amounts for the initial distribution of tokens.

Buys and sells are taxed, with the tax being broken into liquidity, marketing, and team fees. The percentages stored in these variables is not proportional to the amount of the total fees that gets distributed however. The liquidity, marketing, and team shares instead are used to calculate how the total fees are distributed when `swapAndLiquify()` is called. For example, upon construction liquidity fees account for 2/5 of the total fees. However, the liquidity share is only 1/6 of the total distribution of shares and as a result only approximately 1/6 of the total fees is used for liquidity.

The `public` functions: - `airdrop()` - `setMarketPairStatus()` - `setIsExcludedFromFee()` - `setSwapAndLiquifyEnabled()` - `setSwapAndLiquifyByLimitOnly()` - `changeRouterVersion()` are never called by the contract can be declared `external`. External functions can be more efficient than `public` functions.

There should always be events emitted in the sensitive functions that are controlled by centralization roles. The following functions are controlled by `_owner`: - `airdrop()` - `setMarketPairStatus()` - `setIsExcludedFromFee()` - `setBuyTaxes()` - `setSellTaxes()` - `setDistributionSettings()` - `setMarketingWalletAddress()` - `setTeamWalletAddress()` - `setSwapAndLiquifyByLimitOnly()` - `changeRouterVersion()`

The function `transferToAddressETH()` uses the built in `transfer()` function. There are potential issues with this as this forwards exactly 2300 gas and if the receiving contract has a `fallback` function or gas prices are changed, then the transaction may be reverted. See this [doc](https://ethereum.stackexchange.com/questions/19341/address-send-vs-address-transfer-best-practice-usage) for more details.