ERC20Upgradeable.sol 13 KB

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