Coin98 (C98)

0X202107150017

Coin98 (C98) Audit Summary

Coin98 (C98) Audit
Document information
Audit results
Audited target file
Vulnerability analysis
Vulnerability distribution
Summary of audit results
Contract file
Analysis of audit results
Re-Entrancy
Arithmetic Over/Under Flows
Unexpected Blockchain Currency
Delegatecall
Default Visibilities
Entropy Illusion
External Contract Referencing
Unsolved TODO comments
Short Address/Parameter Attack
Unchecked CALL Return Values
Race Conditions / Front Running
Denial Of Service (DOS)
Block Timestamp Manipulation
Constructors with Care
Unintialised Storage Pointers
Floating Points and Numerical Precision
tx.origin Authentication
Permission restrictions

1 / 21
0X202107150017

Coin98 (C98) Audit Summary

Project name : Coin98 (C98) Contract

Project address: None

Code URL : https://bscscan.com/address/0xaec945e04baf28b135fa7c640f624f8d90f1c3a6#code

Commit : None

Project target : Coin98 (C98) Contract Audit

Blockchain : Binance Smart Chain(BSC)

Test result : PASSED

Audit Info

Audit NO : 0X202107150017

Audit Team : Armors Labs

Audit Proofreading: https://armors.io/#project-cases

Coin98 (C98) Audit

The Coin98 (C98) team asked us to review and audit their Coin98 (C98) contract. We looked at the code and now
publish our results.

Here is our assessment and recommendations, in order of importance.

Document information

Name Auditor Version Date

Coin98 (C98) Audit Rock, Sophia, Rushairer, Rico, David, Alice 1.0.0 2021-07-15

Audit results
Notice:Contract Owner can freeze in transfers

Note that as of the date of publishing, the above review reflects the current understanding of known security patterns
as they relate to the Coin98 (C98) contract. The above should not be construed as investment advice.

Based on the widely recognized security status of the current underlying blockchain and smart contract, this audit
report is valid for 3 months from the date of output.

(Disclaimer

Armors Labs Reports is not and should not be regarded as an "approval" or "disapproval" of any particular project or
team. These reports are not and should not be regarded as indicators of the economy or value of any "product" or
"asset" created by any team. Armors do not cover testing or auditing the integration with external contract or services
(such as Unicrypt, Uniswap, PancakeSwap etc’…)

2 / 21
0X202107150017

Armors Labs Reports represent an extensive auditing process intending to help our customers increase the quality of
their code while reducing the high level of risk presented by cryptographic tokens and blockchain technology. Armors
does not guarantee the safety or functionality of the technology agreed to be analyzed.

Armors Labs postulates that the information provided is not missing, tampered, deleted or hidden. If the information
provided is missing, tampered, deleted, hidden or reflected in a way that is not consistent with the actual situation,
Armors Labs shall not be responsible for the losses and adverse effects caused.) Armors Labs Audits should not be
used in any way to make decisions around investment or involvement with any particular project. These reports in no
way provide investment advice, nor should be leveraged as investment advice of any sort.)

Audited target file

file md5

coin.sol 71df658623c920080d804cf99b4bdf5a

Vulnerability analysis

Vulnerability distribution

vulnerability level number

Critical severity 0

High severity 0

Medium severity 0

Low severity 0

Summary of audit results

Vulnerability status

Re-Entrancy safe

Arithmetic Over/Under Flows safe

Unexpected Blockchain Currency safe

Delegatecall safe

Default Visibilities safe

Entropy Illusion safe

External Contract Referencing safe

Short Address/Parameter Attack safe

Unchecked CALL Return Values safe

Race Conditions / Front Running safe

Denial Of Service (DOS) safe

3 / 21
0X202107150017

Vulnerability status

Block Timestamp Manipulation safe

Constructors with Care safe

Unintialised Storage Pointers safe

Floating Points and Numerical Precision safe

tx.origin Authentication safe

Permission restrictions safe

Contract file
coin.sol

/**
*Submitted for verification at Etherscan.io on 2021-07-15
*/

// SPDX-License-Identifier: MIT
pragma solidity >=0.6.0 <0.8.0;

/**
* @dev Wrappers over Solidity's arithmetic operations with added overflow
* checks.
*
* Arithmetic operations in Solidity wrap on overflow. This can easily result
* in bugs, because programmers usually assume that an overflow raises an
* error, which is the standard behavior in high level programming languages.
* `SafeMath` restores this intuition by reverting the transaction when an
* operation overflows.
*
* Using this library instead of the unchecked operations eliminates an entire
* class of bugs, so it's recommended to use it always.
*/
library SafeMath {
/**
* @dev Returns the addition of two unsigned integers, with an overflow flag.
*
* _Available since v3.4._
*/
function tryAdd(uint256 a, uint256 b) internal pure returns (bool, uint256) {
uint256 c = a + b;
if (c < a) return (false, 0);
return (true, c);
}

/**
* @dev Returns the substraction of two unsigned integers, with an overflow flag.
*
* _Available since v3.4._
*/
function trySub(uint256 a, uint256 b) internal pure returns (bool, uint256) {
if (b > a) return (false, 0);
return (true, a - b);
}

/**
* @dev Returns the multiplication of two unsigned integers, with an overflow flag.
*

4 / 21
0X202107150017

* _Available since v3.4._

*/
function tryMul(uint256 a, uint256 b) internal pure returns (bool, uint256) {
// Gas optimization: this is cheaper than requiring 'a' not being zero, but the
// benefit is lost if 'b' is also tested.
// See: https://github.com/OpenZeppelin/openzeppelin-contracts/pull/522
if (a == 0) return (true, 0);
uint256 c = a * b;
if (c / a != b) return (false, 0);
return (true, c);
}

/**
* @dev Returns the division of two unsigned integers, with a division by zero flag.
*
* _Available since v3.4._
*/
function tryDiv(uint256 a, uint256 b) internal pure returns (bool, uint256) {
if (b == 0) return (false, 0);
return (true, a / b);
}

/**
* @dev Returns the remainder of dividing two unsigned integers, with a division by zero flag.
*
* _Available since v3.4._
*/
function tryMod(uint256 a, uint256 b) internal pure returns (bool, uint256) {
if (b == 0) return (false, 0);
return (true, a % b);
}

/**
* @dev Returns the addition of two unsigned integers, reverting on
* overflow.
*
* Counterpart to Solidity's `+` operator.
*
* Requirements:
*
* - Addition cannot overflow.
*/
function add(uint256 a, uint256 b) internal pure returns (uint256) {
uint256 c = a + b;
require(c >= a, "SafeMath: addition overflow");
return c;
}

/**
* @dev Returns the subtraction of two unsigned integers, reverting on
* overflow (when the result is negative).
*
* Counterpart to Solidity's `-` operator.
*
* Requirements:
*
* - Subtraction cannot overflow.
*/
function sub(uint256 a, uint256 b) internal pure returns (uint256) {
require(b <= a, "SafeMath: subtraction overflow");
return a - b;
}

/**
* @dev Returns the multiplication of two unsigned integers, reverting on
* overflow.

5 / 21
0X202107150017

*
* Counterpart to Solidity's `*` operator.
*
* Requirements:
*
* - Multiplication cannot overflow.
*/
function mul(uint256 a, uint256 b) internal pure returns (uint256) {
if (a == 0) return 0;
uint256 c = a * b;
require(c / a == b, "SafeMath: multiplication overflow");
return c;
}

/**
* @dev Returns the integer division of two unsigned integers, reverting on
* division by zero. The result is rounded towards zero.
*
* Counterpart to Solidity's `/` operator. Note: this function uses a
* `revert` opcode (which leaves remaining gas untouched) while Solidity
* uses an invalid opcode to revert (consuming all remaining gas).
*
* Requirements:
*
* - The divisor cannot be zero.
*/
function div(uint256 a, uint256 b) internal pure returns (uint256) {
require(b > 0, "SafeMath: division by zero");
return a / b;
}

/**
* @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),
* reverting when dividing by zero.
*
* Counterpart to Solidity's `%` operator. This function uses a `revert`
* opcode (which leaves remaining gas untouched) while Solidity uses an
* invalid opcode to revert (consuming all remaining gas).
*
* Requirements:
*
* - The divisor cannot be zero.
*/
function mod(uint256 a, uint256 b) internal pure returns (uint256) {
require(b > 0, "SafeMath: modulo by zero");
return a % b;
}

/**
* @dev Returns the subtraction of two unsigned integers, reverting with custom message on
* overflow (when the result is negative).
*
* CAUTION: This function is deprecated because it requires allocating memory for the error
* message unnecessarily. For custom revert reasons use {trySub}.
*
* Counterpart to Solidity's `-` operator.
*
* Requirements:
*
* - Subtraction cannot overflow.
*/
function sub(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
require(b <= a, errorMessage);
return a - b;
}

6 / 21
0X202107150017

/**
* @dev Returns the integer division of two unsigned integers, reverting with custom message on
* division by zero. The result is rounded towards zero.
*
* CAUTION: This function is deprecated because it requires allocating memory for the error
* message unnecessarily. For custom revert reasons use {tryDiv}.
*
* Counterpart to Solidity's `/` operator. Note: this function uses a
* `revert` opcode (which leaves remaining gas untouched) while Solidity
* uses an invalid opcode to revert (consuming all remaining gas).
*
* Requirements:
*
* - The divisor cannot be zero.
*/
function div(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
require(b > 0, errorMessage);
return a / b;
}

/**
* @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),
* reverting with custom message when dividing by zero.
*
* CAUTION: This function is deprecated because it requires allocating memory for the error
* message unnecessarily. For custom revert reasons use {tryMod}.
*
* Counterpart to Solidity's `%` operator. This function uses a `revert`
* opcode (which leaves remaining gas untouched) while Solidity uses an
* invalid opcode to revert (consuming all remaining gas).
*
* Requirements:
*
* - The divisor cannot be zero.
*/
function mod(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
require(b > 0, errorMessage);
return a % b;
}
}

/**
* @dev Interface of the ERC20 standard as defined in the EIP.
*/
interface IERC20 {
/**
* @dev Returns the amount of tokens in existence.
*/
function totalSupply() external view returns (uint256);

/**
* @dev Returns the amount of tokens owned by `account`.
*/
function balanceOf(address account) external view returns (uint256);

/**
* @dev Moves `amount` tokens from the caller's account to `recipient`.
*
* Returns a boolean value indicating whether the operation succeeded.
*
* Emits a {Transfer} event.
*/
function transfer(address recipient, uint256 amount) external returns (bool);

/**
* @dev Returns the remaining number of tokens that `spender` will be

7 / 21
0X202107150017

* allowed to spend on behalf of `owner` through {transferFrom}. This is

* zero by default.
*
* This value changes when {approve} or {transferFrom} are called.
*/
function allowance(address owner, address spender) external view returns (uint256);

/**
* @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
*
* Returns a boolean value indicating whether the operation succeeded.
*
* IMPORTANT: Beware that changing an allowance with this method brings the risk
* that someone may use both the old and the new allowance by unfortunate
* transaction ordering. One possible solution to mitigate this race
* condition is to first reduce the spender's allowance to 0 and set the
* desired value afterwards:
* https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
*
* Emits an {Approval} event.
*/
function approve(address spender, uint256 amount) external returns (bool);

/**
* @dev Moves `amount` tokens from `sender` to `recipient` using the
* allowance mechanism. `amount` is then deducted from the caller's
* allowance.
*
* Returns a boolean value indicating whether the operation succeeded.
*
* Emits a {Transfer} event.
*/
function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);

/**
* @dev Emitted when `value` tokens are moved from one account (`from`) to
* another (`to`).
*
* Note that `value` may be zero.
*/
event Transfer(address indexed from, address indexed to, uint256 value);

/**
* @dev Emitted when the allowance of a `spender` for an `owner` is set by
* a call to {approve}. `value` is the new allowance.
*/
event Approval(address indexed owner, address indexed spender, uint256 value);
}

/*
* @dev Provides information about the current execution context, including the
* sender of the transaction and its data. While these are generally available
* via msg.sender and msg.data, they should not be accessed in such a direct
* manner, since when dealing with GSN meta-transactions the account sending and
* paying for execution may not be the actual sender (as far as an application
* is concerned).
*
* This contract is only required for intermediate, library-like contracts.
*/
abstract contract Context {
function _msgSender() internal view returns (address payable) {
return msg.sender;
}

function _msgData() internal view returns (bytes memory) {

this; // silence state mutability warning without generating bytecode - see https://github.com/et

8 / 21
0X202107150017

return msg.data;
}
}

/**
* @dev Contract module which provides a basic access control mechanism, where
* there is an account (an owner) that can be granted exclusive access to
* specific functions.
*
* By default, the owner account will be the one that deploys the contract. This
* can later be changed with {transferOwnership}.
*
* This module is used through inheritance. It will make available the modifier
* `onlyOwner`, which can be applied to your functions to restrict their use to
* the owner.
*/
abstract contract Ownable is Context {
address private _owner;
address private _newOwner;

event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);

/**
* @dev Initializes the contract setting the deployer as the initial owner.
*/
constructor () {
address msgSender = _msgSender();
_owner = msgSender;
emit OwnershipTransferred(address(0), msgSender);
}

/**
* @dev Returns the address of the current owner.
*/
function owner() public view returns (address) {
return _owner;
}

/**
* @dev Throws if called by any account other than the owner.
*/
modifier onlyOwner() {
require(owner() == _msgSender(), "Ownable: caller is not the owner");
_;
}

/**
* @dev Accept the ownership transfer. This is to make sure that the contract is
* transferred to a working address
*
* Can only be called by the newly transfered owner.
*/
function acceptOwnership() public {
require(_msgSender() == _newOwner, "Ownable: only new owner can accept ownership");
address oldOwner = _owner;
_owner = _newOwner;
_newOwner = address(0);
emit OwnershipTransferred(oldOwner, _owner);
}

/**
* @dev Transfers ownership of the contract to a new account (`newOwner`).
*
* Can only be called by the current owner.
*/
function transferOwnership(address newOwner) public onlyOwner {

9 / 21
0X202107150017

require(newOwner != address(0), "Ownable: new owner is the zero address");

_newOwner = newOwner;
}
}

/**
* @dev Contract module which allows children to implement an emergency stop
* mechanism that can be triggered by an authorized account.
*
* This module is used through inheritance. It will make available the
* modifiers `whenNotFrozen` and `whenFrozen`, which can be applied to
* the functions of your contract. Note that they will not be pausable by
* simply including this module, only once the modifiers are put in place.
*/
abstract contract Pausable is Context, Ownable {
/**
* @dev Emitted when the freeze is triggered by `account`.
*/
event Frozen(address account);

/**
* @dev Emitted when the freeze is lifted by `account`.
*/
event Unfrozen(address account);

bool private _frozen;

/**
* @dev Initializes the contract in unfrozen state.
*/
constructor () {
_frozen = false;
}

/**
* @dev Returns true if the contract is frozen, and false otherwise.
*/
function frozen() public view returns (bool) {
return _frozen;
}

/**
* @dev Modifier to make a function callable only when the contract is not frozen.
*
* Requirements:
*
* - The contract must not be frozen.
*/
modifier whenNotFrozen() {
require(!frozen(), "Freezable: frozen");
_;
}

/**
* @dev Modifier to make a function callable only when the contract is frozen.
*
* Requirements:
*
* - The contract must be frozen.
*/
modifier whenFrozen() {
require(frozen(), "Freezable: frozen");
_;
}

/**

10 / 21
0X202107150017

* @dev Triggers stopped state.

*
* Requirements:
*
* - The contract must not be frozen.
*/
function _freeze() internal whenNotFrozen {
_frozen = true;
emit Frozen(_msgSender());
}

/**
* @dev Returns to normal state.
*
* Requirements:
*
* - Can only be called by the current owner.
* - The contract must be frozen.
*/
function _unfreeze() internal whenFrozen {
_frozen = false;
emit Unfrozen(_msgSender());
}
}

/**
* @dev Implementation of the {IERC20} interface.
*
* This implementation is agnostic to the way tokens are created. This means
* that a supply mechanism has to be added in a derived contract using {_mint}.
* For a generic mechanism see {ERC20PresetMinterPauser}.
*
* TIP: For a detailed writeup see our guide
* https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How
* to implement supply mechanisms].
*
* We have followed general OpenZeppelin guidelines: functions revert instead
* of returning `false` on failure. This behavior is nonetheless conventional
* and does not conflict with the expectations of ERC20 applications.
*
* Additionally, an {Approval} event is emitted on calls to {transferFrom}.
* This allows applications to reconstruct the allowance for all accounts just
* by listening to said events. Other implementations of the EIP may not emit
* these events, as it isn't required by the specification.
*
* Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
* functions have been added to mitigate the well-known issues around setting
* allowances. See {IERC20-approve}.
*/
contract Coin98 is Context, Ownable, Pausable, IERC20 {
using SafeMath for uint256;

mapping (address => uint256) private _balances;

mapping (address => mapping (address => uint256)) private _allowances;

uint256 private _maxSupply;

uint256 private _totalSupply;

string private _name;

string private _symbol;
uint8 private _decimals;

/**
* @dev Sets the values for {name} and {symbol}, initializes {decimals} with
* a default value of 18.

11 / 21
0X202107150017

*
* To select a different value for {decimals}, use {_setupDecimals}.
*
* All three of these values are immutable: they can only be set once during
* construction.
*/
constructor() {
uint256 fractions = 10 ** uint256(18);
_name = "Coin98";
_symbol = "C98";
_decimals = 18;
_maxSupply = 1000000000 * fractions;
}

/**
* @dev Returns the name of the token.
*/
function name() public view returns (string memory) {
return _name;
}

/**
* @dev Returns the symbol of the token, usually a shorter version of the
* name.
*/
function symbol() public view returns (string memory) {
return _symbol;
}

/**
* @dev Returns the number of decimals used to get its user representation.
* For example, if `decimals` equals `2`, a balance of `505` tokens should
* be displayed to a user as `5,05` (`505 / 10 ** 2`).
*
* Tokens usually opt for a value of 18, imitating the relationship between
* Ether and Wei. This is the value {ERC20} uses, unless {_setupDecimals} is
* called.
*
* NOTE: This information is only used for _display_ purposes: it in
* no way affects any of the arithmetic of the contract, including
* {IERC20-balanceOf} and {IERC20-transfer}.
*/
function decimals() public view returns (uint8) {
return _decimals;
}

/**
* @dev See {IERC20-totalSupply}.
*/
function totalSupply() public view override returns (uint256) {
return _totalSupply;
}

/**
* @dev See {IERC20-balanceOf}.
*/
function balanceOf(address account) public view override returns (uint256) {
return _balances[account];
}

/**
* @dev See {IERC20-transfer}.
*
* Requirements:
*
* - `recipient` cannot be the zero address.

12 / 21
0X202107150017

* - the caller must have a balance of at least `amount`.

*/
function transfer(address recipient, uint256 amount) public override returns (bool) {
_transfer(_msgSender(), recipient, amount);
return true;
}

/**
* @dev See {IERC20-allowance}.
*/
function allowance(address owner, address spender) public view override returns (uint256) {
return _allowances[owner][spender];
}

/**
* @dev See {IERC20-approve}.
*
* Requirements:
*
* - `spender` cannot be the zero address.
*/
function approve(address spender, uint256 amount) public override returns (bool) {
_approve(_msgSender(), spender, amount);
return true;
}

/**
* @dev See {IERC20-transferFrom}.
*
* Emits an {Approval} event indicating the updated allowance. This is not
* required by the EIP. See the note at the beginning of {ERC20}.
*
* Requirements:
*
* - `sender` and `recipient` cannot be the zero address.
* - `sender` must have a balance of at least `amount`.
* - the caller must have allowance for ``sender``'s tokens of at least
* `amount`.
*/
function transferFrom(address sender, address recipient, uint256 amount) public override returns (b
_transfer(sender, recipient, amount);
_approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "ERC20: transfer amo
return true;
}

/**
* @dev Atomically increases the allowance granted to `spender` by the caller.
*
* This is an alternative to {approve} that can be used as a mitigation for
* problems described in {IERC20-approve}.
*
* Emits an {Approval} event indicating the updated allowance.
*
* Requirements:
*
* - `spender` cannot be the zero address.
*/
function increaseAllowance(address spender, uint256 addedValue) public returns (bool) {
_approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));
return true;
}

/**
* @dev Atomically decreases the allowance granted to `spender` by the caller.
*
* This is an alternative to {approve} that can be used as a mitigation for

13 / 21
0X202107150017

* problems described in {IERC20-approve}.

*
* Emits an {Approval} event indicating the updated allowance.
*
* Requirements:
*
* - `spender` cannot be the zero address.
* - `spender` must have allowance for the caller of at least
* `subtractedValue`.
*/
function decreaseAllowance(address spender, uint256 subtractedValue) public returns (bool) {
_approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue, "ERC20: d
return true;
}

/**
* @dev Issues `amount` tokens to the designated `address`.
*
* Can only be called by the current owner.
* See {ERC20-_mint}.
*/
function mint(address account, uint256 amount) public onlyOwner {
_mint(account, amount);
}

/**
* @dev Destroys `amount` tokens from the caller.
*
* See {ERC20-_burn}.
*/
function burn(uint256 amount) public {
_burn(_msgSender(), amount);
}

/**
* @dev Destroys `amount` tokens from `account`, deducting from the caller's
* allowance.
*
* See {ERC20-_burn} and {ERC20-allowance}.
*
* Requirements:
*
* - the caller must have allowance for ``accounts``'s tokens of at least
* `amount`.
*/
function burnFrom(address account, uint256 amount) public {
uint256 decreasedAllowance = allowance(account, _msgSender()).sub(amount, "ERC20: burn amount exc

_approve(account, _msgSender(), decreasedAllowance);

_burn(account, amount);
}

/**
* @dev Disable the {transfer}, {mint} and {burn} functions of contract.
*
* Can only be called by the current owner.
* The contract must not be frozen.
*/
function freeze() public onlyOwner {
_freeze();
}

/**
* @dev Enable the {transfer}, {mint} and {burn} functions of contract.
*
* Can only be called by the current owner.

14 / 21
0X202107150017

* The contract must be frozen.

*/
function unfreeze() public onlyOwner {
_unfreeze();
}

/**
* @dev Moves tokens `amount` from `sender` to `recipient`.
*
* This is internal function is equivalent to {transfer}, and can be used to
* e.g. implement automatic token fees, slashing mechanisms, etc.
*
* Emits a {Transfer} event.
*
* Requirements:
*
* - `sender` cannot be the zero address.
* - `recipient` cannot be the zero address.
* - `sender` must have a balance of at least `amount`.
*/
function _transfer(address sender, address recipient, uint256 amount) internal {
require(sender != address(0), "ERC20: transfer from the zero address");
require(recipient != address(0), "ERC20: transfer to the zero address");

_beforeTokenTransfer(sender, recipient, amount);

_balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance");

_balances[recipient] = _balances[recipient].add(amount);
emit Transfer(sender, recipient, amount);
}

/** @dev Creates `amount` tokens and assigns them to `account`, increasing
* the total supply.
*
* Emits a {Transfer} event with `from` set to the zero address.
*
* Requirements:
*
* - `to` cannot be the zero address.
*/
function _mint(address account, uint256 amount) internal {
require(account != address(0), "ERC20: mint to the zero address");
require(_totalSupply + amount <= _maxSupply, "ERC20: mint amount exceeds max supply");

_beforeTokenTransfer(address(0), account, amount);

_totalSupply = _totalSupply.add(amount);
_balances[account] = _balances[account].add(amount);
emit Transfer(address(0), account, amount);
}

/**
* @dev Destroys `amount` tokens from `account`, reducing the
* total supply.
*
* Emits a {Transfer} event with `to` set to the zero address.
*
* Requirements:
*
* - `account` cannot be the zero address.
* - `account` must have at least `amount` tokens.
*/
function _burn(address account, uint256 amount) internal {
require(account != address(0), "ERC20: burn from the zero address");

_beforeTokenTransfer(account, address(0), amount);

15 / 21
0X202107150017

_balances[account] = _balances[account].sub(amount, "ERC20: burn amount exceeds balance");

_totalSupply = _totalSupply.sub(amount);
emit Transfer(account, address(0), amount);
}

/**
* @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens.
*
* This internal function is equivalent to `approve`, and can be used to
* e.g. set automatic allowances for certain subsystems, etc.
*
* Emits an {Approval} event.
*
* Requirements:
*
* - `owner` cannot be the zero address.
* - `spender` cannot be the zero address.
*/
function _approve(address owner, address spender, uint256 amount) internal {
require(owner != address(0), "ERC20: approve from the zero address");
require(spender != address(0), "ERC20: approve to the zero address");

_allowances[owner][spender] = amount;
emit Approval(owner, spender, amount);
}

/**
* @dev Hook that is called before any transfer of tokens. This includes
* minting and burning.
*
* Calling conditions:
*
* - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
* will be to transferred to `to`.
* - when `from` is zero, `amount` tokens will be minted for `to`.
* - when `to` is zero, `amount` of ``from``'s tokens will be burned.
* - `from` and `to` are never both zero.
*
* To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
*/
function _beforeTokenTransfer(address from, address to, uint256 amount) internal {
require(!frozen(), "ERC20: token transfer while frozen");
}

function _afterTokenTransfer(
address from,
address to,
uint256 amount
) internal {}
}

Analysis of audit results

Re-Entrancy

Description:
One of the features of smart contracts is the ability to call and utilise code of other external contracts. Contracts
also typically handle Blockchain Currency, and as such often send Blockchain Currency to various external user
addresses. The operation of calling external contracts, or sending Blockchain Currency to an address, requires

16 / 21
0X202107150017

the contract to submit an external call. These external calls can be hijacked by attackers whereby they force the
contract to execute further code (i.e. through a fallback function) , including calls back into itself. Thus the code
execution "re-enters" the contract. Attacks of this kind were used in the infamous DAO hack.
Detection results:

PASSED!

Security suggestion:
no.

Arithmetic Over/Under Flows

Description:
The Virtual Machine (EVM) specifies fixed-size data types for integers. This means that an integer variable, only
has a certain range of numbers it can represent. A uint8 for example, can only store numbers in the range
[0,255]. Trying to store 256 into a uint8 will result in 0. If care is not taken, variables in Solidity can be exploited if
user input is unchecked and calculations are performed which result in numbers that lie outside the range of the
data type that stores them.
Detection results:

PASSED!

Security suggestion:
no.

Unexpected Blockchain Currency

Description:
Typically when Blockchain Currency is sent to a contract, it must execute either the fallback function, or another
function described in the contract. There are two exceptions to this, where Blockchain Currency can exist in a
contract without having executed any code. Contracts which rely on code execution for every Blockchain
Currency sent to the contract can be vulnerable to attacks where Blockchain Currency is forcibly sent to a
contract.
Detection results:

PASSED!

Security suggestion: no.

Delegatecall

Description:
The CALL and DELEGATECALL opcodes are useful in allowing developers to modularise their code. Standard
external message calls to contracts are handled by the CALL opcode whereby code is run in the context of the
external contract/function. The DELEGATECALL opcode is identical to the standard message call, except that
the code executed at the targeted address is run in the context of the calling contract along with the fact that
msg.sender and msg.value remain unchanged. This feature enables the implementation of libraries whereby
developers can create reusable code for future contracts.
Detection results:

PASSED!

17 / 21
0X202107150017

Security suggestion: no.

Default Visibilities

Description:
Functions in Solidity have visibility specifiers which dictate how functions are allowed to be called. The visibility
determines whBlockchain Currency a function can be called externally by users, by other derived contracts, only
internally or only externally. There are four visibility specifiers, which are described in detail in the Solidity Docs.
Functions default to public allowing users to call them externally. Incorrect use of visibility specifiers can lead to
some devestating vulernabilities in smart contracts as will be discussed in this section.
Detection results:

PASSED!

Security suggestion:
no.

Entropy Illusion

Description:
All transactions on the blockchain are deterministic state transition operations. Meaning that every transaction
modifies the global state of the ecosystem and it does so in a calculable way with no uncertainty. This ultimately
means that inside the blockchain ecosystem there is no source of entropy or randomness. There is no rand()
function in Solidity. Achieving decentralised entropy (randomness) is a well established problem and many
ideas have been proposed to address this (see for example, RandDAO or using a chain of Hashes as described
by Vitalik in this post).
Detection results:

PASSED!

Security suggestion:
no.

External Contract Referencing

Description:
One of the benefits of the global computer is the ability to re-use code and interact with contracts already
deployed on the network. As a result, a large number of contracts reference external contracts and in general
operation use external message calls to interact with these contracts. These external message calls can mask
malicious actors intentions in some non-obvious ways, which we will discuss.
Detection results:

PASSED!

Security suggestion:
no.

Unsolved TODO comments

18 / 21
0X202107150017

Description:
Check for Unsolved TODO comments
Detection results:

PASSED!

Security suggestion:
no.

Short Address/Parameter Attack

Description:
This attack is not specifically performed on Solidity contracts themselves but on third party applications that may
interact with them. I add this attack for completeness and to be aware of how parameters can be manipulated in
contracts.
Detection results:

PASSED!

Security suggestion:
no.

Unchecked CALL Return Values

Description:
There a number of ways of performing external calls in solidity. Sending Blockchain Currency to external
accounts is commonly performed via the transfer() method. However, the send() function can also be used and,
for more versatile external calls, the CALL opcode can be directly employed in solidity. The call() and send()
functions return a boolean indicating if the call succeeded or failed. Thus these functions have a simple caveat,
in that the transaction that executes these functions will not revert if the external call (intialised by call() or send())
fails, rather the call() or send() will simply return false. A common pitfall arises when the return value is not
checked, rather the developer expects a revert to occur.
Detection results:

PASSED!

Security suggestion:
no.

Race Conditions / Front Running

Description:
The combination of external calls to other contracts and the multi-user nature of the underlying blockchain gives
rise to a variety of potential Solidity pitfalls whereby users race code execution to obtain unexpected states. Re-
Entrancy is one example of such a race condition. In this section we will talk more generally about different kinds
of race conditions that can occur on the blockchain. There is a variety of good posts on this subject, a few are:
Wiki - Safety, DASP - Front-Running and the Consensus - Smart Contract Best Practices.
Detection results:

PASSED!

19 / 21
0X202107150017

Security suggestion:
no.

Denial Of Service (DOS)

Description:
This category is very broad, but fundamentally consists of attacks where users can leave the contract inoperable
for a small period of time, or in some cases, permanently. This can trap Blockchain Currency in these contracts
forever, as was the case with the Second Parity MultiSig hack
Detection results:

PASSED!

Security suggestion:
no.

Block Timestamp Manipulation

Description:
Block timestamps have historically been used for a variety of applications, such as entropy for random numbers
(see the Entropy Illusion section for further details), locking funds for periods of time and various state-changing
conditional statements that are time-dependent. Miner's have the ability to adjust timestamps slightly which can
prove to be quite dangerous if block timestamps are used incorrectly in smart contracts.
Detection results:

PASSED!

Security suggestion:
no.

Constructors with Care

Description:
Constructors are special functions which often perform critical, privileged tasks when initialising contracts.
Before solidity v0.4.22 constructors were defined as functions that had the same name as the contract that
contained them. Thus, when a contract name gets changed in development, if the constructor name isn't
changed, it becomes a normal, callable function. As you can imagine, this can (and has) lead to some interesting
contract hacks.
Detection results:

PASSED!

Security suggestion:
no.

Unintialised Storage Pointers

Description:
The EVM stores data either as storage or as memory. Understanding exactly how this is done and the default

20 / 21
0X202107150017

types for local variables of functions is highly recommended when developing contracts. This is because it is
possible to produce vulnerable contracts by inappropriately intialising variables.
Detection results:

PASSED!

Security suggestion:
no.

Floating Points and Numerical Precision

Description:
As of this writing (Solidity v0.4.24), fixed point or floating point numbers are not supported. This means that
floating point representations must be made with the integer types in Solidity. This can lead to
errors/vulnerabilities if not implemented correctly.
Detection results:

PASSED!

Security suggestion:
no.

tx.origin Authentication

Description:
Solidity has a global variable, tx.origin which traverses the entire call stack and returns the address of the
account that originally sent the call (or transaction). Using this variable for authentication in smart contracts
leaves the contract vulnerable to a phishing-like attack.
Detection results:

PASSED!

Security suggestion:
no.

Permission restrictions

Description:
Contract managers who can control liquidity or pledge pools, etc., or impose unreasonable restrictions on other
users.
Detection results:

PASSED!

Security suggestion:
no.

21 / 21