OSCAR security record

In the contract `OSCAR`, the role `devWallet` has authority over the functions shown in the diagram below. Any compromise to the `devWallet` account may allow the hacker to take advantage of this authority and withdraw the contract's ETH balance to the dev wallet owner, withdraw collected `OSCAR` tokens to the dev wallet, and perform token swaps for a specified percentage to swap collected `OSCAR` tokens to WETH and send to the `marketingWallet`. 

All of the `OSCAR` tokens are sent to the contract deployer. This is a centralization risk because the deployer can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

The transaction may be charged fees, so the max holding of the receiver should be the sum of the held tokens and the amount received from the transfer. The fees should not be included in the max holding.

The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

State variables that never change should be declared as `constant` to save gas. ```solidity=513 uint256 public initialTotalSupply = 1000000000 * 10**_decimals; ``` - `initialTotalSupply` should be declared `constant`.

In the `addLPToUniswap()` function, the contract owner adds liquidity to the DEX pair and sends the received LP tokens to the wallet address `0xf75ABFB159a5a960F854be03575Df74277cB72e8`. The contract grants unlimited approval of LP tokens to the DEX router, which is unnecessary because the token contract itself does not retain any LP tokens.

Some state variables are not used in the codebase. This can lead to incomplete functionality or potential vulnerabilities if these variables are expected to be utilized. Variable `deadAddress` in `OSCAR` is never used in `OSCAR`. ```solidity=510 address private constant deadAddress = address(0xdead); ```

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.