<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

transfer

transferFrom

totalSupply

balanceOf

allowance

approve

OPEN

In `OpenStaking`, the privileged role `isOperator` has power over functions `addOperator()` and `removeOperator()`.
\
Any operator can then remove anyone from the set of operators, if a malicious user acquires the role `isOperator`, they would be able to revoke the privileged role from any other user.

Operators can remove each other

All `OPEN` tokens are sent to the address given as an input parameter when initializing the contract. This is a potential centralization risk as the receiver can distribute `OPEN` tokens without the consensus of the community.

Initial Token Distribution

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

Centralized Control of Contract Upgrade

In the contract `OapRouter` 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:
- set any address they control as the owner;
- set any address as the new `pancakeRouter`;
- set any address as the new `rewardRouter`;
- set any token address as whitelisted or non-whitelisted;

This could lead to a loss of assets or complete sabotage of the contract.
![](https://accelerator-tasks-prod.s3.amazonaws.com/47bbbe913bd4401da71b840d104cf680/diagrams/centralization_OapRouter-OapRouter-_owner.svg)

-----

In the contract `OpenStaking.sol` the role `isOperator` has authority over the following functions:

- `addOperator()`
- `removeOperator()`
- `setUnstakingFee()`
- `setUnstakingThreshold()`
- `emergencyWithdraw()`

Any compromise to an `isOperator` account may allow a hacker to take advantage of this authority and :
- set any address they control as an operator;
- revoke the operator privilege from any other address;
- set the fees to any value less than 20%, those fees will not be transferred to the caller unstaking their `depositToken`;
- set any non-zero value as `unstakingThreshold`;
- drain all ERC20 tokens from the contract.

-----

In the contract `RewardRouterV2.sol`, the role `onlyGov` has authority over the following functions:

- `initialize()`
- `withdrawToken()`
- `batchStakeOpenForAccount()`
- `stakeOpenForAccount()`
- `compoundForAccount()`
- `batchCompoundForAccounts()`

Any compromise to an `onlyGov` account may allow a hacker to take advantage of this authority and:
- initialize the contract if it has not be done already;
- drain all ERC20 from the contract;
- open staking for any address;
- allow compounding for any address;

-----

In the contract `OPEN` 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;
- mint any amount of token to any address;
- burn any amount of token from any address;
- blacklist or whitelist any address, both for EOA and contracts;
- add or remove any address to the set of `_sellAddresses`;
- change the `sellFeeRate`;
- add or remove any address to the set of `_exceptionAddresses`;
- set any address as the `stakerAddress`;
- drain every ERC20 token from the contract.
![](https://accelerator-tasks-prod.s3.amazonaws.com/9fe3bd7dbf554fe2ac1040822258b010/diagrams/centralization_OpenWorld-OPEN-_owner.svg)


Centralization Related Risks

In `OpenWorld.sol`, when `initialize()` is called the caller will be set as the `owner` of the contract and will also be approved to transfer up to the total supply of `OPEN` tokens from the contract.

This allowance will not be revocated nor transferred if the ownership is renounced or transferred.

Initializer Gives Large Allowance 

In `OpenWorld.sol`, the contract inherits `ERC20PausableUpgradeable` and uses extensively the `whenNotPaused` modifier to prevent many functions from being called if the contract is paused.
\
However, the contract does not implement any function allowing to set `_paused` as true. Therefore the contract is not pausable.

`OPEN` is not pausable

When transferring deflationary ERC20 tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee), only 90 tokens actually arrived to the contract. However, a failure to discount such fees may allow the same user to withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction.

Reference:
https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f


Incompatibility with Deflationary Tokens

In `OapRouter.sol`, the function `swapAndStake()` does not require any type of whitelisting for `tokenIn`.

A malicious contract could be given as input. Moreover, some legit contracts could interfere with the logic of the functions, for example, deflationary tokens will not work well with `swapExactTokensForTokens()`.

No Restriction on `tokenIn`

The mathematical expression does not check arithmetic overflow. Such unsafe math operations may cause unexpected behavior if unusual parameters are given.

Here `depositToken` is set when deploying the contract, hence it is not possible to guarantee the logic of the ERC20 will interact safely with `OpenStaking`.

SafeMath Not Used

In `OpenWorld.sol`, the contract `OPEN` does not protect its initializer. 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=6
contract OPEN is ERC20PausableUpgradeable, OwnableUpgradeable {
```
- `OPEN` is an upgradeable contract that does not protect its initializer.

```solidity=31
    function initialize(address owner_) public initializer {
```
- `initialize` is an unprotected initializer function.



Unprotected Initializer

In `OpenWorld.sol`, the function `burn()` is the only function allowing any user to modify the state of the contract `OPEN` (under specific conditions) that is not pausable.

`burn()` is Not Pausable

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

Missing Zero Address Validation

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

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

In `OpenWorld.sol`, There are no upper boundaries for `setSellFeeRate()`, it is possible to set `sellFeeRate` up to any arbitrary amount.
\
However, if `sellFeeRate > 1000` then `getValuesWithSellRate()` might fail unexpectedly, preventing `transfer()` and `transferFrom()` to work correctly.

-----

In `OpenStaking.sol`, there are no upper boundaries for `setUnstakingThreshold()`, it is possible to set `unstakingThreshold` up to any arbitrary value.
\
If `unstakingThreshold` is set to a very high value then `unstake()` will fail before the threshold is passed, preventing users from unstaking their tokens.

Missing Bounds

In `RewardRouterV2.sol`, the function `batchStakeOpenForAccount()` does not check that `_accounts` and `_amounts` have the same length.

Missing Check for Array's Length

External calls are made inside a *for* loop. This might lead to a denial-of-service, if any of the calls fail, it will cause the entire loop to revert.

External Call Inside Loop

States variables should be updated before making an external call to another contract. Interacting with external contracts increases the complexity of a function and makes its behavior less predictable.

Following the check effect interaction pattern allows for preventing unexpected mistakes. 

Check Effect Interaction Pattern Violated

The return value of an external call is not stored in a local or state variable.

Unused Return Value

In `OpenStaking.sol`, the functions `submit()` and `_submit()` take an address `_referral` as an input parameter. This address is only used during an event emission and has no effect on the logic of the contract.

Could you please provide us with more information about how this variable will be used off-chain?

Unnecessary `_referral` Parameter

The linked function is equivalent to the compiler-generated getter function for the respective variable.

User-Defined Getters

In `OpenWorld.sol`, the mapping `_nextClaimTime` is private and never used in the contract `OPEN`.

```solidity=15
    mapping(address => uint256) private _nextClaimTime;
```

Unused Private Mapping

In `OpenWorld.sol`, the function `transferFrom()` performs two checks returning the same error message:
```solidity=81
        require(
            tokenBlacklist[_from] == false && tokenBlacklist[_to] == false,
            "Blacklist address cannot transfer"
        );

        require(
            tokenBlacklist[msg.sender] == false,
            "Blacklist address cannot transfer"
        );
```


Duplicated Error Messages

In `OpenWorld.sol`, the state variable `stakerAddress` is defined and can be set to any address, however, it is never used.

`stakerAddress` Never Used

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.

Variables That Could Be Declared as Immutable

In `OpenWorld.sol`, the function `initialize()` takes an address as a parameter named `owner_`. This parameter will be used to set the `feeAddress` and will receive all the `INITIAL_SUPPLY`.
\
`OwnableUpgradeable.__Ownable_init();` will set the initializer address as the `owner` of the contract.

The name `owner_` could lead one to think that the address provided will be the owner of the contract when it is not the case.

Misleading Variable Names

The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

Missing Error Messages

Boolean constants can be used directly and do not need to be compared to true or false.
---
```solidity=45
        require(
            tokenBlacklist[msg.sender] == false && tokenBlacklist[_to] == false,
            "Blacklist address cannot transfer"
        );
```


---
```solidity=50
        require(
            isContractTransferBlock(msg.sender, _to) == false,
            "This address cannot send to ContractBlacklist Address"
        );
```


---
```solidity=54
        require(
            isContractTransferBlock(_to, msg.sender) == false,
            "This address cannot receive from ContractBlacklist Address"
        );
```


---
```solidity=81
        require(
            tokenBlacklist[_from] == false && tokenBlacklist[_to] == false,
            "Blacklist address cannot transfer"
        );
```


---
```solidity=86
        require(
            tokenBlacklist[msg.sender] == false,
            "Blacklist address cannot transfer"
        );
```


---
```solidity=91
        require(
            isContractTransferBlock(_from, _to) == false,
            "This address cannot send to ContractBlacklist Address"
        );
```


---
```solidity=95
        require(
            isContractTransferBlock(_to, _from) == false,
            "This address cannot receive from ContractBlacklist Address"
        );
```



Comparison to Boolean Constant

```solidity=24
    event Mint(address indexed from, address indexed to, uint256 value);
```
- `Mint` is declared in `OPEN` but never emitted.


---
```solidity=25
    event Burn(address indexed burner, uint256 value);
```
- `Burn` is declared in `OPEN` but never emitted.



Unused Event

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Missing Emit Events

In `RewardRouterV2.sol`, the function `_unstakeOpen()` computes a `reductionAmount` to burn as follow:
```solidity=695
                uint256 reductionAmount = stakedBnOpen.mul(_amount).div(
                    balance
                );
```
if `stakedBnOpen.mul(_amount) < balance` then the burnt amount will be zero.


`reductionAmount` could equal zero

Open World

OpenStaking.sol

OapRouter.sol

StOPEN.sol

RewardRouterV2.sol

OrderExecutor.sol

OpenWorld.sol

Top 10% Watchlisted

Top 10% Security Score

OpenWorld is a decentralized perpetual exchange that aims to provide crypto community derivative exposure to not only cryptoassets but also wider financial products and assets that have been developed from the traditional finance space.

Leaderboards

Due Diligence Tools

Resources

KYC Status