ERC20.sol 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321
  1. // SPDX-License-Identifier: MIT
  2. // OpenZeppelin Contracts (last updated v4.9.0) (token/ERC20/ERC20.sol)
  3. pragma solidity ^0.8.20;
  4. import {IERC20} from "./IERC20.sol";
  5. import {IERC20Metadata} from "./extensions/IERC20Metadata.sol";
  6. import {Context} from "../../utils/Context.sol";
  7. import {IERC20Errors} from "../../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. abstract contract ERC20 is Context, IERC20, IERC20Metadata, IERC20Errors {
  32. mapping(address account => uint256) private _balances;
  33. mapping(address account => mapping(address spender => uint256)) private _allowances;
  34. uint256 private _totalSupply;
  35. string private _name;
  36. string private _symbol;
  37. /**
  38. * @dev Indicates a failed `decreaseAllowance` request.
  39. */
  40. error ERC20FailedDecreaseAllowance(address spender, uint256 currentAllowance, uint256 requestedDecrease);
  41. /**
  42. * @dev Sets the values for {name} and {symbol}.
  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 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 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 default value returned by this function, unless
  71. * it's 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 returns (uint8) {
  78. return 18;
  79. }
  80. /**
  81. * @dev See {IERC20-totalSupply}.
  82. */
  83. function totalSupply() public view virtual returns (uint256) {
  84. return _totalSupply;
  85. }
  86. /**
  87. * @dev See {IERC20-balanceOf}.
  88. */
  89. function balanceOf(address account) public view virtual 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 `value`.
  99. */
  100. function transfer(address to, uint256 value) public virtual returns (bool) {
  101. address owner = _msgSender();
  102. _transfer(owner, to, value);
  103. return true;
  104. }
  105. /**
  106. * @dev See {IERC20-allowance}.
  107. */
  108. function allowance(address owner, address spender) public view virtual returns (uint256) {
  109. return _allowances[owner][spender];
  110. }
  111. /**
  112. * @dev See {IERC20-approve}.
  113. *
  114. * NOTE: If `value` 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 value) public virtual returns (bool) {
  122. address owner = _msgSender();
  123. _approve(owner, spender, value);
  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 `value`.
  139. * - the caller must have allowance for ``from``'s tokens of at least
  140. * `value`.
  141. */
  142. function transferFrom(address from, address to, uint256 value) public virtual returns (bool) {
  143. address spender = _msgSender();
  144. _spendAllowance(from, spender, value);
  145. _transfer(from, to, value);
  146. return true;
  147. }
  148. /**
  149. * @dev Moves a `value` amount of tokens from `from` to `to`.
  150. *
  151. * This internal function is equivalent to {transfer}, and can be used to
  152. * e.g. implement automatic token fees, slashing mechanisms, etc.
  153. *
  154. * Emits a {Transfer} event.
  155. *
  156. * NOTE: This function is not virtual, {_update} should be overridden instead.
  157. */
  158. function _transfer(address from, address to, uint256 value) internal {
  159. if (from == address(0)) {
  160. revert ERC20InvalidSender(address(0));
  161. }
  162. if (to == address(0)) {
  163. revert ERC20InvalidReceiver(address(0));
  164. }
  165. _update(from, to, value);
  166. }
  167. /**
  168. * @dev Transfers a `value` amount of tokens from `from` to `to`, or alternatively mints (or burns) if `from`
  169. * (or `to`) is the zero address. All customizations to transfers, mints, and burns should be done by overriding
  170. * this function.
  171. *
  172. * Emits a {Transfer} event.
  173. */
  174. function _update(address from, address to, uint256 value) internal virtual {
  175. if (from == address(0)) {
  176. // Overflow check required: The rest of the code assumes that totalSupply never overflows
  177. _totalSupply += value;
  178. } else {
  179. uint256 fromBalance = _balances[from];
  180. if (fromBalance < value) {
  181. revert ERC20InsufficientBalance(from, fromBalance, value);
  182. }
  183. unchecked {
  184. // Overflow not possible: value <= fromBalance <= totalSupply.
  185. _balances[from] = fromBalance - value;
  186. }
  187. }
  188. if (to == address(0)) {
  189. unchecked {
  190. // Overflow not possible: value <= totalSupply or value <= fromBalance <= totalSupply.
  191. _totalSupply -= value;
  192. }
  193. } else {
  194. unchecked {
  195. // Overflow not possible: balance + value is at most totalSupply, which we know fits into a uint256.
  196. _balances[to] += value;
  197. }
  198. }
  199. emit Transfer(from, to, value);
  200. }
  201. /**
  202. * @dev Creates a `value` amount of tokens and assigns them to `account`, by transferring it from address(0).
  203. * Relies on the `_update` mechanism
  204. *
  205. * Emits a {Transfer} event with `from` set to the zero address.
  206. *
  207. * NOTE: This function is not virtual, {_update} should be overridden instead.
  208. */
  209. function _mint(address account, uint256 value) internal {
  210. if (account == address(0)) {
  211. revert ERC20InvalidReceiver(address(0));
  212. }
  213. _update(address(0), account, value);
  214. }
  215. /**
  216. * @dev Destroys a `value` amount of tokens from `account`, lowering the total supply.
  217. * Relies on the `_update` mechanism.
  218. *
  219. * Emits a {Transfer} event with `to` set to the zero address.
  220. *
  221. * NOTE: This function is not virtual, {_update} should be overridden instead
  222. */
  223. function _burn(address account, uint256 value) internal {
  224. if (account == address(0)) {
  225. revert ERC20InvalidSender(address(0));
  226. }
  227. _update(account, address(0), value);
  228. }
  229. /**
  230. * @dev Sets `value` as the allowance of `spender` over the `owner` s tokens.
  231. *
  232. * This internal function is equivalent to `approve`, and can be used to
  233. * e.g. set automatic allowances for certain subsystems, etc.
  234. *
  235. * Emits an {Approval} event.
  236. *
  237. * Requirements:
  238. *
  239. * - `owner` cannot be the zero address.
  240. * - `spender` cannot be the zero address.
  241. *
  242. * Overrides to this logic should be done to the variant with an additional `bool emitEvent` argument.
  243. */
  244. function _approve(address owner, address spender, uint256 value) internal {
  245. _approve(owner, spender, value, true);
  246. }
  247. /**
  248. * @dev Variant of {_approve} with an optional flag to enable or disable the {Approval} event.
  249. *
  250. * By default (when calling {_approve}) the flag is set to true. On the other hand, approval changes made by
  251. * `_spendAllowance` during the `transferFrom` operation set the flag to false. This saves gas by not emitting any
  252. * `Approval` event during `transferFrom` operations.
  253. *
  254. * Anyone who wishes to continue emitting `Approval` events on the`transferFrom` operation can force the flag to
  255. * true using the following override:
  256. * ```
  257. * function _approve(address owner, address spender, uint256 value, bool) internal virtual override {
  258. * super._approve(owner, spender, value, true);
  259. * }
  260. * ```
  261. *
  262. * Requirements are the same as {_approve}.
  263. */
  264. function _approve(address owner, address spender, uint256 value, bool emitEvent) internal virtual {
  265. if (owner == address(0)) {
  266. revert ERC20InvalidApprover(address(0));
  267. }
  268. if (spender == address(0)) {
  269. revert ERC20InvalidSpender(address(0));
  270. }
  271. _allowances[owner][spender] = value;
  272. if (emitEvent) {
  273. emit Approval(owner, spender, value);
  274. }
  275. }
  276. /**
  277. * @dev Updates `owner` s allowance for `spender` based on spent `value`.
  278. *
  279. * Does not update the allowance value in case of infinite allowance.
  280. * Revert if not enough allowance is available.
  281. *
  282. * Might emit an {Approval} event.
  283. */
  284. function _spendAllowance(address owner, address spender, uint256 value) internal virtual {
  285. uint256 currentAllowance = allowance(owner, spender);
  286. if (currentAllowance != type(uint256).max) {
  287. if (currentAllowance < value) {
  288. revert ERC20InsufficientAllowance(spender, currentAllowance, value);
  289. }
  290. unchecked {
  291. _approve(owner, spender, currentAllowance - value, false);
  292. }
  293. }
  294. }
  295. }