Read the findings of the 2022 Web3 Security Report

Because of the high number of import statements, it would be easier for an outside reviewer of the code to break up the imports into openzeppelin sections and custom imports.

Lack of Readability With Import Statements

Users of Infinity can lock their tokens for 0, 3, 6, and 12 months. All staking levels get the same discount on fees so there is no incentive past the bronze threshold.
For example: 
```solidity
uint16 public BRONZE_EFFECTIVE_FEE_BPS = 10000;
uint16 public SILVER_EFFECTIVE_FEE_BPS = 10000;
uint16 public GOLD_EFFECTIVE_FEE_BPS = 10000;
uint16 public PLATINUM_EFFECTIVE_FEE_BPS = 10000;
```
```solidity
function _getUserStakePower(address user) internal view returns (uint256) {
return
((userstakedAmounts[user][Duration.NONE].amount * 1) +
(userstakedAmounts[user][Duration.THREE_MONTHS].amount * 2) +
(userstakedAmounts[user][Duration.SIX_MONTHS].amount * 3) +
(userstakedAmounts[user][Duration.TWELVE_MONTHS].amount * 4)) / (10**18);
  }
```
```solidity
uint16 public BRONZE_STAKE_THRESHOLD = 1000;
uint16 public SILVER_STAKE_THRESHOLD = 5000;
uint16 public GOLD_STAKE_THRESHOLD = 10000;
uint16 public PLATINUM_STAKE_THRESHOLD = 20000;
```
If the user locks up tokens for 12 months, they can easily hit the threshold of bronze. 

If it is easy to reach the maximum threshold because the multiple of 4 by locking for one year, this could create a massive downward trend on price if the inflation is relatively high.

Tokenomics

This contract uses many different types of fees such as `CURATOR_FEE_BPS`,BRONZE_EFFECTIVE_FEE_BPS, etc. To make this easier for outsider reviewers to understand what is happening quicker. Labeling what the 250 is equal to.

Abbreviations such as bps might be hard for outside reviewers to understand what the abbreviation stands for. 

Code Readability

The implementation of the native and reward token are not included in the audit. Because these are not in the scope, they will be treated as blackbox. We assume that these tokens have correct logical behavior.

External Dependency

The owner has privilege to withdraw any token inside the `InfinityStaker` and `InfinityTradingRewards` and transfer it to any address they wish. If a malicious actor got control over this function, they could invalidate the entire contract. 

For example: Bob stakes 100,000 tokens. Malicious actor takes over dev wallet and calls `rescueTokens()` and takes 100,000 out of the contract. Bob calls to withdraw his tokens after duration and cannot because balance exceeds amount exceeds balance. Bob will never be able to use the contract again due to his account never being able to be reset.

Excessive Owner Permissions on Staked Tokens

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

Outside Token Dependency

The contract uses the console contract from Hardhat, which is meant to be used for testing purposes.

Usage of Hardhat's Console

The contract has 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 an 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

The function that affects the status of sensitive variables should be able to emit events as notifications to [users].
- `updateInfinityTreasury()`
- `updateInfinityRewardsContract()`
- `updateStakeLevelThreshold()`
- `updateupdatePenalties()`
- `updateInfinityStaker()`
- `updateInfinityExchange()`
- `updateInfinityToken()`
- `updateRewardsMap()`

Missing Emit Events

The given input is missing the check for the non-zero address.

Missing Input Validation

All for loops could be a more gas efficient by declaring the length into a local variable before calling it.

For example:  
The function `cancelMultipleOrders()` loops multiple times for the length of orders cancelled.
```solidity
for (uint256 i = 0; i < orderNonces.length; i++) {
```

Inefficient Loop Over  Memory Array

External function accepts `memory` arrays. This will force redundant copying of `calldata` values into memory.

External Function Arguments Have `memory` Specifier`

The linked variables could be declared as `constant` since these state variables are never modified.

Variables That Could Be Declared as `constant`

In the contract `InfinityExchange` the role `onlyOwner` has authority over the functions shown in the diagram below.
Any compromise to the `onlyOwner` account may allow the hacker to take advantage of this authority.
![](https://accelerator-tasks-prod.s3.amazonaws.com/f22a47bfdb214da29e2b2af12c1f6b89/diagrams/centralization_InfinityExchange__owner.svg)

Centralization Risks in InfinityExchange.sol

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

Third Party Dependencies

This internal function is not called anywhere in the contract.

Unused `internal` Function

```solidity=139
require(orderNonces[i] > userMinOrderNonce[msg.sender], 'nonce too low');
```
```solidity=510
bool orderExpired = isUserOrderNonceExecutedOrCancelled[signer][nonce] || nonce < userMinOrderNonce[signer];
```
```solidity=237
function isNonceValid(address user, uint256 nonce) external view returns (bool) {
return !isUserOrderNonceExecutedOrCancelled[user][nonce] && nonce > userMinOrderNonce[user];
}

The function `isNonceValid()` states that nonce should always be greater than `userMinOrderNonce`, but there is a lack of check in `orderValidty()`. This could potentially create unintended results of not being able to cancel orders unless `CancelAllOrders()` is called. However, this is a waste of gas on the users end and could create a negative experience.

We understand there is no way for the nonce to be less than `userMinOrderNonce`. However, what happens if the nonce is equal to `userMinOrderNonce`? The order will execute properly with no issue, but it could have an issue with canceling it. The user can call `cancelAllOrders()` to cancel if it is equal to the `userMinOrderNonce`. If a user wants to cancel just that equal order, they cannot remove the order off `cancelMultipleOrders()` because it will revert trying to cancel an order that is not greater than `userMinOrderNonce`.

Because the user has to call `cancelAllOrders()` to raise their `userMinOrderNonce` to cancel it. They waste gas and then have to spend time to redo everything they had setup.

For example: Bob submits an order that is given a nonce of 20. Bob's userMinOrderNonce is 20. However, Bob wants to cancel his order because the price starts tanking. He goes to call function `cancelMultipleOrders()` the function reverts due it failing for too low of a nonce. The only way for him to cancel this is calling `cancelAllOrders()`. 

Potential Error on Canceling Orders/orderValidity

Due to the treasury paying back gas fee to match executor, it should always have enough native tokens such as WETH for Ethereum and other natives for other chains. These are used to cover gas fee cost by match executor.

Treasury Maintanence

Inside the comment on line 613, `transfering` is spelled incorrectly. It should be spelled as `transferring`.

Typo

As this function is commonly used as a batch transfer in erc1155 tokens, this could be easier explained by adding a comment as to who the from is to avoid confusion. This also could also be achieved by changing the from to exchange.

Code Readability on Exchange Transfer

There are no listed complications inside the code for reviewers to see what strategies will be potentially executed during the purchase and sale of different assets. Because of the nature of dynamic purchases and other types of purchasing, there should be multiple complications able for people to review to be able to have greater trust.

Unknown Complication Strategies

If a complication is incorrectly added or used, this could attribute to loss of funds/NFT's. We cannot verify any strategies because this is out of the scope of the audit.

Orders Controlled by Complication

In the contract `InfinityFeeTreasury` the role `onlyOwner` has authority over the functions shown in the diagram below.
Any compromise to the `onlyOwner` account may allow the hacker to take advantage of this.
![](https://accelerator-tasks-prod.s3.amazonaws.com/f22a47bfdb214da29e2b2af12c1f6b89/diagrams/centralization_InfinityFeeTreasury__owner.svg)

Centralization Risks in InfinityFeeTreasury.sol

The contract fails to compile on version 0.8.0 since the linked functions are missing the `override` specifier as these functions are implementations of the `IInfinityFeeTreasury` interface.

Missing Override Specifier

In the contract `InfinityFeeTreasury`, the state variable `merkleRoot` stands for an off-chain Merkle tree, which is used to verify whether a given user has the privilege to claim Curator fees from the treasury. However, the actual Merkle tree used by the contract is uncertain and can be changed. Normally, the Merkle tree is used to prevent arbitrary change to the nodes, but the contracts allow direct updates to the Merkle tree root, which can change the whole tree.

Unknown Merkle tree and parameter `proofs`

In the contract `InfinityOrderBookComplication` the role `onlyOwner` has authority over the functions shown in the diagram below.
Any compromise to the `onlyOwner` account may allow the hacker to take advantage of this authority.
![](https://accelerator-tasks-prod.s3.amazonaws.com/f22a47bfdb214da29e2b2af12c1f6b89/diagrams/centralization_InfinityOrderBookComplication__owner.svg)

Centralization Risks in InfinityOrderBookComplication.sol

In the contract `InfinityStaker` the role `onlyOwner` has authority over the functions shown in the diagram below.
Any compromise to the `onlyOwner` account may allow the hacker to take advantage of this authority and [fixme, describe what hacker can do and the impact].
![](https://accelerator-tasks-prod.s3.amazonaws.com/f22a47bfdb214da29e2b2af12c1f6b89/diagrams/centralization_InfinityStaker__owner.svg)


Centralization Risks in InfinityStaker.sol

If a user withdraw all their funds, they can call the function `getVestingInfo()`. This will display 0 in the amount in that slot, but it will also still show the block timestamp.

Incorrect Update on `_updateUserStakedAmounts()`

In the contract `InfinityTradingRewards` the role `onlyOwner` has authority over the functions shown in the diagram below.
Any compromise to the `onlyOwner` account may allow the hacker to take advantage of this.
![](https://accelerator-tasks-prod.s3.amazonaws.com/f22a47bfdb214da29e2b2af12c1f6b89/diagrams/centralization_InfinityTradingRewards__owner.svg)

Centralization Risks in InfinityTradingRewards.sol

Because this function does not check the message sender for rewards rather it checks if the address has enough to claim. If the malicious actor was pre-approved to trade the token, then they could steal the rewards.

For example: Alice has 100 tokens to claim. Alice approves Bob to trade her tokens. Bob claims her tokens.

Potential Approval Risk on `claimReward()`

The function `updateRewards()` loops over a dynamic array. If this loop has to be run too many times it could exceed block limit.

Potential Resource Exhaustion

This error is correct. However, it would be better described as 
```solidity
`User withdrawing more than balance`
```

Unclear Error Message

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 this farming, only 90 tokens actually arrived 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. 

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

Infinity.xyz

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

33

0

26

1

6