# Gysr Audit
## Info
- Auditor: Amine El-merzouki
- Commit hash:
git repository (commit hash)
## Disclaimers
## Issues
# ==core 1.0.0==
## ==Geyser.sol==
### Missing Value Verification[Medium]
**Description**
Certain functions lack a value safety check, the values of the arguments should be verified to allow only the ones that comply with the contract’s logic. In the `create()` function, the contract must verify bonusMin,bonusMax and bonusPeriod variables.
**File(s)**
* `contract/GeyserFactory.sol` (L209,)
**Recommendation**
We recommend that you verify the variables provided in the arguments. The issue can be addressed by utilizing a require statement to verify if bonusMin & bonusPeriod doesn't equal 0 and bonusMax according the contract logic.
**********
### Missing address verification [Low]
**Description**
Certain functions lack a safety check in the address, the address-type arguments should include a zero-address test, otherwise, the contract's functionality may become inaccessible.
**File(s)**
* `contract/Geyser.sol` (L99,100,153)
**Recommendation**
We recommend that you make sure the addresses provided in the arguments are different from the address(0).
*******
### Usage of block.timestamp[low]
**Description**
Block.timestamp is used in the contract. The variable block is a set of variables. The timestamp does not always reflect the current time and may be inaccurate. The value of a block can be influenced by miners. Maximal Extractable Value attacks require a timestamp of up to 900 seconds. There is no guarantee that the value is right, all what is guaranteed is that it is higher than the timestamp of the previous block
**File(s)**
* `contract/Geyser.sol` (L99,100,153,214,474,489,493,499,503,506,527,552,560,565,732,762)
**Recommendation**
Verify that a delay of 900 seconds will not harm the logic of the contract.
**********
### For Loop Over Dynamic Array [Low]
**Description**
When smart contracts are deployed or their associated functions are invoked, the
execution of these operations always consumes a certain quantity of gas, according to the amount of computation required to accomplish them. Modifying an unknown- size array that grows in size over time can result in a Denial-of-Service attack. Simply by having an excessively huge array, users can exceed the gas limit, therefore preventing the transaction from.

**File(s)**
* `contract/Geyser.sol` (L296,522,702)
**Recommendation**
We recommend that the team avoid any actions that involve looping across the entire data structure. If you really must loop over an array of unknown size, you will need to arrange for it to consume many blocks and thus multiple transactions.

*************
### Floating Pragma [Low]
**Description**
The contract makes use of the floating-point pragma 0.8.6 . Contracts should be
deployed using the same compiler version and flags that were used during the testing
process.Locking the pragma helps ensure that contracts are not unintentionally deployed
using another pragma, such as an obsolete version, that may introduce issues in the
contract system.

**File(s)**
* `contract/Geyser.sol` (L15)

**Recommendation**
Consider locking the pragma version. It is advised that floating pragma should not be used
in production. Both truffle-config.js and hardhat.config.js support locking the pragma
version.
********
### Unnecessary Initializations[Best-practice]
**Description**
When a variable is declared in solidity, it gets initialized with its type’s default value. Thus,
there is no need to initialize a variable with the default value.
**File(s)**
* `contract/Geyser.sol` (L294,434,436,513,521,699,701,725,726)

## ==GeyserFactory.sol==
### Missing Value Verification[Medium]
**Description**
Certain functions lack a value safety check, the values of the arguments should be verified to allow only the ones that comply with the contract’s logic. In the `create()` function, the contract must verify bonusMin,bonusMax and bonusPeriod variables.
**File(s)**
* `contract/GeyserFactory.sol` (L36,37,38)
**Recommendation**
We recommend that you verify the variables provided in the arguments. The issue can be addressed by utilizing a require statement to verify if bonusMin & bonusPeriod doesn't equal 0 and bonusMax according the contract logic.

*****
### Missing address verification [Low]
**Description**
Certain functions lack a safety check in the address, the address-type arguments should include a zero-address test, otherwise, the contract's functionality may become inaccessible.
**File(s)**
* `contract/GeyserFactory.sol` (L26,34,35)
**Recommendation**
We recommend that you make sure the addresses provided in the arguments are different from the address(0).

**************
### Floating Pragma [Low]
**Description**
The contract makes use of the floating-point pragma 0.8.6 . Contracts should be
deployed using the same compiler version and flags that were used during the testing
process.Locking the pragma helps ensure that contracts are not unintentionally deployed
using another pragma, such as an obsolete version, that may introduce issues in the
contract system.

**File(s)**
* `contract/GeyserFactory.sol` (L12)

**Recommendation**
Consider locking the pragma version. It is advised that floating pragma should not be used
in production. Both truffle-config.js and hardhat.config.js support locking the pragma
version.
********
### Public Function Can Be Called External[Best-practice]
**Description**
Functions with a public scope that are not called inside the contract should be
declared external to reduce the gas fees

**File(s)**
* `contract/GeyserFactory.sol` (L33,63)
**Recommendation**
Declare the create() and count() functions as external.

*****
## ==GeyserToken.sol==
### Approve Race Condition[Low]
**Description**
The standard ERC20 implementation contains a widely known racing condition in its approve function, wherein a spender can witness the token owner broadcast a transaction altering their approval and quickly sign and broadcast a transaction using transferFrom to move the current approved amount from the owner's balance to the spender. If the spender's transaction is validated before the owner's, the spender will be able to get both approval amounts of both transactions.

**File(s)**
* `contracts/GeyserPool.sol` (L16)

**Recommendation**
We recommend that you prevent the owner from calling renounceOwnership without first transferring ownership to a different address. Additionally, if you decide to use a multi-signature wallet, then the execution of the renounceOwnership will require for at least two or more users to be confirmed. Alternatively, you can disable Renounce Ownership functionality by overriding it.
******
### Floating Pragma [Low]
**Description**
The contract makes use of the floating-point pragma 0.8.6 . Contracts should be
deployed using the same compiler version and flags that were used during the testing
process.Locking the pragma helps ensure that contracts are not unintentionally deployed
using another pragma, such as an obsolete version, that may introduce issues in the
contract system.

**File(s)**
* `contract/GeyserToken.sol` (L11)
**Recommendation**
Consider locking the pragma version. It is advised that floating pragma should not be used
in production. Both truffle-config.js and hardhat.config.js support locking the pragma
version.
## ==GeyserPool.sol==
### Owner Can Renounce Ownership [Low]
**Description**
Typically, the account that deploys the contract is also its owner. Consequently, the owner is able to engage in certain privileged activities in his own name. In smart contracts, the renounceOwnership function is used to renounce ownership, which means that if the contract's ownership has never been transferred, it will never have an Owner, rendering some owner-exclusive functionality unavailable.

**File(s)**
* `contracts/GeyserPool.sol` (L20)

**Recommendation**
We recommend that you prevent the owner from calling renounceOwnership without first transferring ownership to a different address. Additionally, if you decide to use a multi-signature wallet, then the execution of the renounceOwnership will require for at least two or more users to be confirmed. Alternatively, you can disable Renounce Ownership functionality by overriding it.

### Missing address verification [Low]
**Description**
Certain functions lack a safety check in the address, the address-type arguments should include a zero-address test, otherwise, the contract's functionality may become inaccessible.
**File(s)**
* `contract/GeyserPool.sol` (L25)
**Recommendation**
We recommend that you make sure the addresses provided in the arguments are different from the address(0).

**************
### Floating Pragma [Low]
**Description**
The contract makes use of the floating-point pragma 0.8.6 . Contracts should be
deployed using the same compiler version and flags that were used during the testing
process.Locking the pragma helps ensure that contracts are not unintentionally deployed
using another pragma, such as an obsolete version, that may introduce issues in the
contract system.

**File(s)**
* `contract/GeyserPool.sol` (L14)

**Recommendation**
Consider locking the pragma version. It is advised that floating pragma should not be used
in production. Both truffle-config.js and hardhat.config.js support locking the pragma
version.
********
### Public Function Can Be Called External[Best-practice]
**Description**
Functions with a public scope that are not called inside the contract should be
declared external to reduce the gas fees

**File(s)**
* `contract/GeyserPool.sol` (L29)
**Recommendation**
Declare the balance() function as external.

***************
# ==core Master==
## ==ERC20BaseRewardModule.sol==
### Missing address verification [Low]
**Description**
Certain functions lack a safety check in the address, the address-type arguments should include a zero-address test, otherwise, the contract's functionality may become inaccessible.
**File(s)**
* `contract/ERC20BaseRewardModule.sol` (L47,61,232,233,205,)
**Recommendation**
We recommend that you make sure the addresses provided in the arguments are different from the address(0).
********
### Usage of block.timestamp[low]
**Description**
Block.timestamp is used in the contract. The variable block is a set of variables. The timestamp does not always reflect the current time and may be inaccurate. The value of a block can be influenced by miners. Maximal Extractable Value attacks require a timestamp of up to 900 seconds. There is no guarantee that the value is right, all what is guaranteed is that it is higher than the timestamp of the previous block
**File(s)**
* `contract/ERC20BaseRewardModule.sol` (L99,107,132,212)
**Recommendation**
Verify that a delay of 900 seconds will not harm the logic of the contract.
**********
### For Loop Over Dynamic Array [Low]
**Description**
When smart contracts are deployed or their associated functions are invoked, the
execution of these operations always consumes a certain quantity of gas, according to the amount of computation required to accomplish them. Modifying an unknown- size array that grows in size over time can result in a Denial-of-Service attack. Simply by having an excessively huge array, users can exceed the gas limit, therefore preventing the transaction from.

**File(s)**
* `contract/ERC20BaseRewardModule.sol` (L174,207)
**Recommendation**
We recommend that the team avoid any actions that involve looping across the entire data structure. If you really must loop over an array of unknown size, you will need to arrange for it to consume many blocks and thus multiple transactions.

*************
## ==ERC20CompetitiveRewardModule.sol==
### Missing Value Verification[Medium]
**Description**
Certain functions lack a value safety check, the values of the arguments should be verified to allow only the ones that comply with the contract’s logic. In the `constructor()` function, the contract must verify bonusMin,bonusMax and bonusPeriod variables.
**File(s)**
* `contract/ERC20CompetitiveRewardModule.sol` (L60)
**Recommendation**
We recommend that you verify the variables provided in the arguments. The issue can be addressed by utilizing a require statement to verify if bonusMin & bonusPeriod doesn't equal 0 and bonusMax according the contract logic.
**********
### Missing Value Verification 2[Medium]
**Description**
Certain functions lack a value safety check, the values of the arguments should be verified to allow only the ones that comply with the contract’s logic. In the `_stake()` & `_unstake()` functions, the contract must verify shares variable
**File(s)**
* `contract/ERC20CompetitiveRewardModul.sol` (L263,280)
**Recommendation**
We recommend that you verify the variables provided in the arguments. The issue can be addressed by utilizing a require statement to verify if shares doesn't equal 0 .
**********
### Missing address verification [Low]
**Description**
Certain functions lack a safety check in the address, the address-type arguments should include a zero-address test, otherwise, the contract's functionality may become inaccessible.
**File(s)**
* `contract/ERC20CompetitiveRewardModul.sol` (L125,139,152,153,252,263,281,282)
**Recommendation**
We recommend that you make sure the addresses provided in the arguments are different from the address(0).
******
### Usage of block.timestamp[low]
**Description**
Block.timestamp is used in the contract. The variable block is a set of variables. The timestamp does not always reflect the current time and may be inaccurate. The value of a block can be influenced by miners. Maximal Extractable Value attacks require a timestamp of up to 900 seconds. There is no guarantee that the value is right, all what is guaranteed is that it is higher than the timestamp of the previous block
**File(s)**
* `contract/ERC20CompetitiveRewardModul.sol` (L76,188,265,354,356,377)
**Recommendation**
Verify that a delay of 900 seconds will not harm the logic of the contract.
**********
## ==ERC20FriendlyRewardModule.sol==
### Missing Values Verification [Medium]
**Description**
Certain functions lack a value safety check, the values of the arguments should be verified to allow only the ones that comply with the contract’s logic. In the `_stake()` & `_unstake()` functions, the contract must verify shares variable
**File(s)**
* `contract/ERC20FriendlyRewardModule.sol` (L149,186)
**Recommendation**
We recommend that you verify the variables provided in the arguments. The issue can be addressed by utilizing a require statement to verify if shares doesn't equal 0 .
**********
### Missing address verification [Low]
**Description**
Certain functions lack a safety check in the address, the address-type arguments should include a zero-address test, otherwise, the contract's functionality may become inaccessible.
**File(s)**
* `contract/ERC20FriendlyRewardModule.sol` (L71,74,131,132,150,151,187,188,205,206,293,294,447)
**Recommendation**
We recommend that you make sure the addresses provided in the arguments are different from the address(0).
*********
### Usage of block.timestamp[low]
**Description**
Block.timestamp is used in the contract. The variable block is a set of variables. The timestamp does not always reflect the current time and may be inaccurate. The value of a block can be influenced by miners. Maximal Extractable Value attacks require a timestamp of up to 900 seconds. There is no guarantee that the value is right, all what is guaranteed is that it is higher than the timestamp of the previous block
**File(s)**
* `contract/ERC20FriendlyRewardModule.sol` (L84,173,218,331,364,387)
**Recommendation**
Verify that a delay of 900 seconds will not harm the logic of the contract.
**********

## ==PoolFctory.sol==
### Missing address verification [Low]
**Description**
Certain functions lack a safety check in the address, the address-type arguments should include a zero-address test, otherwise, the contract's functionality may become inaccessible.
**File(s)**
* `contract/PoolFactory.sol` (L60,61)
**Recommendation**
We recommend that you make sure the addresses provided in the arguments are different from the address(0).

### Race Condition [Medium]
**Description**
The _fee variable have setter. If the user checks the value of one of these variables, then performs a transaction, and the owner updates the fees, the order of the transaction might overturn and the user's transaction in this case will be executed with the new variables without him knowing about it.
**File(s)**
* `contract/PoolFactory.sol` (L134)
**Recommendation**
It is recommended to notify the users before modifying the _fee variable or to add it in the arguments with a require which makes sure that the one in the contract is the same as the one provided in the arguments.

## ==ERC20StakingModule.sol==
### Missing address verification [LOW]
**Description**
Certain functions lack a safety check in the address, the address-type arguments should include a zero-address test, otherwise, the contract's functionality may become inaccessible.
**File(s)**
* `contract/ERC20StakingModule.sol` (L41,L42,68)
**Recommendation**
We recommend that you make sure the addresses provided in the arguments are different from the address(0).

## ==ERC721StakingModule.sol==
### Missing address verification [Low]
**Description**
Certain functions lack a safety check in the address, the address-type arguments should include a zero-address test, otherwise, the contract's functionality may become inaccessible.
**File(s)**
* `contract/ERC20StakingModule.sol` (L41,42,68)
**Recommendation**
We recommend that you make sure the addresses provided in the arguments are different from the address(0).
*********