Uniswap v3: why LP positions go negative
Concentrated liquidity in Uniswap v3 works like this: you set the price range within which your funds operate. While the price is inside, capital is utilized more densely than in a classic pool, and the fee per unit invested grows.
As soon as the price exits the boundary, the LP position stops earning: the asset is fully converted into a single token, and you hold it on the sidelines of the market.
This is exactly where the main cause of losses lies. The range is not a static setting but a parameter that must be revised as the market moves. The narrower the corridor, the higher the return on capital, but the more often the price leaves it.
Without automation, the owner either keeps a wide range and loses in profitability, or sets a narrow one and a few hours later finds the position outside the boundary.
Manual rebalancing does not scale: you need to continuously monitor the price, close and reopen the position in time, re-select the boundaries, and make no mistakes in calculating volumes.
In a volatile market, such transitions happen several times a day, and every missed moment is lost fees plus accumulated adverse selection.
A separate problem is choosing the wrong moment. If you rebalance on every fluctuation, transaction costs and slippage eat up all the profit from fees. If you rebalance rarely, the position sits idle outside the range for a long time.
The balance between these extremes is achieved only algorithmically, taking into account volatility, pool depth, and gas cost.
An automatic manager solves this as a closed loop: it tracks the price relative to the boundaries, initiates exiting the range and reopening the position according to set rules, recalculates the boundaries for current volatility, and controls the costs of each operation. Below we break down how this is handled in practice.
Architecture of the Automatic LP Position Manager
The automatic manager keeps an LP position within the target range of Uniswap v3 without operator involvement: the contract monitors the current pool price, compares it with the boundaries, and initiates a rebalance when the position approaches the edge.
Manual management loses here not in accuracy, but in reaction speed — while the operator checks the chart, the range has already been passed, liquidity stops earning, and assets remain in an unfavorable proportion.
Trigger-Based Rebalancing
The smart contract stores the target zone and the trigger threshold. When the price goes beyond the boundary, it removes liquidity, changes the ratio of assets, and opens a new position with a recalculated range.
The key parameter is the width of the corridor: a narrow one yields more fees but requires restructuring more often, while a wide one is touched less frequently but brings less per unit of invested capital.
Manager Operating Modes
| Mode | When it fits | Limitations |
|---|---|---|
| Manual with notifications | Rare rebalances, control over every operation | Reaction depends on the operator, the window is missed |
| Semi-automatic | Confirmation is needed before a major restructuring | Delay between signal and execution |
| Fully automatic | Volatile pairs, round-the-clock operation | Requires correct limits and slippage protection |
Protection Against the Human Factor
Automation eliminates the class of failures associated with manual operations: a missed signal, incorrectly set boundaries, entering at a moment of sharp price movement.
The contract executes pre-defined logic identically at any hour, and all actions are recorded in a log — you can see when and why a rebalance was triggered.
Uniswap v3 provides concentrated liquidity, but it is precisely because of this that the position requires constant attention. The manager turns this from a routine into a manageable process with predictable rules.
How we implement a position manager: stages of work
Implementing an automatic LP position manager for Uniswap v3 starts with an audit: we look at which ranges your funds are currently placed in, how often you go out of range, how much time a position spends out of range, and which fees are wasted. Without this stage, any automation cements the existing errors in the rebalancing logic.
Next, we design the logic for your risk profile and horizon: rules for entering and exiting a range, trigger thresholds, limits on step size and frequency of rebuilds.
Separately, we define what the manager does during a sharp price move and when gas is insufficient — these are the scenarios where homemade bots most often lose funds.
- Audit of current positions. We collect history by pairs and ranges, calculate the share of time out of range and missed fees — this gives us a baseline for comparison after implementation.
- Logic design. We describe the rebalancing rules, stop conditions, and protective limits, and agree on them with you before writing code.
- Parameter configuration. We set the range width, rebuild step, fee thresholds, and limits on operation frequency for a specific pair.
- Development and internal checks. We write the position management module, cover the key paths with tests, including emergency stop and rollback.
- Testing on a testnet. We run scenarios on historical data and on a testnet: we observe how the logic behaves during sharp moves and in a calm market.
- Handover and documentation. We deliver the configurations, the logic diagram, instructions for changing parameters, and the procedure for actions in case of failure.
- Post-launch support. For the first while, we monitor actual metrics and adjust thresholds if market behavior differs from the projected one.
Each stage ends with an artifact that can be verified: an audit report, a rules specification, a set of parameters, run results. Describe your task — we will come back with an estimate and a stage-by-stage work plan.
How does an automated manager differ from manual management?
Manual management of an LP position in Uniswap v3 comes down to three actions: choose a price range, monitor its relevance, and move liquidity in time when the price goes beyond the boundaries. While the market is calm, this works.
But a range in Uniswap v3 is not "set it and forget it": the narrower it is, the higher the share of fees, and the faster the price leaves it.
At the moment of exit, the position stops earning and fully converts into one asset — in essence, you hold it without fees and with the risk of further movement against you.
Automation changes the very nature of the process. The manager tracks the price and the state of the position continuously, rather than at those moments when the operator has time to open the interface.
The reaction is measured not in minutes and hours, but in blocks: as soon as the price approaches the boundary or breaks through it, the position is rebuilt according to a predefined logic.
Manual management cannot do this — a person sleeps, works on another task, simply does not have time. It is precisely during these idle windows that the main part of the fees is lost.
Accuracy of hitting the range is the second gap. The operator sets the boundaries "by eye" and rarely recalculates them for changed volatility.
The algorithm calculates the range from the current price and a specified width, so the position stays in the working zone rather than hanging as dead weight outside it.
Gas costs with a manual approach are unpredictable: the rebuild lands on a peak in network load, and the fee eats up what was earned. The manager can postpone the action until an acceptable gas level or combine operations — where a person reacts immediately and expensively.
And most importantly — the human factor. A missed exit from the range, an incorrectly entered boundary, a forgotten position. The algorithm does not get tired and is not distracted, and all its actions are reproducible and logged.
Case study: how a manager kept a position within range
Before implementation, a position in a narrow-range pool lived on average 6-9 hours: the price moved outside the boundary, liquidity stopped earning, and returning to the range required manual intervention.
The operator checked the state several times a day, but hours passed between checks — during that time the position managed to fall out and accumulate unfulfilled orders.
The share of time in range held at 55-60%, and each repositioning of the boundaries was done manually and with a delay.
What was changed
We built an automatic manager that monitors the price and repositions the position boundaries according to a given strategy. The logic is placed in a separate service: it reads the pool state, compares the current price with the active range, and decides on repositioning.
All actions go through a simulation on a fork before being sent — the transaction is first verified against the real network state, and only then goes to mainnet.
Metrics before and after
| Indicator | Before | After |
|---|---|---|
| Share of time in range | 55-60% | 92-95% |
| Manual operations per week | 20-30 | 1-2 |
| Average reaction delay | hours | minutes |
| Class of eliminated failures | going out of bounds, missed repositionings | — |
We separately closed the class of failures related to transaction races: when the operator and the script simultaneously tried to change the position, some operations dropped out due to nonce. Now the queue of actions is serialized, and resending is done with gas recalculation.
What remained under human control
Automation does not cancel supervision: the operator sets the strategy, limits on position size, and thresholds beyond which the manager stops and waits for a decision. All actions are logged, and there is a rollback to the previous position state. This approach removes the routine but leaves risk management with the human.
Uniswap v3
Doubts before implementation: access, migration, rollback
Before launching an automatic Uniswap v3 LP position manager, the client usually asks three questions: what keys we get, what will happen to already open positions, and how to roll back if the strategy goes wrong. We answer to the point — without generalities.
What about access? The manager signs wallet transactions, so it needs access to the account that manages positions. We design roles so that the bot has a separate key with the right only to rebalance and collect fees, while withdrawal of funds remains with you. Keys are stored in a secure vault, not in code or configuration files.
What if migration? We do not touch already open positions until the first scheduled cycle: the manager reads the current ranges and picks them up as they are. The transition to the new logic is gradual — first on one pair, then on the rest, with result monitoring at every step.
How is rollback arranged? Each rebalancing cycle writes a state snapshot: range, liquidity, fees.
Rollback is a return to the previous snapshot and reopening the position according to it, not "manual restoration by eye." Plus there is always an emergency mode: stopping the bot and handing control over to you.
What if the strategy starts losing money on a volatile pair?
Every manager has limits: maximum drawdown, minimum range, fee threshold for rebalancing. If a limit is exceeded, the bot stops and sends a notification instead of continuing to trade. Limits are configured for your pair and horizon.
What if you already have your own bot or scripts? We do not break the existing logic: the manager connects as a separate layer on top of the current positions, and the old scripts can be kept in reserve.
What you will receive:
- Manager configurations: ranges, drawdown limits, rebalancing thresholds.
- A scheme of roles and access with separation of rights for management and withdrawal.
- A key storage policy and rotation rules.
- Documentation on operating cycles and decision-making logic.
- Instructions for rollback and emergency stop.
- A step-by-step migration scheme for existing positions.
- A set of metrics and a dashboard for fees and drawdown.
Describe your task — the pair, the horizon, and the current state of positions. We will come back with an estimate and an implementation plan.
Timeline for LP Position Manager Implementation
Timelines depend not on the volume of code, but on how quickly the position management rules are agreed upon: range boundaries, rebalancing thresholds, gas limits, and acceptable slippage. Below are approximate stages for a Uniswap v3 LP position manager.
The ranges are given for a typical project with a single strategy; parallel strategies and non-standard logic add time proportionally.
What affects the timeline. The number of pools and strategies, the need for an external code audit, multi-signature requirements for withdrawing funds, and the availability of ready-made monitoring infrastructure. If you already have a network node deployed and alerts configured, the setup stage is shortened.
How to speed things up. Fix the position management rules before development starts — this eliminates rework at the testing stage. Detailed requirements for behavior during volatility save more time than any tool.
Describe the task: which pools, what rebalancing logic, who manages the funds — we will come back with an estimate and a stage-by-stage plan.