MultiPositionManager

Proof of concept: PoC

The MultiPositionDeployer.deploy() function is externally callable without access control. This function deploys MultiPositionManager contracts using CREATE2 with a caller-supplied salt.

In the intended flow, MultiPositionFactory.deployMultiPositionManager() computes a deterministic salt and calls MultiPositionDeployer.deploy(). This flow is used by:

1. Token Launch Migration.
2. Pool Creation with Limit Order Support.

An attacker can extract parameters from the mempool or from deployed SuperchainLBPStrategy contracts (all fields are public). Using these parameters, the attacker computes the exact same salt and constructor arguments, then front-runs by calling MultiPositionDeployer.deploy() directly.

When the legitimate deployment proceeds, the factory attempts to deploy at the same address via the deployer, causing a CREATE2 collision and reverting.

This will block migration and/or creating pools with limit order support.

Restrict MultiPositionDeployer::deploy() to only be callable by MultiPositionFactory.

Gamma Team: Resolved.

The deployMultiPositionManager function loops through the _allTokenPairs array to locate and update a token pair’s manager count.

As the number of unique token pairs grows, this linear scan becomes increasingly expensive and can lead to gas exhaustion or DoS, potentially blocking new deployments.

Add a hard cap or redesign the accounting so deployment cost doesn’t grow with the number of pairs.

Gamma Team: Resolved.

MultiPositionManager.rebalanceSwap unwinds all existing positions via poolManager.unlock(Action.BURN_ALL, ...).

The BURN_ALL callback burns liquidity across positions and clears position state, but it does not execute the fee-splitting logic used elsewhere (the zeroBurnAll flow), where the treasury cut is computed as totalFee / s.fee and minted as ERC-6909 claims.

Because this unwind path skips that step, any accrued fees realized during the full burn are treated as ordinary vault assets and can be swapped/redeployed immediately, while the protocol fee recipient receives no claimable share.

Any caller permitted to call rebalanceSwap can bypass protocol fees by calling rebalanceSwap first and then proceeding with other actions.

Apply protocol fee accounting on all unwind paths. Run zeroBurnAll (or equivalent treasury-cut logic) before burning liquidity, or implement the treasury cut directly in the burn-all flow so fees are split consistently.

Gamma Team: Resolved.

MultiPositionManager inherits Multicall and executes batches via delegatecall, meaning every subcall observes the same msg.value. For native-asset pools, deposit() ultimately relies on _transferIn(), which validates ETH payment using require(msg.value >= amount).

Because the contract does not track or decrement ETH across subcalls, multiple deposits in a single multicall can each independently satisfy the ETH check using the same msg.value.

Batching multiple deposits could be used when depositing for multiple recipients or when deposits are split across different from addresses/flows.

As a result, shares can be minted multiple times even though ETH was only provided once, inflating supply and diluting existing shareholders.

Depending on the deposit amounts and refund behavior, the contract may also attempt to incorrectly run refund logic multiple times within the same transaction, creating inconsistent ETH flows and potentially leaving the contract’s ETH balance misaligned with assumptions in the share/accounting logic.

Disallow batching with ETH (revert if msg.value != 0 and data.length > 1), or implement an explicit ETH “remaining value” budget for multicall and consume it inside _transferIn() instead of reading msg.value per subcall.

Gamma Team: Resolved.

WithdrawLogic.processWithdrawCustom can select a “balance + fees” path and calls zeroBurnAllWithoutUnlock(s, poolManager) directly. That function calls PoolManagerUtils.zeroBurnAll(), which invokes poolManager.modifyLiquidity() to realize fees.

In Uniswap v4, modifyLiquidity is expected to be executed while the PoolManager is unlocked (during poolManager.unlock() via the callback). Calling it directly from withdrawCustom outside an unlock is incompatible with standard v4 behaviour and can cause this branch to revert, making withdrawCustom fail whenever it selects the “balance + fees” path.

This can also impact automation. RelayerLogic.withdrawSingleToken (used by Relayer.executeWithdrawal) calls manager.withdrawCustom and may then call manager.rebalance to redeploy the remaining asset.

If withdrawCustom selects the USE_BALANCE_PLUS_FEES path, the relayer execution will revert due to fee collection occurring outside unlock, preventing the withdrawal and any subsequent rebalance in that transaction.

When withdrawCustom needs fee realization, execute it via poolManager.unlock(Action.ZERO_BURN, ...) (or via the existing Action.WITHDRAW callback flow) rather than calling zeroBurnAllWithoutUnlock directly.

Gamma Team: Resolved.

setFee in MultiPositionManager allows s.fee to be set to zero, with no minimum enforced. Several core execution paths assume s.fee is non-zero and divide by it to compute the protocol’s share of accrued fees.

For example, WithdrawLogic.getTotalAmounts() adjusts TVL and fee totals using expressions like totalFee / s.fee, and fee-claim logic similarly derives mint/burn amounts from totalFee / s.fee. If s.fee is set to zero, these divisions revert.

As a result, setting s.fee to zero can cause withdrawals, fee claims, and other fee-dependent flows to revert, effectively bricking core functionality.

Enforce a non-zero minimum fee in setFee, or explicitly handle the zero-fee case in all accounting and fee-distribution logic to avoid division-by-zero reverts.

Gamma Team: Resolved.

Proof of concept: PoC

_executeAggregatorSwap is intended to prevent arbitrary external calls by restricting swaps to a approved set of aggregator integrations. It does this by validating params.aggregator (≤ 3), which corresponds to the supported options (ZERO_X, KYBERSWAP, ODOS, PARASWAP).

However, the actual call target, params.aggregatorAddress, is user-controlled and is not derived from or validated against the selected enum value. A caller can therefore pass a valid params.aggregator value while setting params.aggregatorAddress to an arbitrary contract.

Because _executeAggregatorSwap also grants params.aggregatorAddress an allowance for the input token (forceApprove) and then performs a low-level external call with user-controlled calldata, the enum validation does not prevent arbitrary external calls or malicious approval usage.

Any caller that can reach swap-based paths (including relayer/automation flows) can route execution to untrusted contracts and potentially drain or misdirect funds.

Even with a semi-trusted relayer, this is misleading: owners may grant relayer permissions believing swaps are constrained to known aggregators, but in practice the relayer can execute arbitrary external calls with token approvals because params.aggregatorAddress is not properly constrained.

Bind each aggregator enum value to a fixed, trusted aggregator address (or a whitelist per enum), and derive aggregatorAddress internally based on params.aggregator rather than accepting it as user input. Alternatively, explicitly validate that params.aggregatorAddress matches an address from an allowlisted set for the selected aggregator.

Gamma Team: Resolved.

MultiPositionManager issues transferable ERC20 shares, but redemption is tied only to owner instead of the shareholder.

Deposits can mint shares to an arbitrary to address. However, both withdrawal paths (withdraw and withdrawCustom functions) pay assets to and burn shares from owner.

Consequently, if shares are held by any address other than owner, those holders cannot redeem, and withdrawals may revert if owner address lacks the shares to burn.

Make shares non-transferable and always mint them to owner.

Gamma Team: Partially Resolved.

In calculateCurrentRangeExcess, when the current price is close to the lower tick of a range, the denominator sqrtPriceX96 - sqrtPriceLower becomes small, producing an extremely large liquidity result that may exceed uint128.max and silently truncate.

Consider the following example (low priced pool): sqrtPriceLower ≈ 1e18 sqrtPriceX96 ≈ 1.00005e18 denominator = sqrtPriceX96 - sqrtPriceLower ≈ 5e13 token1Allocation: 5e23 (18 decimals) liquidityFrom1 = 5e23 * 7.9e28 / 5e13 = 7.9e38

However, uint128.max ≈ 3.4e38, therefore the result will silently truncate.

This will result in incorrect excess calculations and liquidity allocation across MPM positions. This may also cause DoS or unexpected behaviour to token launch migrations, depending on the launch and migration configuration.

Also consider applying the changes to mintFromAllocations .

Consider reverting upon overflow for both liquidityFrom1 and actualLiquidity calculations within calculateCurrentRangeExcess.

Gamma Team: Resolved.

WithdrawSingleToken implemented in RelayerLogic, is used by the relayer withdrawal automation when configured for withdrawToken0Only or withdrawToken1Only.

The function first executes withdrawCustom to withdraw all amount of one token from the pool, then conditionally calls rebalance on MultiPositionManager to redeploy the remaining token into fresh positions.

The rebalance call is constructed with an outMin array sized only to the number of base positions. However, in RebalanceLogic, the rebalance function strictly requires the outMin length to match the number of currently active positions being burned (basePositionsLength + limitPositionsLength).

If the vault has any active limit positions, the call always reverts because withdrawSingleToken passes an outMin array that ignores limit positions. Consequently, single-token withdrawals will be permanently unusable for managers with active limit positions.

Size the rebalance outMin to cover all current positions - basePositionsLength + limitPositionsLength.

Gamma Team: Resolved.

Relayer admin control is permanently bound to the deploy-time manager owner via an immutable owner parameter, while the MultiPositionManager owner can change. All relayer admin functions use onlyOwner against this captured address.

However, execution already treats the MPM owner as dynamic:

address mpmOwner = Ownable(address(manager)).owner();
uint256 ownerShares = manager.balanceOf(mpmOwner);
manager.withdraw(ownerShares, outMin, true);

After MPM ownership is transferred, the new MPM owner cannot pause/configure/withdraw relayer ETH, while the old owner still can. Since the factory enforces a single relayer per manager, deploying a replacement is blocked, making this loss of control permanent.

Remove the captured immutable relayer owner and derive it from the current MultiPositionManager owner.

Gamma Team: Resolved.

In proportional mode (weight0 == 0 && weight1 == 0), mintFromAllocations computes liquidity starting from token1.

When liquidityFrom1 = 0 (price at lower tick boundary, zero token1 allocation after swaps, or one-sided deposits), the code never calculates liquidity from token0 as a fallback. This causes liquidities[i] = 0 even when sufficient token0 exists.

The same issue exists in calculateCurrentRangeExcess, where actualLiquidity becomes 0 and all tokens are marked as excess and redistributed away from the current range.

With carpet mode enabled, _validateCarpetLiquidity requires non-zero liquidity for the outer carpet ranges and reverts if edge range liquidity is 0 (even with sufficient one-sided funds). This creates DoS when price lands exactly on a range boundary during initialization or rebalances.

Add fallback to calculate liquidity from token0 when token1 cannot contribute calculateCurrentRangeExcess.

Alternatively, replace the custom boundary handling with LiquidityAmounts.getLiquidityForAmounts which handles all boundary cases correctly.

Gamma Team: Resolved.

In Relayer contract, getRatios returns inPositionRatio and outOfPositionRatio as respectively 5th and 6th values. However, Relayer unpacks the returned values as if outOfPositionRatio were the 5th return value.

(,,,, uint256 outOfPositionRatio,,,,,,,) = manager.getRatios();

This binds the 5th return value (inPositionRatio) to a variable named outOfPositionRatio. That means the relayer checks the wrong condition and it effectively allows compounding when assets are in position (inPositionRatio >= threshold) instead of when assets are idle (outOfPositionRatio >= threshold).

In practice, this makes executeCompoundSwap behave like it is almost always enabled even when the vault is not meaningfully out of position, wasting ETH on reimbursements and potentially causing unnecessary swaps

Update Relayer’s getRatios unpacking to use the correct outOfPositionRatio position.

Gamma Team: Resolved.

When TWAP-based centering is used (baseTwapTickTrigger or useTwapCenter), the relayer sets params.center to the raw TWAP tick returned by the oracle. That TWAP tick is not guaranteed to be aligned to the pool’s tickSpacing.

Range generation does not use that raw value directly. For example, SingleUniformStrategy snaps the received centerTick onto the tickSpacing grid using centerTick = (centerTick / tickSpacing) * tickSpacing.

This uses truncating division, so the “center” actually used to build ranges can differ from the value stored in lastStrategyParams.centerTick whenever the TWAP tick is not already aligned.

This mismatch is more severe for negative ticks because truncation rounds toward zero (e.g., tickSpacing = 60, TWAP = -1 snaps to 0 instead of -60).

Any subsequent logic that references the stored center (for example, trigger calculations or comparisons relative to centerTick) can become inconsistent because the system records one center while liquidity was deployed around a different one.

Align the TWAP tick to tickSpacing before using it as params.center, using the same rounding convention as the manager’s tick alignment (round down for negatives), and store that aligned value as lastStrategyParams.centerTick. Furthermore, update strategies such as SingleUniformStrategy to align ticks using floor-style rounding for negative ticks rather than truncating division.

Gamma Team: Resolved.

When compoundFees is false, the relayer always calls claimFee on MPM before rebalancing, and triggers WithdrawLogic.processClaimFee, which zero-burns fees, then pays the owner’s share out of the MPM and forwards the treasury share to the factory feeRecipient.

Consequently, those transfers remove fee amounts from the manager’s token balances immediately before the rebalance.

However, in RelayerLens, previewRebalance ignores this step and bases expected positions, swapAmount and inMin on getTotalAmounts that still include the unpaid fees.

With non‑zero fees, the preview overstates available tokens and automation can submit a rebalance that reverts once fees are paid, despite the lens reporting it should succeed, causing failed automation and wasted gas.

Update previewRebalance to simulate claimFee when compoundFees is false by using balances after the claim.

Gamma Team: Resolved.

Proof of concept: PoC

During rebalancing, the limit positions are updated only if the positions are non-empty.

This allows a state where limitPositions[0] is empty while limitPositions[1] is non-empty, resulting in limitPositionsLength = 1.

However, when burning limit positions, the outMin index is derived from the slot index i.

Applying slippage will not be possible if the outMin list is limited only to the length of s.basePositionsLength + s.limitPositionsLength in this case, forcing the owner to remove the limit position liquidity with 0 slippage.

Consider the following example:

• basePositionsLength = 3
• limitPositions[0] is empty (0, 0)
• limitPositions[1] is non-empty (100, 200)
• limitPositionsLength = 1 (only position 1 counted)

Validation requires outMin.length = basePositionsLength + limitPositionsLength = 3 + 1 = 4 User provides outMin with indices [0, 1, 2, 3].

During burnLimitPositions: i = 0: limitRanges[0] is empty, so this iteration is skipped. i = 1: limitRanges[1] is non-empty, so outMinIndex = baseRangesLength + i = 3 + 1 = 4. Check: 4 < 4 → False. Falls back to [0, 0] → zero slippage.

This will remove liquidity from the position with 0 slippage, with MPM owners having no way around this, leading to loss of funds (i.e sandwich attack, price movement, etc).

There is another issue in a separate function, called during compounds, DepositLogic::addLiquidityToPositions. The for (uint8 i = 0; i < limitLength;) { loop will skip adding liquidity to limitPosition[1] if limitPosition[0] is empty, causing yield loss (same root cause).

Consider utilizing a limit counter to properly fetch the correct index.

Gamma Team: Resolved.

When burning liquidity positions during rebalancing, outMin slippage checks are performed against callerDelta which includes both principal and accrued fees.

Uniswap V4's PositionManager explicitly subtracts fees before slippage validation because minOut parameters are intended to protect the principal value.

There are two cases during rebalances that are affected:

1.rebalanceSwap(): Uses BURN_ALL without collecting fees prior.

1. rebalance() with only limit positions. The ZERO_BURN check only considers base positions.

Because accrued fees are included in the slippage comparison, they can mask losses on the principal portion.

Due to price changes or manipulation before the owner's rebalance transaction is executed, the principal value can be reduced, while the slippage check still passes due to accumulated fees acting as a buffer.

For rebalanceSwap(): Either follow Uniswap V4 PositionManager's pattern by subtracting feesAccrued from callerDelta before checking against outMin, or collect fees prior to burning positions (similar to the withdrawal flow).

For rebalance(): Update the ZERO_BURN condition to also check for limit positions (s.basePositionsLength > 0 || s.limitPositionsLength > 0).

Gamma Team: Resolved.

_reimburseGas refunds only the L2 execution cost using the following calculations:

// Calculate gas used
uint256 gasUsed = gasBefore - gasleft() + BASE_GAS_OVERHEAD;
// Calculate reimbursement with 10% buffer
uint256 reimbursement = (gasUsed * tx.gasprice * GAS_BUFFER_NUMERATOR) /
GAS_BUFFER_DENOMINATOR;

However, Unichain (where the protocol is intended to be deployed) is an Ethereum L2 built on the OP Stack.

On OP Stack chains, sequenced L2 transactions are charged an additional L1 data fee that covers publishing the transaction batch data to Ethereum, which is not captured by gasUsed * tx.gasprice.

This means automation services will be systematically under-reimbursed, and the gap can be especially large for calls with large calldata

Reimburse the full transaction cost by adding the L1 data fee.

Gamma Team: Partially Resolved.

The MultiPositionManager stores limit positions in two fixed slots, s.limitPositions[0] for the lower range and s.limitPositions[1] for the upper range. The variable s.limitPositionsLength is intended to represent how many of these slots are active.

Several code paths iterate limit positions using for (i < s.limitPositionsLength) and then access s.limitPositions[i]. This logic assumes that when exactly one limit position is active, it must be stored at index 0. That assumption is not guaranteed.

If the lower limit position collapses into an empty range due to tick rounding or clamping near the minimum usable tick while the upper limit remains valid, s.limitPositionsLength becomes 1 even though the only active position resides at index 1. In this case, loops bounded by s.limitPositionsLength will only read s.limitPositions[0] and will skip the active upper limit.

As a result, deployed liquidity and accrued fees can be undercounted in aggregation logic such as total amount calculations. Liquidity add or rebalance flows may also ignore an active limit range, leading to incorrect allocations, understated vault value, or unexpected idle balances.

Do not use s.limitPositionsLength as an index bound for accessing s.limitPositions. Always iterate over both fixed slots and skip inactive entries by checking that lowerTick != upperTick.

Gamma Team: Resolved.

When a withdrawal trigger is configured with withdrawToken0Only or withdrawToken1Only, the relayer calls RelayerLogic.withdrawSingleToken, which first withdraws all of the specified token using withdrawCustom, and then attempts to rebalance the remaining assets.

Then, the relayer fetches the last strategy parameters and calls rebalance on MPM. using lastUseCarpet parameter.

However, the rebalance implementation enforces that carpet mode requires both tokens to be non-zero, reverting when either available token amount is zero.

if (ctx.useCarpet && (available0 == 0 || available1 == 0)) {
revert CarpetRequiresBothTokens();
}

Since the single-token withdrawal intentionally makes one token amount zero, the subsequent rebalance reverts whenever lastUseCarpet is true, causing the entire automated withdrawal transaction to revert.

Either change withdrawSingleToken to not attempt a carpet rebalance after making the vault one-sided or explicitly disallow configuring withdrawToken0Only/withdrawToken1Only when useCarpet is enabled.

Gamma Team: The issue was resolved in commit af04adb.

The protocol treats proportional mode (weight0 == 0 && weight1 == 0) differently depending on the rebalance entrypoint.

In the rebalance() flow, _processRebalance() explicitly disables limit logic by forcing limitWidth = 0, stating that limit positions do not make sense when weights are derived from amounts. This guarantees that proportional rebalances only construct base ranges.

However, the rebalanceSwap() flow does not apply the same restriction. When building the strategy context, _buildStrategyContext() forwards params.limitWidth unchanged even if weight0 == 0 && weight1 == 0. As a result, rebalanceSwap() can execute in proportional mode with a nonzero limit width, allowing strategies to construct limit positions.

This leads to inconsistent behaviour where two operations that appear equivalent can result in different final positions depending on the entrypoint used. In particular, operators assumptions that proportional mode always results in base-only positions may break if a rebalance is executed through rebalanceSwap() instead.

Normalize proportional mode handling by setting limitWidth = 0 whenever weight0 == 0 & weight1 == 0 in the rebalanceSwap() path as well, or clearly document that proportional mode may include limit position construction.

Gamma Team: Resolved.

The standard rebalance path enforces carpet invariants when useCarpet is set to true. It requires both tokens to be non-zero and it the edge carpet positions to have non-zero liquidity.

The rebalanceSwap path does not execute this validation logic. It burns positions, optionally swaps and persists lastStrategyParams.useCarpet=true, without validating carpet liquidity and total available amounts.

As a result, rebalanceSwap can persist useCarpet set to true, even when the post-swap state is one-sided or assigns zero liquidity to the carpet edges, violating the intended carpet mechanism.

Apply the same carpet checks in the rebalanceSwap path.

Gamma Team: The issue was resolved in commit af04adb.

The withdrawal path is initiated in executeWithdrawal by checking in-position ratios returned by getRatios and then calling withdrawSingleToken that is supposed to withdraw token0 or token1 and rebalance with the other token.

This function withdraws the entire selected token amount using getTotalAmounts, which includes position amounts, fees and idle balances.

When the relayer trigger for “withdraw only token0” is met, pool0Ratio must be non-zero (it is computed from in-position amounts). In that state, total0 necessarily includes some token0 that is currently inside positions.

Therefore, withdrawCustom cannot be satisfied from idle balances alone and must enter the burn positions path, which computes how many shares worth of positions must be burned to source the requested token amount.

Because amount0Desired is equal to total0 in this flow, sharesForToken0 becomes totalSupply, so it burns 100% of positions. After positions are fully burned, the in-position amounts are zero, so getRatios reports pool0Ratio == 0 and pool1Ratio == 0 regardless of any remaining idle token balances (as idle balances are not included in pool0Ratio/pool1Ratio).

This makes the subsequent rebalance block unreachable in the intended, triggered case, even if the burn left a non-zero amount of the other token sitting idle in the manager, what consequently break the intended “withdraw and rebalance” behaviour.

Also, the only scenario where the rebalance block could run is when the selected token is entirely idle (so no burn happens and positions still contain the other token), but in that scenario the relayer cannot trigger “withdraw token0 only” or “withdraw token1 only” because the corresponding in-position ratio is zero and cannot meet a non-zero threshold.

Change the post withdraw rebalance check to use a value that includes idle balances rather than pool0Ratio/pool1Ratio which reflect positions only.

Gamma Team: Resolved.

Relayer deployment relies on CREATE2 to deterministically compute relayer addresses from the MPM address, owner address, and configuration parameters.

While RelayerFactory enforces authorization checks, the underlying RelayerDeployer.deploy() function itself is permissionless and can be called directly.

As a result, any user can front-run a legitimate deployment by calling RelayerDeployer.deploy() with the same parameters the owner intends to use. This preemptive deployment occupies the expected relayer address.

When the rightful MPM owner later attempts to deploy through the factory, the call reverts because the contract is already deployed.

This enables a griefing attack where attackers can block MPM owners from deploying relayers with their intended configuration.

Restrict RelayerDeployer.deploy() so it can only be called by the authorized factory, ensuring relayer creation cannot be front-run or griefed by external callers.

Gamma Team: Resolved.

The deposit() function calculates shares using the slot0 price without any slippage protection parameter (minSharesOut).

While the owner is typically the sole shareholder and cannot lose value to themselves, in edge cases where the owner mints shares to third-party addresses via the to parameter, or in future integrations, this could lead to share recipients receiving fewer shares than expected due to price movements or manipulation (i.e., sandwich attack).

Add minSharesOut parameter to deposit() for slippage protection, and consider validating sqrtPriceX96 against a slippage threshold.

Gamma Team: Acknowledged.

Relayer deployment and post deploy updates enforce different TWAP constraints. RelayerFactory rejects overly large TWAP windows and verifies the oracle can serve the requested twapSeconds.

After deployment, the relayer owner can call setRebalanceParams, which uses _validateTwapParams and does not enforce the same twapSeconds upper bound or re-check oracle availability.

If twapSeconds is set beyond the oracle’s retained history, oracle.consult can revert and brick all paths that rely on TWAP until the params are corrected.

Consider enforcing the same TWAP bounds and oracle availability validation in Relayer._validateTwapParams as in the factory.

Gamma Team: Resolved.

In StrategyParams struct, useRebalanceSwap parameter is treated as the configuration setting that indicates whether rebalances should use the swap path, but the relayer does not enforce it at execution time.

A whitelisted automation service can always call either executeRebalance or executeRebalanceSwap, regardless of the configured flag.

Off-chain preview contract (RelayerLens) relies on useRebalanceSwap to decide whether a swap is expected, but on-chain the flag is not enforced at execution time.

If the automation service is misconfigured, it can execute the unintended path (swap when disabled or no-swap when swap is required), potentially leading to unnecessary and unexpected executions.

Consider gating executeRebalance and executeRebalanceSwap so the callable entrypoint must match useRebalanceSwap parameter, making the configuration enforceable on-chain.

Gamma Team: Resolved.

In setLimitRanges, when a base range width matches limitWidth, the code increments limitWidth once and immediately exits the loop. The new value is not rechecked against remaining base ranges, allowing another collision to remain undetected.

for (uint256 i = 0; i < baseRangesLength;) {
int24 rangeWidth = baseRanges[i].upperTick - baseRanges[i].lowerTick;
if (rangeWidth == int24(limitWidth)) {
limitWidth = uint24(int24(limitWidth) + tickSpacing);
break;  // Exits without checking the rest
}
unchecked { ++i; }
}

If the resulting limit range later matches a base range’s (lowerTick, upperTick), checkRanges() will revert with DuplicatedRange, causing the rebalance or migration to fail.

Consider iterating until limitWidth no longer collides with any base range width.

Gamma Team: Resolved.

executeRebalance and executeRebalanceSwap run _checkTwapProtection before sampling gasleft.

Since _reimburseGas only accounts for gas spent after gasBefore is captured, the oracle/TWAP check gas is excluded from reimbursement even on successful executions.

Consequently, automation service is systematically under-reimbursed when TWAP protection is enabled.

Capture gasBefore before calling _checkTwapProtection.

Gamma Team: Resolved.

RelayerFactory.getUniqueTokenPairs() iterates through deployed relayers and reads each relayer’s poolKey to derive token metadata (symbol and decimals).

It unwraps each Currency into an address and treats it as an ERC-20 by calling IERC20Metadata(token).symbol() and IERC20Metadata(token).decimals().

For Uniswap v4 pools that use the native currency (ETH), the corresponding Currency unwraps to address(0). As a result, getUniqueTokenPairs() will call IERC20Metadata(address(0)), which will revert.

Handle native currency explicitly before calling ERC-20 metadata methods. If token == address(0), return a fixed symbol ("ETH") and decimals (18).

Gamma Team: Resolved.

In proportional mode (weight0 == 0 && weight1 == 0), the current range math computes token0Needed using the return value of the following equation, as a denominator:

FullMath.mulDiv(sqrtPriceUpper, sqrtPriceX96, FixedPoint96.Q96)

Near extreme MIN_SQRT_PRICE (2^32), this inner mulDiv can floor to 0 (when sqrtPriceUpper * sqrtPriceX96 < 2^96), causing the outer mulDiv to revert due to division by zero.

This is only reachable at very extreme pool prices, but it is still a valid Uniswap state. In this scenario, proportional rebalances can revert, halting automated rebalancing and compounding at those prices.

Be aware of this edge case and add a simple guard before the outer mulDiv so proportional rebalances never revert due to division by zero.

Gamma Team: Resolved.

When a user provides explicit weights (e.g., weight0=0.7e18, weight1=0.3e18), the system validates they sum to 1e18 but may silently override them to 50/50 in calculateWeightsWithPoolKey if the strategy doesn't support weighted distribution:

if (!params.useCarpet && !supportsWeightedDist && (params.weight0 != 0.5e18 || params.weight1
!= 0.5e18)) {
params.weight0 = 0.5e18;
params.weight1 = 0.5e18;
}

The ctx struct is never updated to reflect this change. Subsequently, _calculateLiquiditiesFromWeights operates on weights calculated with 50/50 weighting, causing a mismatch between user intent and actual execution.

A user requesting 70/30 may get silently ignored, and would instead get 50/50 weighting from the strategy’s density computation, leaving idle token/unused balances.

Consider reverting when weights are requested (explicit) but unsupported.

Gamma Team: Resolved.

In _executeProvidedSwap, the code assumes the full swapAmount is consumed by the aggregator:

if (swapParams.swapToken0) {
return (amount0 - swapParams.swapAmount, amount1 + amountOut);
}
return (amount0 + amountOut, amount1 - swapParams.swapAmount);

For exactOut swaps, the aggregator may consume less than swapAmount (which represents maximum input). The code subtracts the full swapAmount regardless, underestimating the remaining input token balance.

In the rebalanceSwap flow, this causes liquidity calculations based on understated balances resulting in under-minting of liquidity positions. The difference remains idle in the contract.

Track actual input spent by checking balance difference before and after swap (for ETH and ERC20).

Gamma Team: Acknowledged.

The withdrawCustom flow relies on converting the vault’s total value and the requested withdrawal value into token1 terms, then computing how many shares to burn.

This has two related failure modes caused by integer rounding:

• poolValueInToken1 can become 0 even though the vault holds assets. This happens when the vault

is one-sided in token0 (so pool1 == 0) and the conversion FullMath.mulDiv(pool0, price, PRECISION) rounds down to 0 because the entire token0 balance is worth less than 1 smallest unit of token1.

• even when poolValueInToken1 is nonzero, the same rounding behavior can

make withdrawalValue0InToken1 round down to 0 for small token0-only withdrawals, which can produce shares == 0.

Consequently, withdrawCustom can be DoS’d for valid, edge-case states.

Be aware of these edge cases in calculateSharesToBurn and add explicit guards/fallbacks so poolValueInToken1 can’t be 0 and any nonzero withdrawCustom burns at least 1 share.

Gamma Team: Resolved.

Relayer is intended to be deployed via RelayerFactory, but neither the factory nor the Relayer constructor validates the ratio fields in TriggerConfig.

The constructor only validates deltas and weights before storing _triggerConfig, and _validateRatios is only enforced later in setRebalanceParams.

This means a relayer can be deployed through the factory with out‑of‑range ratios (>1e18) or baseMinRatio > baseMaxRatio, resulting in permanently misconfigured triggers until the owner updates parameters.

The deployment path therefore allows invalid trigger thresholds that the update path would reject.

Validate TriggerConfig ratios at deployment by calling _validateRatios in the constructor or factory.

Gamma Team: Resolved.

computeRelayerAddress accepts an arbitrary owner parameter and uses it in the CREATE2 address computation, but deployRelayer ignores any external owner input and always deploys the relayer with the actual MPM owner.

If a caller computes the address with any owner other than the MPM owner, the computed address will not match the deployed address and consequently, external integrations can end up configured with the wrong address.

Consider removing the owner parameter and always use MultiPositionManager(mpm).owner for address computation.

Gamma Team: Resolved.

When MultiPositionManager::claimFee is executed by the factory CLAIM_MANAGER, address(0) is encoded to skip owner fee collection. However, an MPM owner can call grantRelayerRole(CLAIM_MANAGER), causing the CLAIM_MANAGER to match the first condition:

function claimFee() external {
if (msg.sender == owner() || s.relayers[msg.sender]) {
poolManager.unlock(abi.encode(IMultiPositionManager.Action.CLAIM_FEE, abi.encode(owner())));
}

This will attempt to send ETH fees to the owner, triggering the receive() function. A malicious owner can revert this transaction, thus blocking protocol treasury fee collection.

Eventually, the owner must withdraw and claim fees, which will allow fee collection by skipping owner ETH fee collection.

However, if the owner decides to burn up to 99% of their positions, and follow-up with a small donation via PoolManager::donate, this will accrue fees in the existing in-range positions, thus blocking protocol fee collection permanently (as it will always attempt to send small ETH fees to the owner).

Do not allow MPM owners to grant relayer role to the CLAIM_MANAGER address.

Gamma Team: Resolved.

When fees are collected via MultiPositionManager::claimFee, both token0 and token1 fees are collected together:

_claimFeeCurrency(poolManager, s.factory, s.currency0);
_claimFeeCurrency(poolManager, s.factory, s.currency1);

If any of these calls fail, this blocks fee collection for both currency0 and currency1. Given the design of the protocol is to facilitate token launches, any custom token can contain blacklist mechanisms.

If a malicious owner blacklists the protocol fee recipient, the claimFee transaction will revert, and the protocol will also lose fees on the other currency (which, given the auction mechanism, in most cases will be ETH/USDC).

Consider separating the fee collection for both tokens in two different functions, so if fee collection fails for one token, it can still be possible to collect for the other token.

Gamma Team: Acknowledged.

Carpet positions use a fixed weight of 0.005% (CARPET_WEIGHT = 0.00005e18) and span the full tick range (min to max usable ticks). When calculating liquidity:

liquidity = token1 * Q96 / (sqrtPriceUpper - sqrtPriceLower)

The extreme tick range can create a large denominator, which combined with the relatively small fixed allocation, liquidity rounds down to zero for small deposit amounts. The validation then reverts:

function _validateCarpetLiquidity(...) {
if (baseRanges[0].lowerTick == minUsable && liquidities[0] == 0) {
revert InsufficientLiquidityForCarpet();
}
}

For regular rebalances, users can disable carpet mode. However, during migration via LBPStrategyBasic, if currencyRaised from the auction is small and carpet mode is enabled, migration will be permanently blocked since parameters are preset at deployment.

Similar to base positions, skip carpet positions gracefully when liquidity rounds to zero instead of reverting. Alternatively, allow users to disable carpet mode during migration if needed.

Gamma Team: Resolved.

The protocol's revenue model relies on splitting LP fees collected via zeroBurnAll between the position owner and the fee recipient.

However, Uniswap V4 hooks can capture swap fees before they accrue to LP positions through mechanisms like BEFORE_SWAP_RETURNS_DELTA or LP fee overrides.

Since MPM allows creating positions on any pool, users can select pools with fee-capturing hooks. In such pools, LP positions accrue reduced or zero fees, leaving the protocol with no revenue despite providing a managed liquidity service.

Consider validating pool hooks during position creation, or implementing an alternative fee mechanism that doesn't depend solely on LP fee accrual.

Gamma Team: Acknowledged.

When creating pools through OrderBookFactory, the desired deposits and ethForDeployment is calculated, followed by MGM deployment through either MultiPositionFactory.deployDepositAndRebalance() or deployDepositAndRebalanceSwap().

In case a user sends ETH exceeding the deposit desired, it is refunded to msg.sender: MultiPositionManager::_transferIn:

function _transferIn(address from, Currency currency, uint256 amount) internal {
if (currency.isAddressZero()) {
require(msg.value >= amount);
if (msg.value > amount) {
payable(msg.sender).transfer(msg.value - amount);
}
...
}

However, in the OrderBookFactory or Token Launch Migration flow, msg.sender is the MultiPositionFactory contract, which lacks a receive() function.

This means any transaction with refunded ETH will revert, causing DoS to pool launches with limit order support.

Add a receive() function to MultiPositionFactory and And refund excess ETH to the original caller at the end of deployDepositAndRebalance() and deployDepositAndRebalanceSwap().

Gamma Team: Acknowledged.

Multiple functions in MultiPositionManager lack deadline parameters, including deposit(), withdraw(), withdrawCustom(), rebalance(), and compound().

Without deadlines, transactions can remain pending in the mempool and execute at a much later time when market conditions have changed significantly, potentially resulting in unfavorable outcomes for the user (i.e., during deposits, users may receive shares at an outdated price).

Add a deadline parameter to the above MPM functions

Gamma Team: Acknowledged.

The scaleAllocations function in RebalanceLogic contains an unreachable else branch that handles explicit weights mode (useAssetWeights = false).

This code path can never be executed because the only caller, _calculateLiquiditiesFromWeights always calls this function with useAssetWeights = true, and returns early when explicit weights are used.

Remove the else branch and the useAssetWeights parameter from scaleAllocations.

Gamma Team: Acknowledged.

The scaleAllocations function in RebalanceLogic iterates over the same array indices twice (once for token0Allocations and once for token1Allocations). Since both arrays are always the same length, these loops can be combined into a single iteration to save gas.

Combine the loop into one to save gas:

for (uint256 i = 0; i < rangesLength;) {
if (data.totalToken0Needed != 0) {
data.token0Allocations[i] = FullMath.mulDiv(data.token0Allocations[i], available0,
data.totalToken0Needed);
}
if (data.totalToken1Needed != 0) {
data.token1Allocations[i] = FullMath.mulDiv(data.token1Allocations[i], available1,
data.totalToken1Needed);
}
unchecked { ++i; }
}

Gamma Team: Acknowledged.

The _executeRebalance function accepts outMin and inMin parameters but never uses them:

function _executeRebalance(
SharedStructs.ManagerStorage storage s,
IPoolManager poolManager,
StrategyContext memory ctx,
IMultiPositionManager.Range[] memory baseRanges,
uint256[] memory weights,
uint256[2][] memory, /* outMin */  // Unused
uint256[2][] memory /* inMin */    // Unused
)

The actual slippage protection occurs later in processRebalanceInCallback.

Remove the unused parameters from _executeRebalance signature to improve code clarity and save gas.

Gamma Team: Acknowledged.

In calculateCurrentRangeExcess, the else branch setting actualLiquidity = 0 is unreachable:

if (sqrtPriceX96 < sqrtPriceUpper) {
uint256 intermediate = FullMath.mulDiv(sqrtPriceUpper, sqrtPriceX96, FixedPoint96.Q96);
actualLiquidity =
uint128(FullMath.mulDiv(data.token0Allocations[idx], intermediate, sqrtPriceUpper -
sqrtPriceX96));
} else {
actualLiquidity = 0;  // Unreachable
}

If token0Needed is non-zero, then that already means sqrtPriceX96 < sqrtPriceUpper (due to the previous lines). Therefore, for the if (data.token0Allocations[idx] < token0Needed) branch to execute, if (sqrtPriceX96 < sqrtPriceUpper) will always be true, thus never entering the else branch.

The unreachable branch also exists in mintFromAllocations for the current range branch.

Remove the unreachable else branch.

Gamma Team: Resolved.

RebalanceLogic.processRebalanceAfterWithdraw is implemented but never called. This function is intended for automatic rebalancing after single token withdrawals.

Note that owners can achieve the same result by manually calling rebalance() after withdrawing.

Remove the dead code or integrate into withdrawal flow.

Gamma Team: Resolved.

In RebalanceLogic::calculateInitialAllocations, when multiple position ranges contain the current tick, only the last one is recorded as currentRangeIndex:

for (uint256 i = 0; i < rangesLength;) {
...
if (baseRanges[i].lowerTick <= data.currentTick && data.currentTick <
baseRanges[i].upperTick) {
data.currentRangeIndex = i;  // Overwrites on each match
data.hasCurrentRange = true;
}
unchecked { ++i; }
}

Subsequently, fixCurrentRangeAndRedistribute only fixes the range at currentRangeIndex and neglects redistributing for the previous positions that were also in the current range.

The impact is that the excess tokens from these other positions will remain idle in the MPM, until the owner withdraws them.

Currently, the protocol strategies enforce that the ranges list will not have any overlapping ranges. However, if an MPM owner decides to utilize custom strategies (with overlapping ranges), then they should be aware of this edge case.

Consider documenting this edge case for MPM owners who decide to utilize custom strategies.

Gamma Team: Acknowledged.

The contracts MultiPositionManager, MultiPositionFactory, RelayerFactory, DynamicFeeHook, DynamicF eeLimitOrderHook, VolatilityDynamicFeeHook, and VolatilityDynamicFeeLimitOrderHook rely on OpenZeppelin Ownable to guard sensitive actions, but ownership transfers take effect immediately.

If the owner key is compromised or a transfer is made by mistake, control moves instantly with no explicit acceptance step and no time for monitoring to react.

Consider implementing OpenZeppelin Ownable2Step in these contracts so ownership transfers require a separate acceptOwnership call before onlyOwner privileges move to the new owner.

Gamma Team: Acknowledged.

In Relayer, executeWithdrawal contains a check that includes (withdrawToken0Only && withdrawToken1Only).

However, validateWithdrawalParams function forbids setting both withdrawToken0Only and withdrawToken1Only at the same time and executeWithdrawal validates params before this branch.

This part of the condition is effectively unreachable under any allowed configuration.

Consider removing the unreachable branch.

Gamma Team: Resolved.

Limit positions are minted using all remaining balances with inMin = [0,0], meaning no slippage protection is applied.

This is not currently exploitable because limit positions are single-sided and use only leftover tokens, so no excess spending or token loss can occur.

If future changes introduce different execution assumptions, this could become a real slippage risk.

Ensure protocol team is aware of this, or consider documenting it.

Gamma Team: Acknowledged.

The compound() (and compoundSwap) function calls zeroBurnAllWithoutUnlock() twice:

function compound(uint256[2][] calldata inMin) external payable onlyOwnerOrRelayerOrFactory {
if (s.basePositionsLength > 0) {
poolManager.unlock(abi.encode(IMultiPositionManager.Action.ZERO_BURN, ""));
}
poolManager.unlock(abi.encode(IMultiPositionManager.Action.COMPOUND, abi.encode(inMin)));
}

Then, processCompound() calls it again:

function processCompound(...) external {
if (s.basePositionsLength == 0) return;
WithdrawLogic.zeroBurnAllWithoutUnlock(s, poolManager);

The second call collects zero fees since they were already collected. This wastes gas from looping through all positions twice and two separate UniswapV4 unlock calls.

Remove the zeroBurnAllWithoutUnlock call from processCompound().

Gamma Team: Acknowledged.

In WithdrawLogic.processWithdraw, when withdrawToWallet = false, a Burn event is emitted even though shares are not actually burned. The main contract only burns shares when withdrawToWallet = true:

if (withdrawToWallet) {
_burn(owner(), shares);
}

This causes a mismatch between emitted events and actual state, misleading off-chain indexers and integrations that track share burns.

Either rename the event to accurately reflect the action (e.g., LiquidityRemoved), or only emit Burn when shares are actually burned.

Gamma Team: Acknowledged.

In withdraw, ETH is transferred to the owner before shares are burned: WithdrawLogic.processWithdraw():

s.currency0.transfer(to, amount0);  // ETH sent here

MultiPositionManager.withdraw():

if (withdrawToWallet) {
_burn(owner(), shares);  // Shares burned after
}

The owner could re enter deposit (which lacks nonReentrant) during the ETH callback, potentially receiving inflated shares since totalSupply hasn't been reduced yet.

Currently unexploitable because only the owner can deposit/withdraw, meaning they would be the only user affected. However, this violates CEI pattern and could become exploitable if the design changes to support multiple users.

Either add nonReentrant to deposit, or burn shares before transferring tokens.

Gamma Team: Resolved.

When a full withdrawal occurs, the WITHDRAW action burns all liquidity but doesn't clear position storage (basePositionsLength, basePositions, limitPositionsLength, limitPositions).

As a result, the vault is left in a state where no liquidity exists, yet the position storage still reflects old ranges.

Subsequent operations (e.g. future deposit + rebalance) rely on these stale lengths for validation:

if (outMin.length != s.basePositionsLength + s.limitPositionsLength)
revert OutMinLengthMismatch();

Users must provide outMin arrays sized for stale positions with zero values, otherwise the transaction reverts. This also causes wasted gas due to unnecessary iteration over zero-liquidity positions.

Clear all position storage when totalSupply becomes zero.

Gamma Team: Resolved.

Several admin and configuration functions, as well as ETH flow functions, update important state without emitting events, reducing on-chain observability for monitoring, alerting, and incident response.

RelayerFactory.sol

• setAutomatedManagementFee updates automatedManagementFee with no event.

Relayer.sol

• setAutomatedManagementFee updates automatedManagementFee with no event,
• setWithdrawalParams updates state.withdrawalParams without emitting an event,
• setCompoundSwapParams updates state.compoundSwapParams without emitting an event,
• pause/unpause update state.isPaused without emitting Paused/Unpaused event declared

in IRelayer.sol,

• fundContract/receive accept ETH with no event. withdrawFunds transfers ETH out with no event.
• executeRebalance/executeRebalanceSwap can use TWAP centering without

emitting TwapCenterUsed (declared in IRelayer.sol).

MultiPositionFactory.sol

• setFeeRecipient updates feeRecipient with no event,
• setProtocolFee updates protocolFee with no event.

MultiPositionManager.sol

• claimFee triggers fee distribution without an event that records amounts/recipients.

Consider emitting dedicated events for these functions.

Gamma Team: Acknowledged.

In executeRebalanceSwap and executeCompoundSwap, the initial funding check uses address(this).balance, which temporarily includes msg.value.

However, msg.value is later forwarded to MPM before _reimburseGas. If the relayer has little or no pre-funded ETH, the call can pass the MIN_BALANCE check using the caller-supplied msg.value, then revert during reimbursement due to insufficient remaining balance, reverting the entire transaction and causing wasted executions.

Check the relayer’s balance excluding msg.value before proceeding.

Gamma Team: Resolved.

The rebalance() path validates that weights sum to 1e18:

if (ctx.weight0 + ctx.weight1 != 1e18) revert InvalidWeightSum();

However, _buildStrategyContext() used by the rebalanceSwap path lacks this validation. Malformed weights (e.g., weight0=0.8e18, weight1=0.8e18) can be passed into density calculations and be stored in lastStrategyParams.

Since only trusted callers can invoke this functions, impact is limited to user error.

Add the same validation in _buildStrategyContext() for consistency.

Gamma Team: Resolved.

In RelayerFactory.deployRelayer, the function requires a minimum payment: if (msg.value < 0.001 ether) revert InsufficientPayment();

Later, the function conditionally forwards ETH to the relayer:

if (msg.value > 0) {
(bool success,) = relayer.call{value: msg.value}("");
if (!success) revert InvalidAddress();
}

The if (msg.value > 0) check is redundant since the earlier validation guarantees msg.value >= 0.001 ether. The condition will always be true.

Remove the redundant check:

(bool success,) = relayer.call{value: msg.value}("");
if (!success) revert InvalidAddress();

Gamma Team: Resolved.

The WithdrawPath enum in WithdrawLogic.sol defines a path named BURN_AND_REBALANCE, but the implementation explicitly does not rebalance:

// Withdrawal path enum
enum WithdrawPath {
USE_CURRENT_BALANCE, // Step 1: sufficient idle balance
USE_BALANCE_PLUS_FEES, // Step 2: need zeroBurn for fees
BURN_AND_REBALANCE // Step 3: burn all + rebalance remaining
}

After burning, there is no rebalance, which the following comments confirm:

// NO REBALANCING - excess remains as unused balance

This creates confusion about the intended behavior and could mislead integrators.

Rename the enum to accurately reflect its behavior, e.g., BURN_POSITIONS

Gamma Team: Resolved.

The _mintLiquidityForAmounts function uses minAmountIn slippage protection instead of maxAmountIn.

This protects only against spending too little, but provides no protection against spending more than expected at an unfavourable price.

In most cases, the outMin slippage from burning will provide protection against this attack. However, burning existing positions (no outMin protection) can be skipped in the following cases: 1. The first deposit + rebalance on a pool with existing liquidity. Note that multiple MPMs (with different owners) can exist for a single pool. 2. Users deploying MPMs on popular trading pairs (WETH/USDC, etc.) with existing liquidity (i.e through direct deployDepositAndRebalance call). 3. The first deposit + rebalance after a full withdrawal (no existing positions to burn).

Combined with slot0 spot price reads, attackers can sandwich this transaction: 1. Front-run: manipulate price with a swap. 2. Rebalance mints liquidity at the manipulated price. 3. Back-run: restore price and extract profit.

The slippage check still passes because min tokens were spent, even though they were spent at a worse exchange rate.

Unless minIn is always set high enough to prevent this attack, the transaction reverts easily due to small price changes, causing DoS.

Similar to Uniswap, consider also using maxAmountIn slippage when adding liquidity to a position.

Gamma Team: Acknowledged.

Proof of concept: PoC

In RelayerLogic, withdrawSingleToken function first calls MultiPositionManager.withdrawCustom (using the caller supplied outMin) to withdraw only token0 or token1 to the owner, then, if the other token still remains, calls rebalance to redeploy the leftover assets.

For this rebalance leg it constructs fresh outMin and inMin arrays and leaves them at their default zero values, effectively disabling slippage checks for both burning existing liquidity and minting new liquidity.

Because the rebalance flow derives allocations from the pool’s current slot0 spot price, an attacker can sandwich the transaction by moving the price before the rebalance and restoring it after, extracting value from the vault and reducing the owner’s remaining total value.

Since the rebalance mechanism in the withdrawSingleToken flow is currently unreachable due to M-26 issue, the severity of this finding has been reduced.

Accept and enforce outMin/inMin for the rebalance step and consider adding a TWAP deviation check.

Gamma Team: Acknowledged.

The calculateSharesToBurn function in WithdrawLogic.sol uses the slot0 spot price to determine the amount of shares users must burn when calling withdrawCustom.

For PATH_1 (USE_CURRENT_BALANCE) and PATH_2 (USE_BALANCE_PLUS_FEES), there is no slippage protection on this calculation.

If the spot price moves unfavourably (natural volatility or attacker manipulation swapping token1 -> token0 and swap back at a small cost), the owner ends up burning significantly more shares than intended.

Since PATH 1 and PATH 2 withdraw from idle balances without burning positions, the outMin parameter provides no protection.

The user receives their requested tokens but permanently lose the excess shares burned.

Since the owner remains the sole shareholder, they can still withdraw all remaining vault value using their remaining shares. However, if the MPM ever supports multiple shareholders, this becomes problematic.

Ensure the protocol team is aware of this, in case there are any future changes. Consider adding a maxSharesToBurn parameter to withdrawCustom.

Gamma Team: Acknowledged.

According to the comment, the StrategyParams struct is intended to fit in two storage slots, but the current field sizes exceed 32 bytes in the second slot.

The second slot contains two uint120 fields (30 bytes) and three bool flags (3 bytes), totaling 33 bytes.

This forces the last flag to spill into a third slot. As a result, the existing comment claiming two-slot packing is misleading.

Change the mentioned comment or consider replacing the three bool fields with a single uint8 flags value to keep the struct within two slots.

Gamma Team: Resolved.

Multiple loops that iterate over base positions use uint8 as the counter, which implicitly assumes basePositionsLength <= 255.

There is no explicit guard in the contract to enforce this bound, so if a strategy (especially a custom strategy) returns more than 255 ranges, the loop counter will overflow the loop will behave incorrectly.

Consider using uint256 for loop counters or enforcing a hard upper bound on the number of ranges returned by strategies and revert if exceeded.

Gamma Team: Acknowledged.

Base positions with zero liquidity can be stored in the basePositions[] array. Unlike carpet positions which revert via InsufficientLiquidityForCarpet() when liquidity rounds to zero, base positions have no such validation.

Once stored, these positions are completely ignored — compound() distributes tokens proportionally based on existing token holdings:

if (positionToken0[i] != 0) {
amounts0[i] = FullMath.mulDiv(amount0ToDistribute, positionToken0[i],
totalToken0InPositions);
}

Positions with zero liquidity hold zero tokens, so they receive zero allocation and remain empty indefinitely. These dead positions consume gas during iteration in every operation (compound, withdraw, rebalance) while contributing nothing.

Consider allowing compound for these positions, or validate minimum liquidity/skip storing zero-liquidity positions during rebalancing.

Gamma Team: Acknowledged.

The lens computes withdrawal slippage bounds using manager.totalSupply(), but Relayer.executeWithdrawal withdraws only the MPM owner’s shares. Since shares are ERC20 and deposit can mint to arbitrary to addresses, the owner may not hold the full supply.

This inconsistency can overstate the shares actually withdrawn, producing misleading outMin values and inaccurate withdrawal previews.

Update the preview to mirror the actual withdrawal logic by using the MPM owner’s share balance (balanceOf(Ownable(manager).owner())) when calculating outMinForShares.

Gamma Team: Resolved.

Native ETH payouts use transfer, which forwards only 2300 gas and can fail for valid contract recipients. This creates a dos risk: fee claims or withdrawals can revert and leave ETH stranded.

Use a safe call pattern for native transfers ((bool ok, ) = recipient.call{value: amount}("")) and require success.

Gamma Team: Resolved.

_checkLimitTickTrigger decides whether the current price is inside the active limit range using only slot0.tick. Uniswap v4 documents an edge case where slot0.tick can be one less than the tick implied by sqrtPriceX96 when the price is exactly on a lower tick boundary.

In that state, the observed currentTick equals lowerTick - 1 even though the price is on the lower boundary.

The implementation uses asymmetric inequalities for below/above distance checks. Using > below the range but >= above makes the threshold asymmetric by one tick.

It requires lowerTick - currentTick to exceed limitDeltaTicks to trigger below, but triggers as soon as currentTick - upperTick reaches limitDeltaTicks above.

This subtle one-tick directional buffer may surprise integrators expecting symmetric distance checks.

Consider explicitly treating the lower-boundary edge case as inside. When currentTick == lowerTick - 1 and sqrtPriceX96 == TickMath.getSqrtPriceAtTick(lowerTick), consider treating the price as on-boundary and do not trigger.

Gamma Team: Acknowledged.

The relayer tries to reimburse OP Stack full transaction cost by adding an L1 data fee to the normal L2 gas refund, by calling the OP Stack GasPriceOracle with the current call data.

However, this is inaccurate for two reasons:

• getL1Fee is designed to estimate the L1 data cost from the bytes of an unsigned, RLP‑encoded

transaction, but the relayer passes only msg.data. Because this omits the transaction envelope bytes (transaction type prefix, nonce, gas limit, maxFeePerGas/maxPriorityFeePerGas, to, value, access list, etc.), the oracle is not pricing the same data that will actually be published to L1, so the L1 fee estimate will be consistently too low.

• gasUsed is computed before calling the oracle, so the L2 gas spent to compute l1Fee is not

included in gasUsed and is never reimbursed.

Consequently, automation services can be systematically under-reimbursed, causing rebalances and withdrawals to stop running reliably.

Reorder the accounting so the oracle call is included in gasUsed, and estimate L1 fee using a more accurate input, commonly by appending a small constant padding to msg.data before calling getL1Fee.

Gamma Team: Resolved.

During processRebalanceInCallback, the contract validates the length of the user-supplied inMin array. When rebalanceParams.useCarpet is true and inMin.length != baseRanges.length, the code discards the caller’s inMin and replaces it with a zero-filled array.

Since inMin is mint-side slippage protection, filling it with zeros effectively disables the caller’s intended safeguards. A rebalance can then proceed under worse than expected execution conditions without reverting.

Consequently, a MEV actor can sandwich the rebalance and it may still succeed because mint inMin slippage checks have been bypassed.

Do not auto-zero slippage parameters on length mismatch. Consider always reverting when inMin.length != baseRanges.length, and only accept inMin.length == 0 as an explicit no slippage protection signal.

Gamma Team: Resolved.

The protocol uses a sentinel value type(int24).max to derive the strategy center from the pool’s current tick when executing rebalances. The relayer constructs RebalanceParams with this value in constructRebalanceParams function.

Downstream, the rebalance and rebalanceSwap flows interpret this sentinel by reading currentTick from slot0 and rounding it down to a tickSpacing multiple.

This rounding is not constrained to Uniswap’s usable tick range (multiples of tickSpacing within [MIN_TICK, MAX_TICK]). When currentTick is close to the minimum tick boundary, the floor rounding can produce a ctx.center below minUsableTick(tickSpacing).

That invalid ctx.center is then passed to strategy.generateRanges, where range generation can compute an invalid span (right bound below left bound).

When several strategy converts this signed span into a uint256, the negative value becomes a huge number and later arithmetic overflows, causing the rebalance to revert.

Clamp the derived ctx.center to Uniswap’s usable tick range before calling the strategy.

Gamma Team: Resolved.

Proof of concept: PoC

The rebalance flow can revert while minting liquidity under specific edge-state combinations. In the rebalance callback path, liquidity is computed using LiquidityAmounts.getLiquidityForAmounts() and must fit into uint128.

In edge states (price near usable tick boundaries, edge-aligned/narrow limit ranges, and large effective per-range allocations), computed liquidity can exceed type(uint128).max, causing a revert (liquidity overflow).

When this happens, the rebalance transaction reverts, liquidity is not redeployed, and repeated attempts can continue to fail under similar conditions, creating a temporary DoS.

Add a pre-mint bound check before calling getLiquidityForAmounts() and cap or rescale per-range allocations whenever projected liquidity would exceed type(uint128).max.

Gamma Team: Resolved.

In WithdrawLogic, processWithdrawCustom function computes sharesBurned for the requested amounts and then, when idle balances and fees are insufficient, takes the PATH 3 branch. In this branch it burns a pro-rata portion of positions and then transfers the idle balances.

The underlying burn is performed by computing how much liquidity corresponds to the burned shares. However, in PoolManagerUtils.burnLiquidityForShare, the amount of liquidity to burn is truncated with integer division, so no liquidity is burned and no tokens are released.

uint256 liquidityForShares = FullMath.mulDiv(liquidity, shares, totalSupply);

The withdrawCustom then computes outputs from the post-burn idle balances, which can remain 0, and the caller still burns sharesBurned after processWithdrawCustom returns.

The protocol intends each MPM to have a single trusted shareholder, which reduces the impact of this finding - however this assumption is not enforced at the contract level because shares are standard ERC20 and deposits can mint to arbitrary to address.

Prevent share burns when the withdrawal produces no assets by reverting PATH 3 when both outputs are zero.

Gamma Team: Resolved.

When RelayerFactory.deployRelayer is called, it sets automatedManagementFee on the MPM via setFee. This increases the protocol fees from 5% to 10%.

If the MPM owner later pauses the relayer, automated rebalances stop but the increased fee remains.

Fees accumulated during the paused period are still split at the higher automatedManagementFee rate when claimed, even though no automation service is being provided.

Consider rebooting the fee to the factory's default protocolFee when the relayer is paused (ensure to collect fees just before changing the protocol fee, so previous accumulated fees still apply), and increase it again when unpaused.

Gamma Team: Resolved.

In processWithdraw, the withdrawToWallet = false path calculates unusedAmounts as a proportional share of balanceOfSelf(). However, at this point balanceOfSelf() already includes the tokens received from the burn callback (settled via _closePair).

Adding these to the already-set amount0/amount1 double counts the burned amounts in the emitted Burn event. The withdrawToWallet = true path avoids this by transferring burned amounts before calculating unused balances.

Subtract the burned amounts from balanceOfSelf() before calculating unused amounts, or compute unused amounts only from the pre-existing idle balance.

Gamma Team: Resolved.

In WithdrawLogic, calculateSharesToBurn includes a fallback for poolValueInToken1 == 0 intended to handle non zero token1 values.

However, in the real withdrawCustom flow these branches are effectively unreachable, as processWithdrawCustom enforces amount1Desired <= total1 before calling calculateSharesToBurn.

if (params.amount1Desired > pathInfo.total1) revert InsufficientBalance();

processWithdrawCustom passes pathInfo.total1 into calculateSharesToBurn as pool1. When the fallback triggers (poolValueInToken1 == 0), pool1 must be 0, which forces amount1Desired to also be 0 due to the precondition above.

Therefore, the fallback logic intended to handle nonzero token1 (the price conversion branches gated by amount1Desired != 0 or pool1 != 0) cannot be executed in the withdrawCustom path.

Move the nonzero-token1 fallback logic to preview-only code or document that it cannot occur in withdrawCustom flow.

Gamma Team: Acknowledged.

The relayer reimburses automation callers with no cap on the effective gas price or per-call reimbursement.

Because execution is restricted to AUTOMATION_SERVICE_ROLE, this is a privileged-abuse path rather than a permissionless exploit; however, a malicious or compromised automation address can still overpay gas and extract disproportionate ETH reimbursements, draining the relayer balance and causing automation to stop once balance falls below minBalance.

Consider adding configurable caps on reimbursable gas price and per-call reimbursement to limit overpayment risk.

Gamma Team: Acknowledged.

calculateSharesToBurn computes shares to burn using fee-inclusive totals from getTotalAmounts.

When the owner uses withdrawCustom and the withdrawal is satisfied partly by claimable fees (via USE_BALANCE_PLUS_FEES or BURN_AND_WITHDRAW paths), shares are burned proportional to the full withdrawal amount including the fee portion.

Since the owner can claim fees via claimFee() without burning any shares, this effectively costs the owner shares for value they are entitled to for free.

Since the owner is the sole shareholder, they're not losing value to anyone, just burning more shares than needed.

Exclude the owner's claimable fee portion from the share calculation, or automatically call claimFee before computing sharesBurned so that fee value is already extracted before the withdrawal share math is applied.

Gamma Team: Acknowledged.

In processClaimFee, if (s.fee != 0) is checked prior to executing owner transfer logic. However, s.fee is guaranteed non-zero (explicitly requires newFee != 0 in setFee) since totalFee0 / s.fee would revert due to division-by-zero.

Remove the redundant check.

Gamma Team: Resolved.

setFee updates s.fee immediately, but fee splits are calculated at claim time using the current s.fee as a denominator.

If fees accumulated under a previous rate are not claimed before changing the fee, the new rate applies retroactively.

For example, fees accumulated at s.fee = 20 (5% treasury) would be split at 10% if s.fee is changed to 10 before claiming (i.e., during relayer deployment).

Call claimFee before updating the fee, either by enforcing it within setFee itself or documenting it as a required precondition. In RelayerFactory::deployRelayer, trigger a fee claim on the MPM before calling setFee.

Gamma Team: Acknowledged.

Proof of concept: PoC

The rebalance flow can still revert during mint under edge-state combinations due to per-tick liquidity capping, causing TickLiquidityOverflow in Uniswap v4.

In the rebalance callback path (PoolManagerUtils._mintLiquidityForAmounts), liquidity is derived via LiquidityAmountsCapped.getLiquidityForAmountsCapped() and capped to int128.max, but not capped against the pool’s maxLiquidityPerTick constraint.

When price is near extreme usable ticks and ranges become narrow/edge-aligned (for example, near 887271 -> 887272), the computed liquidityDelta can remain valid for uint128 yet still exceed per-tick headroom, so poolManager.modifyLiquidity(...) reverts with TickLiquidityOverflow.

Cap rebalance mint liquidity by tick headroom, not just uint128 bounds.

Before modifyLiquidity, compute maxLiquidityPerTick from tickSpacing and clamp liquidityDelta to the smaller remaining headroom across tickLower and tickUpper. If headroom is zero, skip that mint.

Gamma Team: Acknowledged.

The MultiPositionManager mints new liquidity using the full on-contract balances of the pool currencies (including any unsolicited ERC20 or ETH sent to the contract).

If an operator or automation service supplies tight inMin values for rebalance minting, a third party can grief those rebalances by donating a small amount of one of the pool tokens immediately before execution, shifting the mint outcomes and a base position to fall below the precomputed inMin thresholds.

The minting path enforces per-position minimums and will revert the entire rebalance when any position under-mints either token.

Consequently, rebalances can be DoS’d as long as the attacker is willing to donate assets to the vault, forcing repeated reverts until inMin is loosened.

Be aware of this vector. While the attack is infeasible since an attacker would burn funds, a tightly set inMin could still be violated by a donation and cause a SlippageExceeded revert.

Gamma Team: Acknowledged.