Advantages Of The LZN Protocol Over Other Protocols
The security of a protocol is of the utmost importance. The Revoluzion team has put in extensive research, development, and testing to ensure that the Luzion Protocol, when deployed on the MainNet, is secure and reliable for our users' investments. We prioritize a properly functioning protocol over rushing to meet hype or deadlines.
The Luzion Protocol was the first to successfully implement a properly functioning rebase rate, as well as the correct formula for continuous automatic compounding.
Key Features of the Luzion Protocol that Set it Apart ;-
The Luzion Protocol was developed entirely from scratch, with no copy-pasting of code. The lead full stack developer, Nizar, and his team spent hundreds of hours perfecting every aspect of the smart contract's logic to ensure its quality
The Luzion Protocol offers fully functional dual rewards through an automated staking system. By simply holding $LZN in their wallet, users can receive both LZN reflections and BUSD rewards on a perpetual basis. This helps to stabilize the market by incentivizing holders to hold onto their $LZN, rather than cashing out, as they are consistently earning BUSD rewards as profits.
The Luzion Protocol utilizes a fully automated rebalancing system that operates until the maximum supply is reached after 13 years. This eliminates the need for users to stake their tokens on a smart contract, which can expose them to vulnerabilities and exploits. The automated rebalancing helps to ensure the long-term sustainability of the protocol.
The rebase rate code and logic of the Luzion Protocol are fully functioning throughout its lifespan. Unlike other protocols, the rebase rate does not need to be amended after 365 days, which helps to maintain control over the supply and prevent the mass reduction in token value over time. The Luzion Protocol's rebalancing system is robust and helps to ensure the stability and value of the token.
The Luzion Protocol has a fully automated burning mechanism in place. Every transaction on the protocol automatically burns 2% of the transaction amount directly to the blackhole. This helps to reduce the overall supply of tokens and promotes sustainability.
Other protocols may have manually-executed burns that can be manipulated or sold on the market, which does not effectively reduce the supply. The automatic burn on the Luzion Protocol ensures that the supply is consistently and transparently reduced.
Other protocols may have a "burned" address that is essentially a wallet, and burns are done manually. This can be opaque and potentially subject to manipulation. The Luzion Protocol, on the other hand, has a fully automated burning mechanism that sends burned tokens directly to an actual burn address. This ensures a transparent and tamper-proof burn process. The use of a dedicated burn address also helps to increase confidence in the protocol.
The Luzion Protocol offers competitive buy and sell tax rates for investors. The lower fees make it more cost-effective for investors to purchase and sell tokens on the protocol, which can encourage more participation and liquidity. These competitive tax rates are a key advantage for the Luzion Protocol in the market.
The Luzion Protocol has a transparent and secure tax fee structure in place. The tax fee rate is hardcoded directly into the smart contract, which ensures that it cannot be adjusted or manipulated by the team.
This provides a high level of security for transactions on the protocol. In contrast, many other protocols may have variable tax fee rates or even no limits, which can be a cause for concern for investors. The hardcoded tax fee rate on the Luzion Protocol helps to build trust and confidence in the protocol.
The Luzion Protocol utilizes a hardware wallet storage vault to ensure maximum security and safety for treasury funds. By storing all treasury funds directly in a hardware wallet, the protocol is able to prevent exploitation or hacks from occurring. The use of a hardware wallet provides an additional layer of security and helps to build trust and confidence in the protocol.
The entire Revoluzion team behind the Luzion Protocol is fully doxxed, with all necessary information readily available through social media profiles and other channels. The team is actively involved in the development and progress of the protocol, regularly holding Video AMAs and providing updates to the community.
The Revoluzion team has been with the project from the start and is committed to continuously developing and updating the protocol on a daily basis. The team's transparency and dedication to the project helps to build trust and confidence in the Luzion Protocol.
Many projects have an insurance fund wallet in case of an emergency. The Luzion Protocol, however, takes a different approach to risk management by directly paying out insurance funding to users on a regular basis. This provides a risk-free investment experience for users.
The protocol's approach is based on the belief that it is not advisable to hold a large sum of insurance funds in a single entity, and instead, it is better to have the funds distributed to users consistently. The Luzion Protocol's dividend fund is a unique approach to risk management that helps to build trust and confidence in the protocol.
1
/**
2
*Submitted for verification at Etherscan.io on 2022-04-11
3
*/
4
5
// SPDX-License-Identifier: MIT
6
7
/**
8
* @title Luzion Protocol
9
* @notice The future of Dual Reward with Auto-Staking, Auto-Compounding & BUSD Reflection all together!
10
*
11
* @custom:website https://luzion.io
12
* @custom:whitepaper https://docs.luzion.io
13
* @custom:telegram https://t.me/revoluzionecosystem
14
*/
15
16
pragma solidity ^0.8.13;
17
18
19
/** LIBRARY / DEPENDENCY **/
20
21
// CAUTION
22
// This version of SafeMath should only be used with Solidity 0.8 or later,
23
// because it relies on the compiler's built in overflow checks.
24
25
/**
26
* @title Safe Math
27
*
28
* @dev Wrappers over Solidity's arithmetic operations.
29
*
30
* NOTE: `SafeMath` is generally not needed starting with Solidity 0.8, since the compiler
31
* now has built in overflow checking.
32
*/
33
library SafeMath {
34
/**
35
* @dev Returns the addition of two unsigned integers, with an overflow flag.
36
*
37
* _Available since v3.4._
38
*/
39
function tryAdd(uint256 a, uint256 b) internal pure returns (bool, uint256) {
40
unchecked {
41
uint256 c = a + b;
42
if (c < a) return (false, 0);
43
return (true, c);
44
}
45
}
46
47
/**
48
* @dev Returns the subtraction of two unsigned integers, with an overflow flag.
49
*
50
* _Available since v3.4._
51
*/
52
function trySub(uint256 a, uint256 b) internal pure returns (bool, uint256) {
53
unchecked {
54
if (b > a) return (false, 0);
55
return (true, a - b);
56
}
57
}
58
59
/**
60
* @dev Returns the multiplication of two unsigned integers, with an overflow flag.
61
*
62
* _Available since v3.4._
63
*/
64
function tryMul(uint256 a, uint256 b) internal pure returns (bool, uint256) {
65
unchecked {
66
// Gas optimization: this is cheaper than requiring 'a' not being zero, but the
67
// benefit is lost if 'b' is also tested.
68
// See: https://github.com/OpenZeppelin/openzeppelin-contracts/pull/522
69
if (a == 0) return (true, 0);
70
uint256 c = a * b;
71
if (c / a != b) return (false, 0);
72
return (true, c);
73
}
74
}
75
76
/**
77
* @dev Returns the division of two unsigned integers, with a division by zero flag.
78
*
79
* _Available since v3.4._
80
*/
81
function tryDiv(uint256 a, uint256 b) internal pure returns (bool, uint256) {
82
unchecked {
83
if (b == 0) return (false, 0);
84
return (true, a / b);
85
}
86
}
87
88
/**
89
* @dev Returns the remainder of dividing two unsigned integers, with a division by zero flag.
90
*
91
* _Available since v3.4._
92
*/
93
function tryMod(uint256 a, uint256 b) internal pure returns (bool, uint256) {
94
unchecked {
95
if (b == 0) return (false, 0);
96
return (true, a % b);
97
}
98
}
99
100
/**
101
* @dev Returns the addition of two unsigned integers, reverting on
102
* overflow.
103
*
104
* Counterpart to Solidity's `+` operator.
105
*
106
* Requirements:
107
*
108
* - Addition cannot overflow.
109
*/
110
function add(uint256 a, uint256 b) internal pure returns (uint256) {
111
return a + b;
112
}
113
114
/**
115
* @dev Returns the subtraction of two unsigned integers, reverting on
116
* overflow (when the result is negative).
117
*
118
* Counterpart to Solidity's `-` operator.
119
*
120
* Requirements:
121
*
122
* - Subtraction cannot overflow.
123
*/
124
function sub(uint256 a, uint256 b) internal pure returns (uint256) {
125
return a - b;
126
}
127
128
/**
129
* @dev Returns the multiplication of two unsigned integers, reverting on
130
* overflow.
131
*
132
* Counterpart to Solidity's `*` operator.
133
*
134
* Requirements:
135
*
136
* - Multiplication cannot overflow.
137
*/
138
function mul(uint256 a, uint256 b) internal pure returns (uint256) {
139
return a * b;
140
}
141
142
/**
143
* @dev Returns the integer division of two unsigned integers, reverting on
144
* division by zero. The result is rounded towards zero.
145
*
146
* Counterpart to Solidity's `/` operator.
147
*
148
* Requirements:
149
*
150
* - The divisor cannot be zero.
151
*/
152
function div(uint256 a, uint256 b) internal pure returns (uint256) {
153
return a / b;
154
}
155
156
/**
157
* @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),
158
* reverting when dividing by zero.
159
*
160
* Counterpart to Solidity's `%` operator. This function uses a `revert`
161
* opcode (which leaves remaining gas untouched) while Solidity uses an
162
* invalid opcode to revert (consuming all remaining gas).
163
*
164
* Requirements:
165
*
166
* - The divisor cannot be zero.
167
*/
168
function mod(uint256 a, uint256 b) internal pure returns (uint256) {
169
return a % b;
170
}
171
172
/**
173
* @dev Returns the subtraction of two unsigned integers, reverting with custom message on
174
* overflow (when the result is negative).
175
*
176
* CAUTION: This function is deprecated because it requires allocating memory for the error
177
* message unnecessarily. For custom revert reasons use {trySub}.
178
*
179
* Counterpart to Solidity's `-` operator.
180
*
181
* Requirements:
182
*
183
* - Subtraction cannot overflow.
184
*/
185
function sub(
186
uint256 a,
187
uint256 b,
188
string memory errorMessage
189
) internal pure returns (uint256) {
190
unchecked {
191
require(b <= a, errorMessage);
192
return a - b;
193
}
194
}
195
196
/**
197
* @dev Returns the integer division of two unsigned integers, reverting with custom message on
198
* division by zero. The result is rounded towards zero.
199
*
200
* Counterpart to Solidity's `/` operator. Note: this function uses a
201
* `revert` opcode (which leaves remaining gas untouched) while Solidity
202
* uses an invalid opcode to revert (consuming all remaining gas).
203
*
204
* Requirements:
205
*
206
* - The divisor cannot be zero.
207
*/
208
function div(
209
uint256 a,
210
uint256 b,
211
string memory errorMessage
212
) internal pure returns (uint256) {
213
unchecked {
214
require(b > 0, errorMessage);
215
return a / b;
216
}
217
}
218
219
/**
220
* @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),
221
* reverting with custom message when dividing by zero.
222
*
223
* CAUTION: This function is deprecated because it requires allocating memory for the error
224
* message unnecessarily. For custom revert reasons use {tryMod}.
225
*
226
* Counterpart to Solidity's `%` operator. This function uses a `revert`
227
* opcode (which leaves remaining gas untouched) while Solidity uses an
228
* invalid opcode to revert (consuming all remaining gas).
229
*
230
* Requirements:
231
*
232
* - The divisor cannot be zero.
233
*/
234
function mod(
235
uint256 a,
236
uint256 b,
237
string memory errorMessage
238
) internal pure returns (uint256) {
239
unchecked {
240
require(b > 0, errorMessage);
241
return a % b;
242
}
243
}
244
}
245
246
/**
247
* @title Context
248
*
249
* @dev Provides information about the current execution context, including the
250
* sender of the transaction and its data. While these are generally available
251
* via msg.sender and msg.data, they should not be accessed in such a direct
252
* manner, since when dealing with meta-transactions the account sending and
253
* paying for execution may not be the actual sender (as far as an application
254
* is concerned).
255
*
256
* This contract is only required for intermediate, library-like contracts.
257
*/
258
abstract contract Context {
259
260
261
/** FUNCTION **/
262
263
/**
264
* @dev Act as the shorthand for msg.sender reference.
265
*/
266
function _msgSender() internal view virtual returns (address) {
267
return msg.sender;
268
}
269
270
/**
271
* @dev Act as the shorthand for msg.data reference.
272
*/
273
function _msgData() internal view virtual returns (bytes calldata) {
274
return msg.data;
275
}
276
277
/**
278
* @dev Act as the shorthand for msg.value reference.
279
*/
280
function _msgValue() internal view virtual returns (uint256) {
281
return msg.value;
282
}
283
284
}
285
286
/**
287
* @title Ownable
288
*
289
* @dev Contract module which provides a basic access control mechanism, where
290
* there is an account (an owner) that can be granted exclusive access to
291
* specific functions.
292
*
293
* By default, the owner account will be the one that deploys the contract. This
294
* can later be changed with {transferOwnership}.
295
*
296
* This module is used through inheritance. It will make available the modifier
297
* `onlyOwner`, which can be applied to your functions to restrict their use to
298
* the owner.
299
*/
300
abstract contract Ownable is Context {
301
302
address private _owner;
303
304
mapping(address => bool) internal authorizations;
305
306
event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);
307
308
/**
309
* @dev Initializes the contract setting the deployer as the initial owner.
310
*/
311
constructor() {
312
_transferOwnership(_msgSender());
313
authorizations[_msgSender()] = true;
314
}
315
316
/**
317
* @dev Returns the address of the current owner.
318
*/
319
function owner() public view virtual returns (address) {
320
return _owner;
321
}
322
323
/**
324
* @dev Throws if called by any account other than the owner.
325
*/
326
modifier onlyOwner() {
327
require(owner() == _msgSender(), "Ownable: caller is not the owner");
328
_;
329
}
330
331
/**
332
* @dev Throws if called by any account other authorized accounts.
333
*/
334
modifier authorized() {
335
require(isAuthorized(_msgSender()), "Ownable: caller is not an authorized account");
336
_;
337
}
338
339
/**
340
* @dev Authorize address. Owner only
341
*/
342
function authorize(address adr) public onlyOwner {
343
authorizations[adr] = true;
344
}
345
346
/**
347
* @dev Remove address' authorization. Owner only
348
*/
349
function unauthorize(address adr) public onlyOwner {
350
authorizations[adr] = false;
351
}
352
353
/**
354
* @dev Check if address is owner
355
*/
356
function isOwner(address adr) public view returns (bool) {
357
return adr == owner();
358
}
359
360
/**
361
* @dev Return address' authorization status
362
*/
363
function isAuthorized(address adr) public view returns (bool) {
364
return authorizations[adr];
365
}
366
367
/**
368
* @dev Leaves the contract without owner. It will not be possible to call
369
* `onlyOwner` functions anymore. Can only be called by the current owner.
370
*
371
* NOTE: Renouncing ownership will leave the contract without an owner,
372
* thereby removing any functionality that is only available to the owner.
373
*/
374
function renounceOwnership() public virtual onlyOwner {
375
_transferOwnership(address(0));
376
}
377
378
/**
379
* @dev Transfers ownership of the contract to a new account (`newOwner`).
380
* Can only be called by the current owner.
381
*/
382
function transferOwnership(address newOwner) public virtual onlyOwner {
383
require(newOwner != address(0), "Ownable: new owner is the zero address");
384
_transferOwnership(newOwner);
385
}
386
387
/**
388
* @dev Transfers ownership of the contract to a new account (`newOwner`).
389
* Internal function without access restriction.
390
*/
391
function _transferOwnership(address newOwner) internal virtual {
392
address oldOwner = _owner;
393
_owner = newOwner;
394
emit OwnershipTransferred(oldOwner, newOwner);
395
}
396
397
}
398
399
400
/** ERC STANDARD **/
401
402
/**
403
* @title IERC20Extended
404
*
405
* @dev The interface for ERC20 with metadata extension included.
406
*/
407
interface IERC20Extended {
408
409
410
/** FUNCTION **/
411
412
/**
413
* @dev Returns the name of the token.
414
*/
415
function name() external view returns (string memory);
416
417
/**
418
* @dev Returns the symbol of the token.
419
*/
420
function symbol() external view returns (string memory);
421
422
/**
423
* @dev Returns the decimals places of the token.
424
*/
425
function decimals() external view returns (uint8);
426
427
/**
428
* @dev Returns the amount of tokens in existence.
429
*/
430
function totalSupply() external view returns (uint256);
431
432
/**
433
* @dev Returns the amount of tokens owned by `account`.
434
*/
435
function balanceOf(address account) external view returns (uint256);
436
437
/**
438
* @dev Moves `amount` tokens from the caller's account to `recipient`.
439
*
440
* Returns a boolean value indicating whether the operation succeeded.
441
*
442
* Emits a {Transfer} event.
443
*/
444
function transfer(address recipient, uint256 amount) external returns (bool);
445
446
/**
447
* @dev Returns the remaining number of tokens that `spender` will be
448
* allowed to spend on behalf of `owner` through {transferFrom}. This is
449
* zero by default.
450
*
451
* This value changes when {approve} or {transferFrom} are called.
452
*/
453
function allowance(address _owner, address spender) external view returns (uint256);
454
455
/**
456
* @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
457
*
458
* Returns a boolean value indicating whether the operation succeeded.
459
*
460
* IMPORTANT: Beware that changing an allowance with this method brings the risk
461
* that someone may use both the old and the new allowance by unfortunate
462
* transaction ordering. One possible solution to mitigate this race
463
* condition is to first reduce the spender's allowance to 0 and set the
464
* desired value afterwards:
465
* https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
466
*
467
* Emits an {Approval} event.
468
*/
469
function approve(address spender, uint256 amount) external returns (bool);
470
471
/**
472
* @dev Moves `amount` tokens from `sender` to `recipient` using the
473
* allowance mechanism. `amount` is then deducted from the caller's
474
* allowance.
475
*
476
* Returns a boolean value indicating whether the operation succeeded.
477
*
478
* Emits a {Transfer} event.
479
*/
480
function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
481
482
483
/** EVENT **/
484
485
/**
486
* @dev Emitted when `value` tokens are moved from one account (`from`) to
487
* another (`to`).
488
*
489
* Note that `value` may be zero.
490
*/
491
event Transfer(address indexed from, address indexed to, uint256 value);
492
493
/**
494
* @dev Emitted when the allowance of a `spender` for an `owner` is set by
495
* a call to {approve}. `value` is the new allowance.
496
*/
497
event Approval(address indexed owner, address indexed spender, uint256 value);
498
499
}
500
501
/**
502
* @title ERC20
503
*
504
* @dev Implementation of the {IERC20} interface.
505
*
506
* This implementation is agnostic to the way tokens are created. This means
507
* that a supply mechanism has to be added in a derived contract using {_mint}.
508
* For a generic mechanism see {ERC20PresetMinterPauser}.
509
*
510
* TIP: For a detailed writeup see our guide
511
* https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How
512
* to implement supply mechanisms].
513
*
514
* We have followed general OpenZeppelin Contracts guidelines: functions revert
515
* instead returning `false` on failure. This behavior is nonetheless
516
* conventional and does not conflict with the expectations of ERC20
517
* applications.
518
*
519
* Additionally, an {Approval} event is emitted on calls to {transferFrom}.
520
* This allows applications to reconstruct the allowance for all accounts just
521
* by listening to said events. Other implementations of the EIP may not emit
522
* these events, as it isn't required by the specification.
523
*
524
* Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
525
* functions have been added to mitigate the well-known issues around setting
526
* allowances. See {IERC20-approve}.
527
*/
528
contract ERC20 is Context, IERC20Extended {
529
530
531
/** DATA **/
532
uint8 private _decimals;
533
534
uint256 private _totalSupply;
535
536
string private _name;
537
string private _symbol;
538
539
mapping(address => uint256) private _balances;
540
mapping(address => mapping(address => uint256)) private _allowances;
541
542
543
/** CONSTRUTOR **/
544
545
/**
546
* @dev Sets the values for {name} and {symbol}.
547
*
548
* The default value of {decimals} is 18. To select a different value for
549
* {decimals} you should overload it.
550
*
551
* All two of these values are immutable: they can only be set once during
552
* construction.
553
*/
554
constructor(uint8 decimals_, string memory name_, string memory symbol_) {
555
_decimals = decimals_;
556
_name = name_;
557
_symbol = symbol_;
558
}
559
560
561
/** FUNCTION **/
562
563
/**
564
* @dev Returns the name of the token.
565
*/
566
function name() public view virtual override returns (string memory) {
567
return _name;
568
}
569
570
/**
571
* @dev Returns the symbol of the token, usually a shorter version of the
572
* name.
573
*/
574
function symbol() public view virtual override returns (string memory) {
575
return _symbol;
576
}
577
578
/**
579
* @dev Returns the number of decimals used to get its user representation.
580
* For example, if `decimals` equals `2`, a balance of `505` tokens should
581
* be displayed to a user as `5.05` (`505 / 10 ** 2`).
582
*
583
* Tokens usually opt for a value of 18, imitating the relationship between
584
* Ether and Wei. This is the value {ERC20} uses, unless this function is
585
* overridden;
586
*
587
* NOTE: This information is only used for _display_ purposes: it in
588
* no way affects any of the arithmetic of the contract, including
589
* {IERC20-balanceOf} and {IERC20-transfer}.
590
*/
591
function decimals() public view virtual override returns (uint8) {
592
return _decimals;
593
}
594
595
/**
596
* @dev See {IERC20-totalSupply}.
597
*/
598
function totalSupply() public view virtual override returns (uint256) {
599
return _totalSupply;
600
}
601
602
/**
603
* @dev See {IERC20-balanceOf}.
604
*/
605
function balanceOf(address account) public view virtual override returns (uint256) {
606
return _balances[account];
607
}
608
609
/**
610
* @dev See {IERC20-transfer}.
611
*
612
* Requirements:
613
*
614
* - `to` cannot be the zero address.
615
* - the caller must have a balance of at least `amount`.
616
*/
617
function transfer(address to, uint256 amount) public virtual override returns (bool) {
618
address owner = _msgSender();
619
_transfer(owner, to, amount);
620
return true;
621
}
622
623
/**
624
* @dev See {IERC20-allowance}.
625
*/
626
function allowance(address owner, address spender) public view virtual override returns (uint256) {
627
return _allowances[owner][spender];
628
}
629
630
/**
631
* @dev See {IERC20-approve}.
632
*
633
* NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on
634
* `transferFrom`. This is semantically equivalent to an infinite approval.
635
*
636
* Requirements:
637
*
638
* - `spender` cannot be the zero address.
639
*/
640
function approve(address spender, uint256 amount) public virtual override returns (bool) {
641
address owner = _msgSender();
642
_approve(owner, spender, amount);
643
return true;
644
}
645
646
/**
647
* @dev See {IERC20-transferFrom}.
648
*
649
* Emits an {Approval} event indicating the updated allowance. This is not
650
* required by the EIP. See the note at the beginning of {ERC20}.
651
*
652
* NOTE: Does not update the allowance if the current allowance
653
* is the maximum `uint256`.
654
*
655
* Requirements:
656
*
657
* - `from` and `to` cannot be the zero address.
658
* - `from` must have a balance of at least `amount`.
659
* - the caller must have allowance for ``from``'s tokens of at least
660
* `amount`.
661
*/
662
function transferFrom(address from, address to, uint256 amount) public virtual override returns (bool) {
663
address spender = _msgSender();
664
_spendAllowance(from, spender, amount);
665
_transfer(from, to, amount);
666
return true;
667
}
668
669
/**
670
* @dev Atomically increases the allowance granted to `spender` by the caller.
671
*
672
* This is an alternative to {approve} that can be used as a mitigation for
673
* problems described in {IERC20-approve}.
674
*
675
* Emits an {Approval} event indicating the updated allowance.
676
*
677
* Requirements:
678
*
679
* - `spender` cannot be the zero address.
680
*/
681
function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
682
address owner = _msgSender();
683
_approve(owner, spender, allowance(owner, spender) + addedValue);
684
return true;
685
}
686
687
/**
688
* @dev Atomically decreases the allowance granted to `spender` by the caller.
689
*
690
* This is an alternative to {approve} that can be used as a mitigation for
691
* problems described in {IERC20-approve}.
692
*
693
* Emits an {Approval} event indicating the updated allowance.
694
*
695
* Requirements:
696
*
697
* - `spender` cannot be the zero address.
698
* - `spender` must have allowance for the caller of at least
699
* `subtractedValue`.
700
*/
701
function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
702
address owner = _msgSender();
703
uint256 currentAllowance = allowance(owner, spender);
704
require(currentAllowance >= subtractedValue, "ERC20: decreased allowance below zero");
705
unchecked {
706
_approve(owner, spender, currentAllowance - subtractedValue);
707
}
708
709
return true;
710
}
711
712
/**
713
* @dev Moves `amount` of tokens from `sender` to `recipient`.
714
*
715
* This internal function is equivalent to {transfer}, and can be used to
716
* e.g. implement automatic token fees, slashing mechanisms, etc.
717
*
718
* Emits a {Transfer} event.
719
*
720
* Requirements:
721
*
722
* - `from` cannot be the zero address.
723
* - `to` cannot be the zero address.
724
* - `from` must have a balance of at least `amount`.
725
*/
726
function _transfer(address from, address to, uint256 amount) internal virtual {
727
require(from != address(0), "ERC20: transfer from the zero address");
728
require(to != address(0), "ERC20: transfer to the zero address");
729
730
_beforeTokenTransfer(from, to, amount);
731
732
uint256 fromBalance = _balances[from];
733
require(fromBalance >= amount, "ERC20: transfer amount exceeds balance");
734
unchecked {
735
_balances[from] = fromBalance - amount;
736
}
737
_balances[to] += amount;
738
739
emit Transfer(from, to, amount);
740
741
_afterTokenTransfer(from, to, amount);
742
}
743
744
/**
745
* @dev Creates `amount` tokens and assigns them to `account`, increasing
746
* the total supply.
747
*
748
* Emits a {Transfer} event with `from` set to the zero address.
749
*
750
* Requirements:
751
*
752
* - `account` cannot be the zero address.
753
*/
754
function _mint(address account, uint256 amount) internal virtual {
755
require(account != address(0), "ERC20: mint to the zero address");
756
757
_beforeTokenTransfer(address(0), account, amount);
758
759
_totalSupply += amount;
760
_balances[account] += amount;
761
emit Transfer(address(0), account, amount);
762
763
_afterTokenTransfer(address(0), account, amount);
764
}
765
766
/**
767
* @dev Destroys `amount` tokens from `account`, reducing the
768
* total supply.
769
*
770
* Emits a {Transfer} event with `to` set to the zero address.
771
*
772
* Requirements:
773
*
774
* - `account` cannot be the zero address.
775
* - `account` must have at least `amount` tokens.
776
*/
777
function _burn(address account, uint256 amount) internal virtual {
778
require(account != address(0), "ERC20: burn from the zero address");
779
780
_beforeTokenTransfer(account, address(0), amount);
781
782
uint256 accountBalance = _balances[account];
783
require(accountBalance >= amount, "ERC20: burn amount exceeds balance");
784
unchecked {
785
_balances[account] = accountBalance - amount;
786
}
787
_totalSupply -= amount;
788
789
emit Transfer(account, address(0), amount);
790
791
_afterTokenTransfer(account, address(0), amount);
792
}
793
794
/**
795
* @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens.
796
*
797
* This internal function is equivalent to `approve`, and can be used to
798
* e.g. set automatic allowances for certain subsystems, etc.
799
*
800
* Emits an {Approval} event.
801
*
802
* Requirements:
803
*
804
* - `owner` cannot be the zero address.
805
* - `spender` cannot be the zero address.
806
*/
807
function _approve(address owner, address spender, uint256 amount) internal virtual {
808
require(owner != address(0), "ERC20: approve from the zero address");
809
require(spender != address(0), "ERC20: approve to the zero address");
810
811
_allowances[owner][spender] = amount;
812
emit Approval(owner, spender, amount);
813
}
814
815
/**
816
* @dev Updates `owner` s allowance for `spender` based on spent `amount`.
817
*
818
* Does not update the allowance amount in case of infinite allowance.
819
* Revert if not enough allowance is available.
820
*
821
* Might emit an {Approval} event.
822
*/
823
function _spendAllowance(address owner, address spender, uint256 amount) internal virtual {
824
uint256 currentAllowance = allowance(owner, spender);
825
if (currentAllowance != type(uint256).max) {
826
require(currentAllowance >= amount, "ERC20: insufficient allowance");
827
unchecked {
828
_approve(owner, spender, currentAllowance - amount);
829
}
830
}
831
}
832
833
/**
834
* @dev Hook that is called before any transfer of tokens. This includes
835
* minting and burning.
836
*
837
* Calling conditions:
838
*
839
* - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
840
* will be transferred to `to`.
841
* - when `from` is zero, `amount` tokens will be minted for `to`.
842
* - when `to` is zero, `amount` of ``from``'s tokens will be burned.
843
* - `from` and `to` are never both zero.
844
*
845
* To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
846
*/
847
function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual {}
848
849
/**
850
* @dev Hook that is called after any transfer of tokens. This includes
851
* minting and burning.
852
*
853
* Calling conditions:
854
*
855
* - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
856
* has been transferred to `to`.
857
* - when `from` is zero, `amount` tokens have been minted for `to`.
858
* - when `to` is zero, `amount` of ``from``'s tokens have been burned.
859
* - `from` and `to` are never both zero.
860
*
861
* To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
862
*/
863
function _afterTokenTransfer(address from, address to, uint256 amount) internal virtual {}
864
865
}
866
867
868
/** ROUTER **/
869
870
interface IUniswapV2Pair {
871
872
event Approval(address indexed owner, address indexed spender, uint256 value);
873
874
event Transfer(address indexed from, address indexed to, uint256 value);
875
876
function name() external pure returns (string memory);
877
878
function symbol() external pure returns (string memory);
879
880
function decimals() external pure returns (uint8);
881
882
function totalSupply() external view returns (uint256);
883
884
function balanceOf(address owner) external view returns (uint256);
885
886
function allowance(address owner, address spender) external view returns (uint256);
887
888
function approve(address spender, uint256 value) external returns (bool);
889
890
function transfer(address to, uint256 value) external returns (bool);
891
892
function transferFrom(address from, address to, uint256 value) external returns (bool);
893
894
function DOMAIN_SEPARATOR() external view returns (bytes32);
895