Uniswap CLMM closePosition hardcodes 400k gas limit and cannot be overridden

[aaurix]

Summary

Uniswap CLMM closePosition can revert because the route uses a hard-coded gas limit of 400000, and callers do not have a way to override it through the current close-position endpoint. In the observed case, the same close calldata succeeds when simulated with a higher gas limit.

The route also appears to hardcode close slippage internally, while the public/tooling layers may expose slippage parameters that do not actually reach this close path.

Concrete example

• Network: Ethereum mainnet
• Connector: Uniswap CLMM
• Position id: 1268766
• Close transaction: 0x12ba380643a228201caf2f8201f4ee00e9500564ed57a5c65eab24705dac165f
• Receipt status: 0
• Position status after tx: still open

Transaction details observed from Gateway logs:

• Target: Uniswap V3 NonfungiblePositionManager
• Fixed gas limit: 400000
• Failed transaction gas used: approximately 394011
• Logs: empty due to revert

Simulation using the same calldata at the relevant block:

• eth_call with gas = 400000: failed
• eth_call with gas = 800000: succeeded
• Approximate minimum successful gas was above 400k

This strongly suggests the revert was caused by insufficient gas limit rather than by missing position, ownership mismatch, or ordinary slippage.

Relevant implementation details

In the Gateway container source, the Uniswap CLMM close-position route uses a fixed gas limit:

const CLMM_CLOSE_POSITION_GAS_LIMIT = 400000;

The close-position route accepts the shared CLMM close schema with only:

• network
• walletAddress
• positionAddress

The route does not appear to accept or forward maxGas / gas limit for close, even though related Uniswap CLMM schemas contain fields such as maxGas.

The close path also uses an internal slippage tolerance instead of a caller-provided close slippage setting.

Expected behavior

Gateway should allow callers to configure or override the gas limit for Uniswap CLMM close-position transactions, or estimate gas before sending.

A safer route behavior would be:

1. Accept an optional maxGas / gas-limit parameter on CLMM close.
2. Accept an optional close slippage parameter, or clearly document that close slippage is fixed/config-derived.
3. Use eth_estimateGas or a preflight eth_call before sending the transaction.
4. Return an actionable error before submission if the estimated gas exceeds the configured gas limit.

Suggested fix

Possible implementation direction:

• Extend the close-position request schema to include optional maxGas and slippagePct.
• Change closePosition(network, walletAddress, positionAddress) to accept those optional parameters.
• Default to the current behavior for backward compatibility.
• Replace the hard-coded close slippage with a request/config value.
• Use the provided maxGas or a safer estimated gas value instead of always using 400000.

Example target behavior:

closePosition(network, walletAddress, positionAddress, maxGas?, slippagePct?)

With preflight:

const estimatedGas = await provider.estimateGas(txRequest);
const gasLimit = maxGas ?? addSafetyMargin(estimatedGas);

Related context

Existing issues show similar classes of Gateway parameter/config propagation mismatch:

• Uniswap connector improvements and inconsistencies #510
• Bug Report | Gateway gas settings for Polygon are not used when approving tokens on uniswap/router #545
• Gateway lp - Remove liquidity always remove 100% of the liquidity from position in Solana hummingbot#7840