├── ERC20.sol ├── ERC20Detailed.sol ├── IERC20.sol ├── SafeMath.sol └── Token.sol /ERC20.sol: -------------------------------------------------------------------------------- 1 | pragma solidity ^0.5.0; 2 | 3 | import "./IERC20.sol"; 4 | import "./SafeMath.sol"; 5 | 6 | /** 7 | * @dev Implementation of the {IERC20} interface. 8 | * 9 | * This implementation is agnostic to the way tokens are created. This means 10 | * that a supply mechanism has to be added in a derived contract using {_mint}. 11 | * For a generic mechanism see {ERC20Mintable}. 12 | * 13 | * TIP: For a detailed writeup see our guide 14 | * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How 15 | * to implement supply mechanisms]. 16 | * 17 | * We have followed general OpenZeppelin guidelines: functions revert instead 18 | * of returning `false` on failure. This behavior is nonetheless conventional 19 | * and does not conflict with the expectations of ERC20 applications. 20 | * 21 | * Additionally, an {Approval} event is emitted on calls to {transferFrom}. 22 | * This allows applications to reconstruct the allowance for all accounts just 23 | * by listening to said events. Other implementations of the EIP may not emit 24 | * these events, as it isn't required by the specification. 25 | * 26 | * Finally, the non-standard {decreaseAllowance} and {increaseAllowance} 27 | * functions have been added to mitigate the well-known issues around setting 28 | * allowances. See {IERC20-approve}. 29 | */ 30 | contract ERC20 is IERC20 { 31 | using SafeMath for uint256; 32 | 33 | mapping (address => uint256) private _balances; 34 | 35 | mapping (address => mapping (address => uint256)) private _allowances; 36 | 37 | uint256 private _totalSupply; 38 | 39 | /** 40 | * @dev See {IERC20-totalSupply}. 41 | */ 42 | function totalSupply() public view returns (uint256) { 43 | return _totalSupply; 44 | } 45 | 46 | /** 47 | * @dev See {IERC20-balanceOf}. 48 | */ 49 | function balanceOf(address account) public view returns (uint256) { 50 | return _balances[account]; 51 | } 52 | 53 | /** 54 | * @dev See {IERC20-transfer}. 55 | * 56 | * Requirements: 57 | * 58 | * - `recipient` cannot be the zero address. 59 | * - the caller must have a balance of at least `amount`. 60 | */ 61 | function transfer(address recipient, uint256 amount) public returns (bool) { 62 | _transfer(msg.sender, recipient, amount); 63 | return true; 64 | } 65 | 66 | /** 67 | * @dev See {IERC20-allowance}. 68 | */ 69 | function allowance(address owner, address spender) public view returns (uint256) { 70 | return _allowances[owner][spender]; 71 | } 72 | 73 | /** 74 | * @dev See {IERC20-approve}. 75 | * 76 | * Requirements: 77 | * 78 | * - `spender` cannot be the zero address. 79 | */ 80 | function approve(address spender, uint256 value) public returns (bool) { 81 | _approve(msg.sender, spender, value); 82 | return true; 83 | } 84 | 85 | /** 86 | * @dev See {IERC20-transferFrom}. 87 | * 88 | * Emits an {Approval} event indicating the updated allowance. This is not 89 | * required by the EIP. See the note at the beginning of {ERC20}; 90 | * 91 | * Requirements: 92 | * - `sender` and `recipient` cannot be the zero address. 93 | * - `sender` must have a balance of at least `value`. 94 | * - the caller must have allowance for `sender`'s tokens of at least 95 | * `amount`. 96 | */ 97 | function transferFrom(address sender, address recipient, uint256 amount) public returns (bool) { 98 | _transfer(sender, recipient, amount); 99 | _approve(sender, msg.sender, _allowances[sender][msg.sender].sub(amount)); 100 | return true; 101 | } 102 | 103 | /** 104 | * @dev Atomically increases the allowance granted to `spender` by the caller. 105 | * 106 | * This is an alternative to {approve} that can be used as a mitigation for 107 | * problems described in {IERC20-approve}. 108 | * 109 | * Emits an {Approval} event indicating the updated allowance. 110 | * 111 | * Requirements: 112 | * 113 | * - `spender` cannot be the zero address. 114 | */ 115 | function increaseAllowance(address spender, uint256 addedValue) public returns (bool) { 116 | _approve(msg.sender, spender, _allowances[msg.sender][spender].add(addedValue)); 117 | return true; 118 | } 119 | 120 | /** 121 | * @dev Atomically decreases the allowance granted to `spender` by the caller. 122 | * 123 | * This is an alternative to {approve} that can be used as a mitigation for 124 | * problems described in {IERC20-approve}. 125 | * 126 | * Emits an {Approval} event indicating the updated allowance. 127 | * 128 | * Requirements: 129 | * 130 | * - `spender` cannot be the zero address. 131 | * - `spender` must have allowance for the caller of at least 132 | * `subtractedValue`. 133 | */ 134 | function decreaseAllowance(address spender, uint256 subtractedValue) public returns (bool) { 135 | _approve(msg.sender, spender, _allowances[msg.sender][spender].sub(subtractedValue)); 136 | return true; 137 | } 138 | 139 | /** 140 | * @dev Moves tokens `amount` from `sender` to `recipient`. 141 | * 142 | * This is internal function is equivalent to {transfer}, and can be used to 143 | * e.g. implement automatic token fees, slashing mechanisms, etc. 144 | * 145 | * Emits a {Transfer} event. 146 | * 147 | * Requirements: 148 | * 149 | * - `sender` cannot be the zero address. 150 | * - `recipient` cannot be the zero address. 151 | * - `sender` must have a balance of at least `amount`. 152 | */ 153 | function _transfer(address sender, address recipient, uint256 amount) internal { 154 | require(sender != address(0), "ERC20: transfer from the zero address"); 155 | require(recipient != address(0), "ERC20: transfer to the zero address"); 156 | 157 | _balances[sender] = _balances[sender].sub(amount); 158 | _balances[recipient] = _balances[recipient].add(amount); 159 | emit Transfer(sender, recipient, amount); 160 | } 161 | 162 | /** @dev Creates `amount` tokens and assigns them to `account`, increasing 163 | * the total supply. 164 | * 165 | * Emits a {Transfer} event with `from` set to the zero address. 166 | * 167 | * Requirements 168 | * 169 | * - `to` cannot be the zero address. 170 | */ 171 | function _mint(address account, uint256 amount) internal { 172 | require(account != address(0), "ERC20: mint to the zero address"); 173 | 174 | _totalSupply = _totalSupply.add(amount); 175 | _balances[account] = _balances[account].add(amount); 176 | emit Transfer(address(0), account, amount); 177 | } 178 | 179 | /** 180 | * @dev Destroys `amount` tokens from `account`, reducing the 181 | * total supply. 182 | * 183 | * Emits a {Transfer} event with `to` set to the zero address. 184 | * 185 | * Requirements 186 | * 187 | * - `account` cannot be the zero address. 188 | * - `account` must have at least `amount` tokens. 189 | */ 190 | function _burn(address account, uint256 value) internal { 191 | require(account != address(0), "ERC20: burn from the zero address"); 192 | 193 | _totalSupply = _totalSupply.sub(value); 194 | _balances[account] = _balances[account].sub(value); 195 | emit Transfer(account, address(0), value); 196 | } 197 | 198 | /** 199 | * @dev Sets `amount` as the allowance of `spender` over the `owner`s tokens. 200 | * 201 | * This is internal function is equivalent to `approve`, and can be used to 202 | * e.g. set automatic allowances for certain subsystems, etc. 203 | * 204 | * Emits an {Approval} event. 205 | * 206 | * Requirements: 207 | * 208 | * - `owner` cannot be the zero address. 209 | * - `spender` cannot be the zero address. 210 | */ 211 | function _approve(address owner, address spender, uint256 value) internal { 212 | require(owner != address(0), "ERC20: approve from the zero address"); 213 | require(spender != address(0), "ERC20: approve to the zero address"); 214 | 215 | _allowances[owner][spender] = value; 216 | emit Approval(owner, spender, value); 217 | } 218 | 219 | /** 220 | * @dev Destoys `amount` tokens from `account`.`amount` is then deducted 221 | * from the caller's allowance. 222 | * 223 | * See {_burn} and {_approve}. 224 | */ 225 | function _burnFrom(address account, uint256 amount) internal { 226 | _burn(account, amount); 227 | _approve(account, msg.sender, _allowances[account][msg.sender].sub(amount)); 228 | } 229 | } -------------------------------------------------------------------------------- /ERC20Detailed.sol: -------------------------------------------------------------------------------- 1 | pragma solidity ^0.5.0; 2 | 3 | import "./IERC20.sol"; 4 | 5 | /** 6 | * @dev Optional functions from the ERC20 standard. 7 | */ 8 | contract ERC20Detailed is IERC20 { 9 | string private _name; 10 | string private _symbol; 11 | uint8 private _decimals; 12 | 13 | /** 14 | * @dev Sets the values for `name`, `symbol`, and `decimals`. All three of 15 | * these values are immutable: they can only be set once during 16 | * construction. 17 | */ 18 | constructor (string memory name, string memory symbol, uint8 decimals) public { 19 | _name = name; 20 | _symbol = symbol; 21 | _decimals = decimals; 22 | } 23 | 24 | /** 25 | * @dev Returns the name of the token. 26 | */ 27 | function name() public view returns (string memory) { 28 | return _name; 29 | } 30 | 31 | /** 32 | * @dev Returns the symbol of the token, usually a shorter version of the 33 | * name. 34 | */ 35 | function symbol() public view returns (string memory) { 36 | return _symbol; 37 | } 38 | 39 | /** 40 | * @dev Returns the number of decimals used to get its user representation. 41 | * For example, if `decimals` equals `2`, a balance of `505` tokens should 42 | * be displayed to a user as `5,05` (`505 / 10 ** 2`). 43 | * 44 | * Tokens usually opt for a value of 18, imitating the relationship between 45 | * Ether and Wei. 46 | * 47 | * NOTE: This information is only used for _display_ purposes: it in 48 | * no way affects any of the arithmetic of the contract, including 49 | * {IERC20-balanceOf} and {IERC20-transfer}. 50 | */ 51 | function decimals() public view returns (uint8) { 52 | return _decimals; 53 | } 54 | } 55 | 56 | -------------------------------------------------------------------------------- /IERC20.sol: -------------------------------------------------------------------------------- 1 | pragma solidity ^0.5.0; 2 | 3 | /** 4 | * @dev Interface of the ERC20 standard as defined in the EIP. Does not include 5 | * the optional functions; to access them see {ERC20Detailed}. 6 | */ 7 | interface IERC20 { 8 | /** 9 | * @dev Returns the amount of tokens in existence. 10 | */ 11 | function totalSupply() external view returns (uint256); 12 | 13 | /** 14 | * @dev Returns the amount of tokens owned by `account`. 15 | */ 16 | function balanceOf(address account) external view returns (uint256); 17 | 18 | /** 19 | * @dev Moves `amount` tokens from the caller's account to `recipient`. 20 | * 21 | * Returns a boolean value indicating whether the operation succeeded. 22 | * 23 | * Emits a {Transfer} event. 24 | */ 25 | function transfer(address recipient, uint256 amount) external returns (bool); 26 | 27 | /** 28 | * @dev Returns the remaining number of tokens that `spender` will be 29 | * allowed to spend on behalf of `owner` through {transferFrom}. This is 30 | * zero by default. 31 | * 32 | * This value changes when {approve} or {transferFrom} are called. 33 | */ 34 | function allowance(address owner, address spender) external view returns (uint256); 35 | 36 | /** 37 | * @dev Sets `amount` as the allowance of `spender` over the caller's tokens. 38 | * 39 | * Returns a boolean value indicating whether the operation succeeded. 40 | * 41 | * IMPORTANT: Beware that changing an allowance with this method brings the risk 42 | * that someone may use both the old and the new allowance by unfortunate 43 | * transaction ordering. One possible solution to mitigate this race 44 | * condition is to first reduce the spender's allowance to 0 and set the 45 | * desired value afterwards: 46 | * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 47 | * 48 | * Emits an {Approval} event. 49 | */ 50 | function approve(address spender, uint256 amount) external returns (bool); 51 | 52 | /** 53 | * @dev Moves `amount` tokens from `sender` to `recipient` using the 54 | * allowance mechanism. `amount` is then deducted from the caller's 55 | * allowance. 56 | * 57 | * Returns a boolean value indicating whether the operation succeeded. 58 | * 59 | * Emits a {Transfer} event. 60 | */ 61 | function transferFrom(address sender, address recipient, uint256 amount) external returns (bool); 62 | 63 | /** 64 | * @dev Emitted when `value` tokens are moved from one account (`from`) to 65 | * another (`to`). 66 | * 67 | * Note that `value` may be zero. 68 | */ 69 | event Transfer(address indexed from, address indexed to, uint256 value); 70 | 71 | /** 72 | * @dev Emitted when the allowance of a `spender` for an `owner` is set by 73 | * a call to {approve}. `value` is the new allowance. 74 | */ 75 | event Approval(address indexed owner, address indexed spender, uint256 value); 76 | } 77 | -------------------------------------------------------------------------------- /SafeMath.sol: -------------------------------------------------------------------------------- 1 | pragma solidity ^0.5.0; 2 | 3 | /** 4 | * @dev Wrappers over Solidity's arithmetic operations with added overflow 5 | * checks. 6 | * 7 | * Arithmetic operations in Solidity wrap on overflow. This can easily result 8 | * in bugs, because programmers usually assume that an overflow raises an 9 | * error, which is the standard behavior in high level programming languages. 10 | * `SafeMath` restores this intuition by reverting the transaction when an 11 | * operation overflows. 12 | * 13 | * Using this library instead of the unchecked operations eliminates an entire 14 | * class of bugs, so it's recommended to use it always. 15 | */ 16 | library SafeMath { 17 | /** 18 | * @dev Returns the addition of two unsigned integers, reverting on 19 | * overflow. 20 | * 21 | * Counterpart to Solidity's `+` operator. 22 | * 23 | * Requirements: 24 | * - Addition cannot overflow. 25 | */ 26 | function add(uint256 a, uint256 b) internal pure returns (uint256) { 27 | uint256 c = a + b; 28 | require(c >= a, "SafeMath: addition overflow"); 29 | 30 | return c; 31 | } 32 | 33 | /** 34 | * @dev Returns the subtraction of two unsigned integers, reverting on 35 | * overflow (when the result is negative). 36 | * 37 | * Counterpart to Solidity's `-` operator. 38 | * 39 | * Requirements: 40 | * - Subtraction cannot overflow. 41 | */ 42 | function sub(uint256 a, uint256 b) internal pure returns (uint256) { 43 | require(b <= a, "SafeMath: subtraction overflow"); 44 | uint256 c = a - b; 45 | 46 | return c; 47 | } 48 | 49 | /** 50 | * @dev Returns the multiplication of two unsigned integers, reverting on 51 | * overflow. 52 | * 53 | * Counterpart to Solidity's `*` operator. 54 | * 55 | * Requirements: 56 | * - Multiplication cannot overflow. 57 | */ 58 | function mul(uint256 a, uint256 b) internal pure returns (uint256) { 59 | // Gas optimization: this is cheaper than requiring 'a' not being zero, but the 60 | // benefit is lost if 'b' is also tested. 61 | // See: https://github.com/OpenZeppelin/openzeppelin-contracts/pull/522 62 | if (a == 0) { 63 | return 0; 64 | } 65 | 66 | uint256 c = a * b; 67 | require(c / a == b, "SafeMath: multiplication overflow"); 68 | 69 | return c; 70 | } 71 | 72 | /** 73 | * @dev Returns the integer division of two unsigned integers. Reverts on 74 | * division by zero. The result is rounded towards zero. 75 | * 76 | * Counterpart to Solidity's `/` operator. Note: this function uses a 77 | * `revert` opcode (which leaves remaining gas untouched) while Solidity 78 | * uses an invalid opcode to revert (consuming all remaining gas). 79 | * 80 | * Requirements: 81 | * - The divisor cannot be zero. 82 | */ 83 | function div(uint256 a, uint256 b) internal pure returns (uint256) { 84 | // Solidity only automatically asserts when dividing by 0 85 | require(b > 0, "SafeMath: division by zero"); 86 | uint256 c = a / b; 87 | // assert(a == b * c + a % b); // There is no case in which this doesn't hold 88 | 89 | return c; 90 | } 91 | 92 | /** 93 | * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo), 94 | * Reverts when dividing by zero. 95 | * 96 | * Counterpart to Solidity's `%` operator. This function uses a `revert` 97 | * opcode (which leaves remaining gas untouched) while Solidity uses an 98 | * invalid opcode to revert (consuming all remaining gas). 99 | * 100 | * Requirements: 101 | * - The divisor cannot be zero. 102 | */ 103 | function mod(uint256 a, uint256 b) internal pure returns (uint256) { 104 | require(b != 0, "SafeMath: modulo by zero"); 105 | return a % b; 106 | } 107 | } 108 | -------------------------------------------------------------------------------- /Token.sol: -------------------------------------------------------------------------------- 1 | // 0.5.1-c8a2 2 | // Enable optimization 3 | pragma solidity ^0.5.0; 4 | 5 | import "./ERC20.sol"; 6 | import "./ERC20Detailed.sol"; 7 | 8 | /** 9 | * @title SimpleToken 10 | * @dev Very simple ERC20 Token example, where all tokens are pre-assigned to the creator. 11 | * Note they can later distribute these tokens as they wish using `transfer` and other 12 | * `ERC20` functions. 13 | */ 14 | contract Token is ERC20, ERC20Detailed { 15 | 16 | /** 17 | * @dev Constructor that gives msg.sender all of existing tokens. 18 | */ 19 | constructor () public ERC20Detailed("YourTokenName", "YTN", 18) { 20 | _mint(msg.sender, 10000000000 * (10 ** uint256(decimals()))); 21 | } 22 | } --------------------------------------------------------------------------------