Monitoring DeFi positions: where accounting breaks
A stale registry shows a position as healthy, while in the protocol the collateral ratio has already crossed the threshold.
The reason is data desynchronization: the indexer lags several blocks behind, some loan events remain unparsed, and the price is taken from a single source and is not recalculated during a sharp market move.
The collateral state in the interface and in the contract diverges, and no one measures that divergence itself — it surfaces only when trying to close the position.
The cost of an error is not an inconvenient report but a missed liquidation risk.
While collateral accounting lives in a table updated on a schedule, the window between risk growth and reaction is measured in hours: during that time the position is forcibly closed at an unfavorable price, and then days are spent on manual transaction review.
Across several protocols the situation is worse — each has its own event formats, its own rules for recalculating accrued interest, and its own thresholds; consolidating them into a single summary without reconciliation is impossible.
That is why DeFi position monitoring is built around reconciliation, not around a single data source.
Collateral state is recalculated from raw events, independently re-read from the blockchain, and the divergence is surfaced as a separate signal indicating exactly which parameter drifted and by how much.
Then the notification arrives at the threshold, not when an external liquidator has already acted, and the team has time for partial repayment or adding collateral.
How this is handled in practice — from the event collection scheme to the threshold policy and the procedure for manual actions when triggered — we break down below.
What continuous collateral and yield control provides
Position collateral has a life of its own: the underlying asset price moves, borrowing rates change, and part of the collateral goes into staking with variable yield.
Continuous state polling — on a schedule and on events such as a sharp price move or a large transaction on the address — keeps the current buffer to liquidation up to date, and early warning arrives as the threshold is approached, not after it triggers.
Yield calculation is assembled from accrued interest, asset values in the base currency, and fees that the position pays or receives.
We consolidate this into a metric per position and for the entire portfolio: you can see how much each account earns and where the result is consumed by the cost of borrowed funds. The data is stored with history — any divergence can be broken down step by step, not from memory.
A unified account registry eliminates scattered wallets, networks, and tables: addresses, markets, position types, and notification rules reside in a single reference with versioning.
State collection comes from the Aave contract, you set the comparison thresholds, and the notification arrives in the agreed channel as human-readable text: what happened, how far the buffer is below the threshold, and which position is affected.
From a results standpoint, reaction time to an event is measured in minutes instead of hours, the share of caught risks grows, and the failure class of “found out after the fact” disappears along with manual checks.
Reducing liquidation risk here is not a promise but a consequence: thresholds are recalculated automatically, and rules trigger without human involvement.
Comparison of approaches to collecting data from protocols
Notification accuracy is determined not by the logic of the rules, but by how we obtain protocol state.
An error in collecting data from protocols manifests later and more expensively: the signal arrives after the position has been liquidated, or it duplicates on every connection drop. Below are working schemes with applicability conditions and method limitations.
| Option | When it fits | Limitations |
|---|---|---|
| Periodic network polling | positions change slowly: collateral, rates, low-activity pools; a full snapshot of state is needed | latency equals the polling interval; load grows linearly with the number of addresses and frequency |
| Event subscription | reaction is needed within a few blocks: liquidations, a sharp pool rate shift | requires its own indexing layer and reorganization handling; when the connection drops, some events are lost, and reconciliation with history is needed |
| Hybrid scheme | the primary mode for working with real positions: subscription for urgent triggers, polling as a confirming contour | two sources must be reconciled, divergences resolved, and duplicates suppressed |
| External data services | quick start and coverage of many networks without your own infrastructure | dependence on someone else's index and its limits, no access to raw logs, latency and completeness outside our control |
We validate the choice on historical data: we run snapshots and events from a past period, calculate the divergence share and the number of missed triggers for each position type.
If periodic network polling produces misses on volatile pools, we switch the confirming contour to subscription. The result is recorded in the stage report together with a source map for each protocol.
How system implementation proceeds: work stages
We implement in short iterations, and the first step is not development but an audit of data sources: where funds are deployed, which contracts service them, and with what latency rates arrive.
Until the list of sources and their limitations is fixed, position calculation diverges from reality.
- Data source audit. We inventory positions by protocol and network and record what each source provides: some data is read from contracts, some from events, and rates are taken from oracle channels Chainlink.
- Accounting scheme and storage. We determine how data from different protocols is normalized and how position value is calculated taking into account loans, collateral, and accrued interest; we store history so the calculation can be rechecked.
- Threshold setup. Trigger rules: price deviation, approaching liquidation, yield decline, source downtime. We set thresholds with hysteresis and urgency levels so the channel does not turn into a stream of noise.
- Validation on historical data. We run the rules on the archive: how many notifications would have been sent over the past period, what share would be false, and whether the notification would have arrived before the critical event. Based on the result, we calibrate thresholds.
- Delivery and access. We connect notification channels and delimit permissions: critical items go to the on-call engineer immediately, informational items go to the general digest.
- System handover. We provide configurations, data flow diagrams, the on-call policy, and instructions for adding new protocols, and train the customer's team.
- Review of first triggers. For the first weeks we support operation and review every notification: what triggered correctly, what needs tuning, and which sources should be added.
What we hand over: configurations, diagrams, policies
We hand over not an archive with source code but a working system with a description of how it is built and what to do when it goes silent.
Each artifact is tied to a specific action: from the diagram it is clear where to look for desynchronization; from the procedure, how many minutes it takes for the on-call engineer to come online; from the policy, who is authorized to change thresholds.
- Data flow diagrams: the path from price sources and protocol states to calculation of the position health factor, with failure points and behavior when rates diverge between sources.
- Integration map: list of external nodes, price aggregators, and delivery channels, polling frequency, request limits, and the procedure for switching to a backup source.
- Monitoring rule configurations: health factor and debt ratio thresholds, quiet windows, duplicate suppression, escalation ladder — as files in the repository, versioned together with code.
- Notification procedure: who receives the signal and where, how many seconds after the event, what is considered critical, and how false triggers are suppressed during sharp market moves.
- Access policies: roles and rights for changing thresholds, rotation of keys to nodes and channels, operator action log, and the procedure for actions if an access token is compromised.
- System documentation: calculation architecture, metric dictionary, deployment checklist, and recovery procedure from position state snapshots.
- On-call policy: rotation schedule, target response time, escalation points, and mandatory staging run before rolling out changes to integrations.
We conduct a post-mortem on each item during handover — with recording and review of two training triggers.
Case study: DeFi position control instead of manual spreadsheets
The customer manages liquidity in several lending pools.
Positions were tracked manually: the on-call engineer checked collateral, debt, and the current price once every few hours, so liquidation was approached only after the fact — when there was nothing left to defend the position with.
What it was like before implementation
Average risk detection time was about four hours, stretching to twelve on weekends. Checks were incomplete: some positions fell out of the table during shift changes, and each person configured the notification threshold their own way.
Incident review took almost a day — from chat logs and screenshots they reconstructed who saw what and at what moment.
What was changed and what the result was
We built a service that reads position state from public sources and reconciles it with price benchmarks from DefiLlama. Notification rules were described declaratively: position collateral threshold, price change speed, and separate conditions for night shifts.
The notification arrives in the on-call channel with a link to the position and its change history, so the engineer sees context rather than an abstract “triggered.”
- risk detection: from four hours to two minutes;
- false trigger rate: 40% → 6% — only real price fluctuations remained;
- incident review: a day → 20 minutes, with the full timeline already in the log;
- missed risks per quarter: three → zero.
Change and trigger history is now stored by the service, not by a person: spreadsheets are no longer the single source of truth about position state.
What to do if account data diverges from the chain
Data divergence between the accounting database and the chain almost never means “the network broke.” In most cases a processing segment is lost: an indexer restart, changed contract logic, or a reorg of a confirmed branch.
Therefore the first step is not to edit numbers in the database, but to find the point where the divergence originated.
Then the principle is the same: the source of truth is the chain, and local records are recoverable.
Rebuilding history gives a deterministic result only with an unchanged set of parsing rules, so first we verify contract logic against what is executing now, and only then run the pass again.
| Cause of divergence | How it manifests | Recovery plan |
|---|---|---|
| Missing segment after restart | The position “freezes,” although there was activity on-chain | Rebuild history by range, then re-reconcile |
| Changed contract logic | Some events are not recognized, amounts do not fully match | Verify contract logic, update parsing rules |
| Reorg of a confirmed branch | Backdated records become incorrect | Roll back affected records, re-reconcile |
| Different source processing order | Alerts arrive for the wrong positions | Unified processing order, re-reconcile on historical data |
The recovery plan is closed out by re-reconciliation over a historical window, not at the latest block — that way it is clear that the divergence is fully gone, not masked.
After that, data divergence is surfaced as a separate alert: the next break is caught at the moment it appears, not a week later.
Access policies, limits, and notification channels
We build access policies around service roles: the blockchain read node, indexer, position calculation engine, and notification sender receive separate credentials with the minimum required rights.
The calculation contour does not have the right to send signals directly, and the sender does not see the keys — compromise of one service does not expose the others. Every action is recorded in the event log, which is append-only: who requested what and when.
Notification limits protect against a stream of identical signals. Deduplication uses the key “protocol + position + event type,” and within the aggregation window repeats are collapsed into one message with a counter.
We set the trigger threshold as a share of position size rather than an absolute number — noise from minor fluctuations does not reach the channel. Notification channels are separated by criticality: instant for liquidation risk, scheduled digest for everything else.
What happens if a data source is unavailable?
The service publishes a liveness signal and marks the calculation as stale — the position is not closed based on the last known value. A separate message about source unavailability goes to the channel, and retries are performed with increasing intervals until recovery.
Can a service be granted read-only access?
Yes. Service roles are separated, credentials are limited to their own scope of work, and the event log shows who accessed data and when. Revoking access for one service does not affect the other contours.
Let's discuss your task and come back with a work plan
To come back with a work plan rather than generalities, we need at minimum from you: a list of networks and protocols where positions are open, the set of events for which a signal is needed — change in loan health, price leaving a corridor, approaching liquidation, data source failure — and notification delivery channels: email, messenger, call to your service.
On our side, we fix the stages before the first line of configuration: delivery scope, responsibility boundaries, and the points where your confirmation is needed.
- Task breakdown: we mark which positions and metrics are included in monitoring and which we intentionally leave outside the perimeter.
- Data collection scheme: sources, polling frequency, and behavior when a node or provider is unavailable.
- Trigger rules: thresholds, averaging windows, duplicate suppression, signal priorities.
- Delivery channels: routing by criticality, escalation to the on-call engineer, log of delivered and rejected notifications.
- Timeline estimate: a stage-by-stage plan with checkpoints where you see a working result, not a report about work performed.
- Delivery scope and post-implementation support: configurations, deployment diagram, instructions for the on-call shift, response to protocol contract changes, and threshold tuning based on actual false triggers.
Describe your task in free form — we will come back with a timeline estimate and a stage-by-stage work plan.