TL;DR

Most big exploits leave a trail on-chain minutes before the worst damage: strange flow patterns, abnormal function calls and outsized transfers.
You do not need full-blown data science to get value: a few simple dashboards and alerts can dramatically shorten reaction time.
Focus on three things first: how funds move, which functions are being called, and where value is leaving your contracts.
These signals do not replace audits, but they give founders a fighting chance to pause, respond, and contain damage in real time.

1. Unusual flows: when money starts moving in new ways

Almost every serious Web3 incident has a moment where the flow of funds stops looking like normal user behaviour and starts looking like a script.

That might be a single address calling your contracts hundreds of times in a short window, cycling assets between pools, or routing value in a way your team has never seen before. In events like the Ronin bridge hack or Mango Markets exploit, on-chain forensics show heavy activity concentrated in a handful of addresses and paths shortly before or during the drain, not a broad pattern of everyday usage. In 2022 alone, Chainalysis estimated that DeFi protocols lost over three billion dollars to hacks, with many incidents driven by some privileged or attacker-controlled accounts moving huge volumes rapidly.

From a founder’s perspective, you do not need to reconstruct full attack graphs to get value. Start with a few practical views:

a list of top addresses by volume over a short time window
a view of new addresses interacting with your protocol for the first time, sorted by impact
basic anomaly alerts when one address suddenly accounts for an unusually large share of activity

If you normally see a long tail of moderate activity and, suddenly, one address dominates volume with complex multi-step interactions, that is a strong “look closer” signal even before you know the full story.

This doesn’t mean every whale is an attacker. It does mean that watching flow concentration helps you distinguish “busy day” from “someone is aggressively exploring your edges.” That is precisely the kind of pattern you want an on-call person to see fast, not three days later in a postmortem.

2. Function mix changes when your contracts are used in “weird” ways.

Most protocols have a fairly stable mix of function calls in normal operation. Deposits, withdrawals, swaps, small parameter changes, the occasional admin operation. Even when volume goes up, the relative distribution of calls tends to stay within a predictable band.

During many exploits, that mix changes sharply. Attackers hammer a particular function that was rarely used before, chain an unusual sequence of calls, or repeatedly hit an “advanced” code path that only exists for edge cases. In the Euler Finance attack, for example, the exploit chain leaned heavily on specific hooks and donation mechanics that normal users rarely touched; in various oracle-manipulation attacks, you see a sudden burst of borrow/repay and collateral-tweaking operations in very tight loops, not the slower, messier mix of retail usage.

Founders do not need to read raw traces to benefit from this. A simple dashboard that shows:

which functions are called the most in the last N blocks or N minutes
how that distribution compares to a recent baseline
whether rarely-used functions have suddenly become hot

Is already powerful. If a function that normally represents one percent of your calls suddenly jumps to forty percent, you want someone asking why.

The practical move is to tag sensitive functions internally: anything that affects collateral calculations, reserve donations, emergency controls, unusual mint/burn paths, or low-level configuration. When any of those climb sharply in relative usage, it is worth a human investigation even if everything is still technically “working.” Many attacks run for minutes, not milliseconds. Spotting a weird function mix early is an opportunity to pause markets, tighten parameters or at least get eyes on the right parts of the system before it is too late.

3. Large and clustered transfers: watching the exits

The most obvious signal is still one of the most useful: large value leaving your contracts in ways that do not match your usual behaviour.

Bridge hacks and lending protocol drains consistently show this pattern. Ronin lost the equivalent of hundreds of millions of dollars in a small number of outsized withdrawals. Wormhole, Poly Network, and others all ended up with a handful of transactions that moved more value in minutes than the protocol normally moved in days. Industry overviews of DeFi hacks call out these “mega-transfers” as a common feature: once the exploit path is ready, attackers maximize value extraction in as few steps as possible before anyone can react.

Monitoring for this does not require complex models. At minimum, you want:

alerts on single transfers above some dynamic threshold (for example, a multiple of your average recent withdrawal size)
Alerts on many large transfers packed into a short period, even if each one individually is below the threshold
a clear, human-readable view of which contracts and destinations are involved in those transfers

This is where operational readiness matters as much as any technical alert. If your system flags an abnormal outflow and nobody is on-call, or there is no clear procedure for hitting pause, the information does not help. The point of watching exits is not just to know that money is leaving. It is to give the team a chance to stop the bleeding, contact partners such as exchanges or bridges, and start an incident response process while some options are still on the table.

How Exploitless fits into this picture

Exploitless focuses on one thing only: audits for smart contracts and Web3 protocols. A good audit cannot replace monitoring and incident response, but it can make those jobs dramatically easier by surfacing risky code paths and integration points before they are abused.

When we audit a system, we do not just mark vulnerabilities and move on. We highlight which functions and flows are most likely to matter during an incident: where collateral is computed, where external data is consumed, where large transfers are initiated, and where complex internal hooks live. Teams often turn those findings directly into monitoring priorities and alert conditions.

If you are running a protocol and want your next audit to help you ship safer code and understand what “weird” looks like on-chain for your specific design, that is precisely the type of work we do at Exploitless. A few well-chosen signals and a clear view of your critical flows will not stop every incident, but they give you a far better chance of reacting in time when something starts to go wrong.

Learn more at Exploitless

Three On-Chain Signals That Something Is Going Wrong Right Now