<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectButton />

<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectLogo /><space /><projectName>{{ projectName }}</projectName>

Bug Bounty rewards are grouped by severity and the impact of the vulnerability. Examples and descriptions of the type of vulnerabilities that correspond to each severity level can be found below. The payout amount has a 5 tier structure with separate scalesfor website/apps and smart contracts.

Description of vulnerability and your proof of concept or validation steps

Name

Please input a title

Short description of the vulnerability and the affected asset.

The core team is situated in country(ies) that received low aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests an increased difficulty and complexity in preventing and mitigating fraud.

The core team is situated in country(ies) that received medium aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests a medium level of geographic accountability, thus reducing and mitigating the risk of fraud.

The core team is situated in country(ies) that received the best aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests the highest level of geographic accountability, thus maximizing the risk reduction and mitigation.

Vulnerability Title

In the contract `MultiToken` the role `_owner` has authority over the functions shown in the diagram below.
Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and:
- transfer the ownership to an address they control;
- change the URI;
- pause or unpause the contract (if `MultiToken` is deployed as pausable);
- grant or revoke the capacity to mint tokens from any address;
- grant or revoke the capacity to burn tokens from any address (if `MultiToken` is deployed as pausable);

![](https://accelerator-tasks-prod.s3.amazonaws.com/f658097ba27243648e500b85400ba67f/diagrams/centralization_MultiToken-MultiToken-_owner.svg)

-----
-----

In the contract `UtilityToken` the role `_owner` has authority over the functions shown in the diagram below.
Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and:
- transfer ownership to an address they control;
- grant or revoke the minter role from any address.

![](https://accelerator-tasks-prod.s3.amazonaws.com/f658097ba27243648e500b85400ba67f/diagrams/centralization_UtilityToken-UtilityToken-_owner.svg)

----
In the contract `UtilityToken` the role `minters` has authority over the functions shown in the diagram below.
Any compromise to the `minters` account may allow the hacker to take advantage of this authority and :
- mint any amount of tokens to any address;
- burn tokens they own or are approved to handle.

![](https://accelerator-tasks-prod.s3.amazonaws.com/f658097ba27243648e500b85400ba67f/diagrams/centralization_UtilityToken-UtilityToken-minters.svg)

-----
-----

In the contract `ItemNFT` the role `_owner` has authority over the functions shown in the diagram below.
Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and :
- grant or revoke the capacity to mint tokens to any address;
- grant or revoke the capacity to burn tokens to any address (if the contract has been deployed as burnable);
- change the URI;

![](https://accelerator-tasks-prod.s3.amazonaws.com/f658097ba27243648e500b85400ba67f/diagrams/centralization_ItemNFT-ItemNFT-_owner.svg)

-----
-----

In the contract `Vesting` the role `_owner` has authority over the functions shown in the diagram below.
Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and:
- transfer the ownership to an address they control;
- prepare a new vesting;
- set the start of a vesting;
- revoke the vesting and send the tokens to an address they control.

![](https://accelerator-tasks-prod.s3.amazonaws.com/f658097ba27243648e500b85400ba67f/diagrams/centralization_Vesting-Vesting-_owner.svg)

----

In the contract `Vesting` the role `beneficiary` has authority over the functions shown in the diagram below.
Any compromise to the `beneficiary` account may allow the hacker to take advantage of this authority and:
- change the beneficiary address to an address they control;
- claim tokens vested;


![](https://accelerator-tasks-prod.s3.amazonaws.com/f658097ba27243648e500b85400ba67f/diagrams/centralization_Vesting-Vesting-beneficiary.svg)

Centralization Related Risks

All tokens are sent to the contract deployer when deploying the contract. This is a potential centralization risk as the deployer can distribute tokens without the consensus of the community.

Initial Token Distribution

`Vesting` is an upgradeable contract, the owner can upgrade the contract without the community's commitment. If an attacker compromises the account, he can change the implementation of the contract and drain tokens from the contract.

Centralized Control of Contract Upgrade

The function `ERC721._mint()` updates the receiver balance as follows:
```solidity
        unchecked {
            // Will not overflow unless all 2**256 token ids are minted to the same owner.
            // Given that tokens are minted one by one, it is impossible in practice that
            // this ever happens. Might change if we allow batch minting.
            // The ERC fails to describe this case.
            _balances[to] += 1;
        }
```
In theory, the function `safeMintBatch()` could cause an overflow.

Batchminting does not prevent overflow

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=10
contract Vesting is OwnableUpgradeable {
```
- `Vesting` is an upgradeable contract that does not protect its initializer.

```solidity=47
    function initialize() public initializer {
```
- `initialize` is an unprotected initializer function.



Unprotected Initializer

The return value of the transfer()/transferFrom() call is not checked.

```solidity=93
        token.transferFrom(
            _distributor,
            address(this),
            initialVestingAmount * 10**18
        );
```


---
```solidity=146
            token.transfer(_reclaimer, _amount);
```


---
```solidity=169
        token.transfer(beneficiary, _amount * 10**18);
```



Unchecked ERC-20 `transfer()`/`transferFrom()` Call

Addresses should be checked before assignment or external call to make sure they are not zero addresses.

```solidity=187
        beneficiary = _newBeneficiary;
```
- `_newBeneficiary` is not zero-checked before being used.



Missing Zero Address Validation

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects.

*This finding is considered minor because the reentrancy only causes out-of-order events.*


Check Effect Interaction Pattern Violated

The contract is serving as the underlying entity to interact with one third-party protocol. The scope of the audit treats third-party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc.

---
```solidity=34
    IERC20 public token;
```
- The contract `Vesting` interacts with a third-party contract with `IERC20` interface via `token`.



Third Party Dependency

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user stakes 100 deflationary tokens (with a 10% transaction fee) in the `Vesting` contract, only 90 tokens actually arrive in the contract. However, the user can still withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction. 

Incompatibility With Deflationary Tokens

In the contract `Vesting.sol`, the function `revoke()` should have a check preventing `_reclaimer == address(this)`.
\
If the `_reclaimer` parameter is mistakenly set as the address of the contract, all tokens will stay in `Vesting`, and since after the transfer the `VestingStatus` is set as `REVOKED` it will be impossible to retrieve the tokens.

Missing Input Validation on `_reclaimer`

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

`Ownable2Step` is never used

One or more parameters with `memory` data location are never modified in their functions and those functions are never called internally within the contract. Thus, their data location can be changed to `calldata` to avoid the gas consumption copying from calldata to memory.

```solidity=14
    function setURI(string memory newuri) public {
```
`setURI` has memory location parameters: `newuri`.

---
```solidity=18
    function mint(
```
`mint` has memory location parameters: `data`.

---
```solidity=27
    function mintBatch(
```
`mintBatch` has memory location parameters: `ids`, `values`, `data`.

---
```solidity=44
    function burnBatch(
```
`burnBatch` has memory location parameters: `ids`, `values`.

---
```solidity=60
    function setURI(uint256 tokenId, string memory tokenURI_) public onlyOwner {
```
`setURI` has memory location parameters: `tokenURI_`.

---
```solidity=64
    function setBaseURI(string memory baseURI) public onlyOwner {
```
`setBaseURI` has memory location parameters: `baseURI`.

---
```solidity=121
    function mint(
```
`mint` has memory location parameters: `data`.

---
```solidity=130
    function mintBatch(
```
`mintBatch` has memory location parameters: `ids`, `amounts`, `data`.

---
```solidity=115
    function setTokenURI(uint256 tokenId, string memory _tokenURI)
```
`setTokenURI` has memory location parameters: `_tokenURI`.


Inefficient Memory Parameter

In the contract `Vesting.sol`, the function `prepare()` performs the following checks:
```solidity=71
        require(_duration > 0, "Vesting:  `_duration` is 0");
        // otherwise, claimer can claim all amount after first unlock period
        require(_amount > 0, "Vesting: `_amount` is 0");
```
```solidity=79
        require(
            _amount >= _duration,
            "Vesting: _amount must be greater than _duration"
        );
```

Since `_duration > 0` is enforced by the first **require** statement and `_amount >= _duration` is enforced by the third one, the `_amount > 0` is implied and:
```solidity=74
        require(_amount > 0, "Vesting: `_amount` is 0");
```
is redundant.

Unnecessary Check

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`"
        );
```

Checked arithmetic is unnecessary

In `Vesting.sol`, the functions `prepare()` and `claim()` transfer specific amounts of tokens. However, in the linked locations the amount is multiplied by 1e18 in the transfer functions.

The functions `transfer()` and `transferFrom()` from an ERC20 are already supposed to work without multiplying the amount by the decimals.

Inaccurate Transfer Amount

Iskra - Audit for Token (Part 1)

MultiToken.sol

GameToken.sol

UtilityToken.sol

ItemNFT.sol

Vesting.sol

Iskra offers a premier destination for players, developers and investors to explore the thrill and opportunity of Web3 gaming alongside a vibrant community.


Leaderboards

Due Diligence Tools

Resources

KYC Status

Bug Bounty Program