ERC20.sol 13 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366
  1. // SPDX-License-Identifier: MIT
  2. // OpenZeppelin Contracts (last updated v4.9.0) (token/ERC20/ERC20.sol)
  3. pragma solidity ^0.8.19;
  4. import "./IERC20.sol";
  5. import "./extensions/IERC20Metadata.sol";
  6. import "../../utils/Context.sol";
  7. import "../../interfaces/draft-IERC6093.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. *
  14. * TIP: For a detailed writeup see our guide
  15. * https://forum.openzeppelin.com/t/how-to-implement-erc20-supply-mechanisms/226[How
  16. * to implement supply mechanisms].
  17. *
  18. * The default value of {decimals} is 18. To change this, you should override
  19. * this function so it returns a different value.
  20. *
  21. * We have followed general OpenZeppelin Contracts guidelines: functions revert
  22. * instead returning `false` on failure. This behavior is nonetheless
  23. * conventional and does not conflict with the expectations of ERC20
  24. * applications.
  25. *
  26. * Additionally, an {Approval} event is emitted on calls to {transferFrom}.
  27. * This allows applications to reconstruct the allowance for all accounts just
  28. * by listening to said events. Other implementations of the EIP may not emit
  29. * these events, as it isn't required by the specification.
  30. *
  31. * Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
  32. * functions have been added to mitigate the well-known issues around setting
  33. * allowances. See {IERC20-approve}.
  34. */
  35. abstract contract ERC20 is Context, IERC20, IERC20Metadata, IERC20Errors {
  36. mapping(address => uint256) private _balances;
  37. mapping(address => mapping(address => uint256)) private _allowances;
  38. uint256 private _totalSupply;
  39. string private _name;
  40. string private _symbol;
  41. /**
  42. * @dev Indicates a failed `decreaseAllowance` request.
  43. */
  44. error ERC20FailedDecreaseAllowance(address spender, uint256 currentAllowance, uint256 requestedDecrease);
  45. /**
  46. * @dev Sets the values for {name} and {symbol}.
  47. *
  48. * All two of these values are immutable: they can only be set once during
  49. * construction.
  50. */
  51. constructor(string memory name_, string memory symbol_) {
  52. _name = name_;
  53. _symbol = symbol_;
  54. }
  55. /**
  56. * @dev Returns the name of the token.
  57. */
  58. function name() public view virtual 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 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 default value returned by this function, unless
  75. * it's 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 returns (uint8) {
  82. return 18;
  83. }
  84. /**
  85. * @dev See {IERC20-totalSupply}.
  86. */
  87. function totalSupply() public view virtual returns (uint256) {
  88. return _totalSupply;
  89. }
  90. /**
  91. * @dev See {IERC20-balanceOf}.
  92. */
  93. function balanceOf(address account) public view virtual returns (uint256) {
  94. return _balances[account];
  95. }
  96. /**
  97. * @dev See {IERC20-transfer}.
  98. *
  99. * Requirements:
  100. *
  101. * - `to` cannot be the zero address.
  102. * - the caller must have a balance of at least `amount`.
  103. */
  104. function transfer(address to, uint256 amount) public virtual returns (bool) {
  105. address owner = _msgSender();
  106. _transfer(owner, to, amount);
  107. return true;
  108. }
  109. /**
  110. * @dev See {IERC20-allowance}.
  111. */
  112. function allowance(address owner, address spender) public view virtual returns (uint256) {
  113. return _allowances[owner][spender];
  114. }
  115. /**
  116. * @dev See {IERC20-approve}.
  117. *
  118. * NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on
  119. * `transferFrom`. This is semantically equivalent to an infinite approval.
  120. *
  121. * Requirements:
  122. *
  123. * - `spender` cannot be the zero address.
  124. */
  125. function approve(address spender, uint256 amount) public virtual returns (bool) {
  126. address owner = _msgSender();
  127. _approve(owner, spender, amount);
  128. return true;
  129. }
  130. /**
  131. * @dev See {IERC20-transferFrom}.
  132. *
  133. * Emits an {Approval} event indicating the updated allowance. This is not
  134. * required by the EIP. See the note at the beginning of {ERC20}.
  135. *
  136. * NOTE: Does not update the allowance if the current allowance
  137. * is the maximum `uint256`.
  138. *
  139. * Requirements:
  140. *
  141. * - `from` and `to` cannot be the zero address.
  142. * - `from` must have a balance of at least `amount`.
  143. * - the caller must have allowance for ``from``'s tokens of at least
  144. * `amount`.
  145. */
  146. function transferFrom(address from, address to, uint256 amount) public virtual 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. * `requestedDecrease`.
  182. */
  183. function decreaseAllowance(address spender, uint256 requestedDecrease) public virtual returns (bool) {
  184. address owner = _msgSender();
  185. uint256 currentAllowance = allowance(owner, spender);
  186. if (currentAllowance < requestedDecrease) {
  187. revert ERC20FailedDecreaseAllowance(spender, currentAllowance, requestedDecrease);
  188. }
  189. unchecked {
  190. _approve(owner, spender, currentAllowance - requestedDecrease);
  191. }
  192. return true;
  193. }
  194. /**
  195. * @dev Moves `amount` of tokens from `from` to `to`.
  196. *
  197. * This internal function is equivalent to {transfer}, and can be used to
  198. * e.g. implement automatic token fees, slashing mechanisms, etc.
  199. *
  200. * Emits a {Transfer} event.
  201. *
  202. * NOTE: This function is not virtual, {_update} should be overridden instead.
  203. */
  204. function _transfer(address from, address to, uint256 amount) internal {
  205. if (from == address(0)) {
  206. revert ERC20InvalidSender(address(0));
  207. }
  208. if (to == address(0)) {
  209. revert ERC20InvalidReceiver(address(0));
  210. }
  211. _update(from, to, amount);
  212. }
  213. /**
  214. * @dev Transfers `amount` of tokens from `from` to `to`, or alternatively mints (or burns) if `from` (or `to`) is
  215. * the zero address. All customizations to transfers, mints, and burns should be done by overriding this function.
  216. *
  217. * Emits a {Transfer} event.
  218. */
  219. function _update(address from, address to, uint256 amount) internal virtual {
  220. if (from == address(0)) {
  221. _totalSupply += amount;
  222. } else {
  223. uint256 fromBalance = _balances[from];
  224. if (fromBalance < amount) {
  225. revert ERC20InsufficientBalance(from, fromBalance, amount);
  226. }
  227. unchecked {
  228. // Overflow not possible: amount <= fromBalance <= totalSupply.
  229. _balances[from] = fromBalance - amount;
  230. }
  231. }
  232. if (to == address(0)) {
  233. unchecked {
  234. // Overflow not possible: amount <= totalSupply or amount <= fromBalance <= totalSupply.
  235. _totalSupply -= amount;
  236. }
  237. } else {
  238. unchecked {
  239. // Overflow not possible: balance + amount is at most totalSupply, which we know fits into a uint256.
  240. _balances[to] += amount;
  241. }
  242. }
  243. emit Transfer(from, to, amount);
  244. }
  245. /**
  246. * @dev Creates `amount` tokens and assigns them to `account`, by transferring it from address(0).
  247. * Relies on the `_update` mechanism
  248. *
  249. * Emits a {Transfer} event with `from` set to the zero address.
  250. *
  251. * NOTE: This function is not virtual, {_update} should be overridden instead.
  252. */
  253. function _mint(address account, uint256 amount) internal {
  254. if (account == address(0)) {
  255. revert ERC20InvalidReceiver(address(0));
  256. }
  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. if (account == address(0)) {
  269. revert ERC20InvalidSender(address(0));
  270. }
  271. _update(account, address(0), amount);
  272. }
  273. /**
  274. * @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens.
  275. *
  276. * This internal function is equivalent to `approve`, and can be used to
  277. * e.g. set automatic allowances for certain subsystems, etc.
  278. *
  279. * Emits an {Approval} event.
  280. *
  281. * Requirements:
  282. *
  283. * - `owner` cannot be the zero address.
  284. * - `spender` cannot be the zero address.
  285. */
  286. function _approve(address owner, address spender, uint256 amount) internal virtual {
  287. _approve(owner, spender, amount, true);
  288. }
  289. /**
  290. * @dev Alternative version of {_approve} with an optional flag that can enable or disable the Approval event.
  291. *
  292. * By default (when calling {_approve}) the flag is set to true. On the other hand, approval changes made by
  293. * `_spendAllowance` during the `transferFrom` operation set the flag to false. This saves gas by not emitting any
  294. * `Approval` event during `transferFrom` operations.
  295. *
  296. * Anyone who wishes to continue emitting `Approval` events on the`transferFrom` operation can force the flag to true
  297. * using the following override:
  298. * ```
  299. * function _approve(address owner, address spender, uint256 amount, bool) internal virtual override {
  300. * super._approve(owner, spender, amount, true);
  301. * }
  302. * ```
  303. *
  304. * Requirements are the same as {_approve}.
  305. */
  306. function _approve(address owner, address spender, uint256 amount, bool emitEvent) internal virtual {
  307. if (owner == address(0)) {
  308. revert ERC20InvalidApprover(address(0));
  309. }
  310. if (spender == address(0)) {
  311. revert ERC20InvalidSpender(address(0));
  312. }
  313. _allowances[owner][spender] = amount;
  314. if (emitEvent) {
  315. emit Approval(owner, spender, amount);
  316. }
  317. }
  318. /**
  319. * @dev Updates `owner` s allowance for `spender` based on spent `amount`.
  320. *
  321. * Does not update the allowance amount in case of infinite allowance.
  322. * Revert if not enough allowance is available.
  323. *
  324. * Might emit an {Approval} event.
  325. */
  326. function _spendAllowance(address owner, address spender, uint256 amount) internal virtual {
  327. uint256 currentAllowance = allowance(owner, spender);
  328. if (currentAllowance != type(uint256).max) {
  329. if (currentAllowance < amount) {
  330. revert ERC20InsufficientAllowance(spender, currentAllowance, amount);
  331. }
  332. unchecked {
  333. _approve(owner, spender, currentAllowance - amount, false);
  334. }
  335. }
  336. }
  337. }