Babydoge2.0 security record

In the function `changeLpPair` at the pointed locations, the `newPair` indicated will be added as `lpPair` in the mapping `isLpPair`. Although, there is no way to remove invalid liquidity pool pairs from that mapping in the current codebase.

If the `totalSupply` is zero, the `decimals()` function will revert. Making it impossible for the users to check the decimals of the token.

It is expected that the `totalSupply` function always succeeds, assuming that its execution does not run out of gas. However, the implementation of `totalSupply` in contract Babydoge2 sometimes reverts.

Addresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens. in ETH: ```solidity=290 isLpPair[newPair] = true; ``` - `newPair` is not zero-checked before being used. --- ```solidity=328 marketingAddress = payable(marketing); ``` - `marketing` is not zero-checked before being used. --- ```solidity=329 marketing2Address = payable(marketing2); ``` - `marketing2` is not zero-checked before being used. --- ```solidity=329 setPresaleAddress(address presale, bool yesno) ``` - `presale` is not zero-checked before being used. --- In BSC: ```solidity=285 isLpPair[newPair] = true; ``` - `newPair` is not zero-checked before being used. --- ```solidity=322 marketingAddress = payable(marketing2); ``` - `marketing` is not zero-checked before being used. --- ```solidity=367 setPresaleAddress(address presale, bool yesno) ``` - `presale` is not zero-checked before being used. ---

The contract contains a hardcoded gas limit of 35000 for calls to `marketingAddress` and `marketing2Address` within the `internalSwap` function. The Ethereum network requires gas for executing operations, and different operations require different amounts of gas. Hardcoding the gas limit could lead to potential risks in terms of compatibility and functionality during future Ethereum chain upgrades. If the gas requirements for operations change in future Ethereum versions and the hardcoded gas limit is insufficient, these calls will fail. This may disrupt the token's normal functionality, potentially halting the swaps or transfers.

Contract `Babydoge2` is vulnerable to [a known ERC20 race condition issue](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729), which could lead to token theft. When a user calls `approve()` for a second time on a spender that has already been allowed, the spender could call `transferFrom()` to transfer the previous value and still receive the authorization to transfer the new value.

The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=182 IRouter02 public swapRouter; ``` - The contract `Babydoge2` interacts with third party contract with `IRouter02` interface via `swapRouter`.

The `success` variable of the `.call` functions in `internalSwap` is not checked. ```solidity=371 if(twoThird > 0) {(success,) = marketingAddress.call{value: twoThird, gas: 35000}("");} if(address(this).balance > 0) {(success,) = marketing2Address.call{value: address(this).balance, gas: 35000}("");} ``` ```solidity=363 if(address(this).balance > 0) {(success,) = marketingAddress.call{value: address(this).balance, gas: 35000}("");} ``` In this way, there is no guarantee that the `call` succeded.

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.