Telegram bot for monitoring DeFi positions: what breaks
Manual position monitoring relies on a person who watches the collateral ratio in the protocol interface and keeps entry thresholds in their head.
Between "noticed a deviation" and "topped up collateral" lies a chain: check, choose network, assemble transaction, wait for confirmation. In a calm market it goes unnoticed; during a sharp move, it is the point of failure.
The most expensive failure is a missed event. The threshold is crossed not gradually, but with a single oracle update: the price moves, the collateral ratio falls below the acceptable level, and the position goes into liquidation before the on-call engineer even opens the app.
At night, on weekends, during a call, the person is physically outside the loop, and liquidation does not wait.
The second class is data desynchronization between sources. The rate on one venue, the borrow rate in the protocol, and the position state in a third interface update with different delays, and a "by eye" calculation produces an error in the dangerous direction. The engineer makes a decision based on an outdated snapshot and believes there is a buffer.
The third is reaction delay. Even when the signal arrives, a manual top-up takes minutes: choose the network, estimate the fee, sign, wait for inclusion in a block. By the time of confirmation, conditions have already changed, and the threshold may have shifted.
It is these three modes — missed event, desynchronization, delay — that set the requirements for a Telegram bot for DeFi monitoring: polling sources, thresholds with hysteresis, escalation when there is no confirmation. Let's break down how this is addressed in the architecture.
Position health monitoring: what changes after implementation
Before implementation, position status was checked manually: you open the protocol interface, check the health factor, estimate the buffer to the liquidation threshold.
After implementation, the bot polls positions on a schedule and simultaneously listens to protocol events — a discrepancy between these two sources itself becomes a signal that the data is outdated or diverging.
The speed of reaction to risk no longer depends on who opened the app first.
As soon as the health factor drops below a set level, the Telegram message contains the position address, current value, threshold, and buffer to liquidation — this is enough to make a decision without bringing up third-party services or checking numbers manually.
There are fewer manual checks not because they were disabled, but because only meaningful ones arrive.
Thresholds and notification frequency are configurable: in a calm market there are no messages; during a sharp move, the alert goes to a separate chat topic where the on-call engineer sees it, not the whole team.
The eliminated class of failures is missing a threshold crossing when the market moves faster than a human can react. Previously, such a miss ended in forced liquidation; now every trigger is recorded in a log with a timestamp, and it shows how much buffer remained for action.
Silence during a failure is closed there as well: if the price source does not respond or returns a value older than acceptable, the bot reports monitoring degradation instead of pretending the position is fine.
Alert modes: comparing control approaches
The control mode determines how quickly the bot notices risk and how much maintenance it requires. We combine three approaches — threshold, network event subscription, and scheduled sweep: each covers its own part of the tasks, and each has limitations to consider during setup.
Threshold alerting recalculates the position using the latest price and triggers when the collateral ratio falls below a set level. The mode is cheap in terms of load, but it stays silent until the price moves, and on a thin market it produces false calls.
Network event subscription reacts to changes in contract state — liquidations, large swaps, pool parameter changes. We take rates from several sources and compare them against each other: DefiLlama as the primary reference, and a backup one in case of divergence.
| Mode | When it fits | Mode limitations |
|---|---|---|
| Threshold alerting | One or two positions, need a fast signal by collateral level | Depends on the frequency and quality of the price source; a false call is possible |
| Network event subscription | Large positions where every block matters | A stable node and chain reorganization handling are needed; the notification stream requires a significance filter |
| Scheduled sweep | A portfolio of dozens of positions, summary and reporting | Between sweeps, an event remains unnoticed |
| Calculation model | Assets with variable yield where a forecast is needed rather than the current state | Sensitive to assumptions; an error in parameters causes systematic misses |
In practice, the scheduled sweep serves as the base, the threshold provides a fast signal, and the subscription catches what is visible only in the contract itself.
We explicitly close the limitations: a significance filter, a duplicate price source, a trigger log for analyzing false calls — a notification remains a reason to act, not noise.
How we build position monitoring: stages of work
We start with an inventory of how position monitoring is currently set up: where records are kept, who learns about risk and through which channel, how much time passes between a position change and a message in chat.
At this stage we also find out which triggers were false and why — most often the cause is a single data source or a threshold that triggers on ordinary market movement. Then we assemble the position calculation scheme and test it on past periods before putting it on watch.
- Review of current monitoring. We record the list of venues and position types, notification channels, reaction time, and trigger history for past periods. The output is a list of gaps: where the signal arrives with a delay, and where it is absent entirely.
- Position calculation scheme. We define quote sources, the structure of collateral and debt, accounting for accruals and fees, and the rule for choosing a value when sources diverge. We calculate the position's margin of safety to the liquidation threshold and show it in the message.
- Alert rules and thresholds. We separate events by significance: approach to threshold, sharp change in value, source unavailability. The owner and the on-call engineer receive different sets of notifications; each signal has a reason and a link to the calculation.
- Testing on historical data. We run the scheme over past periods and compare it with actual position movements. We measure the share of false and missed signals, and tune thresholds so that noise does not drown out significant events.
- Log and reproducibility. Every notification is saved with calculation parameters and the rule version — from the record one can understand why the signal triggered and reproduce the calculation.
- On-call regulations. We describe the escalation order, instructions for typical source failures, check windows, and reaction time. The on-call engineer receives a checklist, not a set of disconnected scripts.
- Handover and shift training. We run a walkthrough using live examples, hand over documentation on the calculation scheme and rules, and record who changes thresholds going forward and how.
As a result, the team retains a reproducible calculation scheme tested on history and on-call regulations — thresholds and channels can be changed without rewriting the bot.
What remains with you after handover to operation
Handover to operation is not an archive with source code, but a set of working documents by which your team itself changes rules, analyzes incidents, and connects new data sources.
Everything lives in the same repository as the code and goes through the same review before change — otherwise the documentation diverges from reality within a couple of weeks.
- Bot and monitoring configurations: connection parameters, list of tracked wallets and pools, request limits to external sources, retry modes when a node is unavailable.
- Alert rules: thresholds for position health, liquidation ratio, price deviation, and gas cost; it separately describes which events are suppressed so the on-call engineer is not flooded with duplicates and noise.
- Calculation scheme: how position health is calculated, where prices and rates come from, what happens when sources diverge, and at which step conservative valuation is enabled.
- Instructions for the on-call shift: step-by-step scenarios for typical events — node unavailability, data delay, critical threshold trigger, false alert.
- Response regulations: severity levels, time to acknowledge an event, escalation order, and message templates so the shift acts consistently regardless of its composition.
- Observability of the bot itself: availability checks, monitoring of notification delivery delay, and a trigger log with history that shows whether a signal occurred or was missed.
- Change procedure: how to add a new protocol or network, which checks to run before release, and where to look if calculations drift after a change.
Case study: position monitoring during sharp market moves
The client maintained liquid positions in several DeFi protocols and monitored them manually: an on-call engineer opened dashboards every 30–40 minutes and compared collateral ratios against thresholds.
During a sharp market move, this interval was not enough — between two sweeps the ratio broke the threshold, and positions closed before anyone could intervene.
The average reaction to a threshold event reached 40 minutes, and some events did not come into view at all: manual sweeping does not cover night hours and peak spikes.
What we built
The bot subscribes to protocol events and recalculates the ratio for each address on significant state changes. Thresholds are set separately for each position and work with hysteresis — fluctuations right at the boundary do not turn into a stream of false messages.
The on-call engineer receives a notification in Telegram with the address, current ratio, and buffer to the threshold; if the notification is not acknowledged, escalation goes to the next person on the shift.
Metrics before and after
- Threshold event coverage: about two thirds were tracked manually; automated monitoring records all of them.
- Reaction time: from ~40 minutes to 2–3 minutes from the moment of breach.
- Misses during night hours: this class of failures was eliminated completely.
- False triggers: decreased by about three times after configuring hysteresis and the buffer threshold.
- Forced closures due to late intervention: from isolated cases per month to zero.
How does threshold alerting differ from calculated control?
Threshold alerting is a rule over a single number: the price fell below a mark, the collateral share dropped, the rate rose. It can be configured in minutes, the load is predictable, and there is no need to read the entire position state. The limitation is that position risk almost never is expressed by a single number.
A position is made up of the collateral amount and its weight, the debt principal, and accrued interest, which grows unevenly under a floating rate. The same price level with different debt means a different proximity to liquidation.
The threshold either triggers too early and drowns in false messages that people stop reacting to, or stays silent until the buffer is already exhausted.
Calculated control recalculates the position: it pulls current data on collateral and debt, accounts for accrued interest and asset parameters, and reduces everything to a single metric — the risk buffer in percent.
The alert does not arrive at the moment the price crosses, but when this buffer falls below a set level, adjusted for reaction time. Recalculation runs both on events and on a schedule — a market jump does not outrun the notification.
Comparing the approaches comes down to the cost of error. A threshold is suitable for a simple position: one collateral, rare changes, predictable rate.
Calculation is needed when there are several collaterals, the rate is floating, and it is important not to state a fact but to react in time. In practice they are combined: thresholds act as a coarse filter, and recalculation confirms the event and refines the risk buffer.
Technical concerns before starting
Before starting, what is checked is not how the bot draws a chart, but how it behaves when DeFi position data is late or missing. We address four concerns that come up most often.
What is the delay between an on-chain event and the alert?
The bot subscribes to network events rather than sweeping wallets on a schedule: a notification about a price moving outside the boundary arrives 2-4 seconds after confirmation. Periodic polling remains a fallback and picks up what was missed if the subscription breaks.
What if the data has become outdated?
Every number has a timestamp and source, and the bot does not silently substitute the last known value.
If the price has not updated, a "data not current" note arrives with the time of the last update — you make a decision based on fact, not on the illusion of fresh data.
How are access rights separated?
Roles are described by a list: the owner sees all positions and thresholds, the analyst sees aggregated metrics without addresses, the observer sees only their own wallets. Rights are granted by identifier, revoked with a single command, and recorded in the log.
What happens during a communication failure?
Alerts are queued and sent with retries, and duplicates are merged — a single event does not turn into a dozen messages.
If the primary source is unavailable, the bot switches to the backup, and if both fail, an explicit "no data coming in" arrives, not silence that can easily be mistaken for a calm market.
Let's discuss your task: what to prepare
To come back with an estimate and plan for your Telegram bot for DeFi monitoring, rather than with averaged assumptions, it is enough for the first conversation to have what is already at hand.
Below are the inputs that remove half the clarifying rounds and allow us to name the polling architecture and work order right away.
- Current monitoring method: how you now learn about collateral drawdown — manually across several windows, via a table in chat, via someone's script on your own server, or not at all.
- Input data on positions: networks and protocols, collateral and debt types, which tokens, whether there is leverage and recursive borrowing mode.
- Threshold values: at what health factor a signal is needed, and which range is considered normal noise and should not wake the on-call engineer at night.
- On-call shift composition: who receives notifications, in which time zones, who has the right to act on a position, and who can only read the summary.
- Expected reaction speed: how long before liquidation the signal must arrive — this determines polling intervals and whether escalation from message to call exists.
- Delivery channels in Telegram: personal chat, shared group with topics, separate routes for critical and informational events.
- Access: wallet addresses for reading and view-only keys — transaction signing remains with you, and the bot does not receive rights to move funds.
Describe the task in free form and attach what you have: we will come back with an estimate and plan that names the stages, polling intervals, and acceptance procedure. If some data is not yet available, we will start with what exists and close the gaps during the review.