<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

### MpRewarder

In the contract `MpRewarder` the role `isAdmin` has authority over the following functions:

- `claim()`
- `setStakingManager()`
- `setRewardRate()`
- `setBooster()`
  
Any compromise to the `isAdmin` role may allow the hacker to take advantage of this authority and do the following:

- claim rewards for the user to another address;
- change the staking manager or booster to a malicious contract allowing them to gain more rewards or clear the rewards of other users;
- change the reward rate;


### RewardBooster

In the contract `RewardBooster` the role `isAdmin` has authority over the following functions:

- `setUserRatios()`
- `setMPRewarder()`
- `setAutoCompounder()`
- `setVolumeBR()`
- `setTvlBR()`
- `setAutoCompoundBR()`

Any compromise to the `isAdmin` role may allow the hacker to take advantage of this authority change the reward boost of any user to whatever value they wish.

### SimpleRewarder

In the contract `SimpleRewarder` the role `isAdmin` has authority over the following functions:

- `claim()`
- `setStakingManager()`
- `setRewardPerBlock()`

Any compromise to the `isAdmin` role may allow the hacker to take advantage of this authority and do the following:

- claim rewards for the user to another address;
- change the staking manager to a malicious contract allowing them to gain more rewards or clear the rewards of other users;
- change the reward rate per block;


Centralization Related Risks

When `Woo` is unstaked a proportional amount of `MP` tokens are to be burned from the user, however, an admin can claim a users `MP` to another address allowing them to keep their `MP` in another address. This allows the user to unstake their `Woo`, but still have the same amout of `MP` held by another address.

Admin Can Claim MP To Another User 

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

The following functions do not verify the input `address` is not the zero address:

### MpRewarder
- In the `constructor()`, the input `_rewardToken` and `stakingManager`.
- In the function `setStakingManager()`, the input `_manager`.
- In the function `setBooster()`, the input `_booster`.

### RewardBooster
- In the `constructor()`, the input `_mpRewarder` and `_compounder`.
- In the function `setMPRewarder()`, the input `_rewarder`.
- In the function `setAutoCompounder(), the input `_compounder`.

### SimpleRewarder
- In the `constructor()`, the input `_rewardToken` and `_stakingManager`.
- In the function `setStakingManager()`, the input `_manager`.


Missing Zero Address Validation

If `setStakingManager()` is called to change the `stakingManager`, the new `stakingManager` is set as an admin. However, the old `stakingManager` is not removed as an admin. If the `stakingManager` is changed due to a compromise in the old `stakingManager` it should be ensured that they are removed as an Admin.

Does Not Revoke Previous Authority

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.

*Considering the reentrancy is only possible if certain tokens are used or an implementation is changed we mark this as minor*

### External call(s)
```solidity=86
        stakingManager.addMP(_to, rewardAmount);
```

### State variables written after the call(s)
```solidity=87
        rewardClaimable[_user] = 0;
```

```solidity=88
        totalRewardClaimable -= rewardAmount;
```

With the current implementation of `addMP` in the contract `stakingManager` this is not possible. However, if the implementation changes to make an external call it may be possible to reenter the contract `MpRewarder` and call `updateReward()` or `updateRewardForUser()`.


---
### External call(s)
```solidity=155
        TransferHelper.safeTransfer(rewardToken, _to, rewardAmount);
```

### State variables written after the call(s)
```solidity=157
        rewardClaimable[_user] = 0;
```

```solidity=156
        totalRewardClaimable -= rewardAmount;
```

In this case if the `rewardToken` implements hooks, then it may be possible to reenter the contract `SimpleRewarder` to call `updateReward()` or  `updateRewardForUser()`.

Potential Reentrancy

When calculating `rewards` the following calculation is made:

```solidity
uint256 rewards = ((block.timestamp - lastRewardTs) * _totalWeight * rewardRate) / 10000 / 31536000;
```

However if instead of the dividing by $10000$ and then dividing by $31536000$, if it is divided by $(1000*31536000)$ it can reduce gas costs. This will slightly reduce the deployment size saving on deployment gas costs and save a small amount of gas on function calls.

Divide By Multiplication Instead Of Double Division

Suffixes like seconds, minutes, hours, and days can be used to specify units of time where seconds are the base unit and units are considered naively in the following way:

- `1` == `1 seconds`
- `1 minutes` == `60 seconds`
- `1 hours` == `60 minutes`
- `1 days` == `24 hours`

This can increase the readability of the code.

Time units can be used directly

The contract `MpRewarder` inherits `IRewarder` and thus must implement a `rewardToken()` function. However, this contract never uses the reward token and is designed to reward `MP` as opposed to a token.

`rewardToken` Unused In `MpRewarder`

The magic number `10000` is used as a denominator for the reward rate in the contract `MpRewarder`. Similarly the magic number `1e18` is used in the contract `MpRewarder` and `SimpleRewarder` for precision.

Usage of Magic Numbers

In the contract `RewardBooster`, the functions `setVolumeBR()`, `setTvlBR()`, and `setAutoCompoundBR()` are all used to change the respective boost ratio. However, the input is never checked to ensure that it will boost the rewards. We recommend checking that the input is greater than or equal to `base` to ensure that the boost is always greater than or equal to 1.

In the contract `MpRewarder`, the function `setRewardRate()` does not have an upper or lower bound. We recommend setting reasonable upper and lower bounds for the reward rates and checking against them. 

Missing Checks

Woofi Ⅴ Addendum

MpRewarder.sol

RewardBooster.sol

SimpleRewarder.sol

Check Effect Interaction Pattern Violated

Third Party Dependency

Hardcoded decimal

WOOFi - Ⅳ

WooPPV2.sol

WooracleV2.sol

Third Party Dependencies

Missing Input Validation

Unknown Imported Source File

Missing Error Messages

Missing Emit Events

Divide Before Multiply

Fee Collectors

Unused `Pausable` Feature

Incompatibility With Deflationary Tokens

WOOFi Ⅲ

WooLendingManager.sol

WooSuperChargerVault.sol

WooWithdrawManager.sol

Missing emit events

Lack of Input Validation

Return value not handled

Wrong Path To Swap `lpToken1`

Address Type Could Be Indexed In Events

Magic Numbers

Contract Locks Ether

Lack Of  Stop Strategy In `setupStrat`

Unknown Imported Source Files

Strategy not Support `WBNB`

WOOFi II

StrategyCake.sol

contracts

WOOFi2

BaseStrategy.sol

StrategyLP.sol

Vault.sol

Centralization Risk

WOOFi

WooRebateManager.sol

WooVaultManager.sol

WooStakingVault.sol

Unlocked Compiler Version Declaration

Lack Of Access Control

Additional Rewards Not Transferred

Potential Call Data Attack

Discussion For `internalFallbackSwap`

WOOFi Swap

RewardManager.sol

WooPP_newmath.sol

WooRouter.sol

Top 10% Security Score

Top 10% Code Security Score

Top 10% Governance Score

Top 10% Community Score

Top 10% Market Score

Top 10% Operation Score

WOO Network is a deep liquidity network that connects traders, exchanges, institutions, and DeFi platforms with democratized access to the best-in-class liquidity, trading execution, and yield generation strategies at lower or zero cost. Currently, the available WOO Network set of products and services, include: WOO X, WOO Network, WOOFi, and WOOFi DEX.

Leaderboards

Due Diligence Tools

Resources

KYC Status