Automated LP position manager for Uniswap v3

We design and develop full-cycle blockchain solutions: from smart contract architecture to launching DeFi protocols, NFT marketplaces and crypto exchanges. Security audits, tokenomics, integration with existing infrastructure.
Showing 1 of 1 servicesAll 1306 services
Automated LP position manager for Uniswap v3
Complex
~1-2 weeks
FAQ
Blockchain Development Services
Blockchain Development Stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1214
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1161
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    852
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1041
  • image_logo-advance_0.png
    B2B Advance company logo design
    561
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    823

Developing automatic LP position manager (Uniswap v3)

Uniswap v3 made liquidity providers significantly more capital-efficient—and significantly more demanding of active management. Position in range $1800-$2200 for ETH earns fees only while ETH price stays in that range. Once price exits—position stops earning and becomes holding one of two tokens. Without automatic rebalancer most v3 LP positions work inefficiently.

Concentrated liquidity mechanics

How fees are calculated in v3

In Uniswap v3 liquidity is added to specific tick range. Tick—discrete price unit, each tick ≈ 0.01% price change. Range [tickLower, tickUpper] determines at which prices position is active.

Accumulated fees stored via global variables feeGrowthGlobal0X128 and feeGrowthGlobal1X128. For specific position—difference between current values and snapshot at creation, adjusted for ticks outside range. This is O(1) calculation—no iteration over all positions.

Collect fees: NonfungiblePositionManager.collect() transfers accumulated fee0 and fee1 to owner address. Calling collect without closing position—normal operation, usually profitable when accumulated fees > gas cost.

Impermanent loss in v3

In v2 impermanent loss is function of price ratio. In v3—function of price ratio and chosen range. Narrow range gives more fees while in range, but exponentially growing IL on exit. Wide range—fewer fees, less IL.

Optimal range width depends on specific pair volatility. For USDC/USDT pair at tick 1—range in few ticks. For ETH/USDC with 3-5% daily volatility—need range ±20-30% from current price to avoid too frequent rebalancing.

Automatic manager architecture

Rebalancing strategy

Several approaches:

Fixed-width rebalance—simplest. When price exits range create new position around current price with same width. Problem: frequent rebalance on sideways movement near boundary—each rebalance costs gas and pays slippage on swap for alignment.

Bollinger Bands—dynamic range width based on 20-day price standard deviation. High volatility—wide range, low volatility—narrow range. Implemented off-chain: keeper-bot calculates optimal range from historical data and calls rebalance only when current range significantly worse than optimal.

Asymmetric ranges—if market view exists, can make asymmetric range. Bullish—wider range up. But this already active trading strategy, not just liquidity management.

On-chain components

Smart contract manager implements:

interface ILPManager {
    // Create position
    function mint(
        address token0, address token1, uint24 fee,
        int24 tickLower, int24 tickUpper,
        uint256 amount0Desired, uint256 amount1Desired
    ) external returns (uint256 tokenId);
    
    // Collect fees
    function collectFees(uint256 tokenId) external returns (uint256 amount0, uint256 amount1);
    
    // Rebalance
    function rebalance(
        uint256 tokenId,
        int24 newTickLower, int24 newTickUpper,
        uint256 swapAmountIn, bytes calldata swapData
    ) external;
}

swapData in rebalance()—calldata for swap via Uniswap v3 Router or 1inch to align token ratio before new position creation. Specific route calculated off-chain and passed in transaction.

ERC-721 ownership: Uniswap v3 NFT positions either at user directly or at manager contract. If at manager—need accounting system "who owns what". If at user—need approve to manager for management. Second approach simpler to audit.

Off-chain keeper

TypeScript bot monitors positions every N blocks:

  1. Get current price via slot0() from pool
  2. For each managed position—check if price in range
  3. If outside range—calculate new optimal range
  4. Calculate necessary swap to align token ratio
  5. Estimate cost/benefit: gas + IL on swap vs expected fees in new range
  6. If profitable—call rebalance()

Important: compare expectedAnnualizedFees - rebalanceCost > holdCost. No point rebalancing $1000 position if gas is $50 and swap loses another $30.

Fee collection and reinvestment

Automatic reinvestment—auto-compound: collect fees, add back to position. This increases liquidity and future fees. But each compound—transaction with gas. Optimally compound when accumulated fees > gas_cost * 10.

Protocols like Arrakis Finance and Gamma automate this and charge % of fees as fee. When developing own manager—decide: take management fee (% TVL annually) or performance fee (% from fees)?

Timeline estimates

Smart contract manager with basic rebalancing strategy—1-2 weeks. Keeper-bot + monitoring + UI for position management—adds 1-2 weeks. Advanced strategy with Bollinger Bands and simulation—4+ weeks.

Cost calculated after discussing strategy and requirements.