Runtime monitoring

Many DeFi exploits are not a single transaction. An attacker deploys a contract, tests it, borrows funds, moves prices and only then drains the target, sometimes over minutes or hours. Each step leaves a trace on a public blockchain. Runtime monitoring is the practice of reading those traces fast enough to act on them.

How it works

Monitoring systems watch the blockchain, and often the queue of transactions waiting to be included, for patterns linked to attacks. Typical signals include:

• a newly deployed contract that calls a protocol's functions in an unusual order
• a large flash loan followed by trades that move an oracle price
• sudden changes in a vault's share price or in a pool's balances
• administrative actions, such as an ownership transfer or an upgrade, that nobody announced
• funds moving to addresses linked to earlier exploits

Detection usually runs in two stages. A fast filter scores each new transaction or contract against known attack patterns, and the suspicious ones are simulated against the current state of the chain to see what they would actually do: which balances change, which prices move and where funds end up. Simulation is what lets a system tell a large but ordinary trade from the opening move of an exploit.

When a signal fires, the system alerts the team. In some setups it can also trigger automated responses: pausing a contract, blocking a function or moving funds out of reach before an attack completes.

A simple example

An attacker deploys a contract that borrows a large sum through a flash loan, swaps it through a thin liquidity pool to distort a price, and prepares to borrow against that price. The monitoring system simulates the new contract, recognises the pattern and flags it as high risk before the real transaction lands. The protocol's guardian pauses borrowing, the attack fails and the team investigates. Without monitoring, the first sign might have been an empty vault.

Monitoring vs. audits and bounties

A smart contract audit examines code before or soon after deployment, and a bug bounty invites researchers to keep examining it. Runtime monitoring watches behaviour instead. It can catch attacks that use code nobody thought to review, such as an interaction with a newly launched protocol, and it covers operational events, such as suspicious administrative activity, that a code review never sees.

Risks and limits

Monitoring cannot stop what it cannot see in time. Some attacks complete in one transaction, leaving only the short window before it is included in a block, and private transaction routes can hide even that. Automated responses need careful design: a pause that triggers too easily disrupts honest users, and one that triggers too slowly is useless. The power to pause is itself a risk if the keys behind it are poorly protected. And a monitoring system is only as good as its models, so a new kind of attack may match no known pattern. That is why monitoring works alongside audits, bounties and proof of reserves, not instead of them.

Tori Finance uses runtime monitoring by Hypernative to watch the onchain activity of its smart contracts. It adds a live layer to the smart contract audits by Sherlock and Nethermind. Tori also runs its own internal bug bounty program.