Baby Neiro

When `transferDelayEnabled` is true, the following check is made: ```solidity if(from == address(lpPair)){ require(tx.origin == to, "no buying to external wallets yet"); } ``` However, the purpose of this check is unclear. The check will ensure that only external owned account receives the tokens as `tx.origin` will be an EOA. However, the error message states that buying to external wallets should not be allowed, which seems to be contradictory.

If `swapTokensAtAmt` is set too high, then Sandwich Attacks may be incentivized, and the frequency at which the token swap and liquify mechanic is triggered may be too low to be effective. The `swapTokensAtAmt` value should set low enough so that tokens are swapped at a lower value within the contract, making incentive to perform a sandwich attack lower. The `swapTokensAtAmt` value should be configured based upon the total supply of the token, transaction and wallet limit, the intended distribution of tokens in the ecosystem and the price of the token within the pair.

During the swap and liquify mechanic, the LP tokens created from adding liquidity are sent to the `DEAD` address. This effectively locks away the LP tokens and makes them unreachable. While this can be an effective mitigation tactic for preventing a removal of liquidity during a private key leak, users should be aware that locking LP tokens means that not all native tokens will be able to be recovered from the pair.

In peer to peer transfers, only the following check is performed in `checkLimits()`: ```solidity require(amount + balanceOfTo <= _txLimits.walletLimit, "Max Wallet"); ``` This check ensures that the amount transferred into the destination address will not cause the balance of the destination address to exceed the `walletLimit`. However, while the `walletLimit` may not be exceeded, there is no guarantee that the `transactionLimit` is not exceeded in this case.