Iskra security record

In `InitialGameOffering.sol`, many functions are depending on the `status()` of the contract to execute correctly. The `status()` depends heavily on the time marks and periods defined using the function `_changeSaleTimeline()`. This function allows the time intervals to have arbitrarily large values. This can cause the state of the contract to be stuck for a crucial amount of time. Since `refund()` and `claim()` functions are also dependent on the status of the contract, this could lead to a loss of assets for users.

Addresses should be checked before assignment or external call to make sure they are not zero addresses. ```solidity=66 token = token_; ``` - `token_` is not zero-checked before being used. --- ```solidity=112 operator = operator_; ``` - `operator_` is not zero-checked before being used.

In `InitialGameOffering.sol`, the function `initialize()` does not perform an upper bound check when setting `sellerFeePerMille` and `buyerFeePerMille` although those values cannot be set higher than 1000 in any other functions.

The function `_verifySignature()` does not perform enough checks to prevent someone from reusing the same parameter more than once. \ This could potentially be used to perform a replay attack. In the scope of this audit, the signature mechanism seems to be used only to ensure a user participating in an `InitialGameOffering` is authorized to do so. In this case, the replay allowed by the signature verification seems to be fine since it will only allow a specific user to participate.

A local variable is shadowing another component defined elsewhere. ```solidity=72 string memory symbol = abi.decode(queriedSymbol, (string)); ``` - Local variable `symbol` in `IGOVesting.initialize` shadows: - Function `symbol` in `ERC20Upgradeable` - Function `symbol` in `IERC20MetadataUpgradeable` --- ```solidity=16 constructor(address signer) StructuredSignVerifier("LaunchpadQualificationChecker", signer, 5 minutes) {} ``` - Local variable `signer` in `LaunchpadQualificationChecker.constructor` shadows the variable `signer` in `StructuredSignVerifier`.

In the linked locations, a function is creating a local variable `prev` whose only purpose is to be used in an event.

One or more logic contracts do not protect their initializers. An attacker can call the initializer and assume ownership of the logic contract, whereby she can perform privileged operations that trick unsuspecting users into believing that she is the owner of the upgradeable contract. ```solidity=15 contract IGOVesting is OwnableUpgradeable, IIGOVesting, ERC20Upgradeable, ERC165 { ``` - `IGOVesting` is an upgradeable contract that does not protect its initializer. ```solidity=53 function initialize( ``` - `initialize` is an unprotected initializer function. --- ```solidity=16 contract InitialGameOffering is OwnableUpgradeable, IInitialGameOffering { ``` - `InitialGameOffering` is an upgradeable contract that does not protect its initializer. ```solidity=90 function initialize( ``` - `initialize` is an unprotected initializer function.

The return value of an external call is not stored in a local or state variable. ```solidity=433 IERC20Upgradeable(_vesting.token()).approve(address(_vesting), amount); ```

The contract `GameToken` is importing and inheriting the `Ownable2Step` contract, however, the `onlyOwner` modifier is never used in the contract.

The contract `Vesting.sol` is using a solidity version greater than 0.8.0; this version has built-in checks in the compiler preventing overflow/underflow of arithmetic operators. In the function `prepare()`, the varaible `_totalLocked` is computed as follow: ```solidity=88 initialVestingAmount = _amount; initialUnlockedAmount = _initialUnlocked; uint256 _totalLocked = initialVestingAmount - initialUnlockedAmount; ``` meaning that `_totalLocked = _amount - _initialUnlocked`, hence any underflow is prevented by the following check: ```solidity=74 require( _amount >= _initialUnlocked, "Vesting: `_initialUnlocked` is greater than `_amount`" ); ```