April 2026 was the worst month in crypto history for on-chain exploits. Not by a little.
Twenty-eight separate incidents. $629 million stolen. Drift Protocol ($285M on April 1) and Kelp DAO ($293M on April 18) together accounted for 90% of the damage. The rest was spread across Rhea Finance ($18M), Grinex ($14M), Wasabi Protocol ($4.5M), Volo Protocol ($3.5M), Hyperbridge ($2.5M), CoW Swap ($1.2M), and a tail of smaller incidents: Dango, Silo Finance, LML Staking, Aethir, Scallop Lending.
Every one of those drained wallets is now looking for somewhere to go.
What happens after the drain
The Drift Protocol attacker spent three weeks social engineering the protocol's Security Council. They pre-signed durable nonce transactions, deployed a fake token, manipulated the price, and drained the vaults in twelve minutes. The Kelp DAO attacker forged cross-chain messages on LayerZero's EndpointV2 to trick the bridge into releasing 116,500 rsETH.
Neither attacker is sitting on the funds. Stolen funds move fast. They hit bridges, swap through DEXes, land in lending markets to bootstrap collateral, move again.
Your protocol may be one of those stops.
If you run a DEX, lending market, liquidity pool, or bridge, you have already processed stolen funds from some earlier exploit without knowing it. That is not an accusation. It is the mechanics of permissionless finance. Funds do not announce their provenance. The swap looks like any other swap.
The gap in standard OFAC screening
Most protocols have built some version of Level 1 screening: check the connecting wallet against the OFAC SDN list, block if there is a match, log the check for your records. That is the right call. The Tornado Cash sanctions enforcement made it clear that running a protocol does not exempt you from OFAC obligations.
But OFAC screening does not catch the Drift Protocol attacker. Not on April 1, when the drain happened. OFAC designations publish asynchronously. Lazarus Group address clusters are tracked by TRM Labs, Chainalysis, and on-chain intelligence teams, but the specific wallets used in a fresh exploit appear on the SDN list days or weeks after the attack, if at all. The forty addresses drained in the Kelp DAO hack were not on the SDN list when they were first active.
OFAC screening is backward-looking. It matches against known designations. A fresh exploit address has no OFAC history.
Level 2 screening is different. It tracks addresses associated with known exploits, drains, and stolen fund clusters in real time, independent of whether OFAC has issued a designation. When a wallet address is flagged in the on-chain incident response community as exploit-linked, that tag is available immediately. Not in sixty days when the designation drops.
Why this matters for your posture
Your legal exposure as a protocol founder runs in two directions.
The first is regulatory: operating infrastructure that processes sanctioned funds is an OFAC violation. That is what Level 1 addresses. OFAC enforcement against Tornado Cash and the subsequent frontend actions by Uniswap and others established that "permissionless" is not a defense.
The second is reputational and operational: becoming the primary laundering route for a major exploit is a problem that does not wait for a regulatory action. Your fiat on-ramp partner notices. Your frontend host notices. Your Tier 1 exchange listing review notices. The bridge that processed $50M of the Kelp DAO funds drew attention within hours. Not from regulators. From the protocols and custodians downstream.
The Wall Street Journal is not sympathetic to the distinction between "we didn't know" and "we had no controls."
The mechanics of Level 2 screening
Level 1: check an address against a static sanctions list. Binary match.
Level 2: check an address against a continuously updated intelligence layer that tags addresses by their relationship to known exploits, drains, bridge hops from drained contracts, and cluster proximity to attacker-controlled wallets.
The intelligence comes from multiple sources. On-chain trace data from exploit incident reports. Community tracking from security researchers. Cross-chain attribution that connects a Solana drain to subsequent Ethereum bridge activity. Cluster analysis that identifies wallets under the same operational control as a known attacker address.
The output is not a binary match. It is a risk label with a confidence score and a provenance trail: "this address received funds from the Kelp DAO attacker wallet 0x... in transaction 0x... on April 19, with chain of custody traceable to the original LayerZero exploit." That label is what you need if your frontend blocks the address and the user disputes it.
The SR³ Intelligence Layer ships that label at screening time. The risk level, entity attribution, confidence score, and evidence chain arrive in the same API response. The protocol sees what the label is based on, not just the conclusion.
What this looks like at the integration layer
The integration surface is narrow. One endpoint handles the common case: screen a wallet address before a transaction executes, get a risk level and label back. If the risk level is above your threshold, block the transaction at the frontend. Log the response.
Latency on addresses runs under 10ms. Batch lookup is about 100ms even for large batches. That fits in the UX budget before a swap executes. You are not adding user-visible delay.
API keys are self-serve. The docs cover the integration pattern, the full response schema, and the error surface. TypeScript and Python SDKs wrap the endpoint if you prefer that over raw REST. An engineer who has wired in an external API before can complete the core integration in an afternoon. The free tier covers prototyping volume. Usage-based pricing kicks in above that, no enterprise minimum.
This is the cost of composability. Protocols compose at chain speed. Exploits compose at chain speed. Stolen funds route through a bridge, land in a lending market, and collateralize a position in the same block cycle that drained the original vault. The risk layer has to keep pace with the chains, not with a 24-hour batch job.
The update cadence matters more than most protocols realize. An address that is clean at noon on April 1 may be exploit-linked by 2pm the same day. The intelligence layer needs to update in near-real-time as incident reports surface, not on a daily batch cycle.
CipherOwl runs 24x7 incident monitoring. When a new exploit surfaces (on-chain evidence, security researcher disclosure, post-mortem report), the team reviews, confirms, and pushes the new attacker address cluster to the label database. Every SR³ customer gets that update at the same time, automatically. You do not need to watch the exploit feeds yourself. You do not need an internal security analyst whose job is to track incident reports and manually update a blocklist. The confirmed incidents flow in, your screening layer picks them up, and your protocol blocks the flagged addresses before the next swap routes through.
For protocols with stricter data requirements, SR³ supports on-premises deployment. The label database, scoring engine, and API run inside your own infrastructure. No address data leaves your network. The 24x7 monitoring and incident updates push to your local instance the same way they push to the hosted version. Banks and regulated custodians use this path for data sovereignty. Protocols building on compliant infrastructure or operating in jurisdictions with data residency requirements use it for the same reason.
The posture this gives you
You are not a bank. You cannot run KYC on every user. You cannot stop permissionless transactions at the contract layer without fundamental changes to how the protocol works. Any vendor that tells you otherwise is selling you something that does not exist.
What you can do is screen at the frontend, document that you did it, and maintain a defensible record of the addresses you blocked and why. That is the posture your GC needs, your host needs, and your on-ramp partner needs.
"We screen connecting wallets against OFAC SDN in real time. We also screen against a second-layer intelligence feed that flags addresses linked to recent exploits and drains. We block wallets above our risk threshold. Here is the API provider. Here is the latency. Here is a sample blocked address with the evidence trail." That is a story you can tell.
The alternative is no story. And in April 2026, when the industry lost $629M in thirty days, "no story" is the one outcome you cannot afford.
April's pattern is structural, not cyclical
The attacks in April were not an anomaly. They reflected a shift in attack methodology that has been building for two years. Smart contract bugs used to dominate. In April 2026, the two biggest losses were social engineering attacks on humans with admin keys. The Drift attacker ran a three-week access campaign. The Kelp attacker forged cross-chain messages at the messaging layer.
That shift means exploit-linked addresses will keep appearing. The question is not whether stolen funds will try to flow through your protocol. They will. The question is whether you have a layer of screening that catches them before they do.
The protocols that shipped this in 2025 had a defensible answer in April. The ones that hadn't were scrambling to explain why they processed seventeen transactions from a known exploit cluster before anyone noticed.
0x, Privacy Cash, and major exchange DEX infrastructure are among the protocols running SR³ second-level screening today. They are not doing it because a regulator told them to. They are doing it because their legal counsel, their hosting partners, and their institutional counterparties asked them to demonstrate a controls story. That conversation is happening earlier in every listing review, every on-ramp partner discussion, and every investor diligence call.
Screening is not a guarantee. A fresh wallet with no history is genuinely ambiguous. A sophisticated attacker uses intermediary wallets to create distance. Level 2 screening is not a wall. It is a filter. What it catches is the bulk of the flow, the addresses that are already tagged in the intelligence layer, that any careful operator would have blocked.
That filter is the difference between being an unwitting stop on a laundering route and being a protocol that did the reasonable thing.
SR³ offers a developer-first screening API with exploit-linked address intelligence, sub-10ms single-address latency, ~100ms for large batches, and transparent attribution on every result. Self-serve API key, free tier to prototype, usage-based above that. No enterprise contract, no sales call.