ERC20.sol 11 KB

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