Uniswap v3 LP Automatic Rebalancing System Development

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
Uniswap v3 LP Automatic Rebalancing System Development
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 Uniswap V3 LP Auto-Rebalancing System

Concentrated liquidity in Uniswap v3 has dual nature. An LP provider with narrow range collects 10-50x more fees than v2. But the moment price exits the range — the position becomes 100% in one asset and stops earning. ETH/USDC position with $1800-$2200 range at ETH $2500 — pure USDC bag, zero fees. Without automatic management, the provider loses yield on every major move.

The auto-rebalancing system's task: track positions, determine when price exits range, collect fees, close position, open new one around current price — atomically or via keeper.

Uniswap V3 Position Mechanics

NFT Positions and NonfungiblePositionManager

Each LP position in v3 is an ERC-721 token managed by NonfungiblePositionManager (address 0xC36442b4a4522E871399CD717aBDD847Ab11FE88 on mainnet). Main operations:

  • mint() — open position in given range [tickLower, tickUpper]
  • increaseLiquidity() — add liquidity to existing position
  • decreaseLiquidity() — partially or fully withdraw liquidity
  • collect() — collect accumulated fee tokens

For auto-rebalancing, a manager contract must own NFT positions (or have approval) — allows atomic calls to all operations.

Tick Math and Ranges

Price in v3 stored as sqrtPriceX96 — square root of price in Q64.96 fixed-point format. Calculate current tick: tick = floor(log(price) / log(1.0001)). Each tick = 0.01% price step.

Position range specified in ticks, must be multiple of tickSpacing. For 0.05% fee pool — tickSpacing 10, for 0.3% — 60, for 1% — 200. Position with 200 tick width around current price covers ~±1% movement.

Rebalancing Strategies

Passive Rebalance (After Range Exit)

Simplest: wait until price exits range, collect fees, close position, open new one centered on current price. Minus: impermanent loss is locked in, position was out-of-range for period.

Active Rebalance (Before Range Exit)

Rebalance when price approaches edge — e.g., when 20% width remains to boundary. Keeps position in-range and earning fees. Minus: frequent rebalancing on volatile market — high gas costs and swap losses.

Asymmetric Ranges

Instead of symmetric [price * 0.9, price * 1.1] — asymmetric per trend. On bull market for ETH/USDC: [price * 0.95, price * 1.20] — larger range upside. Trend parameters from off-chain EMA passed to keeper as performData.

Fee Reinvestment

Collected fees automatically reinvested in same position (compound). Requires pre-swap of fee tokens into correct ratio for current range — off-chain ratio calculation via Uniswap SDK, on-chain execution via exactInputSingle.

Contract Architecture

AutoLPManager
├── positionsByUser: mapping(address => uint256[]) — tokenIds
├── strategyByToken: mapping(uint256 => RebalanceStrategy)
├── rebalance(uint256 tokenId, RangeParams calldata newRange) — keeper call
├── collect(uint256 tokenId) — fee collection
└── compound(uint256 tokenId) — fee reinvestment

Key problem: swap before position opening. To open position in range [tickLower, tickUpper], exact token0/token1 ratio needed. If after closing position you have 100% USDC (price rose), but new position needs 50/50 ETH/USDC — need pre-swap. Swap changes ratio, potentially shifts tick, potentially changes required ratio... iterative calculation off-chain, then on-chain execution.

Alternative: use ready-made vault solutions as base. Arrakis Finance v2 and Gamma Strategies — open source vault contracts with exactly this logic. Forking and customizing is faster than building from scratch.

Monitoring and Keeper

Off-chain service (Node.js + viem) monitors:

  • Current pool tick: slot0()sqrtPriceX96 → tick conversion
  • Position ticks: positions(tokenId)tickLower, tickUpper
  • Accumulated fees: simulate collect() via eth_call

On rebalance trigger condition — call via Chainlink Automation or custom keeper EOA with sufficient gas buffer.

Gas estimates on mainnet:

Operation Gas
collect() fee ~90k
decreaseLiquidity() 100% ~120k
Swap token0 → token1 (v3) ~150k
mint() new position ~180k
Total full rebalance 540k ($15-40 at 20-50 gwei)

On L2 (Arbitrum, Base) same operations cost 20-50x less, making frequent rebalancing economically sensible.

Development Process

Strategy analytics (2-3 days). Backtest chosen strategy on Uniswap v3 historical data. For ETH/USDC 0.05% pool — data available via The Graph, Dune Analytics.

Contracts (1-2 weeks). AutoLPManager + keeper-compatible interfaces. Foundry fork tests on mainnet: simulate several rebalancings via large price movements.

Off-chain components (4-5 days). Position monitoring, optimal swap ratio calculation before mint, Chainlink Automation setup.

Testing (3-5 days). Compare APY with different strategy parameters on historical data.

Timeline Estimates

Basic system with one strategy on one pool — 1-2 weeks. Multi-pool, multi-strategy vault with governance — 3-4 weeks.

Cost calculated after choosing target pools and rebalancing strategies.