Revoluzion
Search
K

Airdrop / Multi-Sender Introduction

Revoluzion Airdrop / Multi-Sender

Are you looking for a efficient way to distribute tokens to a large group of people? Revoluzion's airdrop and multisender tool can help! Our airdrop feature allows you to send tokens to multiple wallet addresses simultaneously, saving you time and effort. This is an effective way to increase awareness and adoption of your project.
Our multisender tool offers even more flexibility, allowing you to send different amounts of tokens to multiple addresses at the same time. This can be useful for tailoring your distribution strategy to meet your specific needs.
Don't waste time manually sending tokens to individual addresses – let Revoluzion's airdrop and multisender tools handle the task for you. Try them out today and see the benefits for yourself!

What is The Difference Between Both?

An airdrop is a distribution of a cryptocurrency token or coin, usually for free, to a large number of wallet addresses. Airdrops are typically used as a marketing strategy to increase awareness and promote the adoption of a cryptocurrency or blockchain-based project.
A multi-sender tool, on the other hand, is a tool that allows a user to send different amounts of a cryptocurrency to multiple wallet addresses at the same time. It is similar to an airdrop in that it allows for the distribution of tokens to multiple recipients, but it is generally used for more targeted distribution and is not necessarily done for free.
In summary, an airdrop is a broad distribution of tokens to a large number of recipients, typically for the purpose of marketing and increasing adoption, while a multi-sender tool is a tool that allows for the customized distribution of tokens to multiple recipients.

Revoluzion Airdrop / Multi-Sender Source Code

Source Code
1
/**
2
*Submitted for verification at BscScan.com on 2022-12-23
3
*/
4
5
// ██████ ███████ ██ ██ ██████ ██ ██ ██ ███████ ██ ██████ ███ ██ ██ ██████
6
// ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ████ ██ ██ ██ ██
7
// ██████ █████ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██
8
// ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██
9
// ██ ██ ███████ ████ ██████ ███████ ██████ ███████ ██ ██████ ██ ████ ██ ██ ██████
10
11
12
// ███████ ███ ███ █████ ██████ ████████ ██████ ██████ ███ ██ ████████ ██████ █████ ██████ ████████
13
// ██ ████ ████ ██ ██ ██ ██ ██ ██ ██ ██ ████ ██ ██ ██ ██ ██ ██ ██ ██
14
// ███████ ██ ████ ██ ███████ ██████ ██ ██ ██ ██ ██ ██ ██ ██ ██████ ███████ ██ ██
15
// ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██
16
// ███████ ██ ██ ██ ██ ██ ██ ██ ██████ ██████ ██ ████ ██ ██ ██ ██ ██  ██████    ██
17
18
//Revoluzion Ecosystem
19
//WEB: https://revoluzion.io
20
//DAPP: https://revoluzion.app
21
22
// SPDX-License-Identifier: MIT
23
24
pragma solidity ^0.8.13;
25
26
27
/** LIBRARY **/
28
29
// CAUTION
30
// This version of SafeMath should only be used with Solidity 0.8 or later,
31
// because it relies on the compiler's built in overflow checks.
32
33
/**
34
* @dev Wrappers over Solidity's arithmetic operations.
35
*
36
* NOTE: `SafeMath` is generally not needed starting with Solidity 0.8, since the compiler
37
* now has built in overflow checking.
38
*/
39
library SafeMath {
40
/**
41
* @dev Returns the addition of two unsigned integers, with an overflow flag.
42
*
43
* _Available since v3.4._
44
*/
45
function tryAdd(uint256 a, uint256 b) internal pure returns (bool, uint256) {
46
unchecked {
47
uint256 c = a + b;
48
if (c < a) return (false, 0);
49
return (true, c);
50
}
51
}
52
53
/**
54
* @dev Returns the subtraction of two unsigned integers, with an overflow flag.
55
*
56
* _Available since v3.4._
57
*/
58
function trySub(uint256 a, uint256 b) internal pure returns (bool, uint256) {
59
unchecked {
60
if (b > a) return (false, 0);
61
return (true, a - b);
62
}
63
}
64
65
/**
66
* @dev Returns the multiplication of two unsigned integers, with an overflow flag.
67
*
68
* _Available since v3.4._
69
*/
70
function tryMul(uint256 a, uint256 b) internal pure returns (bool, uint256) {
71
unchecked {
72
// Gas optimization: this is cheaper than requiring 'a' not being zero, but the
73
// benefit is lost if 'b' is also tested.
74
// See: https://github.com/OpenZeppelin/openzeppelin-contracts/pull/522
75
if (a == 0) return (true, 0);
76
uint256 c = a * b;
77
if (c / a != b) return (false, 0);
78
return (true, c);
79
}
80
}
81
82
/**
83
* @dev Returns the division of two unsigned integers, with a division by zero flag.
84
*
85
* _Available since v3.4._
86
*/
87
function tryDiv(uint256 a, uint256 b) internal pure returns (bool, uint256) {
88
unchecked {
89
if (b == 0) return (false, 0);
90
return (true, a / b);
91
}
92
}
93
94
/**
95
* @dev Returns the remainder of dividing two unsigned integers, with a division by zero flag.
96
*
97
* _Available since v3.4._
98
*/
99
function tryMod(uint256 a, uint256 b) internal pure returns (bool, uint256) {
100
unchecked {
101
if (b == 0) return (false, 0);
102
return (true, a % b);
103
}
104
}
105
106
/**
107
* @dev Returns the addition of two unsigned integers, reverting on
108
* overflow.
109
*
110
* Counterpart to Solidity's `+` operator.
111
*
112
* Requirements:
113
*
114
* - Addition cannot overflow.
115
*/
116
function add(uint256 a, uint256 b) internal pure returns (uint256) {
117
return a + b;
118
}
119
120
/**
121
* @dev Returns the subtraction of two unsigned integers, reverting on
122
* overflow (when the result is negative).
123
*
124
* Counterpart to Solidity's `-` operator.
125
*
126
* Requirements:
127
*
128
* - Subtraction cannot overflow.
129
*/
130
function sub(uint256 a, uint256 b) internal pure returns (uint256) {
131
return a - b;
132
}
133
134
/**
135
* @dev Returns the multiplication of two unsigned integers, reverting on
136
* overflow.
137
*
138
* Counterpart to Solidity's `*` operator.
139
*
140
* Requirements:
141
*
142
* - Multiplication cannot overflow.
143
*/
144
function mul(uint256 a, uint256 b) internal pure returns (uint256) {
145
return a * b;
146
}
147
148
/**
149
* @dev Returns the integer division of two unsigned integers, reverting on
150
* division by zero. The result is rounded towards zero.
151
*
152
* Counterpart to Solidity's `/` operator.
153
*
154
* Requirements:
155
*
156
* - The divisor cannot be zero.
157
*/
158
function div(uint256 a, uint256 b) internal pure returns (uint256) {
159
return a / b;
160
}
161
162
/**
163
* @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),
164
* reverting when dividing by zero.
165
*
166
* Counterpart to Solidity's `%` operator. This function uses a `revert`
167
* opcode (which leaves remaining gas untouched) while Solidity uses an
168
* invalid opcode to revert (consuming all remaining gas).
169
*
170
* Requirements:
171
*
172
* - The divisor cannot be zero.
173
*/
174
function mod(uint256 a, uint256 b) internal pure returns (uint256) {
175
return a % b;
176
}
177
178
/**
179
* @dev Returns the subtraction of two unsigned integers, reverting with custom message on
180
* overflow (when the result is negative).
181
*
182
* CAUTION: This function is deprecated because it requires allocating memory for the error
183
* message unnecessarily. For custom revert reasons use {trySub}.
184
*
185
* Counterpart to Solidity's `-` operator.
186
*
187
* Requirements:
188
*
189
* - Subtraction cannot overflow.
190
*/
191
function sub(
192
uint256 a,
193
uint256 b,
194
string memory errorMessage
195
) internal pure returns (uint256) {
196
unchecked {
197
require(b <= a, errorMessage);
198
return a - b;
199
}
200
}
201
202
/**
203
* @dev Returns the integer division of two unsigned integers, reverting with custom message on
204
* division by zero. The result is rounded towards zero.
205
*
206
* Counterpart to Solidity's `/` operator. Note: this function uses a
207
* `revert` opcode (which leaves remaining gas untouched) while Solidity
208
* uses an invalid opcode to revert (consuming all remaining gas).
209
*
210
* Requirements:
211
*
212
* - The divisor cannot be zero.
213
*/
214
function div(
215
uint256 a,
216
uint256 b,
217
string memory errorMessage
218
) internal pure returns (uint256) {
219
unchecked {
220
require(b > 0, errorMessage);
221
return a / b;
222
}
223
}
224
225
/**
226
* @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),
227
* reverting with custom message when dividing by zero.
228
*
229
* CAUTION: This function is deprecated because it requires allocating memory for the error
230
* message unnecessarily. For custom revert reasons use {tryMod}.
231
*
232
* Counterpart to Solidity's `%` operator. This function uses a `revert`
233
* opcode (which leaves remaining gas untouched) while Solidity uses an
234
* invalid opcode to revert (consuming all remaining gas).
235
*
236
* Requirements:
237
*
238
* - The divisor cannot be zero.
239
*/
240
function mod(
241
uint256 a,
242
uint256 b,
243
string memory errorMessage
244
) internal pure returns (uint256) {
245
unchecked {
246
require(b > 0, errorMessage);
247
return a % b;
248
}
249
}
250
}
251
252
/**
253
* @dev Provides information about the current execution context, including the
254
* sender of the transaction and its data. While these are generally available
255
* via msg.sender and msg.data, they should not be accessed in such a direct
256
* manner, since when dealing with meta-transactions the account sending and
257
* paying for execution may not be the actual sender (as far as an application
258
* is concerned).
259
*
260
* This contract is only required for intermediate, library-like contracts.
261
*/
262
abstract contract Context {
263
function _msgSender() internal view virtual returns (address) {
264
return msg.sender;
265
}
266
267
function _msgData() internal view virtual returns (bytes calldata) {
268
return msg.data;
269
}
270
}
271
272
/**
273
* @dev Contract module which provides a basic access control mechanism, where
274
* there is an account (an owner) that can be granted exclusive access to
275
* specific functions.
276
*
277
* By default, the owner account will be the one that deploys the contract. This
278
* can later be changed with {transferOwnership}.
279
*
280
* This module is used through inheritance. It will make available the modifier
281
* `onlyOwner`, which can be applied to your functions to restrict their use to
282
* the owner.
283
*/
284
abstract contract Ownable is Context {
285
address private _owner;
286
287
event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);
288
289
/**
290
* @dev Initializes the contract setting the deployer as the initial owner.
291
*/
292
constructor() {
293
_transferOwnership(_msgSender());
294
}
295
296
/**
297
* @dev Returns the address of the current owner.
298
*/
299
function owner() public view virtual returns (address) {
300
return _owner;
301
}
302
303
/**
304
* @dev Throws if called by any account other than the owner.
305
*/
306
modifier onlyOwner() {
307
require(owner() == _msgSender(), "Ownable: caller is not the owner");
308
_;
309
}
310
311
/**
312
* @dev Leaves the contract without owner. It will not be possible to call
313
* `onlyOwner` functions anymore. Can only be called by the current owner.
314
*
315
* NOTE: Renouncing ownership will leave the contract without an owner,
316
* thereby removing any functionality that is only available to the owner.
317
*/
318
function renounceOwnership() public virtual onlyOwner {
319
_transferOwnership(address(0));
320
}
321
322
/**
323
* @dev Transfers ownership of the contract to a new account (`newOwner`).
324
* Can only be called by the current owner.
325
*/
326
function transferOwnership(address newOwner) public virtual onlyOwner {
327
require(newOwner != address(0), "Ownable: new owner is the zero address");
328
_transferOwnership(newOwner);
329
}
330
331
/**
332
* @dev Transfers ownership of the contract to a new account (`newOwner`).
333
* Internal function without access restriction.
334
*/
335
function _transferOwnership(address newOwner) internal virtual {
336
address oldOwner = _owner;
337
_owner = newOwner;
338
emit OwnershipTransferred(oldOwner, newOwner);
339
}
340
}
341
342
343
/** ERC20 STANDARD **/
344
345
/**
346
* @dev Interface of the ERC20 standard as defined in the EIP.
347
*/
348
interface IERC20 {
349
/**
350
* @dev Returns the amount of tokens in existence.
351
*/
352
function totalSupply() external view returns (uint256);
353
354
/**
355
* @dev Returns the amount of tokens owned by `account`.
356
*/
357
function balanceOf(address account) external view returns (uint256);
358
359
/**
360
* @dev Moves `amount` tokens from the caller's account to `to`.
361
*
362
* Returns a boolean value indicating whether the operation succeeded.
363
*
364
* Emits a {Transfer} event.
365
*/
366
function transfer(address to, uint256 amount) external returns (bool);
367
368
/**
369
* @dev Returns the remaining number of tokens that `spender` will be
370
* allowed to spend on behalf of `owner` through {transferFrom}. This is
371
* zero by default.
372
*
373
* This value changes when {approve} or {transferFrom} are called.
374
*/
375
function allowance(address owner, address spender) external view returns (uint256);
376
377
/**
378
* @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
379
*
380
* Returns a boolean value indicating whether the operation succeeded.
381
*
382
* IMPORTANT: Beware that changing an allowance with this method brings the risk
383
* that someone may use both the old and the new allowance by unfortunate
384
* transaction ordering. One possible solution to mitigate this race
385
* condition is to first reduce the spender's allowance to 0 and set the
386
* desired value afterwards:
387
* https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
388
*
389
* Emits an {Approval} event.
390
*/
391
function approve(address spender, uint256 amount) external returns (bool);
392
393
/**
394
* @dev Moves `amount` tokens from `from` to `to` using the
395
* allowance mechanism. `amount` is then deducted from the caller's
396
* allowance.
397
*
398
* Returns a boolean value indicating whether the operation succeeded.
399
*
400
* Emits a {Transfer} event.
401
*/
402
function transferFrom(
403
address from,
404
address to,
405
uint256 amount
406
) external returns (bool);
407
408
/**
409
* @dev Emitted when `value` tokens are moved from one account (`from`) to
410
* another (`to`).
411
*
412
* Note that `value` may be zero.
413
*/
414
event Transfer(address indexed from, address indexed to, uint256 value);
415
416
/**
417
* @dev Emitted when the allowance of a `spender` for an `owner` is set by
418
* a call to {approve}. `value` is the new allowance.
419
*/
420
event Approval(address indexed owner, address indexed spender, uint256 value);
421
}
422
423
/**
424
* @dev Interface for the optional metadata functions from the ERC20 standard.
425
*
426
* _Available since v4.1._
427
*/
428
interface IERC20Metadata is IERC20 {
429
/**
430
* @dev Returns the name of the token.
431
*/
432
function name() external view returns (string memory);
433
434
/**
435
* @dev Returns the symbol of the token.
436
*/
437
function symbol() external view returns (string memory);
438
439
/**
440
* @dev Returns the decimals places of the token.
441
*/
442
function decimals() external view returns (uint8);
443
}
444
445
/**
446
* @dev Implementation of the {IERC20} interface.
447
*
448
* This implementation is agnostic to the way tokens are created. This means
449
* that a supply mechanism has to be added in a derived contract using {_mint}.
450
* For a generic mechanism see {ERC20PresetMinterPauser}.
451
*
452
* TIP: For a detailed writeup see our guide
453
* https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How
454
* to implement supply mechanisms].
455
*
456
* We have followed general OpenZeppelin Contracts guidelines: functions revert
457
* instead returning `false` on failure. This behavior is nonetheless
458
* conventional and does not conflict with the expectations of ERC20
459
* applications.
460
*
461
* Additionally, an {Approval} event is emitted on calls to {transferFrom}.
462
* This allows applications to reconstruct the allowance for all accounts just
463
* by listening to said events. Other implementations of the EIP may not emit
464
* these events, as it isn't required by the specification.
465
*
466
* Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
467
* functions have been added to mitigate the well-known issues around setting
468
* allowances. See {IERC20-approve}.
469
*/
470
contract ERC20 is Context, IERC20, IERC20Metadata {
471
mapping(address => uint256) private _balances;
472
473
mapping(address => mapping(address => uint256)) private _allowances;
474
475
uint256 private _totalSupply;
476
477
string private _name;
478
string private _symbol;
479
480
/**
481
* @dev Sets the values for {name} and {symbol}.
482
*
483
* The default value of {decimals} is 18. To select a different value for
484
* {decimals} you should overload it.
485
*
486
* All two of these values are immutable: they can only be set once during
487
* construction.
488
*/
489
constructor(string memory name_, string memory symbol_) {
490
_name = name_;
491
_symbol = symbol_;
492
}
493
494
/**
495
* @dev Returns the name of the token.
496
*/
497
function name() public view virtual override returns (string memory) {
498
return _name;
499
}
500
501
/**
502
* @dev Returns the symbol of the token, usually a shorter version of the
503
* name.
504
*/
505
function symbol() public view virtual override returns (string memory) {
506
return _symbol;
507
}
508
509
/**
510
* @dev Returns the number of decimals used to get its user representation.
511
* For example, if `decimals` equals `2`, a balance of `505` tokens should
512
* be displayed to a user as `5.05` (`505 / 10 ** 2`).
513
*
514
* Tokens usually opt for a value of 18, imitating the relationship between
515
* Ether and Wei. This is the value {ERC20} uses, unless this function is
516
* overridden;
517
*
518
* NOTE: This information is only used for _display_ purposes: it in
519
* no way affects any of the arithmetic of the contract, including
520
* {IERC20-balanceOf} and {IERC20-transfer}.
521
*/
522
function decimals() public view virtual override returns (uint8) {
523
return 18;
524
}
525
526
/**
527
* @dev See {IERC20-totalSupply}.
528
*/
529
function totalSupply() public view virtual override returns (uint256) {
530
return _totalSupply;
531
}
532
533
/**
534
* @dev See {IERC20-balanceOf}.
535
*/
536
function balanceOf(address account) public view virtual override returns (uint256) {
537
return _balances[account];
538
}
539
540
/**
541
* @dev See {IERC20-transfer}.
542
*
543
* Requirements:
544
*
545
* - `to` cannot be the zero address.
546
* - the caller must have a balance of at least `amount`.
547
*/
548
function transfer(address to, uint256 amount) public virtual override returns (bool) {
549
address owner = _msgSender();
550
_transfer(owner, to, amount);
551
return true;
552
}
553
554
/**
555
* @dev See {IERC20-allowance}.
556
*/
557
function allowance(address owner, address spender) public view virtual override returns (uint256) {
558
return _allowances[owner][spender];
559
}
560
561
/**
562
* @dev See {IERC20-approve}.
563
*
564
* NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on
565
* `transferFrom`. This is semantically equivalent to an infinite approval.
566
*
567
* Requirements:
568
*
569
* - `spender` cannot be the zero address.
570
*/
571
function approve(address spender, uint256 amount) public virtual override returns (bool) {
572
address owner = _msgSender();
573
_approve(owner, spender, amount);
574
return true;
575
}
576
577
/**
578
* @dev See {IERC20-transferFrom}.
579
*
580
* Emits an {Approval} event indicating the updated allowance. This is not
581
* required by the EIP. See the note at the beginning of {ERC20}.
582
*
583
* NOTE: Does not update the allowance if the current allowance
584
* is the maximum `uint256`.
585
*
586
* Requirements:
587
*
588
* - `from` and `to` cannot be the zero address.
589
* - `from` must have a balance of at least `amount`.
590
* - the caller must have allowance for ``from``'s tokens of at least
591
* `amount`.
592
*/
593
function transferFrom(
594
address from,
595
address to,
596
uint256 amount
597
) public virtual override returns (bool) {
598
address spender = _msgSender();
599
_spendAllowance(from, spender, amount);
600
_transfer(from, to, amount);
601
return true;
602
}
603
604
/**
605
* @dev Atomically increases the allowance granted to `spender` by the caller.
606
*
607
* This is an alternative to {approve} that can be used as a mitigation for
608
* problems described in {IERC20-approve}.
609
*
610
* Emits an {Approval} event indicating the updated allowance.
611
*
612
* Requirements:
613
*
614
* - `spender` cannot be the zero address.
615
*/
616
function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
617
address owner = _msgSender();
618
_approve(owner, spender, allowance(owner, spender) + addedValue);
619
return true;
620
}
621
622
/**
623
* @dev Atomically decreases the allowance granted to `spender` by the caller.
624
*
625
* This is an alternative to {approve} that can be used as a mitigation for
626
* problems described in {IERC20-approve}.
627
*
628
* Emits an {Approval} event indicating the updated allowance.
629
*
630
* Requirements:
631
*
632
* - `spender` cannot be the zero address.
633
* - `spender` must have allowance for the caller of at least
634
* `subtractedValue`.
635
*/
636
function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
637
address owner = _msgSender();
638
uint256 currentAllowance = allowance(owner, spender);
639
require(currentAllowance >= subtractedValue, "ERC20: decreased allowance below zero");
640
unchecked {
641
_approve(owner, spender, currentAllowance - subtractedValue);
642
}
643
644
return true;
645
}
646
647
/**
648
* @dev Moves `amount` of tokens from `sender` to `recipient`.
649
*
650
* This internal function is equivalent to {transfer}, and can be used to
651
* e.g. implement automatic token fees, slashing mechanisms, etc.
652
*
653
* Emits a {Transfer} event.
654
*
655
* Requirements:
656
*
657
* - `from` cannot be the zero address.
658
* - `to` cannot be the zero address.
659
* - `from` must have a balance of at least `amount`.
660
*/
661
function _transfer(
662
address from,
663
address to,
664
uint256 amount
665
) internal virtual {
666
require(from != address(0), "ERC20: transfer from the zero address");
667
require(to != address(0), "ERC20: transfer to the zero address");
668
669
_beforeTokenTransfer(from, to, amount);
670
671
uint256 fromBalance = _balances[from];
672
require(fromBalance >= amount, "ERC20: transfer amount exceeds balance");
673
unchecked {
674
_balances[from] = fromBalance - amount;
675
}
676
_balances[to] += amount;
677
678
emit Transfer(from, to, amount);
679
680
_afterTokenTransfer(from, to, amount);
681
}
682
683
/** @dev Creates `amount` tokens and assigns them to `account`, increasing
684
* the total supply.
685
*
686
* Emits a {Transfer} event with `from` set to the zero address.
687
*
688
* Requirements:
689
*
690
* - `account` cannot be the zero address.
691
*/
692
function _mint(address account, uint256 amount) internal virtual {
693
require(account != address(0), "ERC20: mint to the zero address");
694
695
_beforeTokenTransfer(address(0), account, amount);
696
697
_totalSupply += amount;
698
_balances[account] += amount;
699
emit Transfer(address(0), account, amount);
700
701
_afterTokenTransfer(address(0), account, amount);
702
}
703
704
/**
705
* @dev Destroys `amount` tokens from `account`, reducing the
706
* total supply.
707
*
708
* Emits a {Transfer} event with `to` set to the zero address.
709
*
710
* Requirements:
711
*
712
* - `account` cannot be the zero address.
713
* - `account` must have at least `amount` tokens.
714
*/
715
function _burn(address account, uint256 amount) internal virtual {
716
require(account != address(0), "ERC20: burn from the zero address");
717
718
_beforeTokenTransfer(account, address(0), amount);
719
720
uint256 accountBalance = _balances[account];
721
require(accountBalance >= amount, "ERC20: burn amount exceeds balance");
722
unchecked {
723
_balances[account] = accountBalance - amount;
724
}
725
_totalSupply -= amount;
726
727
emit Transfer(account, address(0), amount);
728
729
_afterTokenTransfer(account, address(0), amount);
730
}
731
732
/**
733
* @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens.
734
*
735
* This internal function is equivalent to `approve`, and can be used to
736
* e.g. set automatic allowances for certain subsystems, etc.
737
*
738
* Emits an {Approval} event.
739
*
740
* Requirements:
741
*
742
* - `owner` cannot be the zero address.
743
* - `spender` cannot be the zero address.
744
*/
745
function _approve(
746
address owner,
747
address spender,
748
uint256 amount
749
) internal virtual {
750
require(owner != address(0), "ERC20: approve from the zero address");
751
require(spender != address(0), "ERC20: approve to the zero address");
752
753
_allowances[owner][spender] = amount;
754
emit Approval(owner, spender, amount);
755
}
756
757
/**
758
* @dev Updates `owner` s allowance for `spender` based on spent `amount`.
759
*
760
* Does not update the allowance amount in case of infinite allowance.
761
* Revert if not enough allowance is available.
762
*
763
* Might emit an {Approval} event.
764
*/
765
function _spendAllowance(
766
address owner,
767
address spender,
768
uint256 amount
769
) internal virtual {
770
uint256 currentAllowance = allowance(owner, spender);
771
if (currentAllowance != type(uint256).max) {
772
require(currentAllowance >= amount, "ERC20: insufficient allowance");
773
unchecked {
774
_approve(owner, spender, currentAllowance - amount);
775
}
776
}
777
}
778
779
/**
780
* @dev Hook that is called before any transfer of tokens. This includes
781
* minting and burning.
782
*
783
* Calling conditions:
784
*
785
* - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
786
* will be transferred to `to`.
787
* - when `from` is zero, `amount` tokens will be minted for `to`.
788
* - when `to` is zero, `amount` of ``from``'s tokens will be burned.
789
* - `from` and `to` are never both zero.
790
*
791
* To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
792
*/
793
function _beforeTokenTransfer(
794
address from,
795
address to,
796
uint256 amount
797
) internal virtual {}
798
799
/**
800
* @dev Hook that is called after any transfer of tokens. This includes
801
* minting and burning.
802
*
803
* Calling conditions:
804
*
805
* - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
806
* has been transferred to `to`.
807
* - when `from` is zero, `amount` tokens have been minted for `to`.
808
* - when `to` is zero, `amount` of ``from``'s tokens have been burned.
809
* - `from` and `to` are never both zero.
810
*
811
* To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
812
*/
813
function _afterTokenTransfer(
814
address from,
815
address to,
816
uint256 amount
817
) internal virtual {}
818
}
819
820
821
/** AIRDROP **/
822
823
contract Airdrop is Ownable {
824
825
826
/** LIBRARY **/
827
using SafeMath for uint;
828
829
830
/** EVENT **/
831
event NativeTransfer(address beneficiary, uint256 amount);
832
833
834
/** FUNCTION **/
835
836
receive() external payable {}
837
838
/**
839
* @dev Function to airdrop ERC20-based token with different specific values to respective addresses.
840
*/
841
function dropDifferentSpecificTokens(
842
ERC20 _token,
843
address[] memory _recipients,
844
uint256[] memory _amount
845
) public onlyOwner returns (bool) {
846
847
for (
848
uint256 i = 0;
849
i < _recipients.length;
850
i++
851
) {
852
853
// Make sure that the recipient is not zero address
854
require(_recipients[i] != address(0));
855
856
// Make sure that the token can transfer the amount to the address
857
require(ERC20(_token).transfer(_recipients[i], _amount[i]));
858
859
}