Sell Token security record

Flash loans are a way to borrow large amounts of money for a certain fee. The requirement is that the loans need to be returned within the same transaction in a block. If not, the transaction will be reverted. An attacker can use the borrowed money as the initial funds for an exploit to enlarge the profit and/or manipulate the token price in the decentralized exchanges. The below functions rely on price calculations that are based on-chain, meaning they are susceptible to flash-loan attacks by manipulating the price of given pairs to the attacker's benefit. - Minerals.getTokenPrice() - SellToken.getTokenPrice() - SellToken.getToken2Price() - SellToken.getToken3Price()

One or more declarations do not conform to the [Solidity style guide](https://solidity.readthedocs.io/en/v0.7.3/style-guide.html#naming-conventions) with regards to its naming convention. Particularly: - `camelCase`: Should be applied to function names, argument names, local and state variable names, modifiers - `UPPER_CASE`: Should be applied to `constant` variables - `CapWords`: Should be applied to contract names, struct names, event names and enums The below-listed functions/variables/parameters use extremely poor naming conventions: - The function `getpair()` performs the change of pair, which should be named as setPair. - The function `setToken()` sends tokens to the owner, which should be named as getToken. - The function `getToke()` returns the counterpart token names in the pair, which should be named as getTokenName. - The parameter _tolens, represents the address of the token/coin.

Addresses should be checked before assignment or external call to make sure they are not zero addresses. ```solidity=256 ceo=_ceo; ``` - `_ceo` is not zero-checked before being used. --- ```solidity=257 admin=_admin; ``` - `_admin` is not zero-checked before being used. --- ```solidity=447 _TRDT=_trdt; ``` - `_trdt` is not zero-checked before being used.

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.