Revoluzion
Search
K

Simple Token

Revoluzion Simple Token Creation

A Revoluzion simple token is a type of digital asset that represents a unit of value and can be transferred and stored on a blockchain. Revoluzion simple tokens are often used as a medium of exchange, a store of value, or as a way to represent ownership or access to a particular asset or service. They are called "simple" because they have a limited set of features and functionality compared to more complex tokens.
To create a Revoluzion simple token, you would need to deploy it via Revoluzion dApp under token creation and set the properties of the token, such as its name, symbol, and total supply. Once the Revoluzion simple token is deployed to the blockchain, it can be traded and used like any other digital asset.
All Revoluzion tokens created through the Revoluzion token creation dApp will automatically receive an audit badge from our tracker when they create a presale. These tokens can be deployed on any blockchain that is available for deployment in the Revoluzion token creation dApp tab.
The Revoluzion simple token also includes a free audit report and anti-bot feature.
Revoluzion Simple Token Source Code (click here to expand source code)
1
// ██████ ███████ ██ ██ ██████ ██ ██ ██ ███████ ██ ██████ ███ ██ ██ ██████
2
// ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ████ ██ ██ ██ ██
3
// ██████ █████ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██
4
// ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██
5
// ██ ██ ███████ ████ ██████ ███████ ██████ ███████ ██ ██████ ██ ████ ██ ██ ██████
6
7
8
// ███████ ███ ███ █████ ██████ ████████ ██████ ██████ ███ ██ ████████ ██████ █████ ██████ ████████
9
// ██ ████ ████ ██ ██ ██ ██ ██ ██ ██ ██ ████ ██ ██ ██ ██ ██ ██ ██ ██
10
// ███████ ██ ████ ██ ███████ ██████ ██ ██ ██ ██ ██ ██ ██ ██ ██████ ███████ ██ ██
11
// ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
12
// ███████ ██ ██ ██ ██ ██ ██ ██ ██████ ██████ ██ ████ ██ ██ ██ ██ ██  ██████    ██
13
14
//Revoluzion Ecosystem
15
//WEB: https://revoluzion.io
16
//DAPP: https://revoluzion.app
17
18
// SPDX-License-Identifier: MIT
19
pragma solidity ^0.8.16;
20
21
/**
22
* @dev Provides information about the current execution context, including the
23
* sender of the transaction and its data. While these are generally available
24
* via msg.sender and msg.data, they should not be accessed in such a direct
25
* manner, since when dealing with meta-transactions the account sending and
26
* paying for execution may not be the actual sender (as far as an application
27
* is concerned).
28
*
29
* This contract is only required for intermediate, library-like contracts.
30
*/
31
abstract contract Context {
32
function _msgSender() internal view virtual returns (address) {
33
return msg.sender;
34
}
35
}
36
37
/**
38
* @dev Contract module that helps prevent reentrant calls to a function.
39
*
40
* Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier
41
* available, which can be applied to functions to make sure there are no nested
42
* (reentrant) calls to them.
43
*
44
* Note that because there is a single `nonReentrant` guard, functions marked as
45
* `nonReentrant` may not call one another. This can be worked around by making
46
* those functions `private`, and then adding `external` `nonReentrant` entry
47
* points to them.
48
*
49
* TIP: If you would like to learn more about reentrancy and alternative ways
50
* to protect against it, check out our blog post
51
* https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].
52
*/
53
abstract contract ReentrancyGuard {
54
// Booleans are more expensive than uint256 or any type that takes up a full
55
// word because each write operation emits an extra SLOAD to first read the
56
// slot's contents, replace the bits taken up by the boolean, and then write
57
// back. This is the compiler's defense against contract upgrades and
58
// pointer aliasing, and it cannot be disabled.
59
60
// The values being non-zero value makes deployment a bit more expensive,
61
// but in exchange the refund on every call to nonReentrant will be lower in
62
// amount. Since refunds are capped to a percentage of the total
63
// transaction's gas, it is best to keep them low in cases like this one, to
64
// increase the likelihood of the full refund coming into effect.
65
uint256 private constant _NOT_ENTERED = 1;
66
uint256 private constant _ENTERED = 2;
67
68
uint256 private _status;
69
70
constructor() {
71
_status = _NOT_ENTERED;
72
}
73
74
/**
75
* @dev Prevents a contract from calling itself, directly or indirectly.
76
* Calling a `nonReentrant` function from another `nonReentrant`
77
* function is not supported. It is possible to prevent this from happening
78
* by making the `nonReentrant` function external, and making it call a
79
* `private` function that does the actual work.
80
*/
81
modifier nonReentrant() {
82
_nonReentrantBefore();
83
_;
84
_nonReentrantAfter();
85
}
86
87
function _nonReentrantBefore() private {
88
// On the first call to nonReentrant, _status will be _NOT_ENTERED
89
require(_status != _ENTERED, "ReentrancyGuard: reentrant call");
90
91
// Any calls to nonReentrant after this point will fail
92
_status = _ENTERED;
93
}
94
95
function _nonReentrantAfter() private {
96
// By storing the original value once again, a refund is triggered (see
97
// https://eips.ethereum.org/EIPS/eip-2200)
98
_status = _NOT_ENTERED;
99
}
100
}
101
102
/**
103
* @dev Interface of the ERC20 standard as defined in the EIP.
104
*/
105
interface IERC20 {
106
/**
107
* @dev Emitted when `value` tokens are moved from one account (`from`) to
108
* another (`to`).
109
*
110
* Note that `value` may be zero.
111
*/
112
event Transfer(address indexed from, address indexed to, uint256 value);
113
114
/**
115
* @dev Emitted when the allowance of a `spender` for an `owner` is set by
116
* a call to {approve}. `value` is the new allowance.
117
*/
118
event Approval(address indexed owner, address indexed spender, uint256 value);
119
120
/**
121
* @dev Returns the name of the token.
122
*/
123
function name() external view returns (string memory);
124
125
/**
126
* @dev Returns the symbol of the token.
127
*/
128
function symbol() external view returns (string memory);
129
130
/**
131
* @dev Returns the decimals places of the token.
132
*/
133
function decimals() external view returns (uint8);
134
135
/**
136
* @dev Returns the amount of tokens in existence.
137
*/
138
function totalSupply() external view returns (uint256);
139
140
/**
141
* @dev Returns the amount of tokens owned by `account`.
142
*/
143
function balanceOf(address account) external view returns (uint256);
144
145
/**
146
* @dev Moves `amount` tokens from the caller's account to `to`.
147
*
148
* Returns a boolean value indicating whether the operation succeeded.
149
*
150
* Emits a {Transfer} event.
151
*/
152
function transfer(address to, uint256 amount) external returns (bool);
153
154
/**
155
* @dev Returns the remaining number of tokens that `spender` will be
156
* allowed to spend on behalf of `owner` through {transferFrom}. This is
157
* zero by default.
158
*
159
* This value changes when {approve} or {transferFrom} are called.
160
*/
161
function allowance(address owner, address spender) external view returns (uint256);
162
163
/**
164
* @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
165
*
166
* Returns a boolean value indicating whether the operation succeeded.
167
*
168
* IMPORTANT: Beware that changing an allowance with this method brings the risk
169
* that someone may use both the old and the new allowance by unfortunate
170
* transaction ordering. One possible solution to mitigate this race
171
* condition is to first reduce the spender's allowance to 0 and set the
172
* desired value afterwards:
173
* https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
174
*
175
* Emits an {Approval} event.
176
*/
177
function approve(address spender, uint256 amount) external returns (bool);
178
179
/**
180
* @dev Moves `amount` tokens from `from` to `to` using the
181
* allowance mechanism. `amount` is then deducted from the caller's
182
* allowance.
183
*
184
* Returns a boolean value indicating whether the operation succeeded.
185
*
186
* Emits a {Transfer} event.
187
*/
188
function transferFrom(
189
address from,
190
address to,
191
uint256 amount
192
) external returns (bool);
193
}
194
195
/**
196
* @dev Implementation of the {IERC20} interface.
197
*
198
* This implementation is agnostic to the way tokens are created. This means
199
* that a supply mechanism has to be added in a derived contract using {_mint}.
200
* For a generic mechanism see {ERC20PresetMinterPauser}.
201
*
202
* TIP: For a detailed writeup see our guide
203
* https://forum.openzeppelin.com/t/how-to-implement-erc20-supply-mechanisms/226[How
204
* to implement supply mechanisms].
205
*
206
* We have followed general OpenZeppelin Contracts guidelines: functions revert
207
* instead returning `false` on failure. This behavior is nonetheless
208
* conventional and does not conflict with the expectations of ERC20
209
* applications.
210
*
211
* Additionally, an {Approval} event is emitted on calls to {transferFrom}.
212
* This allows applications to reconstruct the allowance for all accounts just
213
* by listening to said events. Other implementations of the EIP may not emit
214
* these events, as it isn't required by the specification.
215
*
216
* Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
217
* functions have been added to mitigate the well-known issues around setting
218
* allowances. See {IERC20-approve}.
219
*/
220
contract ERC20 is Context, IERC20 {
221
mapping(address => uint256) private _balances;
222
223
mapping(address => mapping(address => uint256)) private _allowances;
224
225
uint256 private _totalSupply;
226
227
string private _name;
228
string private _symbol;
229
uint8 private _decimals;
230
231
/**
232
* @dev Sets the values for {name} and {symbol}.
233
*
234
* The default value of {decimals} is 18. To select a different value for
235
* {decimals} you should overload it.
236
*
237
* All two of these values are immutable: they can only be set once during
238
* construction.
239
*/
240
constructor(string memory name_, string memory symbol_, uint8 decimals_, uint256 supplyTotal_) {
241
_name = name_;
242
_symbol = symbol_;
243
_decimals = decimals_;
244
_mint(_msgSender(), supplyTotal_);
245
}
246
247
/**
248
* @dev Returns the name of the token.
249
*/
250
function name() public view virtual override returns (string memory) {
251
return _name;
252
}
253
254
/**
255
* @dev Returns the symbol of the token, usually a shorter version of the
256
* name.
257
*/
258
function symbol() public view virtual override returns (string memory) {
259
return _symbol;
260
}
261
262
/**
263
* @dev Returns the number of decimals used to get its user representation.
264
* For example, if `decimals` equals `2`, a balance of `505` tokens should
265
* be displayed to a user as `5.05` (`505 / 10 ** 2`).
266
*
267
* Tokens usually opt for a value of 18, imitating the relationship between
268
* Ether and Wei. This is the value {ERC20} uses, unless this function is
269
* overridden;
270
*
271
* NOTE: This information is only used for _display_ purposes: it in
272
* no way affects any of the arithmetic of the contract, including
273
* {IERC20-balanceOf} and {IERC20-transfer}.
274
*/
275
function decimals() public view virtual override returns (uint8) {
276
return _decimals;
277
}
278
279
/**
280
* @dev See {IERC20-totalSupply}.
281
*/
282
function totalSupply() public view virtual override returns (uint256) {
283
return _totalSupply;
284
}
285
286
/**
287
* @dev See {IERC20-balanceOf}.
288
*/
289
function balanceOf(address account) public view virtual override returns (uint256) {
290
return _balances[account];
291
}
292
293
/**
294
* @dev See {IERC20-transfer}.
295
*
296
* Requirements:
297
*
298
* - `to` cannot be the zero address.
299
* - the caller must have a balance of at least `amount`.
300
*/
301
function transfer(address to, uint256 amount) public virtual override returns (bool) {
302
address owner = _msgSender();
303
_transfer(owner, to, amount);
304
return true;
305
}
306
307
/**
308
* @dev See {IERC20-allowance}.
309
*/
310
function allowance(address owner, address spender) public view virtual override returns (uint256) {
311
return _allowances[owner][spender];
312
}
313
314
/**
315
* @dev See {IERC20-approve}.
316
*
317
* NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on
318
* `transferFrom`. This is semantically equivalent to an infinite approval.
319
*
320
* Requirements:
321
*
322
* - `spender` cannot be the zero address.
323
*/
324
function approve(address spender, uint256 amount) public virtual override returns (bool) {
325
address owner = _msgSender();
326
_approve(owner, spender, amount);
327
return true;
328
}
329
330
/**
331
* @dev See {IERC20-transferFrom}.
332
*
333
* Emits an {Approval} event indicating the updated allowance. This is not
334
* required by the EIP. See the note at the beginning of {ERC20}.
335
*
336
* NOTE: Does not update the allowance if the current allowance
337
* is the maximum `uint256`.
338
*
339
* Requirements:
340
*
341
* - `from` and `to` cannot be the zero address.
342
* - `from` must have a balance of at least `amount`.
343
* - the caller must have allowance for ``from``'s tokens of at least
344
* `amount`.
345
*/
346
function transferFrom(
347
address from,
348
address to,
349
uint256 amount
350
) public virtual override returns (bool) {
351
address spender = _msgSender();
352
_spendAllowance(from, spender, amount);
353
_transfer(from, to, amount);
354
return true;
355
}
356
357
/**
358
* @dev Atomically increases the allowance granted to `spender` by the caller.
359
*
360
* This is an alternative to {approve} that can be used as a mitigation for
361
* problems described in {IERC20-approve}.
362
*
363
* Emits an {Approval} event indicating the updated allowance.
364
*
365
* Requirements:
366
*
367
* - `spender` cannot be the zero address.
368
*/
369
function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
370
address owner = _msgSender();
371
_approve(owner, spender, allowance(owner, spender) + addedValue);
372
return true;
373
}
374
375
/**
376
* @dev Atomically decreases the allowance granted to `spender` by the caller.
377
*
378
* This is an alternative to {approve} that can be used as a mitigation for
379
* problems described in {IERC20-approve}.
380
*
381
* Emits an {Approval} event indicating the updated allowance.
382
*
383
* Requirements:
384
*
385
* - `spender` cannot be the zero address.
386
* - `spender` must have allowance for the caller of at least
387
* `subtractedValue`.
388
*/
389
function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
390
address owner = _msgSender();
391
uint256 currentAllowance = allowance(owner, spender);
392
require(currentAllowance >= subtractedValue, "ERC20: decreased allowance below zero");
393
unchecked {
394
_approve(owner, spender, currentAllowance - subtractedValue);
395
}
396
397
return true;
398
}
399
400
/**
401
* @dev Moves `amount` of tokens from `from` to `to`.
402
*
403
* This internal function is equivalent to {transfer}, and can be used to
404
* e.g. implement automatic token fees, slashing mechanisms, etc.
405
*
406
* Emits a {Transfer} event.
407
*
408
* Requirements:
409
*
410
* - `from` cannot be the zero address.
411
* - `to` cannot be the zero address.
412
* - `from` must have a balance of at least `amount`.
413
*/
414
function _transfer(
415
address from,
416
address to,
417
uint256 amount
418
) internal virtual {
419
require(from != address(0), "ERC20: transfer from the zero address");
420
require(to != address(0), "ERC20: transfer to the zero address");
421
422
_beforeTokenTransfer(from, to, amount);
423
424
uint256 fromBalance = _balances[from];
425
require(fromBalance >= amount, "ERC20: transfer amount exceeds balance");
426
unchecked {
427
_balances[from] = fromBalance - amount;
428
// Overflow not possible: the sum of all balances is capped by totalSupply, and the sum is preserved by
429
// decrementing then incrementing.
430
_balances[to] += amount;
431
}
432
433
emit Transfer(from, to, amount);
434
435
_afterTokenTransfer(from, to, amount);
436
}
437
438
/** @dev Creates `amount` tokens and assigns them to `account`, increasing
439
* the total supply.
440
*
441
* Emits a {Transfer} event with `from` set to the zero address.
442
*
443
* Requirements:
444
*
445
* - `account` cannot be the zero address.
446
*/
447
function _mint(address account, uint256 amount) internal virtual {
448
require(account != address(0), "ERC20: mint to the zero address");
449
450
_beforeTokenTransfer(address(0), account, amount);
451
452
_totalSupply += amount;
453
unchecked {
454
// Overflow not possible: balance + amount is at most totalSupply + amount, which is checked above.
455
_balances[account] += amount;
456
}
457
emit Transfer(address(0), account, amount);
458
459
_afterTokenTransfer(address(0), account, amount);
460
}
461
462
/**
463
* @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens.
464
*
465
* This internal function is equivalent to `approve`, and can be used to
466
* e.g. set automatic allowances for certain subsystems, etc.
467
*
468
* Emits an {Approval} event.
469
*
470
* Requirements:
471
*
472
* - `owner` cannot be the zero address.
473
* - `spender` cannot be the zero address.
474
*/
475
function _approve(
476
address owner,
477
address spender,
478
uint256 amount
479
) internal virtual {
480
require(owner != address(0), "ERC20: approve from the zero address");
481
require(spender != address(0), "ERC20: approve to the zero address");
482
483
_allowances[owner][spender] = amount;
484
emit Approval(owner, spender, amount);
485
}
486
487
/**
488
* @dev Updates `owner` s allowance for `spender` based on spent `amount`.
489
*
490
* Does not update the allowance amount in case of infinite allowance.
491
* Revert if not enough allowance is available.
492
*
493
* Might emit an {Approval} event.
494
*/
495
function _spendAllowance(
496
address owner,
497
address spender,
498
uint256 amount
499
) internal virtual {
500
uint256 currentAllowance = allowance(owner, spender);
501
if (currentAllowance != type(uint256).max) {
502
require(currentAllowance >= amount, "ERC20: insufficient allowance");
503
unchecked {
504
_approve(owner, spender, currentAllowance - amount);
505
}
506
}
507
}
508
509
/**
510
* @dev Hook that is called before any transfer of tokens. This includes
511
* minting and burning.
512
*
513
* Calling conditions:
514
*
515
* - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
516
* will be transferred to `to`.
517
* - when `from` is zero, `amount` tokens will be minted for `to`.
518
* - when `to` is zero, `amount` of ``from``'s tokens will be burned.
519
* - `from` and `to` are never both zero.
520
*
521
* To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
522
*/
523
function _beforeTokenTransfer(
524
address from,
525
address to,
526
uint256 amount
527
) internal virtual {}
528
529
/**
530
* @dev Hook that is called after any transfer of tokens. This includes
531
* minting and burning.
532
*
533
* Calling conditions:
534
*
535
* - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
536
* has been transferred to `to`.
537
* - when `from` is zero, `amount` tokens have been minted for `to`.
538
* - when `to` is zero, `amount` of ``from``'s tokens have been burned.
539
* - `from` and `to` are never both zero.
540
*
541
* To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
542
*/
543
function _afterTokenTransfer(
544
address from,
545
address to,
546
uint256 amount
547
) internal virtual {}
548
}
549
550
interface ITokenCreationTracker {
551
function createTokenItem(address tokenAddress_, address creatorAddress_, address feeReceiver_, uint256 tokenType_, uint256 creationFee_) external;
552
553
function getFeeReceiver() external view returns (address);
554
555
function getFee() external view returns (uint256);
556
}
557
558
contract SimpleToken is ERC20, ReentrancyGuard {
559
560
// CONSTRUCTOR
561
562
constructor(
563
string memory name,
564
string memory symbol,
565
uint8 decimals,
566
uint256 supplyTotal,
567
ITokenCreationTracker tracker
568
) ERC20(
569
name,
570
symbol,
571
decimals,
572
supplyTotal
573
) payable nonReentrant {
574
payable(tracker.getFeeReceiver()).transfer(tracker.getFee());
575
tracker.createTokenItem(address(this), _msgSender(), tracker.getFeeReceiver(), 0, tracker.getFee());
576
}
577
578
}

Data Inputs

Blockchain Network

  • Binance Smart Chain (Mainnet) - This means you are deploying the token on the live mainnet.
  • Binance Smart Chain (Testnet) - This means you are deploying the token on the Testnet.

Token Type

  • Simple Token - You can select any tokens you wish to deploy from the list

Token Name

  • You can input any token name you desire, do note that to do your research on a name as you can never change it once live on mainnet.
  • The token name is usually set at the time of its creation and cannot be changed afterwards.
  • Disclaimer: Please note that Revoluzion reserves the right to remove any token from its launchpad platform if the token's name is in violation of our naming policy.

Token Symbol

  • Token symbol, also known as a ticker symbol, is a unique abbreviation or code used to identify a specific cryptocurrency or digital asset.
  • The token symbol / ticker is usually set at the time of its creation and cannot be changed afterwards.

Token Decimals

  • Token decimals refer to the number of decimal places used to represent a specific token or cryptocurrency.
  • In most cases, token decimals are set to a value of 18, which allows for a large number of decimal places and enables the token to be divided into very small fractions, just like BNB and Ethereum.
  • For example, a token with 18 decimals could be divided into as small a fraction as 0.000000000000000001 of a unit, while a token with 3 decimals could only be divided into fractions of 0.001 of a unit.
  • If unsure, best is to always select 18 decimals as that is the default decimal point.
  • The token decimal is usually set at the time of its creation and cannot be changed afterwards.

Token Total Supply

  • The total supply of a token refers to the maximum number of units of the token that will ever be created. It is an important aspect of a token's design and can have significant implications for the token's value and utility.
  • The total supply of a token is usually set at the time of its creation and cannot be changed afterwards.
  • The total supply of a token can have a direct impact on its value, as the larger the total supply, the less scarce the token will be and the lower its value may be.