DeFi monitoring: where a protocol loses funds in seconds
Control over a pool is not lost gradually, but within a single transaction: liquidity is withdrawn, the oracle price shifts, and by the close of the block there is nothing left to roll back.
Observability with a delay of minutes means not "we'll find out a bit later," but a guaranteed missed reaction window.
Most transaction anomalies look harmless individually: an unusual sequence of calls, a recipient address appearing in the contract for the first time, an operation size twice the historical maximum for that wallet.
Individually this is noise; together they form the profile of a smart contract exploit being prepared, which single-threshold rules do not catch.
A smart contract exploit rarely means an error in the code.
More often, an allowed function is called in the wrong order and against a pre-prepared pool state — hence the failure class: loss of liquidity in one block, with no rollback and no time to react, because the transaction is irreversible by definition.
That is why real-time detection is built not on lists of suspicious addresses, but on deviation from a behavioral profile: a baseline of volumes, typical call chains, and the rate of change of reserves.
The signal must appear before block confirmation — otherwise DeFi monitoring records not the attack, but its consequences.
What continuous transaction and liquidity control provides
Continuous transaction control is not a scheduled log export, but stream processing of every call to pool contracts. The engineer sees who initiated the operation, how reserves and the oracle rate changed, and whether the address's behavior fits the profile of a normal user.
Deviation from the profile is recorded at the moment of the operation, not the next day in a report.
Reaction speed is determined by the detection point. If an anomaly is searched for based on block results, liquidity has already been withdrawn; if at the moment a transaction appears, only seconds pass between signal and intervention.
Automated policies operate in that interval: pausing a specific function, a withdrawal limit, escalation to an engineer.
This closes an entire class of failures that static checks do not catch: a series of small swaps draining a pool, or a one-time oracle price manipulation. An example is Uniswap pools, where an apparently correct transaction drains the reserve in a single call. A rule for such behavior triggers before a person manages to open the monitoring panel.
For liquidity protection, not only reaction but also protocol observability matters: the share of intercepted anomalies, the time from signal to pause, and pool behavior under sharp movements.
These metrics are visible continuously, so the decision to halt is made based on data, not intuition.
DeFi monitoring modes: comparison and limitations
DeFi monitoring modes differ not by tools, but by decision-making logic: what counts as a deviation and when to raise an alert. Threshold rules trigger at specified boundaries — sharp liquidity outflow, a spike of transactions to the contract, a shift in the reserve ratio.
Anomaly models build a profile of normal pool activity and flag what falls outside it, even if formally no threshold has been crossed.
A hybrid scheme maintains both contours: rules provide instant reaction and a clear reason for triggering, while the model covers scenarios for which a rule was not written in advance.
| Mode | When it fits | Limitations |
|---|---|---|
| Threshold rules | Predictable pool, need reaction in seconds and unambiguous incident analysis | Does not see slow multi-step attacks; the threshold has to be revised as volume grows |
| Anomaly models | Young pools where statistics are not yet stable | Many false positives at the start; requires labeling of confirmed incidents |
| Hybrid scheme | A protocol with real assets and an on-call shift | More complex to maintain: the contours must be aligned by priorities and thresholds |
What determines the choice
The key metric is the ratio of confirmed triggers to false ones. A shift that handles dozens of empty alerts overnight stops reacting to a real one, so the mode is selected for the protocol's profile, not by the principle "the more complex, the better."
How we deploy exploit detection: stages of work
Work proceeds from inventory to handover to the on-call shift, and almost all the time goes not into code, but into clarifying which events count as anomalies for a specific protocol.
At the input, contract addresses, access to a node or event provider, and a test environment where hypotheses can be reproduced safely are needed. Below are the stages of implementing DeFi protocol monitoring.
- We assemble an inventory: contract and proxy addresses, a list of pools, administrator roles. Without this, rules trigger where funds do not actually move.
- Audit of contracts and their environment — we read privileged functions, external calls, dependence on oracles. We look for paths where a single call changes the protocol state entirely.
- Risk map: we rank event classes by priority — liquidity withdrawal, sharp parameter changes, anomalous series of operations. Priority determines what is monitored in real time and what goes into the daily summary.
- Rule configuration — thresholds, aggregation windows, binding to addresses and roles. Noise suppression matters more here: a rule that triggers hundreds of times a day devalues the on-call process.
- Testing on historical data: we run rules against past network events and compare them with known incidents. We calculate the share of misses and false positives, and adjust thresholds.
- Handover to the on-call shift: configurations, flow diagrams, instructions on "what to do when triggered" — up to pausing functions and withdrawing funds.
- Support: we review rules when contracts are updated, the environment changes, or new pools appear.
What we hand over: rules, diagrams, and procedures
Monitoring stops being a black box only when, along with a working service, you receive artifacts that let you operate and develop it without us. Here is what is fixed in the settings and documentation by the time of handover:
- Detection rule set — the logic by which an event is considered an anomaly: withdrawal of funds from a pool, a sharp divergence from the oracle, a call to the contract's administrative functions. With thresholds, a list of ignored situations, and the procedure for fine-tuning without editing code.
- Data flow diagram — the path from the network node and indexer to the alert: where data is normalized, where it is stored, what failure points exist, and how each degradation looks on the dashboard.
- Access matrix — roles in the system, who has access to keys and administrative actions, how access is revoked when an employee changes, and who has the right to halt the contract.
- Response procedure — severity levels, target reaction time for each, escalation order, and the single-voice rule when deciding on a pause.
- System documentation — deployment from scratch, adding a new rule, rolling back an unsuccessful update, a list of checks after a failure.
- On-call procedure — schedule, who receives the night signal, shift handover, incident log, and analysis of false positives.
- Solution handover — repositories and infrastructure on your accounts, team training, a period of joint on-call duty, and acceptance criteria.
Such a package allows you to run the system on your own, and to engage us selectively — for new attack types and rule revisions.
Case: a night attack on a pool and halting fund withdrawal
Before monitoring was implemented, the pool was controlled by threshold alerts based on transaction size and a manual review once a day.
A night attack on an Aave pool proceeded as a series of small calls: each transaction looked normal on its own, the thresholds stayed silent, and by morning part of the liquidity was already gone, with the analysis done from logs after the fact.
The system our engineers configured builds a profile of typical contract behavior and monitors deviations in the call structure: an unfamiliar address, a spike in the frequency of calls to the pool, a growing share of withdrawals in a short window, a divergence from the usual collateral-to-loan ratio.
The signal is formed from a combination of features, not a single threshold, so the trigger arrived in the second minute of the series — before the pool was drained.
Trigger handling is automated as well: the scenario pauses withdrawals for the pool, pings the on-call engineer, and collects a chronology of calls for analysis. The attack was stopped at night, without manual confirmation of each step.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Detection time | morning review, hours | seconds from the start of the series |
| Trigger handling | manual confirmation after analysis | automatic pause of pool withdrawals |
| Incident materials | manual log export | ready chronology of calls and trigger conditions |
How does streaming control differ from a one-time audit?
A one-time audit is a snapshot of a contract at a specific moment: the auditor examines logic, access rights, arithmetic, and external calls; the report records the vulnerability classes found.
The strength of the approach is depth — the snapshot reveals what observation does not catch, for example an error in the economic model.
The weakness is its tie to time: after an update through a proxy or a change of administrator roles, the report describes a contract that is no longer the one running on the network.
Streaming control is structured differently: it does not read code, but monitors behavior — events, changes in pool balances, collateral shares, spikes in withdrawals, loans with a sale in a single transaction.
Forta and similar observation networks show how rules with thresholds of deviation from a baseline are built from a stream of events. Triggering takes seconds — enough to pause the contract before the attack completes.
Comparison of approaches: an audit answers the question "is there an error in the logic," while streaming control answers "is something atypical happening right now." The first provides depth at a single snapshot, the second provides coverage over time and across the number of addresses under observation.
Residual risk remains in both cases. An audit does not cover price manipulation and the protocol's reaction to a market crash; observation does not cover slow withdrawal of funds through legitimate functions.
Therefore, the approaches are combined: a check before launch, repeated checks after every update, and constant streaming control. Then the window between the appearance of a vulnerability and reaction is measured in minutes.
Common technical doubts before launching control
Live control over a protocol raises a predictable set of questions for engineering teams: will you get access to our funds, will we drown in signals, what to do with what is already deployed on the network. Below are short answers to the ones asked most often.
Do you need access to private keys and the treasury address?
No. Observation is based on public data: contract state, events, the pending transaction queue. Signing and withdrawal of funds remain with your team — we see only what is already open on the network.
How do you suppress false positives?
A rule triggers not on a single event, but on a combination of features: an anomalous withdrawal, a change of owner, a sharp rise in borrowing within a short window. We calibrate the threshold on your history, so the stream of signals is compressed to units per day, not hundreds.
What should be done with contracts that are already deployed and immutable?
Control is built on top of external observation and does not require changes to the deployed code. For new versions where an update is available, we additionally add checks at the build and deployment stage.
What will the load on our nodes be?
Within normal network reads: state and event queries from several independent sources. Maintaining your own node is not mandatory, but if needed we connect it as well — with a backup access channel.
How are rules updated if the protocol changes?
Changes in contracts and tokenomics are tracked, after which the rules are edited and run against historical data before being enabled in the production contour. The update takes days, not weeks.
Let's discuss the task and come back with an estimate and plan
So that the estimate is based on facts rather than assumptions, for the first conversation it is enough to attach what already exists: contract and network addresses, a diagram of fund movement between pools, administrator roles and rights, log exports, and current alert rules.
If some data is closed, we will work through that too: often the bottleneck is not the detection rules themselves, but that the signal arrives later than the transaction enters the block.
In discussing the task, we resolve the main forks:
- which calls and events we cover with detection rules, and which we deliberately leave outside control;
- where the boundary lies between an anomaly and a false positive at current thresholds;
- how to connect the signal to action — pausing the contract, withdrawing liquidity, or paging the on-call engineer;
- what data is needed to analyze an incident: a transaction history archive, pool state at the moment of triggering;
- who on the customer side makes the decision and through which channels alerts are sent;
- how we test the system before project start: scenarios on a test copy of the network with an attack simulation.
Then we return with a work plan: the scope of work by stages, a timeline estimate with a buffer for integration, the points where your team's involvement is needed, and the procedure for rolling rules into production.
Describe the task and send the available materials — we will come back with an estimate and plan, and we will start the project with an agreed scope and priorities.