Sign Up for a Code Audit Today and Get 3 Months of Skynet for Free

There are many hard code addresses in `LCCube`, `LCCubeManager`, `LCCubeStakingLogic` and `LCCubeSwappingLogic`.

Hard Code Address

The contract is serving as the underlying entity to interact with third-party protocols. The scope of the audit treats 3rd party entities as black boxes and assumes 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

In the contract `InternalWhitelistControl`, the role `accessWhitelist` has the authority over the following function:
1. function addToWhitelist()

In the contract `LCCube`, the role `accessWhitelist` has the authority over the following function:
1. function startTrading()
2. function wrapETH()
3. function unwrapWETH()
4. function uniV3MintNewPosition()
5. function uniV3IncreasePositionLiquidity()
6. function uniV3DecreasePositionLiquidity()
7. function collectAllFees()
8. function swapExactInputSingle()
9. function swapExactInput()
10. function swapExactOutputSingle()
11. function swapExactOutput()
12. function removeAllPositions()
13. function liquidation()

In the contract `LCCubeDeployer`, the role `accessWhitelist` has the authority over the following function:
1. function createCube()

In the contract `LCCubeManager`, the role `accessWhitelist` has the authority over the following function:
1. function setCubeDeployer()
2. function traderGetAllCubes()
3. function investorGetAllCubes()
4. function createCube()
5. function initCube()
6. function liquidateCube()
7. function traderLiquidate()
8. function investorLiquidate()
9. function mintCubeletsNFT()
10. function burnToken()

In the contract `LCCubeManager`, the role `owner` has the authority over the following function:
 function setPlatform()

In the contract `LCCubeStakingLogic`, the role `accessWhitelist` has the authority over the following function:
1. function uniV3MintNewPositionLogic()
2. function uniV3IncreasePositionLiquidityLogic()
3. function uniV3DecreasePositionLiquidityLogic()
4. function uniV3CollectAllFeesLogic()

In the contract `LCCubeSwappingLogic`, the role `accessWhitelist` has the authority over the following function:
1. function uniV3SwapExactInputSingleLogic()
2. function uniV3SwapExactInputLogic()
3. function uniV3SwapExactOutputSingle()
4. function uniV3SwapExactOutput()

In the contract `LCFactory`, the role `accessWhitelist` has the authority over the following function:
1. function setLCCubeManager()
2. function setSudoCubeState()
3. function createSudoCube()
4. function buyCubelet()
5. function returnCubelet()
6. function LCCubeManagerRequireInvestment()

In the contract `LCPeriphery`, the role `trader` has the authority over the following function:
1. function createPosition()
2. function increaseLiquidity()
3. function decreaseLiquidity()
4. function collectAllFees()
5. function swapExactAForB()
6. function swapAForExactB()

Any compromise to the accounts may allow a hacker to take advantage of this authority and causes security problems.

Centralization Related Risks

The variables `tokenIds`, `liquidities` are passed in by the caller of function `LCPeriphery.liquidateCubeRelay`, the caller can pass the check by passing in 0 for all liquidities. So the check in `LCCube.liquidate` is invalid.

Potential Incorrect Parameters

1. In function `LCCubeSwappingLogic.uniV3SwapExactInputSingleLogic`, `swapParams.amountIn` is transferred in from contract `LCCube`. So the approved value should be `swapParams.amountIn`, but not `MAX_INT`.
2. In functions `LCCubeSwappingLogic.uniV3SwapExactOutputSingle` and `LCCubeSwappingLogic.uniV3SwapExactOutput`, `amountInReceived` is transferred in from contract `LCCube`. So the approved value should be `amountInReceived`, but not `MAX_INT`. The compared value should be `amountInReceived`, but not `swapParams.amountInMaximum`.
3. In function `LCCubeStakingLogic.uniV3MintNewPositionLogic`, if the current token price is outside the range of the position we added, only one token is needed, another amount of token can be 0. So the `mintParams.amount0Desired` or `mintParams.amount1Desired` maybe 0. f.e. `mintParams.amount0Desired` is 0, token0.allowance[stakingContract][nonfungiblePositionManager] == 0. In the future, when the price move to the range of our position or to the other outside of the position, if we want to increase liquidity, the operation may fail. Because the allowance for token0 is 0.

Incorrect Approved Values

1. Functions `LCCubeStakingLogic.uniV3MintNewPositionLogic` and `LCCubeStakingLogic.uniV3IncreasePositionLiquidityLogic` will call `UniswapV3Pool.mint`, the amount of token0 and token1 transferred from `LCCubeStakingLogic` to `UniswapV3Pool` are calculated in `UniswapV3Pool`. When token0 or token1 is `ETH`, the amount may be not equal to the `msg.value` transferred to `nonfungiblePositionManager`. So after calling `nonfungiblePositionManager`, it is necessary to call the function `nonfungiblePositionManager.refundETH` to retrieve excess `ETH`. 
2. Functions `LCCubeSwappingLogic.uniV3SwapExactOutputSingle` and `LCCubeSwappingLogic.uniV3SwapExactOutput` will call `uniV3Router`, the amount of token0 and token1 transferred from `LCCubeSwappingLogic` to `uniV3Router` are calculated in `UniswapV3Pool`. When token0 or token1 is `ETH`, the amount may be not equal to the `msg.value` transferred to `uniV3Router`. So after calling `uniV3Router`, it is necessary to call the function `uniV3Router.refundETH` to retrieve excess `ETH`. 

Missing Refund `ETH` In Some Functions

We noticed that the variable `tokenIds` in contract `LCCube` has been removed. How do you ensure that all the liquidities are removed? If some positions' liquidities haven't been removed, and the `LCCube` liquidated, the tokens in the positions can never get back. Users may suffer a loss.

Since the variable `tokenIds` has been deleted, where are the tokenIds recorded?

Question About Liquidate

Line148 and Line196 of contract `LCCubeSwappingLogic` mean the upper limit of the `amountIn` transferred to Uniswap v3. It should be equal to the tokens transferred in from `LCCube`, equal to `amountInReceived`. Line153 and Line200 mean the amount of `ETH` transferred in from `LCCube`, it should also be equal to `amountInReceived`.

Potential Incorrect Variable

In functions `LCCubeManager.createCube` and `LCCubeManager.initCube`, variable `createCubeParams.creatorAddr` is passed in by the caller of contract `LCPeriphery`, its value is set by the caller, may be not equal to the creator of the SudoCube. So the key value of Line231 should be `sudoCubeToDeploy.creator`, but not `createCubeParams.creatorAddr`. And `createCubeParams.creatorAddr` is useless, it should be removed from struct `CreateCubeParams`. 

Potential Incorrect Parameter

In function `LCCubeStakingLogic.uniV3CollectAllFeesLogic`, `token0` and `token1` are transferred directly from `UniswapV3Pool` to `LCCube`. So where are the tokens in `nonfungiblePositionManager` come from? And why need to call `nonfungiblePositionManager.sweepToken`?

The Purpose To Call `_cleanUp`

In Uniswap V3, the demand for token0 and token1 depends on the range of the position. if the range is [1000,2000], and the current price is 900, only token0 is needed. If the current price is 2100, only token1 is needed. So the token transferred from `LCCubeStakingLogic` to `UniswapV3Pool` maybe not equal to the `amount0Desired` and `amount1Desired`. So the excess token0 and token1 should be transferred back to the contract `LCCube`.

Missing Return Token

LiquidCube II

LCCubeDeployer.sol

LCPeriphery.sol

LiquidCube

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

11

0

3

0

8