ERC20.sol 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306
  1. pragma solidity ^0.6.0;
  2. import "../../GSN/Context.sol";
  3. import "./IERC20.sol";
  4. import "../../math/SafeMath.sol";
  5. import "../../utils/Address.sol";
  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 Context, IERC20 {
  31. using SafeMath for uint256;
  32. using Address for address;
  33. mapping (address => uint256) private _balances;
  34. mapping (address => mapping (address => uint256)) private _allowances;
  35. uint256 private _totalSupply;
  36. string private _name;
  37. string private _symbol;
  38. uint8 private _decimals;
  39. /**
  40. * @dev Sets the values for {name} and {symbol}, initializes {decimals} with
  41. * a default value of 18.
  42. *
  43. * To select a different value for {decimals}, use {_setupDecimals}.
  44. *
  45. * All three of these values are immutable: they can only be set once during
  46. * construction.
  47. */
  48. constructor (string memory name, string memory symbol) public {
  49. _name = name;
  50. _symbol = symbol;
  51. _decimals = 18;
  52. }
  53. /**
  54. * @dev Returns the name of the token.
  55. */
  56. function name() public view returns (string memory) {
  57. return _name;
  58. }
  59. /**
  60. * @dev Returns the symbol of the token, usually a shorter version of the
  61. * name.
  62. */
  63. function symbol() public view returns (string memory) {
  64. return _symbol;
  65. }
  66. /**
  67. * @dev Returns the number of decimals used to get its user representation.
  68. * For example, if `decimals` equals `2`, a balance of `505` tokens should
  69. * be displayed to a user as `5,05` (`505 / 10 ** 2`).
  70. *
  71. * Tokens usually opt for a value of 18, imitating the relationship between
  72. * Ether and Wei. This is the value {ERC20} uses, unless {_setupDecimals} is
  73. * called.
  74. *
  75. * NOTE: This information is only used for _display_ purposes: it in
  76. * no way affects any of the arithmetic of the contract, including
  77. * {IERC20-balanceOf} and {IERC20-transfer}.
  78. */
  79. function decimals() public view returns (uint8) {
  80. return _decimals;
  81. }
  82. /**
  83. * @dev See {IERC20-totalSupply}.
  84. */
  85. function totalSupply() public view override returns (uint256) {
  86. return _totalSupply;
  87. }
  88. /**
  89. * @dev See {IERC20-balanceOf}.
  90. */
  91. function balanceOf(address account) public view override returns (uint256) {
  92. return _balances[account];
  93. }
  94. /**
  95. * @dev See {IERC20-transfer}.
  96. *
  97. * Requirements:
  98. *
  99. * - `recipient` cannot be the zero address.
  100. * - the caller must have a balance of at least `amount`.
  101. */
  102. function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
  103. _transfer(_msgSender(), recipient, amount);
  104. return true;
  105. }
  106. /**
  107. * @dev See {IERC20-allowance}.
  108. */
  109. function allowance(address owner, address spender) public view virtual override returns (uint256) {
  110. return _allowances[owner][spender];
  111. }
  112. /**
  113. * @dev See {IERC20-approve}.
  114. *
  115. * Requirements:
  116. *
  117. * - `spender` cannot be the zero address.
  118. */
  119. function approve(address spender, uint256 amount) public virtual override returns (bool) {
  120. _approve(_msgSender(), spender, amount);
  121. return true;
  122. }
  123. /**
  124. * @dev See {IERC20-transferFrom}.
  125. *
  126. * Emits an {Approval} event indicating the updated allowance. This is not
  127. * required by the EIP. See the note at the beginning of {ERC20};
  128. *
  129. * Requirements:
  130. * - `sender` and `recipient` cannot be the zero address.
  131. * - `sender` must have a balance of at least `amount`.
  132. * - the caller must have allowance for `sender`'s tokens of at least
  133. * `amount`.
  134. */
  135. function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) {
  136. _transfer(sender, recipient, amount);
  137. _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "ERC20: transfer amount exceeds allowance"));
  138. return true;
  139. }
  140. /**
  141. * @dev Atomically increases the allowance granted to `spender` by the caller.
  142. *
  143. * This is an alternative to {approve} that can be used as a mitigation for
  144. * problems described in {IERC20-approve}.
  145. *
  146. * Emits an {Approval} event indicating the updated allowance.
  147. *
  148. * Requirements:
  149. *
  150. * - `spender` cannot be the zero address.
  151. */
  152. function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
  153. _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));
  154. return true;
  155. }
  156. /**
  157. * @dev Atomically decreases the allowance granted to `spender` by the caller.
  158. *
  159. * This is an alternative to {approve} that can be used as a mitigation for
  160. * problems described in {IERC20-approve}.
  161. *
  162. * Emits an {Approval} event indicating the updated allowance.
  163. *
  164. * Requirements:
  165. *
  166. * - `spender` cannot be the zero address.
  167. * - `spender` must have allowance for the caller of at least
  168. * `subtractedValue`.
  169. */
  170. function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
  171. _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue, "ERC20: decreased allowance below zero"));
  172. return true;
  173. }
  174. /**
  175. * @dev Moves tokens `amount` from `sender` to `recipient`.
  176. *
  177. * This is internal function is equivalent to {transfer}, and can be used to
  178. * e.g. implement automatic token fees, slashing mechanisms, etc.
  179. *
  180. * Emits a {Transfer} event.
  181. *
  182. * Requirements:
  183. *
  184. * - `sender` cannot be the zero address.
  185. * - `recipient` cannot be the zero address.
  186. * - `sender` must have a balance of at least `amount`.
  187. */
  188. function _transfer(address sender, address recipient, uint256 amount) internal virtual {
  189. require(sender != address(0), "ERC20: transfer from the zero address");
  190. require(recipient != address(0), "ERC20: transfer to the zero address");
  191. _beforeTokenTransfer(sender, recipient, amount);
  192. _balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance");
  193. _balances[recipient] = _balances[recipient].add(amount);
  194. emit Transfer(sender, recipient, amount);
  195. }
  196. /** @dev Creates `amount` tokens and assigns them to `account`, increasing
  197. * the total supply.
  198. *
  199. * Emits a {Transfer} event with `from` set to the zero address.
  200. *
  201. * Requirements
  202. *
  203. * - `to` cannot be the zero address.
  204. */
  205. function _mint(address account, uint256 amount) internal virtual {
  206. require(account != address(0), "ERC20: mint to the zero address");
  207. _beforeTokenTransfer(address(0), account, amount);
  208. _totalSupply = _totalSupply.add(amount);
  209. _balances[account] = _balances[account].add(amount);
  210. emit Transfer(address(0), account, amount);
  211. }
  212. /**
  213. * @dev Destroys `amount` tokens from `account`, reducing the
  214. * total supply.
  215. *
  216. * Emits a {Transfer} event with `to` set to the zero address.
  217. *
  218. * Requirements
  219. *
  220. * - `account` cannot be the zero address.
  221. * - `account` must have at least `amount` tokens.
  222. */
  223. function _burn(address account, uint256 amount) internal virtual {
  224. require(account != address(0), "ERC20: burn from the zero address");
  225. _beforeTokenTransfer(account, address(0), amount);
  226. _balances[account] = _balances[account].sub(amount, "ERC20: burn amount exceeds balance");
  227. _totalSupply = _totalSupply.sub(amount);
  228. emit Transfer(account, address(0), amount);
  229. }
  230. /**
  231. * @dev Sets `amount` as the allowance of `spender` over the `owner`s tokens.
  232. *
  233. * This is internal function is equivalent to `approve`, and can be used to
  234. * e.g. set automatic allowances for certain subsystems, etc.
  235. *
  236. * Emits an {Approval} event.
  237. *
  238. * Requirements:
  239. *
  240. * - `owner` cannot be the zero address.
  241. * - `spender` cannot be the zero address.
  242. */
  243. function _approve(address owner, address spender, uint256 amount) internal virtual {
  244. require(owner != address(0), "ERC20: approve from the zero address");
  245. require(spender != address(0), "ERC20: approve to the zero address");
  246. _allowances[owner][spender] = amount;
  247. emit Approval(owner, spender, amount);
  248. }
  249. /**
  250. * @dev Sets {decimals} to a value other than the default one of 18.
  251. *
  252. * Requirements:
  253. *
  254. * - this function can only be called from a constructor.
  255. */
  256. function _setupDecimals(uint8 decimals_) internal {
  257. require(!address(this).isContract(), "ERC20: decimals cannot be changed after construction");
  258. _decimals = decimals_;
  259. }
  260. /**
  261. * @dev Hook that is called before any transfer of tokens. This includes
  262. * minting and burning.
  263. *
  264. * Calling conditions:
  265. *
  266. * - when `from` and `to` are both non-zero, `amount` of `from`'s tokens
  267. * will be to transferred to `to`.
  268. * - when `from` is zero, `amount` tokens will be minted for `to`.
  269. * - when `to` is zero, `amount` of `from`'s tokens will be burned.
  270. * - `from` and `to` are never both zero.
  271. *
  272. * To learn more about hooks, head to xref:ROOT:using-hooks.adoc[Using Hooks].
  273. */
  274. function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual { }
  275. }