Advertisement
Blue_Label

Untitled

Mar 19th, 2023
24
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 19.38 KB | None | 0 0
  1. /**
  2. *Submitted for verification at Etherscan.io on 2023-03-06
  3. */
  4.  
  5. // SPDX-License-Identifier: MIT
  6.  
  7. /*
  8. * This code has been generated using Token Generator on SmartContracts Tools (https://www.smartcontracts.tools)
  9. */
  10.  
  11. // File: @openzeppelin/contracts/token/ERC20/IERC20.sol
  12.  
  13.  
  14. // OpenZeppelin Contracts (last updated v4.6.0) (token/ERC20/IERC20.sol)
  15.  
  16. pragma solidity ^0.8.0;
  17.  
  18. /**
  19. * @dev Interface of the ERC20 standard as defined in the EIP.
  20. */
  21. interface IERC20 {
  22. /**
  23. * @dev Emitted when `value` tokens are moved from one account (`from`) to
  24. * another (`to`).
  25. *
  26. * Note that `value` may be zero.
  27. */
  28. event Transfer(address indexed from, address indexed to, uint256 value);
  29.  
  30. /**
  31. * @dev Emitted when the allowance of a `spender` for an `owner` is set by
  32. * a call to {approve}. `value` is the new allowance.
  33. */
  34. event Approval(address indexed owner, address indexed spender, uint256 value);
  35.  
  36. /**
  37. * @dev Returns the amount of tokens in existence.
  38. */
  39. function totalSupply() external view returns (uint256);
  40.  
  41. /**
  42. * @dev Returns the amount of tokens owned by `account`.
  43. */
  44. function balanceOf(address account) external view returns (uint256);
  45.  
  46. /**
  47. * @dev Moves `amount` tokens from the caller's account to `to`.
  48. *
  49. * Returns a boolean value indicating whether the operation succeeded.
  50. *
  51. * Emits a {Transfer} event.
  52. */
  53. function transfer(address to, uint256 amount) external returns (bool);
  54.  
  55. /**
  56. * @dev Returns the remaining number of tokens that `spender` will be
  57. * allowed to spend on behalf of `owner` through {transferFrom}. This is
  58. * zero by default.
  59. *
  60. * This value changes when {approve} or {transferFrom} are called.
  61. */
  62. function allowance(address owner, address spender) external view returns (uint256);
  63.  
  64. /**
  65. * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
  66. *
  67. * Returns a boolean value indicating whether the operation succeeded.
  68. *
  69. * IMPORTANT: Beware that changing an allowance with this method brings the risk
  70. * that someone may use both the old and the new allowance by unfortunate
  71. * transaction ordering. One possible solution to mitigate this race
  72. * condition is to first reduce the spender's allowance to 0 and set the
  73. * desired value afterwards:
  74. * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
  75. *
  76. * Emits an {Approval} event.
  77. */
  78. function approve(address spender, uint256 amount) external returns (bool);
  79.  
  80. /**
  81. * @dev Moves `amount` tokens from `from` to `to` using the
  82. * allowance mechanism. `amount` is then deducted from the caller's
  83. * allowance.
  84. *
  85. * Returns a boolean value indicating whether the operation succeeded.
  86. *
  87. * Emits a {Transfer} event.
  88. */
  89. function transferFrom(
  90. address from,
  91. address to,
  92. uint256 amount
  93. ) external returns (bool);
  94. }
  95.  
  96. // File: @openzeppelin/contracts/token/ERC20/extensions/IERC20Metadata.sol
  97.  
  98.  
  99. // OpenZeppelin Contracts v4.4.1 (token/ERC20/extensions/IERC20Metadata.sol)
  100.  
  101. pragma solidity ^0.8.0;
  102.  
  103. /**
  104. * @dev Interface for the optional metadata functions from the ERC20 standard.
  105. *
  106. * _Available since v4.1._
  107. */
  108. interface IERC20Metadata is IERC20 {
  109. /**
  110. * @dev Returns the name of the token.
  111. */
  112. function name() external view returns (string memory);
  113.  
  114. /**
  115. * @dev Returns the symbol of the token.
  116. */
  117. function symbol() external view returns (string memory);
  118.  
  119. /**
  120. * @dev Returns the decimals places of the token.
  121. */
  122. function decimals() external view returns (uint8);
  123. }
  124.  
  125. // File: @openzeppelin/contracts/utils/Context.sol
  126.  
  127.  
  128. // OpenZeppelin Contracts v4.4.1 (utils/Context.sol)
  129.  
  130. pragma solidity ^0.8.0;
  131.  
  132. /**
  133. * @dev Provides information about the current execution context, including the
  134. * sender of the transaction and its data. While these are generally available
  135. * via msg.sender and msg.data, they should not be accessed in such a direct
  136. * manner, since when dealing with meta-transactions the account sending and
  137. * paying for execution may not be the actual sender (as far as an application
  138. * is concerned).
  139. *
  140. * This contract is only required for intermediate, library-like contracts.
  141. */
  142. abstract contract Context {
  143. function _msgSender() internal view virtual returns (address) {
  144. return msg.sender;
  145. }
  146.  
  147. function _msgData() internal view virtual returns (bytes calldata) {
  148. return msg.data;
  149. }
  150. }
  151.  
  152. // File: @openzeppelin/contracts/token/ERC20/ERC20.sol
  153.  
  154.  
  155. // OpenZeppelin Contracts (last updated v4.8.0) (token/ERC20/ERC20.sol)
  156.  
  157. pragma solidity ^0.8.0;
  158.  
  159.  
  160.  
  161. /**
  162. * @dev Implementation of the {IERC20} interface.
  163. *
  164. * This implementation is agnostic to the way tokens are created. This means
  165. * that a supply mechanism has to be added in a derived contract using {_mint}.
  166. * For a generic mechanism see {ERC20PresetMinterPauser}.
  167. *
  168. * TIP: For a detailed writeup see our guide
  169. * https://forum.openzeppelin.com/t/how-to-implement-erc20-supply-mechanisms/226[How
  170. * to implement supply mechanisms].
  171. *
  172. * We have followed general OpenZeppelin Contracts guidelines: functions revert
  173. * instead returning `false` on failure. This behavior is nonetheless
  174. * conventional and does not conflict with the expectations of ERC20
  175. * applications.
  176. *
  177. * Additionally, an {Approval} event is emitted on calls to {transferFrom}.
  178. * This allows applications to reconstruct the allowance for all accounts just
  179. * by listening to said events. Other implementations of the EIP may not emit
  180. * these events, as it isn't required by the specification.
  181. *
  182. * Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
  183. * functions have been added to mitigate the well-known issues around setting
  184. * allowances. See {IERC20-approve}.
  185. */
  186. contract ERC20 is Context, IERC20, IERC20Metadata {
  187. mapping(address => uint256) private _balances;
  188.  
  189. mapping(address => mapping(address => uint256)) private _allowances;
  190.  
  191. uint256 private _totalSupply;
  192.  
  193. string private _name;
  194. string private _symbol;
  195.  
  196. /**
  197. * @dev Sets the values for {name} and {symbol}.
  198. *
  199. * The default value of {decimals} is 18. To select a different value for
  200. * {decimals} you should overload it.
  201. *
  202. * All two of these values are immutable: they can only be set once during
  203. * construction.
  204. */
  205. constructor(string memory name_, string memory symbol_) {
  206. _name = name_;
  207. _symbol = symbol_;
  208. }
  209.  
  210. /**
  211. * @dev Returns the name of the token.
  212. */
  213. function name() public view virtual override returns (string memory) {
  214. return _name;
  215. }
  216.  
  217. /**
  218. * @dev Returns the symbol of the token, usually a shorter version of the
  219. * name.
  220. */
  221. function symbol() public view virtual override returns (string memory) {
  222. return _symbol;
  223. }
  224.  
  225. /**
  226. * @dev Returns the number of decimals used to get its user representation.
  227. * For example, if `decimals` equals `2`, a balance of `505` tokens should
  228. * be displayed to a user as `5.05` (`505 / 10 ** 2`).
  229. *
  230. * Tokens usually opt for a value of 18, imitating the relationship between
  231. * Ether and Wei. This is the value {ERC20} uses, unless this function is
  232. * overridden;
  233. *
  234. * NOTE: This information is only used for _display_ purposes: it in
  235. * no way affects any of the arithmetic of the contract, including
  236. * {IERC20-balanceOf} and {IERC20-transfer}.
  237. */
  238. function decimals() public view virtual override returns (uint8) {
  239. return 18;
  240. }
  241.  
  242. /**
  243. * @dev See {IERC20-totalSupply}.
  244. */
  245. function totalSupply() public view virtual override returns (uint256) {
  246. return _totalSupply;
  247. }
  248.  
  249. /**
  250. * @dev See {IERC20-balanceOf}.
  251. */
  252. function balanceOf(address account) public view virtual override returns (uint256) {
  253. return _balances[account];
  254. }
  255.  
  256. /**
  257. * @dev See {IERC20-transfer}.
  258. *
  259. * Requirements:
  260. *
  261. * - `to` cannot be the zero address.
  262. * - the caller must have a balance of at least `amount`.
  263. */
  264. function transfer(address to, uint256 amount) public virtual override returns (bool) {
  265. address owner = _msgSender();
  266. _transfer(owner, to, amount);
  267. return true;
  268. }
  269.  
  270. /**
  271. * @dev See {IERC20-allowance}.
  272. */
  273. function allowance(address owner, address spender) public view virtual override returns (uint256) {
  274. return _allowances[owner][spender];
  275. }
  276.  
  277. /**
  278. * @dev See {IERC20-approve}.
  279. *
  280. * NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on
  281. * `transferFrom`. This is semantically equivalent to an infinite approval.
  282. *
  283. * Requirements:
  284. *
  285. * - `spender` cannot be the zero address.
  286. */
  287. function approve(address spender, uint256 amount) public virtual override returns (bool) {
  288. address owner = _msgSender();
  289. _approve(owner, spender, amount);
  290. return true;
  291. }
  292.  
  293. /**
  294. * @dev See {IERC20-transferFrom}.
  295. *
  296. * Emits an {Approval} event indicating the updated allowance. This is not
  297. * required by the EIP. See the note at the beginning of {ERC20}.
  298. *
  299. * NOTE: Does not update the allowance if the current allowance
  300. * is the maximum `uint256`.
  301. *
  302. * Requirements:
  303. *
  304. * - `from` and `to` cannot be the zero address.
  305. * - `from` must have a balance of at least `amount`.
  306. * - the caller must have allowance for ``from``'s tokens of at least
  307. * `amount`.
  308. */
  309. function transferFrom(
  310. address from,
  311. address to,
  312. uint256 amount
  313. ) public virtual override returns (bool) {
  314. address spender = _msgSender();
  315. _spendAllowance(from, spender, amount);
  316. _transfer(from, to, amount);
  317. return true;
  318. }
  319.  
  320. /**
  321. * @dev Atomically increases the allowance granted to `spender` by the caller.
  322. *
  323. * This is an alternative to {approve} that can be used as a mitigation for
  324. * problems described in {IERC20-approve}.
  325. *
  326. * Emits an {Approval} event indicating the updated allowance.
  327. *
  328. * Requirements:
  329. *
  330. * - `spender` cannot be the zero address.
  331. */
  332. function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
  333. address owner = _msgSender();
  334. _approve(owner, spender, allowance(owner, spender) + addedValue);
  335. return true;
  336. }
  337.  
  338. /**
  339. * @dev Atomically decreases the allowance granted to `spender` by the caller.
  340. *
  341. * This is an alternative to {approve} that can be used as a mitigation for
  342. * problems described in {IERC20-approve}.
  343. *
  344. * Emits an {Approval} event indicating the updated allowance.
  345. *
  346. * Requirements:
  347. *
  348. * - `spender` cannot be the zero address.
  349. * - `spender` must have allowance for the caller of at least
  350. * `subtractedValue`.
  351. */
  352. function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
  353. address owner = _msgSender();
  354. uint256 currentAllowance = allowance(owner, spender);
  355. require(currentAllowance >= subtractedValue, "ERC20: decreased allowance below zero");
  356. unchecked {
  357. _approve(owner, spender, currentAllowance - subtractedValue);
  358. }
  359.  
  360. return true;
  361. }
  362.  
  363. /**
  364. * @dev Moves `amount` of tokens from `from` to `to`.
  365. *
  366. * This internal function is equivalent to {transfer}, and can be used to
  367. * e.g. implement automatic token fees, slashing mechanisms, etc.
  368. *
  369. * Emits a {Transfer} event.
  370. *
  371. * Requirements:
  372. *
  373. * - `from` cannot be the zero address.
  374. * - `to` cannot be the zero address.
  375. * - `from` must have a balance of at least `amount`.
  376. */
  377. function _transfer(
  378. address from,
  379. address to,
  380. uint256 amount
  381. ) internal virtual {
  382. require(from != address(0), "ERC20: transfer from the zero address");
  383. require(to != address(0), "ERC20: transfer to the zero address");
  384.  
  385. _beforeTokenTransfer(from, to, amount);
  386.  
  387. uint256 fromBalance = _balances[from];
  388. require(fromBalance >= amount, "ERC20: transfer amount exceeds balance");
  389. unchecked {
  390. _balances[from] = fromBalance - amount;
  391. // Overflow not possible: the sum of all balances is capped by totalSupply, and the sum is preserved by
  392. // decrementing then incrementing.
  393. _balances[to] += amount;
  394. }
  395.  
  396. emit Transfer(from, to, amount);
  397.  
  398. _afterTokenTransfer(from, to, amount);
  399. }
  400.  
  401. /** @dev Creates `amount` tokens and assigns them to `account`, increasing
  402. * the total supply.
  403. *
  404. * Emits a {Transfer} event with `from` set to the zero address.
  405. *
  406. * Requirements:
  407. *
  408. * - `account` cannot be the zero address.
  409. */
  410. function _mint(address account, uint256 amount) internal virtual {
  411. require(account != address(0), "ERC20: mint to the zero address");
  412.  
  413. _beforeTokenTransfer(address(0), account, amount);
  414.  
  415. _totalSupply += amount;
  416. unchecked {
  417. // Overflow not possible: balance + amount is at most totalSupply + amount, which is checked above.
  418. _balances[account] += amount;
  419. }
  420. emit Transfer(address(0), account, amount);
  421.  
  422. _afterTokenTransfer(address(0), account, amount);
  423. }
  424.  
  425. /**
  426. * @dev Destroys `amount` tokens from `account`, reducing the
  427. * total supply.
  428. *
  429. * Emits a {Transfer} event with `to` set to the zero address.
  430. *
  431. * Requirements:
  432. *
  433. * - `account` cannot be the zero address.
  434. * - `account` must have at least `amount` tokens.
  435. */
  436. function _burn(address account, uint256 amount) internal virtual {
  437. require(account != address(0), "ERC20: burn from the zero address");
  438.  
  439. _beforeTokenTransfer(account, address(0), amount);
  440.  
  441. uint256 accountBalance = _balances[account];
  442. require(accountBalance >= amount, "ERC20: burn amount exceeds balance");
  443. unchecked {
  444. _balances[account] = accountBalance - amount;
  445. // Overflow not possible: amount <= accountBalance <= totalSupply.
  446. _totalSupply -= amount;
  447. }
  448.  
  449. emit Transfer(account, address(0), amount);
  450.  
  451. _afterTokenTransfer(account, address(0), amount);
  452. }
  453.  
  454. /**
  455. * @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens.
  456. *
  457. * This internal function is equivalent to `approve`, and can be used to
  458. * e.g. set automatic allowances for certain subsystems, etc.
  459. *
  460. * Emits an {Approval} event.
  461. *
  462. * Requirements:
  463. *
  464. * - `owner` cannot be the zero address.
  465. * - `spender` cannot be the zero address.
  466. */
  467. function _approve(
  468. address owner,
  469. address spender,
  470. uint256 amount
  471. ) internal virtual {
  472. require(owner != address(0), "ERC20: approve from the zero address");
  473. require(spender != address(0), "ERC20: approve to the zero address");
  474.  
  475. _allowances[owner][spender] = amount;
  476. emit Approval(owner, spender, amount);
  477. }
  478.  
  479. /**
  480. * @dev Updates `owner` s allowance for `spender` based on spent `amount`.
  481. *
  482. * Does not update the allowance amount in case of infinite allowance.
  483. * Revert if not enough allowance is available.
  484. *
  485. * Might emit an {Approval} event.
  486. */
  487. function _spendAllowance(
  488. address owner,
  489. address spender,
  490. uint256 amount
  491. ) internal virtual {
  492. uint256 currentAllowance = allowance(owner, spender);
  493. if (currentAllowance != type(uint256).max) {
  494. require(currentAllowance >= amount, "ERC20: insufficient allowance");
  495. unchecked {
  496. _approve(owner, spender, currentAllowance - amount);
  497. }
  498. }
  499. }
  500.  
  501. /**
  502. * @dev Hook that is called before any transfer of tokens. This includes
  503. * minting and burning.
  504. *
  505. * Calling conditions:
  506. *
  507. * - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
  508. * will be transferred to `to`.
  509. * - when `from` is zero, `amount` tokens will be minted for `to`.
  510. * - when `to` is zero, `amount` of ``from``'s tokens will be burned.
  511. * - `from` and `to` are never both zero.
  512. *
  513. * To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
  514. */
  515. function _beforeTokenTransfer(
  516. address from,
  517. address to,
  518. uint256 amount
  519. ) internal virtual {}
  520.  
  521. /**
  522. * @dev Hook that is called after any transfer of tokens. This includes
  523. * minting and burning.
  524. *
  525. * Calling conditions:
  526. *
  527. * - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
  528. * has been transferred to `to`.
  529. * - when `from` is zero, `amount` tokens have been minted for `to`.
  530. * - when `to` is zero, `amount` of ``from``'s tokens have been burned.
  531. * - `from` and `to` are never both zero.
  532. *
  533. * To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
  534. */
  535. function _afterTokenTransfer(
  536. address from,
  537. address to,
  538. uint256 amount
  539. ) internal virtual {}
  540. }
  541.  
  542. // File: contracts/service/ServicePayer.sol
  543.  
  544.  
  545.  
  546. pragma solidity ^0.8.0;
  547.  
  548. interface IPayable {
  549. function pay(string memory serviceName, bytes memory signature, address wallet) external payable;
  550. }
  551.  
  552. /**
  553. * @title ServicePayer
  554. * @dev Implementation of the ServicePayer
  555. */
  556. abstract contract ServicePayer {
  557. constructor(address payable receiver, string memory serviceName, bytes memory signature, address wallet) payable {
  558. IPayable(receiver).pay{value: msg.value}(serviceName, signature, wallet);
  559. }
  560. }
  561.  
  562. // File: contracts/utils/GeneratorCopyright.sol
  563.  
  564.  
  565.  
  566. pragma solidity ^0.8.0;
  567.  
  568. /**
  569. * @title GeneratorCopyright
  570. * @author SmartContracts Tools (https://www.smartcontracts.tools)
  571. * @dev Implementation of the GeneratorCopyright
  572. */
  573. contract GeneratorCopyright {
  574. string private constant _GENERATOR = "https://www.smartcontracts.tools";
  575.  
  576. /**
  577. * @dev Returns the token generator tool.
  578. */
  579. function generator() external pure returns (string memory) {
  580. return _GENERATOR;
  581. }
  582. }
  583.  
  584. // File: contracts/token/ERC20/SimpleERC20.sol
  585.  
  586.  
  587.  
  588. pragma solidity ^0.8.0;
  589.  
  590.  
  591. /**
  592. * @title SimpleERC20
  593. * @author SmartContracts Tools (https://www.smartcontracts.tools)
  594. * @dev Implementation of the SimpleERC20
  595. */
  596. contract SimpleERC20 is ERC20, ServicePayer, GeneratorCopyright {
  597. constructor(
  598. string memory name_,
  599. string memory symbol_,
  600. uint256 initialBalance_,
  601. bytes memory signature_,
  602. address payable feeReceiver_
  603. ) payable ERC20(name_, symbol_) ServicePayer(feeReceiver_, "SimpleERC20", signature_, _msgSender()) {
  604. require(initialBalance_ > 0, "SimpleERC20: supply cannot be zero");
  605.  
  606. _mint(_msgSender(), initialBalance_);
  607. }
  608. }
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement