LP stands for Liquidity Provider. When we talk about “doing LP,” we mean depositing assets into a decentralized exchange's liquidity pool so that others can swap against them, earning a share of trading fees in return. This project uses concentrated liquidity, which lets you choose the price range in which to provide liquidity and concentrate your capital around a particular set of prices. While the price stays in that range, you have an opportunity to keep collecting fees. Once it moves outside, that liquidity no longer participates in trades at the current price. In a pool consisting of a token and a quote token, a prolonged decline in the token's price leaves the position holding more and more of that token. By the time the price breaks below the lower bound, the position may consist entirely of it. LP has been around for a long time, but the recent surge in on-chain trading has made things lively, and I have had a chance to try it a few times. When Robinhood Chain was booming in September, you could enter almost any pool and immediately receive an unexpectedly large amount of fee income. As the saying goes, even pigs can fly with a strong enough tailwind. I made quite a bit, but I lost quite a bit too—I just could not keep my hands off the trade button.

Later, on-chain activity gradually cooled, and the broader financial markets were subdued as well. That gave me a chance to organize what I had been doing. Manually selecting tokens, opening liquidity positions, collecting income, and taking profits or cutting losses could all be handled by a program with FMZ's new DEX functions. After burning through a great many tokens, I started working on an LP strategy that selects tokens automatically and manages positions adaptively.

The Pitfalls of Starting with the Rankings

There were detours along the way, of course. I followed my old approach: find the hottest tokens at the top of the rankings and let the program open positions. Quite a few turned out to be scams. Within minutes of entering, the price would plunge before I could get out, drop straight through the pool's lower bound, and leave me the proud owner of millions of worthless tokens.

That is especially painful for an LP. If you buy a token directly, at least you still hold the same number of tokens when its price falls. With concentrated liquidity, the pool keeps converting your quote token into the falling token along the way. I had hoped to collect fees while waiting for the price to fluctuate. Instead, I collected a little in fees and a very large inventory. Those impressive volume figures on the trending list looked rather different once they reached my own wallet.

In my earlier quantitative strategies, I would normally select an asset and an indicator, enter when certain conditions were met, and exit when others were met. That already amounted to a small systematic implementation. This time, however, the program had to select the asset itself. After entry, it also had to deal with the range, capital allocation, changing fee income, and on-chain execution. Changing a single token-selection indicator could not solve the problems across the whole process. That led me to cybernetics.

Organizing the LP Process Around Feedback

Cybernetics studies how systems can be regulated through feedback. Think of an air conditioner with a target temperature: a sensor continuously reads the room temperature, and the controller adjusts cooling power according to the difference. As the actual environment changes, the control action changes with it. A common PID controller divides this adjustment into three parts:

u(t) = Kp·e(t) + Ki·∫e(t)dt + Kd·de(t)/dt

Here, e(t) is the difference between the target and the current value, and u(t) is the action output by the controller. P is the proportional term, which responds to the current error. I is the integral term, which accounts for error accumulated over time. D is the derivative term, which responds to how quickly the error is changing. The three coefficients determine how strongly each term influences the control action.

Trading, of course, is not as obedient as an air conditioner. Setting a target return does not make the market deliver the money. This strategy adopts the idea of feedback control: model the changes in LP assets and fee income, simulate the possible outcomes of different actions, and then use actual operating data to correct the model. PID offers an intuitive way to understand feedback; the program's ranges and position sizes are calculated by return and risk models.

The first step is to use a consistent return objective. Fees collected from LP are only part of the trade's income. Changes in the value of the assets held, swap costs, and gas must all be included. The system makes decisions around net returns after accounting for these effects, with boundaries for capital usage and losses. An opportunity that looks worthwhile at token selection must still pass the test of actual costs when opening a position, and the test of real outcomes after entry.

Following this approach, I divided the process into five layers: token selection, pool selection, position opening, monitoring, and exit.

Layer 1: Token Selection

Token selection first determines which tokens are worth considering for LP.

Trending rankings are still useful because they provide a continually updated set of candidates. After those sharp drops, though, I no longer wanted ranking to determine entry directly. Active trading is only a starting point. Token safety, trading history, and price stability also matter when deciding whether that activity is worth participating in. For LP, a token that rallies sharply over a short period is not necessarily a better choice than one with sustained trading and relatively steady price fluctuations.

This layer compares expected fee income with inventory losses caused by price fluctuations. High fees provide a source of income, but excessive volatility can consume that income very quickly. Token selection narrows a large candidate set down to the assets more suitable for deploying capital, passing them to the next stage for calculation. Scan results and rejection reasons are also recorded. The status panel shows what the program is investigating in the current round and which tokens have been filtered out.

Actual token-selection scan: even actively traded tokens may be rejected because fees do not cover the model's estimated losses, trading history is insufficient, or the short-term drawdown is too large.

Layer 2: Pool Selection

A token often has pools with different trading pairs and fee tiers. Choosing the token does not yet answer where to put the capital.

One easy mistake is to estimate your fee income directly from the token's total trading volume. Most trading may be happening in a different pool. Even if you choose the pool with the largest volume, substantial liquidity may already be sharing those fees. The fee tier, pool volume, and competing capital need to be considered together.

FMZ's DEX interface can list candidate pools directly:

            javascript
            
            
var pools = exchange.IO("lp.pools", BASE, QUOTE);

The program then compares the pools one by one. For concentrated liquidity, it also needs to consider the active liquidity near the current price that is actually participating in trades. The total amount of money in a pool and the amount sharing in the current trade are not the same number. That distinction affects the estimate of our fee share and how much capital we should deploy next.

Pool selection therefore establishes the specific trading environment for the model. If a token that passed the previous stage has no suitable pool, the strategy will not proceed to open a position. Separating the token and pool decisions keeps “this token is popular” from being confused with “this pool is worth funding.”

Layer 3: Opening Positions

Position opening is where the LP simulation does most of its work. When operating manually, it is easy to choose a range by feel. A narrower range concentrates capital and may earn a larger fee share, but a small price move can take it out of range. A wider range accommodates larger fluctuations, at the cost of lower capital efficiency. The amount invested also affects the outcome: fixed gas costs can eat into a small position, while a larger position may increase swap impact, and its share of fees will not always grow in direct proportion to the principal.

I put these trade-offs into a single model. Using recent price data, the program generates multiple possible price paths and simulates how the assets in the position would change, how much fee income they could earn, and what it would cost to exit under different ranges and investment amounts. The result is a set of possible outcomes that can be compared for return and risk before selecting the range and position size.

The simulation models how LP actually works. Where the price goes, how much of each asset remains, and how long the capital stays within an active range all affect the final return. If you simulate only the token price and then add a fixed amount of fee income, many of concentrated liquidity's defining features are lost.

Once the model selects a configuration, the DEX functions generate and execute the position-opening plan:

            javascript
            
            
var plan = exchange.IO("lp.plan", {
    symbol: SYMBOL,
    budget: budget,
    range: {pct: rg.pct},
    shape: "spot",
    layers: LAYERS,
    pool: pool.id,
    slippage: LP_SLIPPAGE
});

var opened = exchange.IO("lp.add", plan);

lp.plan turns the capital budget, range, and pool into a position-opening plan, and lp.add executes it. This is where the strategy model connects with on-chain operations: the earlier calculations must become an actual position before subsequent feedback has something to measure.

For tokens with little measured history, the program starts with a smaller allocation and adjusts later investments as data accumulates. Costs must be recalculated after reducing the position size. Otherwise, a theoretical plan may look attractive, but the small amount actually invested may fail to earn enough fees to cover entry and exit costs. These calculations appear in the entry assessment so that the basis for the range and amount can be checked.

Layer 4: Monitoring

Once a position is open, feedback control begins to work continuously. The fee data used before entry inevitably involves some extrapolation. Heavy trading in the recent past does not guarantee the same activity ahead. Other investors adding capital to the pool also changes our share. The program must continually read the actual position and compare fees received with the original forecast.

            javascript
            
            
var positions = exchange.IO("lp.positions", SYMBOL);

If actual fees consistently fall short of expectations, the model lowers its subsequent estimates. As measured records accumulate for that token, the experience-based estimates borrowed at entry gradually give way to its actual performance. These records are retained for later decisions. When the same token becomes a candidate again, the program already has experience from its previous participation.

Monitoring also includes reassessing the current range. After the price moves, the program must use the latest state to calculate whether the original range still makes sense, whether continuing to hold compensates for the risk, and whether switching to another range justifies the cost of trading again. It compares holding, changing the range, and exiting, but does not act immediately on every brief change. On-chain adjustments cost money. Excessively frequent control actions can easily consume the fees that would otherwise have been retained.

Layer 5: Exit

The exit layer brings an LP cycle to a real conclusion. Normal exits follow a change in the return assessment: trading activity may have cooled enough that holding is no longer attractive, or the price may have left the range and opening a new position is not worthwhile. These exits can allow time for confirmation to reduce the cost of repeated entries and exits. If a contract anomaly occurs, pool liquidity drops sharply, or losses reach a limit, the outer risk controls intervene directly instead of waiting for the return assessment to confirm slowly.

In execution, withdrawing liquidity and selling the token must be handled together:

            javascript
            
            
var closed = exchange.IO("lp.remove", ids, 1, true);

This requests withdrawal of all liquidity and conversion back into the quote token. On-chain operations may involve several transactions, however. After liquidity has been withdrawn successfully, the wallet must still be checked to confirm that the token has been sold. Any remaining balance needs further handling; if it cannot be sold, the program raises an alert. Having already experienced what it feels like to hold millions of worthless tokens, I naturally take this step seriously.

Exit results also feed back into the system. Each cycle records the fees actually earned, profit or loss from asset-value changes, and transaction costs. Historical cycles and token records then become useful: they can reveal whether a type of opportunity is persistently overestimated and whether frequent range changes are worthwhile. The next round of token selection and position opening continues to draw on those actual outcomes.

With the five layers connected, the program can handle everything from discovering candidates to withdrawing the capital. Market changes enter the model, the model generates actions, and on-chain execution produces new position and return data that feeds into the next calculation. FMZ's new DEX functions save a substantial amount of work on basic operations, letting more effort go into this decision and feedback process.

Impressions from the Last Two Days

The most immediate difference in use is that the work of repeatedly browsing rankings, checking pools, and calculating returns can now be monitored from the status panel and logs. The status panel shows the current stage, capital, and positions, while the logs record specific decisions over time. There is a record of the entire strategy process, from token and pool selection to entry, adjustments while holding, and the final exit.

In this example, CRCL passed token screening and the program compared its pools. But after recalculating for the actual position size, the risk-adjusted return did not meet the entry requirement, so no position was opened. Reading the related log entries together makes it clear where the process stopped. Those same records can help locate the reasons when adjusting the model later.

After these two days of testing, this version can select relatively stable tokens from the candidates and open positions suited to the pool and market conditions. While on-chain activity is quieter, I plan to keep refining the process. Hopefully, by the next burst of on-chain activity, I will have a useful tool ready to go.

Strategy: Robinhood Chain Automatic Token Selection and Model-Adaptive Concentrated Liquidity Provision (Uniswap Live Version)