The Exploit Is the Disclosure: Why On-Chain Hacks Spread Faster Than Patches

Web2 already solved this

Most on-chain attacks are small enough that nobody notices. A few thousand dollars drained out of some forgotten contract, no headline, no post-mortem, nobody posting about it. The market shrugs and moves on.

But the bug behind that quiet little theft doesn't stay contained. The same mistake is usually sitting, unpatched, in other contracts, and sooner or later one of them is holding real money. The small hack nobody noticed is the blueprint for the big one everybody will.

Almost every site you use sits behind something like Cloudflare, filtering attacks around the clock, and most people never even notice it is there. Web2 has dealt with this for twenty years. When a new attack shows up, you don't just patch the box that got hit. You write a signature, push it out, and sweep your whole fleet for the same hole. The tooling for this is mature and kind of boring: threat-intel feeds and fleet-wide variant scanning. It works for one reason. Attacks repeat.

Web3 skipped that step. Most protocols get a single audit at launch and then run untouched for years, in public, while their code gets copied a hundred times over. When one of them finally gets hit, everyone running similar code finds out the hard way.

We think that's fixable, and it doesn't take anything web2 hasn't already invented. The kinds of security tools that became standard there haven't been built for web3 yet, so that's what we're doing. Glider is one of them: think CodeQL, but for Solidity. It turns deployed contract code into something you can query for a specific bug. Glider Monitor is the other, and it's what this post is about. It's a firewall for on-chain protocols. It watches live attacks and turns each one into a detector, on its own, in near real time.

Why web3 needs it more

On-chain, almost everything favors the attacker.

The code is public, so anyone can read exactly how a protocol works. After a hack, the competent attackers are already scanning the rest of the ecosystem for the same slip. The code is also immutable, so there usually is no hot-patch; the vulnerable logic sits there, live, until the money leaves. And there's no dwell time to speak of. A web2 bug is a foothold you develop over weeks. A DeFi bug is a flash loan and one block.

That flips the whole disclosure model. In web2, going public with a bug kicks off a race to patch it. In web3 the "disclosure" is the exploit transaction itself, and it kicks off a race to copy it, usually before the defender even notices.

Every hack is a template

The whole system rests on one assumption: a public exploit is a free, working proof-of-concept.

Someone already did the expensive part. They found the bug and proved it works, on-chain, with real money. Our job is to read what they did, work out why it worked, and then go find everywhere else it will work too. So instead of writing a hack up after the fact, we turn it into a query and run it.

How it works

Here is the loop, from the second a hack lands.

The signal is instant. Glider Monitor sits on a live feed of on-chain activity, so the trigger is the exploit transaction itself, the moment it confirms, well before any disclosure or write-up.

Then an agent takes it apart. We hand it the raw on-chain evidence: the full call trace, the storage and balance changes, the token flows, and the surrounding call context. From that it works out what broke, down to the specific invariant that failed. That reconstruction becomes a Glider query that pins down the exact shape of the bug.

In a typical run, within ten to fifteen minutes that query has already executed against your own contracts and told you the result either way. If something matches, you get an alert that names the function and explains why it's exploitable. If nothing matches, you still hear back: you're clear. Either way you get a verdict on what it checked.

By roughly the half-hour mark, the same query has swept the rest of the chain: about two million recent contracts across Ethereum and BSC, meaning the ones deployed or called at least once in the last month or so. Out of that comes a ranked list of everyone else carrying the bug.

The hard part is precision. A naive search for "code that resembles the hack" buries you in false alarms, and a tool that fires on everything gets muted inside a week. So most of the real work happens in what we throw away. We drop candidates that share the shape but not the exploitable path, and we keep the bar for your feed deliberately high. We would rather say nothing than send you chasing a bug that was never there.

What we found in a couple of weeks

We ran it for a couple of weeks. Twelve live incidents went in. 198 confirmed-vulnerable deployments came out: real contracts, live on Ethereum and BSC, each one carrying a bug we had already watched get exploited somewhere else. They span 80 distinct codebases and nine bug classes, so on average each vulnerable pattern was live in two or three places at once.

One word about "confirmed," because it's doing a lot of work. Every one of these means the system read the contract's own code and traced the path end to end: the entry point, the attacker-controlled input, the sink that moves value, and the guard that should have stopped it and wasn't there. The maybes don't make this number.

Class	How it drains	What makes it exploitable	Confirmed
Burn-from-pair + sync()	one-sided burn of the pair's own balance, then sync() forces the reserves to the post-burn balance and moves the spot price for a sandwiched buy/sell	the burn trigger is permissionless	116
Fee-on-transfer, recipient-debit	a transfer tax debited from the recipient or the pair itself, so a sell into the pair removes more than was deposited and collapses the reserve	the tax path is permissionless and hits the pair, not the sender	51
Unauthenticated swap/flash callback	a swap or flash callback moves value to whoever calls it, with no check that the caller is a real pool, so anyone drains the contract's balance	the caller is trusted implicitly, or a caller check the attacker satisfies with a contract they deploy	14
Spot-price oracle (leverage)	open a leveraged position priced off a raw DEX spot, then self-crash the spot and settle at the manipulated price	no TWAP or external oracle; position value read straight from the manipulable spot	6
Spot-price oracle (reward/mint)	flash-inflate a live reserve read, mint or credit out of thin air, dump	spot read with no TWAP or deviation guard	5
Phantom access control	an authorization check is declared but never enforced on the path, so a fund-mover (or a rollup's withdrawal path) is open to anyone	the allow-list or provider check is written but never read before value moves	3
Single-sided join/exit non-conservation	single-sided join and exit priced by a linear approximation, so a round trip returns more than it put in	no weight exponent or proper invariant; mint and redeem prices do not match	1
Unprotected initializer	seize ownership through an unguarded initializer, then use the owner-only withdraw	a value sink sits behind the role you just took	1
Gas-rebate overpayment	a keeper pays (gas + buffer) × gasprice to the caller with no cap; loop until the reserve empties	the reward exceeds the caller's real cost	1

If you ship contracts, this is about you

You don't have to have forked a hacked contract to be exposed. You only have to make the same mistake, and there are plenty of ways to get there: a copy-paste, an "inspired-by" rewrite, or two teams writing the same bug independently. The vulnerable shape doesn't care which.

So when a protocol you've never heard of gets drained, "was that my code?" is the wrong question. The real one is "does my code do the same thing?" If it does, it's live and exposed right now, and the people who just cashed out already know the pattern. Every public hack should quietly kick off a check on everyone running the same shape, before the copiers get there.

What we're not telling you

A few caveats, because a security post without them is just marketing.

We're not naming targets, and we're not putting numbers on what's at risk. Everything here is aggregate, counts and classes, on purpose. Naming a live, still-vulnerable contract, or publishing how much sits inside it, is just handing attackers a shopping list. The seed incidents were already public the moment they happened; the ones still holding funds stay off the page.

These are early numbers: twelve incidents, a couple of weeks, one slice of the chains we watch.

And the thing we lose sleep over: not wasting your attention. So we bias hard the other way. A finding has to survive real scrutiny before it ever reaches your feed, and we'll drop a borderline case rather than gamble your attention on it.

Security grows up

We think web3 is moving the same way web2 did: toward continuous defense instead of a one-shot audit at launch. The balances are bigger and the code is copied more than ever, and a once-a-year check was never going to keep up.

That's what we build at Hexens. Glider Monitor is that idea as a firewall, and this post was a couple of weeks of it running.

If you also want your contracts to be protected, connect with us here.