L01 - No check of sequencer status on chainlink oracle, fees can be lost in case of withdrawal during sequencer downtime

Summary

On L2, the chainlink returned price can be altered by the sequencer state. Per [chainlink docs](https://docs.chain.link/data-feeds/l2-sequencer-feeds), it is recommended to check sequencer status, and in case of downtime, add a grace period to properly have updatedprice in order to equilibrate the pool and update pool value. A grace period should be added for withdrawing and waiting for the update of the pool value otherwise fees can be miscalculated.

Vulnerability Details

1. Pool is running with user funds in it, lpTokenDepositValue = 100

2. Sequencer down, market move higher, now lpToken = 200

3. user send withdraw request

4. Withdraw request is immediately processed when sequencer is up, pool owner did not had the time to update the pool value.
   5 withdraw is processed and fees are not collected as it's link to the delta between value when depositing and withdrawing

Impact

Loss of fees for the protocol and Pool Owner when a user triggers a withdrawal when the sequencer is down.

Tools Used

Manual

Recommendations

Add a grace period as per chainlink docs so that the Pool owner can update lpTokenValue after the sequencer is up again before any withdrawals.

L02 - UpdateWeightRunner::setQuantAMMUpliftFeeTake update wrong variable

Summary

setQuantAMMUpliftFeeTake() update quantAMMSwapFeeTake variable instead of quantAMMUpliftFeeTake.

Impact

Admin will not update the value he thought he would. However, this value does not seem to be used anywhere.

Tools used

Manual

Recommendations

Either delete all functions related to this variable and the variable itself or properly update the function and declare the variable quantAMMUpliftFeeTake

L04 - UpdateWeightRunner::InitialisePoolLastRunTime will revert if admin try to update pool with owner

Summary

If a pool has a manager and a quantamm admin, admin will not be able to trigger InitialisePoolLastRunTime()

If there is a manager, unless quantammAdminAdress = managerAddress, the function will revert when quantamm admin tries to call it.

Vulnerability Details

1. Pool is deployed with MASK_POOL_OWNER_UPDATES and MASK_POOL_QUANTAMM_ADMIN_UPDATES, a manger is assigned.

2. Quantamm admin tries to call InitialisePoolLastRunTime to retrigger an update

3. It will revert as the function first check for manager address.

Recommendations

Rework the if statement to handle both separately

C01 - an admin or owner of pool can modify directly weights and intermediateValues

Summary

An admin of a pool can totally change the weight of each asset and intermediate value, affecting the moving average of the pool by calling either setWeigthsManualy() or setIntermediateValuesManually()

Vulnerability Details

1. Independent Pool Owner deploy a quantamWeighted pool targeting ETH and a lowCap token

2. A pool has Ether and a low cap token with weight ETH = 90% and lowCap = 10%

3. users deposits in the pool, want to have some exposition to both ether and lowCap with a majority of Eth

4. Pool owner (not quantamm) calls setWeigthsManualy to ETH = 0% and lowCap = 100% and calls performUpdate

5. Pool owner sells his stake of low cap

6. Pool owner reset to Eth = 90% and lowCap = 10% and has made some unrisk profit

Impact

Users expect the strategy to be a certain weight management strategy that the owner can alter freely. It represents a centralization risk. For example if the owner want to manipulate a small market it is possible.

Recommendation

Add a grace period for update to be triggered after manually changing weights. Users can withdraw between this period and avoid a loss. Because of the time of the grace period, it's harder for a pool owner to manipulate any markert