ERC20.sol 12 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383
  1. // SPDX-License-Identifier: MIT
  2. // OpenZeppelin Contracts (last updated v4.6.0) (token/ERC20/ERC20.sol)
  3. pragma solidity ^0.8.0;
  4. import "./IERC20.sol";
  5. import "./extensions/IERC20Metadata.sol";
  6. import "../../utils/Context.sol";
  7. /**
  8. * @dev Implementation of the {IERC20} interface.
  9. *
  10. * This implementation is agnostic to the way tokens are created. This means
  11. * that a supply mechanism has to be added in a derived contract using {_mint}.
  12. * For a generic mechanism see {ERC20PresetMinterPauser}.
  13. *
  14. * TIP: For a detailed writeup see our guide
  15. * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How
  16. * to implement supply mechanisms].
  17. *
  18. * We have followed general OpenZeppelin Contracts guidelines: functions revert
  19. * instead returning `false` on failure. This behavior is nonetheless
  20. * conventional and does not conflict with the expectations of ERC20
  21. * applications.
  22. *
  23. * Additionally, an {Approval} event is emitted on calls to {transferFrom}.
  24. * This allows applications to reconstruct the allowance for all accounts just
  25. * by listening to said events. Other implementations of the EIP may not emit
  26. * these events, as it isn't required by the specification.
  27. *
  28. * Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
  29. * functions have been added to mitigate the well-known issues around setting
  30. * allowances. See {IERC20-approve}.
  31. */
  32. contract ERC20 is Context, IERC20, IERC20Metadata {
  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. /**
  39. * @dev Sets the values for {name} and {symbol}.
  40. *
  41. * The default value of {decimals} is 18. To select a different value for
  42. * {decimals} you should overload it.
  43. *
  44. * All two of these values are immutable: they can only be set once during
  45. * construction.
  46. */
  47. constructor(string memory name_, string memory symbol_) {
  48. _name = name_;
  49. _symbol = symbol_;
  50. }
  51. /**
  52. * @dev Returns the name of the token.
  53. */
  54. function name() public view virtual override returns (string memory) {
  55. return _name;
  56. }
  57. /**
  58. * @dev Returns the symbol of the token, usually a shorter version of the
  59. * name.
  60. */
  61. function symbol() public view virtual override returns (string memory) {
  62. return _symbol;
  63. }
  64. /**
  65. * @dev Returns the number of decimals used to get its user representation.
  66. * For example, if `decimals` equals `2`, a balance of `505` tokens should
  67. * be displayed to a user as `5.05` (`505 / 10 ** 2`).
  68. *
  69. * Tokens usually opt for a value of 18, imitating the relationship between
  70. * Ether and Wei. This is the value {ERC20} uses, unless this function is
  71. * overridden;
  72. *
  73. * NOTE: This information is only used for _display_ purposes: it in
  74. * no way affects any of the arithmetic of the contract, including
  75. * {IERC20-balanceOf} and {IERC20-transfer}.
  76. */
  77. function decimals() public view virtual override returns (uint8) {
  78. return 18;
  79. }
  80. /**
  81. * @dev See {IERC20-totalSupply}.
  82. */
  83. function totalSupply() public view virtual override returns (uint256) {
  84. return _totalSupply;
  85. }
  86. /**
  87. * @dev See {IERC20-balanceOf}.
  88. */
  89. function balanceOf(address account) public view virtual override returns (uint256) {
  90. return _balances[account];
  91. }
  92. /**
  93. * @dev See {IERC20-transfer}.
  94. *
  95. * Requirements:
  96. *
  97. * - `to` cannot be the zero address.
  98. * - the caller must have a balance of at least `amount`.
  99. */
  100. function transfer(address to, uint256 amount) public virtual override returns (bool) {
  101. address owner = _msgSender();
  102. _transfer(owner, to, amount);
  103. return true;
  104. }
  105. /**
  106. * @dev See {IERC20-allowance}.
  107. */
  108. function allowance(address owner, address spender) public view virtual override returns (uint256) {
  109. return _allowances[owner][spender];
  110. }
  111. /**
  112. * @dev See {IERC20-approve}.
  113. *
  114. * NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on
  115. * `transferFrom`. This is semantically equivalent to an infinite approval.
  116. *
  117. * Requirements:
  118. *
  119. * - `spender` cannot be the zero address.
  120. */
  121. function approve(address spender, uint256 amount) public virtual override returns (bool) {
  122. address owner = _msgSender();
  123. _approve(owner, spender, amount);
  124. return true;
  125. }
  126. /**
  127. * @dev See {IERC20-transferFrom}.
  128. *
  129. * Emits an {Approval} event indicating the updated allowance. This is not
  130. * required by the EIP. See the note at the beginning of {ERC20}.
  131. *
  132. * NOTE: Does not update the allowance if the current allowance
  133. * is the maximum `uint256`.
  134. *
  135. * Requirements:
  136. *
  137. * - `from` and `to` cannot be the zero address.
  138. * - `from` must have a balance of at least `amount`.
  139. * - the caller must have allowance for ``from``'s tokens of at least
  140. * `amount`.
  141. */
  142. function transferFrom(
  143. address from,
  144. address to,
  145. uint256 amount
  146. ) public virtual override returns (bool) {
  147. address spender = _msgSender();
  148. _spendAllowance(from, spender, amount);
  149. _transfer(from, to, amount);
  150. return true;
  151. }
  152. /**
  153. * @dev Atomically increases the allowance granted to `spender` by the caller.
  154. *
  155. * This is an alternative to {approve} that can be used as a mitigation for
  156. * problems described in {IERC20-approve}.
  157. *
  158. * Emits an {Approval} event indicating the updated allowance.
  159. *
  160. * Requirements:
  161. *
  162. * - `spender` cannot be the zero address.
  163. */
  164. function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
  165. address owner = _msgSender();
  166. _approve(owner, spender, allowance(owner, spender) + addedValue);
  167. return true;
  168. }
  169. /**
  170. * @dev Atomically decreases the allowance granted to `spender` by the caller.
  171. *
  172. * This is an alternative to {approve} that can be used as a mitigation for
  173. * problems described in {IERC20-approve}.
  174. *
  175. * Emits an {Approval} event indicating the updated allowance.
  176. *
  177. * Requirements:
  178. *
  179. * - `spender` cannot be the zero address.
  180. * - `spender` must have allowance for the caller of at least
  181. * `subtractedValue`.
  182. */
  183. function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
  184. address owner = _msgSender();
  185. uint256 currentAllowance = allowance(owner, spender);
  186. require(currentAllowance >= subtractedValue, "ERC20: decreased allowance below zero");
  187. unchecked {
  188. _approve(owner, spender, currentAllowance - subtractedValue);
  189. }
  190. return true;
  191. }
  192. /**
  193. * @dev Moves `amount` of tokens from `sender` to `recipient`.
  194. *
  195. * This internal function is equivalent to {transfer}, and can be used to
  196. * e.g. implement automatic token fees, slashing mechanisms, etc.
  197. *
  198. * Emits a {Transfer} event.
  199. *
  200. * Requirements:
  201. *
  202. * - `from` cannot be the zero address.
  203. * - `to` cannot be the zero address.
  204. * - `from` must have a balance of at least `amount`.
  205. */
  206. function _transfer(
  207. address from,
  208. address to,
  209. uint256 amount
  210. ) internal virtual {
  211. require(from != address(0), "ERC20: transfer from the zero address");
  212. require(to != address(0), "ERC20: transfer to the zero address");
  213. _beforeTokenTransfer(from, to, amount);
  214. uint256 fromBalance = _balances[from];
  215. require(fromBalance >= amount, "ERC20: transfer amount exceeds balance");
  216. unchecked {
  217. _balances[from] = fromBalance - amount;
  218. }
  219. _balances[to] += amount;
  220. emit Transfer(from, to, amount);
  221. _afterTokenTransfer(from, to, amount);
  222. }
  223. /** @dev Creates `amount` tokens and assigns them to `account`, increasing
  224. * the total supply.
  225. *
  226. * Emits a {Transfer} event with `from` set to the zero address.
  227. *
  228. * Requirements:
  229. *
  230. * - `account` cannot be the zero address.
  231. */
  232. function _mint(address account, uint256 amount) internal virtual {
  233. require(account != address(0), "ERC20: mint to the zero address");
  234. _beforeTokenTransfer(address(0), account, amount);
  235. _totalSupply += amount;
  236. _balances[account] += amount;
  237. emit Transfer(address(0), account, amount);
  238. _afterTokenTransfer(address(0), account, amount);
  239. }
  240. /**
  241. * @dev Destroys `amount` tokens from `account`, reducing the
  242. * total supply.
  243. *
  244. * Emits a {Transfer} event with `to` set to the zero address.
  245. *
  246. * Requirements:
  247. *
  248. * - `account` cannot be the zero address.
  249. * - `account` must have at least `amount` tokens.
  250. */
  251. function _burn(address account, uint256 amount) internal virtual {
  252. require(account != address(0), "ERC20: burn from the zero address");
  253. _beforeTokenTransfer(account, address(0), amount);
  254. uint256 accountBalance = _balances[account];
  255. require(accountBalance >= amount, "ERC20: burn amount exceeds balance");
  256. unchecked {
  257. _balances[account] = accountBalance - amount;
  258. }
  259. _totalSupply -= amount;
  260. emit Transfer(account, address(0), amount);
  261. _afterTokenTransfer(account, address(0), amount);
  262. }
  263. /**
  264. * @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens.
  265. *
  266. * This internal function is equivalent to `approve`, and can be used to
  267. * e.g. set automatic allowances for certain subsystems, etc.
  268. *
  269. * Emits an {Approval} event.
  270. *
  271. * Requirements:
  272. *
  273. * - `owner` cannot be the zero address.
  274. * - `spender` cannot be the zero address.
  275. */
  276. function _approve(
  277. address owner,
  278. address spender,
  279. uint256 amount
  280. ) internal virtual {
  281. require(owner != address(0), "ERC20: approve from the zero address");
  282. require(spender != address(0), "ERC20: approve to the zero address");
  283. _allowances[owner][spender] = amount;
  284. emit Approval(owner, spender, amount);
  285. }
  286. /**
  287. * @dev Updates `owner` s allowance for `spender` based on spent `amount`.
  288. *
  289. * Does not update the allowance amount in case of infinite allowance.
  290. * Revert if not enough allowance is available.
  291. *
  292. * Might emit an {Approval} event.
  293. */
  294. function _spendAllowance(
  295. address owner,
  296. address spender,
  297. uint256 amount
  298. ) internal virtual {
  299. uint256 currentAllowance = allowance(owner, spender);
  300. if (currentAllowance != type(uint256).max) {
  301. require(currentAllowance >= amount, "ERC20: insufficient allowance");
  302. unchecked {
  303. _approve(owner, spender, currentAllowance - amount);
  304. }
  305. }
  306. }
  307. /**
  308. * @dev Hook that is called before any transfer of tokens. This includes
  309. * minting and burning.
  310. *
  311. * Calling conditions:
  312. *
  313. * - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
  314. * will be transferred to `to`.
  315. * - when `from` is zero, `amount` tokens will be minted for `to`.
  316. * - when `to` is zero, `amount` of ``from``'s tokens will be burned.
  317. * - `from` and `to` are never both zero.
  318. *
  319. * To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
  320. */
  321. function _beforeTokenTransfer(
  322. address from,
  323. address to,
  324. uint256 amount
  325. ) internal virtual {}
  326. /**
  327. * @dev Hook that is called after any transfer of tokens. This includes
  328. * minting and burning.
  329. *
  330. * Calling conditions:
  331. *
  332. * - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
  333. * has been transferred to `to`.
  334. * - when `from` is zero, `amount` tokens have been minted for `to`.
  335. * - when `to` is zero, `amount` of ``from``'s tokens have been burned.
  336. * - `from` and `to` are never both zero.
  337. *
  338. * To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
  339. */
  340. function _afterTokenTransfer(
  341. address from,
  342. address to,
  343. uint256 amount
  344. ) internal virtual {}
  345. }