Hack Report: How Exploits Are Usually Discovered

Coverage of a protocol exploit typically begins several hours after the event and is wrong in specifics for the first day. The reason is structural.

The sequence

Anomalous on-chain activity. Automated monitoring detects an unusual transaction pattern: a large withdrawal from a contract, a price movement inside a pool, a function call that rarely executes.

Independent researchers notice. Several monitoring services and individual researchers watch the same data. The first public signal is typically a post from one of them, often within minutes.

The protocol responds. Pausing contracts if a pause function exists, contacting exchanges to flag the receiving addresses, and in some cases publishing an immediate statement.

Funds move. The attacker converts, bridges or mixes. This happens fast, and the window in which exchanges can freeze deposits is short.

Preliminary post-mortem. The protocol publishes an initial account, usually within 24 to 72 hours.

Full analysis. Security firms publish detailed transaction-level reconstructions, frequently correcting the preliminary account.

Why early reports are unreliable

The first figure quoted is usually the value of assets moved, which is not the same as losses. Some of it may be recoverable, some belongs to the protocol’s treasury rather than to users, and valuations of illiquid tokens at the moment of an exploit are unreliable.

Initial attributions of the cause are also frequently wrong. What looks like a smart contract bug sometimes turns out to be a compromised private key, and the two have very different implications for everyone else using similar software.

The categories that recur

Contract logic errors. A flaw in the code allowing withdrawal beyond entitlement.

Oracle manipulation. Moving the price feed a contract relies on, then transacting against the manipulated price.

Access control failures. A privileged function callable by anyone.

Key compromise. Not a contract flaw at all. The keys controlling an upgradeable contract or a bridge are stolen, frequently through targeted social engineering of a team member.

Bridge failures. A persistent category, because bridges hold large balances and combine several trust assumptions.

What a reader should take from an incident

Whether it affects something you hold. Most exploits are specific to one protocol.

Whether the mechanism is shared. An oracle manipulation against one lending protocol raises questions about others using the same feed. A key compromise raises questions about every protocol using a similar multi-signature setup.

Whether approvals you granted are implicated. If you have interacted with the affected protocol, revoking approvals is a reasonable precaution regardless of whether you held funds there.

The reporting standard worth applying

A useful incident report names the transaction hashes, states the mechanism, distinguishes user funds from protocol funds, and says what is not yet known.

Reports lacking those are describing an event rather than analysing one, and the figures in them should be treated as provisional for at least several days.