Fabwelt security record

In the function `FabweltToken.transferFrom()`, the function transfers tokens before checking if the message sender has enough of an allowance. ```solidity=541 _transfer(sender, recipient, amount); _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "TOKEN20: transfer amount exceeds allowance")); ``` It would be better to validate the allowance first to reduce gas costs in case it reverts.

The following functions update crucial state variables. Events should be emitted to log these updates. - `FabweltToken.deliver()` - `FabweltToken.excludeAccount()` - `FabweltToken.includeAccount()` - `FabweltToken.setAsCharityAccount()` - `FabweltToken.updateFee()`

The **require** statement 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 the function `FabweltToken._transfer()`, `takeFee` is set to `false` if `recipient` is excluded: ```solidity=649 if (FeeAddress == sender || FeeAddress == recipient || _isExcluded[recipient]) { takeFee = false; } if (StakeAddress == sender || StakeAddress == recipient || _isExcluded[recipient]) { takeFee = false; } ``` Checking `_isExcluded[recipient]` in the second `if` statement is unnecessary because it has been checked in the first `if` statement. In the function `FabweltToken._transfer()`, the condition `!_isExcluded[sender] && !_isExcluded[recipient]` is unnecessary because `FabweltToken._transferStandard()` will be executed in the `else` statement: ```solidity=664 ... else if (!_isExcluded[sender] && !_isExcluded[recipient]) { _transferStandard(sender, recipient, amount); } ... ``` The function `FabweltToken._reflectFee()` contains the following line: ```solidity=745 _tTotal = _tTotal; ``` However, this does not bring any changes. The function `FabweltToken._getTaxFee()` is a private function but never used within the contract.

The contract has an 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 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.

In the contract `FabweltToken`, the functions `_transferStandard()`, `_transferToExcluded()`, `_transferFromExcluded()`, and `_transferBothExcluded()` all contain the following line: ```solidity uint256 currentRate = _getRate(); ``` However, the local variable `currentRate` is unused in the above mentioned functions.

The values of `FabweltToken._GRANULARITY` and `FabweltToken._MAX` are never changed after assignment, so they can be declared as `constant`. A big advantage of constant variables is that reading them is significantly cheaper than reading from regular state variables.