ValiFi security record

`public` functions that are never called by the contract could be declared as `external`. `external` functions are more efficient than `public` functions.

The modifier `notAllowed(address _account)` requires that the `_account` must not be present in the mapping `notAllowedList` . This means that the account is an allowed one.

In `ValiFi.sol` within `_beforeTokenTransfer()` the following check ```solidity=188 require(amount <= maxSellAmount, "Lower sell amount."); ``` on function input is made at line 188 after calls to other functions like `_trackTrader()`. --- In `ValiFi.sol` within `_beforeTokenTransfer()` the following check ```solidity=200 require(amount <= maxBuyAmount, "Lower buy amount."); ``` on function input is made at line 200 after calls to other functions like `_trackTrader()`.

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

**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.

In `Seller.sol`, the `run()` function has no access controls and is callable by anyone. In addition, there is no functionality built into the contract to accrue tokens to `swapAndLiquify`. Meaning it should only be called after tokens are sent to the contract and the amount in the contract is greater than the `swapThreshold`.

Literals with many digits are difficult to read and review.

The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one. --- Furthermore the compiler version on all contracts are the same except for `IUniswapV2Pair.sol` and `MinimalForwarderUpgradeable.sol`

Inside `Seller.sol`, the name `thresholdPercent` can be confusing as the `thresholdDivisor` can be set to a number other than 100.

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.