Bot for automatic farming: APY normalization and gas minimization

Automatic farming: where profitability breaks

Automatic farming breaks not on strategy, but on the calculation of profitability.

The stated percentage for a pool is an instantaneous snapshot that no one brings to a common denominator: one protocol pays rewards in a single token, another pays in several, some of which are illiquid and sold at a discount.

Without normalizing profitability, the bot compares incomparable things and chooses the pool that looks best on paper but in fact yields less.

The second source of losses is the cost of fees. Every operation in the chain (swap, adding liquidity, harvesting rewards, rebalancing) costs gas, and as network load grows, these costs eat into the margin faster than the strategy can accumulate it.

A bot that rebalances on a schedule rather than based on economic expediency pays for every move regardless of whether it paid off or not.

The third factor is slippage and position liquidation. When the price moves sharply, a large trade executes at a worse price, and a leveraged borrowed position gets liquidated before the bot can react.

What matters here is not reaction speed in itself, but the thresholds at which a position is closed or reassembled.

All three causes come down to one thing: profitability must be calculated in a single metric, fees must be factored into the decision for every operation, and liquidation risk must be kept under control at the level of parameters, not hope for a lucky moment. Let's break down how this is addressed in the bot's architecture.

What a managed farming bot provides

Managed farming begins with yield normalization: the bot brings different sources to a single metric — accounting for accrual frequency, withdrawal locks, and entry/exit fees.

Without this, comparing rates is meaningless: two positions with the same APY actually produce different results, because one accrues rewards daily while the other does so once a week with part lost to gas.

After normalization, the bot ranks pools by net result and keeps the portfolio within the boundaries of a given risk profile.

Fee reduction is a separate engineering task.

The bot groups operations into a single batch, selects a window with low network load, and does not touch a position just to shift it for tenths of a percent: rebalancing is triggered only when the gain in yield covers the cost of gas with a margin.

This removes the main source of unnoticed losses — dozens of small transactions that eat into what has been accumulated.

Yield stability rests on predictable rebalancing: the bot recalculates weights on a schedule and when there is a deviation from target shares, not based on emotions or news.

Liquidation protection works as a separate loop — monitoring the collateral ratio, automatic partial closing of a position, and withdrawal of collateral as the threshold approaches.

The threshold is set in advance, so the decision is made by a rule, not by an operator on duty at night.

Taken together, this moves farming from manual mode into managed mode: yield no longer depends on who is watching the positions today, fees become a predictable line item, and drawdowns are limited by a pre-selected risk.

Farming Automation Methods

Farming automation is a spectrum of solutions ranging from manual operations to fully autonomous agents. The choice depends on how many positions you hold, how often the yield changes, and whether you are ready for the bot to act without your confirmation.

Manual management gives full control but loses on speed: hours pass between a signal and a transaction, and part of the income is lost to fees and missed rates.

Scripts handle the routine — they execute operations on a schedule but do not assess the situation: if yield has gone down, the script will continue depositing funds according to the old plan.

An autonomous bot calculates the normalized yield for each position, compares it with a threshold, and moves funds on its own. Constraints matter here: a limit on the size of a single operation, key protection, and a stop rule for anomalies. Without this, a single logic error is repeated across all positions simultaneously.

In practice, the hybrid approach works more often: the bot handles the routine and rebalancing, while decisions about changing strategy or large amounts remain with the human. Our engineers configure thresholds so that automation does not go beyond the specified boundaries.

How we implement a farming bot

We start implementation not with code, but with an analysis of what already works: which pools are involved, how profitability is calculated, where gas is being lost. Without this step, the bot automates chaos and locks in unprofitable scenarios.

1. Strategy audit. We consolidate venues, pools, and assets into a single table and bring profitability to a comparable base — without this, comparing rates is meaningless. Separately, we calculate what share of income is consumed by fees and slippage on entry and exit.
2. Metric normalization. We bring rates to a single horizon and account for how profitability changes as the invested amount grows. The output is a ranking of strategies by net result, not by the showcase percentage.
3. Logic design. We define entry and exit conditions, rebalancing thresholds, and limits per position. We build in scenarios for when the network is congested: the bot waits for transaction costs to drop rather than paying any price for speed.
4. Bot configuration. We assemble the configuration for the selected venues and assets and connect wallets with limited permissions. Keys are stored in such a way that withdrawing funds without the owner's confirmation is impossible.
5. Testing. We run the logic on historical data and on a small volume in the live network. We compare the calculated profitability with the actual one and adjust thresholds until the discrepancy falls within an acceptable range.
6. Handover and documentation. We deliver the configured bot, a description of the strategies, shutdown instructions, and a protocol for actions in case of venue failure. The client's team can change parameters without us.

Each stage ends with an artifact that can be verified: a strategy table, a set of thresholds, a test run report. This makes it possible to stop work at any step and see what has already been done.

What is included in the delivery

At the end of the project, you retain a working automatic farming loop and a complete set of artifacts that let you operate it, hand it over to another team, or extend it without us. Below is exactly what is included in the delivery.

• Strategy configurations. Files with parameters for each network and protocol: target pools, entry and exit thresholds, rules for normalizing yield to a comparable baseline, position size limits. They can be edited without rebuilding the bot.
• Architecture diagrams. The logic of capital allocation across pools, the transaction signing sequence, failure points, and behavior when a node or protocol becomes unavailable.
• Access policies. Roles for the operator, observer, and service keys, separation of rights for changing strategy and for withdrawing funds, key rotation rules, and hardware storage handling.
• Operational regulations. Startup and shutdown procedures, response to gas cost increases, actions when actual yield deviates from the calculated one, and the manual intervention protocol.
• Reporting. A dashboard for positions and accumulated yield, an operations log with transaction hashes, and regular summaries of fees and deviations from plan.
• Monitoring and alerts. A set of bot health checks, trigger thresholds, and notification channels for the team.
• Documentation and handover. Deployment instructions, configuration descriptions, breakdowns of typical incidents, and a knowledge transfer session for your engineers.

The package is self-sufficient: the configurations and regulations fully describe the system's behavior, so ongoing support is not tied to us. Describe your task — we will come back with an estimate and a delivery plan tailored to your setup.

Case: yield normalization in a volatile market

The client — a liquidity pool manager — came with a problem: position yields jumped from week to week, and part of the profit was eaten up by network fees on every rebalance.

The automatic farming bot operated on a fixed threshold and triggered during the most expensive hours, when network load was at its peak.

As a result, the actual return on capital turned out to be noticeably lower than the projected one, and predicting it a month ahead was impossible.

What we changed

We separated two tasks that a single trigger used to handle: yield normalization and fee management. The logic was rebuilt so that the decision to move funds is made only when there is a sustained deviation of yield from the target corridor, rather than on a one-off spike.

The trigger threshold is tied to the median over the observation window — random APY peaks no longer launch unnecessary operations.

A separate module estimates the cost of an operation before it is sent: if the fee eats up too large a share of the expected benefit, the transfer is postponed until a low-load window.

Batch operations combine several actions into a single transaction, and some transfers were moved to a layer-two network, where the cost of an operation is an order of magnitude lower.

Metrics before and after

The key effect is not peak yield but its predictability: capital stopped losing out to noise and expensive transactions, and the manager gained a clear dynamic over the horizon.

How is automatic farming different from manual?

Manual management is a cycle of "checked the yield → moved liquidity → collected rewards → paid for gas" that you repeat for every pool and every network.

Automatic farming moves this cycle into rules: you set the target pools, the acceptable yield range, and the fee limits once, and then the system itself tracks the rates and moves the funds.

The difference is not in the "speed of pressing a button," but in the fact that the decision is made based on data, not on the basis of a chart you happened to see.

The key difference is yield normalization. Rates in pools are expressed in different units: in some places it is annual with reinvestment, in others it is base without accounting for the frequency of reward collection.

Manual comparison almost always goes by the "pretty number" in the interface, and a pool with frequent reinvestment looks more profitable, although after deducting fees it lags behind.

Automation brings all rates to a single base — accounting for reinvestment frequency, network fees, and pool depth — and only then compares them.

The second difference is gas economics. With manual management, each operation is paid for separately, and on an expensive network, collecting small rewards eats up the profit.

Automatic farming works in batches: operations are grouped, some of the calculations go to a network with low transaction costs, and reward collection is performed only when the accumulated amount exceeds the profitability threshold. This is the automation threshold — the point below which moving funds does not cover the fee.

The threshold is calculated, not guessed: the expected yield for the period is compared with the full cost of operations — the network fee, the protocol fee, and slippage during exchange. If a pool yields less, automation skips it and waits.

With manual management, this calculation is usually not done at all, so some operations end up at a loss.

In terms of efficiency, the gap shows up at scale: a single pool can still be managed by hand, but five networks and a dozen positions require constant presence.

Automatic farming maintains the same quality of decisions both day and night, without missing windows of increased yield. Manual management remains reasonable where there are few positions and you want to control every trade personally.

Common technical concerns

Automated farming works with funds in pools, so the concerns here are not abstract: any failure means either missed yield or a position left unattended.

Below is a breakdown of the three questions most often asked before starting: how funds are protected, what happens if a node or network fails, and how failures affect the final yield.

What happens if a node, the network, or the bot itself fails?

Position state and the operation queue are written to the log before a transaction is sent, so after a restart the bot continues from the stopping point rather than from scratch.

If a node becomes unavailable, it switches to a backup; if a block is delayed, it does not send duplicates and does not pay for rejected transactions.

If the network is unavailable longer than a set threshold, the bot does not act blindly but locks the position and waits for confirmation from the operator.

How do failures and downtime affect yield?

Yield is lost not from the failure itself but from the difference in exchange rates and interest rates during downtime.

That is why APY normalization is recalculated based on the actual time in the position rather than the pool's nominal rate, and the bot does not chase a multiple rate increase if the entry and exit fees eat up the result.

Minimizing gas here directly serves yield: the cheaper it is to move liquidity, the more often it makes sense to do so.

We also separately test behavior on historical data: how the strategy withstands sharp rate movements and periods of high network load. This reveals the real class of failures before funds come into play.

Let's discuss your farming task

To come back with an estimate and a work plan, we need input data on your task, not a general idea. We'll gather it during the first call — usually 40-60 minutes with the engineer who will lead the project, without intermediary managers.

What helps us estimate the scope quickly and accurately:

• The list of networks and protocols where automated farming is planned: the bot's architecture and the set of integrations depend on this.
• The strategy logic: which pools, how we calculate yield, at what threshold we enter and exit, what we do when the rate drops sharply.
• APY normalization requirements: whether we account for token rewards, fees, impermanent loss risks — or only the nominal rate.
• Gas constraints: the acceptable transaction cost threshold, willingness to wait for a low network load window, priority of speed or savings.
• Access and infrastructure: your own nodes or third-party ones, where the keys are stored, whether there is a separate wallet for the strategy.
• Existing work: scripts, spreadsheets, manual procedures — often they can be reused rather than written from scratch.
• Acceptance criteria: which metrics you consider success — the share of profitable trades, the deviation of actual APY from the calculated one, the number of missed windows.

After the call, we record the agreements and come back with a timeline estimate, scope of work, and project kickoff plan.

If during the discussion we see a risk in the strategy or in the choice of network, we'll say so directly and propose an alternative rather than silently factoring it into the estimate.

Describe the task in any convenient form — we'll come back with an estimate and a work plan.