Read the findings of the 2022 Web3 Security Report

The `_owner` of the contract `NutPower` has the responsibility to notify users about the following capabilities:
- set the address of `nut` through `adminSetNut()`
- add an address to whitelist/remove the address from whitelist through `adminSetWhitelist()`

The `_owner` of the contract `Gauge` has the responsibility to notify users about the following capabilities:
- set the ratio of user harvest cToken through `adminSetGaugeRatio()`
- set `rewardNUTPerBlock` and update accs through `adminSetRewardNUTPerBlock()`
- set `distributionRatio.community`, `distributionRatio.poolFactory`,`distributionRatio.user` and update accs through `adminSetNutDistributionRatio()`

The `_owner` of the contract `CosmosStakingFactory` has the responsibility to notify users about the following capabilities:
- add bridge through `adminAddBridge()`
- remove bridge through `adminRemoveBridge()`

Any compromise to the `_owner` account may allow a hacker to take advantage of this authority.

The `community` of the contract `Gauge` has the responsibility to notify users about the following capabilities:
- update ledger through `updateLedger()`

The `community` owner of the contract `Gauge` has the responsibility to notify users about the following capabilities:
- add a new gauge through `addNewGauge()`
- withdraw `Nut` through `communityWithdrawNut()`

The `factory` owner of the contract `Gauge` has the responsibility to notify users about the following capabilities:
- withdraw `Nut` through `poolFactoryWithdrawNut()`

The role `community` of the contract `CosmosStakingFactory` has the responsibility to notify users about the following capabilities:
- create a `CosmosStaking` pool through `createPool()`

The role `bridge` of the contract `CosmosStaking` has the responsibility to notify users about the following capabilities:
- update staking info through `update()`

The `whitelist` of the contract `NutPower` has the responsibility to notify users about the following capabilities:
- lock anyone's powers through `lock()`
- unlock anyone's powers through `unlock()`

Any compromise to the `whitelist` account may allow a hacker to take advantage of this authority.

Centralization Related Risks

Addresses should be checked before assigning to make sure they are not zero addresses.

Lack of Zero Address Validation

The linked variable declaration does not have a visibility specifier explicitly set.

Visibility Specifiers Missing

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. As a result, an inconsistency in the amount will occur and the transaction may fail due to the validation checks.

Incompatibility With Deflationary Tokens

The above lines do not contain the validation of the threshold values.
For example:
```solidity=96
   require(powers[msg.sender].free > _npAmount, "Insufficient free NP");
```
The `powers[msg.sender].free` should be more than or equal to `_npAmount`.

Threshold Not Included

Functions that affect the status of sensitive variables should be able to emit events as notifications to customers.

Missing Emit Events

Walnut-Audit

NutPower.sol

cosmos-atom

CosmosStaking.sol

Gauge.sol

CosmosStakingFactory.sol

The second parameter to the function `updateLedger()` of the contract `Committee` is the community address, but when called in the `CommunityFactory` contract, the contract address is passed in.

Incorrect Community Address

In the function `createCommunity()`, the validation that `msg.sender` is not in the fee-free list is missing. If the `msg.sender` is in the fee-free list, this function will only transfer tokens from `msg.sender` to `treasury` without updating `revenues`, causing inconsistencies.

Discussion For `updateLedger()`

To bridge the gap in trust between the administrators need to express a sincere attitude regarding the considerations of the administrator teamʼs anonymity. 

In the contract `NUTToken`, the role `MINTER_ROLE` has the responsibility to notify users about the following capabilities:
- mint uncapped tokens to anyone through `mint()`

In the contract `NUTToken`, the role `owner` has the responsibility to notify users about the following capabilities:
- add any address to the whitelist through `setWhiteList()`
- remove any address from the whitelist through `removeWhiteList()`
- enable transfer through `enableTransfer()`
- disable transfer through `disableTransfer()`

In the contract `MintableERC20`, the role `MINTER_ROLE` has the responsibility to notify users about the following capabilities:
- mint uncapped tokens to anyone through `mint()`

In the contract `LinearCalculator`, the role `communityFactory` has the responsibility to notify users about the following capabilities:
- set distribution era through `setDistributionEra()`

In the contract `ERC20StakingFactory`, the role `community` has the responsibility to notify users about the following capabilities:
- create a `ERC20Staking` pool through `createPool()`

In the contract `SPStaking`, the role `bridge` has the responsibility to notify users about the following capabilities:
- update staking info through `update()`

In the contract `SPStaking`, the role `community` has the responsibility to notify users about the following capabilities:
- create a `SPStaking` pool through `createPool()`

In the contract `SPStaking`, the role `owner` has the responsibility to notify users about the following capabilities:
- set `bridge` through `adminSetBridge()`

In the contract `Committee`, the role `owner` has the responsibility to notify users about the following capabilities:
- add any address to the whitelist manager through `adminAddWhitelistManager()`
- remove any address from the whitelist manager through `adminRemoveWhitelistManager()`
- add any address to the whitelist contract through `adminAddContract()`
- remove any address from the whitelist contract through `adminRemoveContract()`
- add any address to the fee ignore list through `adminAddFeeIgnoreAddress()`
- remove any address from the fee ignore list through `adminRemoveFeeIgnoreAddress()`
- set `treasury` through `adminSetTreasury()`
- set `nut` through `adminSetNut()`
- transfer uncapped `nut` tokens to anyone through `adminAppropriate()`
- set fee through `adminSetFee()`
- set `gauge` through `adminSetGauge()`

In the contract `Committee`, the role `whitelistManager` has the responsibility to notify users about the following capabilities:
- add any address to the whitelist through `setFeePayer()`

In the contract `Committee`, the role `whitelistManager`/`whitelist` has the responsibility to notify users about the following capabilities:
- update `revenues` and `communityFees` through `updateLedger()`

In the contract `Community`, the role `owner` has the responsibility to notify users about the following capabilities:
- set fee ratio and update pool through `adminSetFeeRatio()`
- withdraw rewards to itself through `adminWithdrawReward()`
- add a new pool through `adminAddPool()`
- close pool through `adminClosePool()`
- set pool ratios through `adminSetPoolRatios()`
- set `devFund` through `adminSetDev()`
- withdraw revenue through `adminWithdrawRevenue()`

In the contract `Community`, the role `whitelist` has the responsibility to notify users about the following capabilities:
- append users' rewards through `appendUserReward()`
- set users' debts through `setUserDebt()`
- update pool through `updatePools()`

The `lastRewardBlock` is a `uint256` type and the `feeRatio` are a `uint16` type, their initial value are both 0.

Redundant Code

Comparison to A Boolean Constant

The current implementation is relying on the trust of the owner to avoid repeatedly adding the same pool, as the function will only be called by the owner.

`adminAddPool()` Function Not Restricted

The function `adminClosePool()` closes the pool without removing it from the `whitelists`. If so, the closed pool can call the function `appendUserReward()`, `setUserDebt()` and `updatePools()`.

Remove Pool from `whitelists`

The `poolAddresses` should be verified as non-empty to prevent being mistaken. 

Lack of Input validation

The contract is serving as the underlying entity to interact with third-party protocols, including:
- IGauge

Third Party Dependencies

The whitelist manager can set whitelist but cannot remove it. 

Discussion For Function `setFeePayer()`

The order of external call/transfer and storage manipulation must follow the check-effect-interaction pattern.

Check Effect Interaction Pattern Violated

According to the logic of lines 125 to 128, the maximum withdrawal amount is `withdrawAmount`, so the line 130 should be `withdrawAmount` instead of `amount`.

Incorrect `withdrawAmount`

The function `burnERC20()` is declared but never used in the contract.

Unused Function `burnERC20()`

It is recommended to add `indexed` keyword for parameters in events, which makes it easier for users to navigate event logs.

Address Type Could Be Indexed In Events

All variable types within Solidity are initialized to their default "empty" value, which is usually their zeroed out representation. Particularly:

- `uint` / `int`: All `uint` and `int` variable types are initialized at `0`
- `address`: All `address` types are initialized to `address(0)`
- `byte`: All `byte` types are initialized to their `byte(0)` representation
- `bool`: All `bool` types are initialized to `false`
- `ContractType`: All contract types (i.e. for a given `contract ERC20 {}` its contract type is `ERC20`) are initialized to their zeroed out address (i.e. for a given `contract ERC20 {}` its default value is `ERC20(address(0))`)
- `struct`: All `struct` types are initialized with all their members zeroed out according to this table

Redundant Variable Initialization

The contract has an unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to ambiguity when debugging as compiler-specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

Unlocked Compiler Version

`initialSupply` tokens were sent to the `owner` when deploying the contract. 
This could be a centralization risk as the deployer can distribute tokens without obtaining the consensus of the community.

Initial Token Distribution

The imported source file `BytesLib.sol` is unknown.

Unknown Imported Source File

The aboved linked are missing the check for the non-zero address.

The `constructor` grants `PAUSER_ROLE` role to the `msg.sender`, but the contract does not implement the functions of the relevant role.

The following functions have no access control, anyone can invoke them.
For example:
- `CommunityFactory.createCommunity()`
- `ERC20StakingFactory.createPool()`
- `SPStakingFactory.createPool()`

Lack of Access Control

In the function `SPStaking.update()`, if the `factory` is not on the fee-free list and the `USER` type has a fee set, then fee tokens should be transferred from `factory` to `treasury`. 
Yet the `community` contract may not have `factory`'s allowance to pay the fee to `treasury`, thus the transaction cannot proceed.
And in the function `ERC20Staking.deposit()`, the `msg.sender` should have approved allowance to the `community` beforehand.

Walnut-V2

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

6

0

2

0

4