VSG

The smart contract contains one or more state changes related to arithmetic operations that do not emit events to communicate the changes outside the blockchain, which can lead to difficulties in tracking or verifying these changes and may affect the contract's transparency and auditability. ```solidity=446 devSplit = _devSplit; ``` ```solidity=447 marketingSplit = _marketingSplit; ``` ```solidity=448 lpSplit = _lpSplit; ``` ```solidity=441 sellTax = _newSellTax; ``` ```solidity=507 swapAtAmount = _newSwapAtAmount; ``` ```solidity=436 buyTax = _newBuyTax; ```

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. ```solidity=418 teamWallet = payable(_teamWallet); ``` - `_teamWallet` is not zero-checked before being used. ```solidity=417 marketingWallet = payable(_MarketingWallet); ``` - `_MarketingWallet` is not zero-checked before being used. ```solidity=456 marketingWallet = newMarketingWallet; ``` - `newMarketingWallet` is not zero-checked before being used. ```solidity=466 teamWallet = newTeamWallet; ``` - `newTeamWallet` is not zero-checked before being used.

The current contract doesn't follow the naming convention specified by [Solidity DOC](https://docs.soliditylang.org/en/v0.8.20/style-guide.html#underscore-prefix-for-non-external-functions-and-variables), including the following: - The function name starts with `_`. However, the function is publicly/externally visible. This violates the naming convention, or even exposes the internal function to the public.

A sandwich attack can occur when an attacker notices a transaction involving token swaps or liquidity additions that lacks slippage restrictions or minimum output amount settings. The attacker can exploit this by frontrunning the transaction to purchase one of the assets, thereby manipulating the exchange rate, and then backrunning the transaction to sell the asset for a profit. The referenced functions are invoked without setting slippage restrictions or minimum output amounts, making transactions that trigger these functions particularly vulnerable to sandwich attacks, especially when large input amounts are involved.

State variables that never change should be declared as `constant` to save gas. ```solidity=398 address dead = 0x000000000000000000000000000000000000dEaD; ``` - `dead` should be declared `constant`.

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=386 IRouter public Router; ``` - The contract `vectorsmartgas` interacts with third party contract with `IRouter` interface via `Router`.

The return values of the `transfer()` and `transferFrom()` calls in the smart contract are not checked. Some ERC-20 tokens' transfer functions return no values, while others return a bool value, they should be handled with care. If a function returns `false` instead of reverting upon failure, an unchecked failed transfer could be mistakenly considered successful in the contract. ```solidity=595 ERC20(_tokenAddress).transfer(msg.sender, ERC20(_tokenAddress).balanceOf(address(this))); ```

The smart contract does not check or store the return value of an external call in a local or state variable, which may introduce vulnerabilities due to the unhandled outcome. ```solidity=579 try Router.addLiquidityETH{value: ethAmount}( address(this), tokenAmount, 0, // slippage is unavoidable 0, // slippage is unavoidable dead, block.timestamp ) {} catch {revert("Failed to add liquidity");} ```

It is not recommended to use Solidity's `transfer()` and `send()` functions for transferring native tokens, since some contracts may not be able to receive the funds. Those functions forward only a fixed amount of gas (2300 specifically) and the receiving contracts may run out of gas before finishing the transfer. Also, EVM instructions' gas costs may increase in the future. Thus, some contracts that can receive now may stop working in the future due to the gas limitation. ```solidity=567 payable(marketingWallet).transfer(marketingAmount); ``` - `vectorsmartgas.SwapFees` uses `transfer()`.