ERC20.sol 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342
  1. // SPDX-License-Identifier: MIT
  2. // OpenZeppelin Contracts (last updated v4.7.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. *
  13. * TIP: For a detailed writeup see our guide
  14. * https://forum.openzeppelin.com/t/how-to-implement-erc20-supply-mechanisms/226[How
  15. * to implement supply mechanisms].
  16. *
  17. * We have followed general OpenZeppelin Contracts guidelines: functions revert
  18. * instead returning `false` on failure. This behavior is nonetheless
  19. * conventional and does not conflict with the expectations of ERC20
  20. * applications.
  21. *
  22. * Additionally, an {Approval} event is emitted on calls to {transferFrom}.
  23. * This allows applications to reconstruct the allowance for all accounts just
  24. * by listening to said events. Other implementations of the EIP may not emit
  25. * these events, as it isn't required by the specification.
  26. *
  27. * Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
  28. * functions have been added to mitigate the well-known issues around setting
  29. * allowances. See {IERC20-approve}.
  30. */
  31. contract ERC20 is Context, IERC20, IERC20Metadata {
  32. mapping(address => uint256) private _balances;
  33. mapping(address => mapping(address => uint256)) private _allowances;
  34. uint256 private _totalSupply;
  35. string private _name;
  36. string private _symbol;
  37. /**
  38. * @dev Sets the values for {name} and {symbol}.
  39. *
  40. * The default value of {decimals} is 18. To select a different value for
  41. * {decimals} you should overload it.
  42. *
  43. * All two of these values are immutable: they can only be set once during
  44. * construction.
  45. */
  46. constructor(string memory name_, string memory symbol_) {
  47. _name = name_;
  48. _symbol = symbol_;
  49. }
  50. /**
  51. * @dev Returns the name of the token.
  52. */
  53. function name() public view virtual override 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 override 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 this function is
  70. * overridden;
  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 override returns (uint8) {
  77. return 18;
  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. * - `to` cannot be the zero address.
  97. * - the caller must have a balance of at least `amount`.
  98. */
  99. function transfer(address to, uint256 amount) public virtual override returns (bool) {
  100. address owner = _msgSender();
  101. _transfer(owner, to, amount);
  102. return true;
  103. }
  104. /**
  105. * @dev See {IERC20-allowance}.
  106. */
  107. function allowance(address owner, address spender) public view virtual override returns (uint256) {
  108. return _allowances[owner][spender];
  109. }
  110. /**
  111. * @dev See {IERC20-approve}.
  112. *
  113. * NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on
  114. * `transferFrom`. This is semantically equivalent to an infinite approval.
  115. *
  116. * Requirements:
  117. *
  118. * - `spender` cannot be the zero address.
  119. */
  120. function approve(address spender, uint256 amount) public virtual override returns (bool) {
  121. address owner = _msgSender();
  122. _approve(owner, spender, amount);
  123. return true;
  124. }
  125. /**
  126. * @dev See {IERC20-transferFrom}.
  127. *
  128. * Emits an {Approval} event indicating the updated allowance. This is not
  129. * required by the EIP. See the note at the beginning of {ERC20}.
  130. *
  131. * NOTE: Does not update the allowance if the current allowance
  132. * is the maximum `uint256`.
  133. *
  134. * Requirements:
  135. *
  136. * - `from` and `to` cannot be the zero address.
  137. * - `from` must have a balance of at least `amount`.
  138. * - the caller must have allowance for ``from``'s tokens of at least
  139. * `amount`.
  140. */
  141. function transferFrom(
  142. address from,
  143. address to,
  144. uint256 amount
  145. ) public virtual override returns (bool) {
  146. address spender = _msgSender();
  147. _spendAllowance(from, spender, amount);
  148. _transfer(from, to, amount);
  149. return true;
  150. }
  151. /**
  152. * @dev Atomically increases the allowance granted to `spender` by the caller.
  153. *
  154. * This is an alternative to {approve} that can be used as a mitigation for
  155. * problems described in {IERC20-approve}.
  156. *
  157. * Emits an {Approval} event indicating the updated allowance.
  158. *
  159. * Requirements:
  160. *
  161. * - `spender` cannot be the zero address.
  162. */
  163. function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
  164. address owner = _msgSender();
  165. _approve(owner, spender, allowance(owner, spender) + addedValue);
  166. return true;
  167. }
  168. /**
  169. * @dev Atomically decreases the allowance granted to `spender` by the caller.
  170. *
  171. * This is an alternative to {approve} that can be used as a mitigation for
  172. * problems described in {IERC20-approve}.
  173. *
  174. * Emits an {Approval} event indicating the updated allowance.
  175. *
  176. * Requirements:
  177. *
  178. * - `spender` cannot be the zero address.
  179. * - `spender` must have allowance for the caller of at least
  180. * `subtractedValue`.
  181. */
  182. function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
  183. address owner = _msgSender();
  184. uint256 currentAllowance = allowance(owner, spender);
  185. require(currentAllowance >= subtractedValue, "ERC20: decreased allowance below zero");
  186. unchecked {
  187. _approve(owner, spender, currentAllowance - subtractedValue);
  188. }
  189. return true;
  190. }
  191. /**
  192. * @dev Moves `amount` of tokens from `from` to `to`.
  193. *
  194. * This internal function is equivalent to {transfer}, and can be used to
  195. * e.g. implement automatic token fees, slashing mechanisms, etc.
  196. *
  197. * Emits a {Transfer} event.
  198. *
  199. * NOTE: This function is not virtual, {_update} should be overridden instead.
  200. */
  201. function _transfer(
  202. address from,
  203. address to,
  204. uint256 amount
  205. ) internal {
  206. require(from != address(0), "ERC20: transfer from the zero address");
  207. require(to != address(0), "ERC20: transfer to the zero address");
  208. _update(from, to, amount);
  209. }
  210. /**
  211. * @dev Transfers `amount` of tokens from `from` to `to`, or alternatively mints (or burns) if `from` (or `to`) is
  212. * the zero address. All customizations to transfers, mints, and burns should be done by overriding this function.
  213. *
  214. * Emits a {Transfer} event.
  215. */
  216. function _update(
  217. address from,
  218. address to,
  219. uint256 amount
  220. ) internal virtual {
  221. if (from == address(0)) {
  222. _totalSupply += amount;
  223. unchecked {
  224. // Overflow not possible: balance + amount is at most totalSupply + amount, which is checked above.
  225. _balances[to] += amount;
  226. }
  227. } else if (to == address(0)) {
  228. uint256 fromBalance = _balances[from];
  229. require(fromBalance >= amount, "ERC20: burn amount exceeds balance");
  230. _totalSupply -= amount;
  231. unchecked {
  232. // Overflow not possible: amount <= fromBalance <= totalSupply.
  233. _balances[from] = fromBalance - amount;
  234. }
  235. } else {
  236. uint256 fromBalance = _balances[from];
  237. require(fromBalance >= amount, "ERC20: transfer amount exceeds balance");
  238. unchecked {
  239. _balances[from] = fromBalance - amount;
  240. // Overflow not possible: the sum of all balances is capped by totalSupply, and the sum is preserved by
  241. // decrementing then incrementing.
  242. _balances[to] += amount;
  243. }
  244. }
  245. emit Transfer(from, to, amount);
  246. }
  247. /**
  248. * @dev Creates `amount` tokens and assigns them to `account`, by transferring it from address(0).
  249. * Relies on the `_update` mechanism
  250. *
  251. * Emits a {Transfer} event with `from` set to the zero address.
  252. *
  253. * NOTE: This function is not virtual, {_update} should be overridden instead.
  254. */
  255. function _mint(address account, uint256 amount) internal {
  256. require(account != address(0), "ERC20: mint to the zero address");
  257. _update(address(0), account, amount);
  258. }
  259. /**
  260. * @dev Destroys `amount` tokens from `account`, by transferring it to address(0).
  261. * Relies on the `_update` mechanism.
  262. *
  263. * Emits a {Transfer} event with `to` set to the zero address.
  264. *
  265. * NOTE: This function is not virtual, {_update} should be overridden instead
  266. */
  267. function _burn(address account, uint256 amount) internal {
  268. require(account != address(0), "ERC20: burn from the zero address");
  269. _update(account, address(0), amount);
  270. }
  271. /**
  272. * @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens.
  273. *
  274. * This internal function is equivalent to `approve`, and can be used to
  275. * e.g. set automatic allowances for certain subsystems, etc.
  276. *
  277. * Emits an {Approval} event.
  278. *
  279. * Requirements:
  280. *
  281. * - `owner` cannot be the zero address.
  282. * - `spender` cannot be the zero address.
  283. */
  284. function _approve(
  285. address owner,
  286. address spender,
  287. uint256 amount
  288. ) internal virtual {
  289. require(owner != address(0), "ERC20: approve from the zero address");
  290. require(spender != address(0), "ERC20: approve to the zero address");
  291. _allowances[owner][spender] = amount;
  292. emit Approval(owner, spender, amount);
  293. }
  294. /**
  295. * @dev Updates `owner` s allowance for `spender` based on spent `amount`.
  296. *
  297. * Does not update the allowance amount in case of infinite allowance.
  298. * Revert if not enough allowance is available.
  299. *
  300. * Might emit an {Approval} event.
  301. */
  302. function _spendAllowance(
  303. address owner,
  304. address spender,
  305. uint256 amount
  306. ) internal virtual {
  307. uint256 currentAllowance = allowance(owner, spender);
  308. if (currentAllowance != type(uint256).max) {
  309. require(currentAllowance >= amount, "ERC20: insufficient allowance");
  310. unchecked {
  311. _approve(owner, spender, currentAllowance - amount);
  312. }
  313. }
  314. }
  315. }