SHANTI security record

In the current implementation, the function `transferFrom()` does not follow the Checks-Effects-Interactation standard, as the transfer is completed before the allowances are checked. While this does not create any security issues in this implementation, it does not follow the standard and thus is only informational.

The contract is serving as the underlying entity to interact with a third party ServicePayer. The scope of the audit treats third party entities as black boxes and assume their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. ```solidity=577 constructor(address payable receiver, string memory serviceName) payable { ``` - The function `ServicePayer.constructor` interacts with third party contract with `IPayable` interface via `receiver`.

The following function can use unchecked blocks to save gas on each call: - `decreaseAllowance()`: `_approve` can be put inside of an unchecked block to save gas due to the require statement preventing overflow and underflow. - `_transfer()`: the change in values in `_balances[sender]` and `_balances[recipient]` can be put inside of an unchecked block due to it not being able to overflow or underflow as `_totalSupply` cannot pass the max value of uint256. - `_mint()`: the change in value inside of `_balances[account]` can be put inside of an unchecked block due to it not being able to overflow or underflow as `_totalSupply` cannot pass the max value of uint256. - `_burn()`: the amount burned inside of `_balances[account]` and `_totalSupply` can be put inside of an unchecked block due to the require statement preventing overflow and underflow.