Fintoken Coin

# Minimum Balance Checks In #L90, if either the sender or recipient are exempt from the fees, there is no check to ensure that the sender's balance after the transfer is not below the minimum balance. If this is the intended behavior and privileged users are not constrained by the minimum balance, then the check in #L73 would prevent the sender from transferring more tokens until they have a sufficient balance. # Locked Tokens In #L84, the calculation of `transferTokenAmount` can lead to tokens being locked out of the transfer. For example, given the following values in a simplified example: Parameter | Value ----------|------- `MIN_BALANCE` | 100 `balanceOf(sender)` | 250 `amount` | 200 Using the fee distributions of `_transfer()`, 6 tokens will be sent as fees, leaving 194 tokens as the `transferTokenAmount`. After #L84, a new total of 100 tokens is sent, bringing the sender balance to 150 tokens. An additional 50 tokens could still be sent without bringing the sender balance below the minimum balance. As structured, as more distinct accounts are sent the `FTC` token, the amount of total `FTC` locked in users' accounts rises.

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

The given inputs are missing the following checks: - In function `initSupply()`, input addresses `_presaleAddr`, `_liquidityAddr`, `_communityAddr`, `_devAddr`, and `_dexAddr` are missing a check that the same address is not used for multiple inputs. - In function `setFeeAddrs()`, input `_communityFundAddr` and `_marketAddr` are missing a check they are not the same address and that they have not been previously set to the same input. - In function `setExcludeFromFee()`, a check is missing that `_isExcludedFromFee[account]` is not already bool `enable`.