ERC20.sol 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303
  1. // SPDX-License-Identifier: MIT
  2. pragma solidity ^0.8.0;
  3. import "../../utils/Context.sol";
  4. import "./IERC20.sol";
  5. /**
  6. * @dev Implementation of the {IERC20} interface.
  7. *
  8. * This implementation is agnostic to the way tokens are created. This means
  9. * that a supply mechanism has to be added in a derived contract using {_mint}.
  10. * For a generic mechanism see {ERC20PresetMinterPauser}.
  11. *
  12. * TIP: For a detailed writeup see our guide
  13. * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How
  14. * to implement supply mechanisms].
  15. *
  16. * We have followed general OpenZeppelin guidelines: functions revert instead
  17. * of returning `false` on failure. This behavior is nonetheless conventional
  18. * and does not conflict with the expectations of ERC20 applications.
  19. *
  20. * Additionally, an {Approval} event is emitted on calls to {transferFrom}.
  21. * This allows applications to reconstruct the allowance for all accounts just
  22. * by listening to said events. Other implementations of the EIP may not emit
  23. * these events, as it isn't required by the specification.
  24. *
  25. * Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
  26. * functions have been added to mitigate the well-known issues around setting
  27. * allowances. See {IERC20-approve}.
  28. */
  29. contract ERC20 is Context, IERC20 {
  30. mapping (address => uint256) private _balances;
  31. mapping (address => mapping (address => uint256)) private _allowances;
  32. uint256 private _totalSupply;
  33. string private _name;
  34. string private _symbol;
  35. uint8 private _decimals;
  36. /**
  37. * @dev Sets the values for {name} and {symbol}, initializes {decimals} with
  38. * a default value of 18.
  39. *
  40. * To select a different value for {decimals}, use {_setupDecimals}.
  41. *
  42. * All three of these values are immutable: they can only be set once during
  43. * construction.
  44. */
  45. constructor (string memory name_, string memory symbol_) {
  46. _name = name_;
  47. _symbol = symbol_;
  48. _decimals = 18;
  49. }
  50. /**
  51. * @dev Returns the name of the token.
  52. */
  53. function name() public view virtual returns (string memory) {
  54. return _name;
  55. }
  56. /**
  57. * @dev Returns the symbol of the token, usually a shorter version of the
  58. * name.
  59. */
  60. function symbol() public view virtual returns (string memory) {
  61. return _symbol;
  62. }
  63. /**
  64. * @dev Returns the number of decimals used to get its user representation.
  65. * For example, if `decimals` equals `2`, a balance of `505` tokens should
  66. * be displayed to a user as `5,05` (`505 / 10 ** 2`).
  67. *
  68. * Tokens usually opt for a value of 18, imitating the relationship between
  69. * Ether and Wei. This is the value {ERC20} uses, unless {_setupDecimals} is
  70. * called.
  71. *
  72. * NOTE: This information is only used for _display_ purposes: it in
  73. * no way affects any of the arithmetic of the contract, including
  74. * {IERC20-balanceOf} and {IERC20-transfer}.
  75. */
  76. function decimals() public view virtual returns (uint8) {
  77. return _decimals;
  78. }
  79. /**
  80. * @dev See {IERC20-totalSupply}.
  81. */
  82. function totalSupply() public view virtual override returns (uint256) {
  83. return _totalSupply;
  84. }
  85. /**
  86. * @dev See {IERC20-balanceOf}.
  87. */
  88. function balanceOf(address account) public view virtual override returns (uint256) {
  89. return _balances[account];
  90. }
  91. /**
  92. * @dev See {IERC20-transfer}.
  93. *
  94. * Requirements:
  95. *
  96. * - `recipient` cannot be the zero address.
  97. * - the caller must have a balance of at least `amount`.
  98. */
  99. function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
  100. _transfer(_msgSender(), recipient, amount);
  101. return true;
  102. }
  103. /**
  104. * @dev See {IERC20-allowance}.
  105. */
  106. function allowance(address owner, address spender) public view virtual override returns (uint256) {
  107. return _allowances[owner][spender];
  108. }
  109. /**
  110. * @dev See {IERC20-approve}.
  111. *
  112. * Requirements:
  113. *
  114. * - `spender` cannot be the zero address.
  115. */
  116. function approve(address spender, uint256 amount) public virtual override returns (bool) {
  117. _approve(_msgSender(), spender, amount);
  118. return true;
  119. }
  120. /**
  121. * @dev See {IERC20-transferFrom}.
  122. *
  123. * Emits an {Approval} event indicating the updated allowance. This is not
  124. * required by the EIP. See the note at the beginning of {ERC20}.
  125. *
  126. * Requirements:
  127. *
  128. * - `sender` and `recipient` cannot be the zero address.
  129. * - `sender` must have a balance of at least `amount`.
  130. * - the caller must have allowance for ``sender``'s tokens of at least
  131. * `amount`.
  132. */
  133. function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) {
  134. _transfer(sender, recipient, amount);
  135. _approve(sender, _msgSender(), _allowances[sender][_msgSender()] - amount);
  136. return true;
  137. }
  138. /**
  139. * @dev Atomically increases the allowance granted to `spender` by the caller.
  140. *
  141. * This is an alternative to {approve} that can be used as a mitigation for
  142. * problems described in {IERC20-approve}.
  143. *
  144. * Emits an {Approval} event indicating the updated allowance.
  145. *
  146. * Requirements:
  147. *
  148. * - `spender` cannot be the zero address.
  149. */
  150. function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
  151. _approve(_msgSender(), spender, _allowances[_msgSender()][spender] + addedValue);
  152. return true;
  153. }
  154. /**
  155. * @dev Atomically decreases the allowance granted to `spender` by the caller.
  156. *
  157. * This is an alternative to {approve} that can be used as a mitigation for
  158. * problems described in {IERC20-approve}.
  159. *
  160. * Emits an {Approval} event indicating the updated allowance.
  161. *
  162. * Requirements:
  163. *
  164. * - `spender` cannot be the zero address.
  165. * - `spender` must have allowance for the caller of at least
  166. * `subtractedValue`.
  167. */
  168. function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
  169. _approve(_msgSender(), spender, _allowances[_msgSender()][spender] - subtractedValue);
  170. return true;
  171. }
  172. /**
  173. * @dev Moves tokens `amount` from `sender` to `recipient`.
  174. *
  175. * This is internal function is equivalent to {transfer}, and can be used to
  176. * e.g. implement automatic token fees, slashing mechanisms, etc.
  177. *
  178. * Emits a {Transfer} event.
  179. *
  180. * Requirements:
  181. *
  182. * - `sender` cannot be the zero address.
  183. * - `recipient` cannot be the zero address.
  184. * - `sender` must have a balance of at least `amount`.
  185. */
  186. function _transfer(address sender, address recipient, uint256 amount) internal virtual {
  187. require(sender != address(0), "ERC20: transfer from the zero address");
  188. require(recipient != address(0), "ERC20: transfer to the zero address");
  189. _beforeTokenTransfer(sender, recipient, amount);
  190. _balances[sender] = _balances[sender] - amount;
  191. _balances[recipient] = _balances[recipient] + amount;
  192. emit Transfer(sender, recipient, amount);
  193. }
  194. /** @dev Creates `amount` tokens and assigns them to `account`, increasing
  195. * the total supply.
  196. *
  197. * Emits a {Transfer} event with `from` set to the zero address.
  198. *
  199. * Requirements:
  200. *
  201. * - `to` cannot be the zero address.
  202. */
  203. function _mint(address account, uint256 amount) internal virtual {
  204. require(account != address(0), "ERC20: mint to the zero address");
  205. _beforeTokenTransfer(address(0), account, amount);
  206. _totalSupply = _totalSupply + amount;
  207. _balances[account] = _balances[account] + amount;
  208. emit Transfer(address(0), account, amount);
  209. }
  210. /**
  211. * @dev Destroys `amount` tokens from `account`, reducing the
  212. * total supply.
  213. *
  214. * Emits a {Transfer} event with `to` set to the zero address.
  215. *
  216. * Requirements:
  217. *
  218. * - `account` cannot be the zero address.
  219. * - `account` must have at least `amount` tokens.
  220. */
  221. function _burn(address account, uint256 amount) internal virtual {
  222. require(account != address(0), "ERC20: burn from the zero address");
  223. _beforeTokenTransfer(account, address(0), amount);
  224. _balances[account] = _balances[account] - amount;
  225. _totalSupply = _totalSupply - amount;
  226. emit Transfer(account, address(0), amount);
  227. }
  228. /**
  229. * @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens.
  230. *
  231. * This internal function is equivalent to `approve`, and can be used to
  232. * e.g. set automatic allowances for certain subsystems, etc.
  233. *
  234. * Emits an {Approval} event.
  235. *
  236. * Requirements:
  237. *
  238. * - `owner` cannot be the zero address.
  239. * - `spender` cannot be the zero address.
  240. */
  241. function _approve(address owner, address spender, uint256 amount) internal virtual {
  242. require(owner != address(0), "ERC20: approve from the zero address");
  243. require(spender != address(0), "ERC20: approve to the zero address");
  244. _allowances[owner][spender] = amount;
  245. emit Approval(owner, spender, amount);
  246. }
  247. /**
  248. * @dev Sets {decimals} to a value other than the default one of 18.
  249. *
  250. * WARNING: This function should only be called from the constructor. Most
  251. * applications that interact with token contracts will not expect
  252. * {decimals} to ever change, and may work incorrectly if it does.
  253. */
  254. function _setupDecimals(uint8 decimals_) internal virtual {
  255. _decimals = decimals_;
  256. }
  257. /**
  258. * @dev Hook that is called before any transfer of tokens. This includes
  259. * minting and burning.
  260. *
  261. * Calling conditions:
  262. *
  263. * - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
  264. * will be to transferred to `to`.
  265. * - when `from` is zero, `amount` tokens will be minted for `to`.
  266. * - when `to` is zero, `amount` of ``from``'s tokens will be burned.
  267. * - `from` and `to` are never both zero.
  268. *
  269. * To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
  270. */
  271. function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual { }
  272. }