Across Protocol's Domain Hijack Proves DeFi's Cheapest Exploit Is a Login

The most valuable thing a DeFi attacker can steal isn't a private key. It's a domain registrar login.

Across Protocol, the intent-based cross-chain bridge, spent this week on cleanup duty, and none of it touched a smart contract. A social engineering attack aimed at Namecheap, the registrar holding the project's domain, let someone talk their way in and repoint the bridge's front end at a phishing page. Across says the site is restored.

No exploit. No drained pool. Just a convincing conversation with a support desk.

That's the whole story. And it's the shape of a huge chunk of crypto's losses over the last three years.

Visualize this: a bar chart of incident types ranked by dollars lost. Smart contract bugs own the tall bars. Domain and DNS takeovers sit in the small ones. Now run the same chart ranked by attacker effort. The distribution inverts. Breaking a curve is a research program. Convincing a registrar's rep that you're the marketing lead is a Tuesday afternoon.

The Evidence Pile

Start with Curve, August 2022. Someone got into the curve.fi DNS and pointed it at a fake approval page. Roughly $570,000 gone in a few hours before the team caught it. One domain. No code touched.

Then Uniswap, July 2022. An attacker slipped a malicious approval into the front end through a third-party analytics dependency. Same lesson, different door.

August 2024 was the heatmap moment. A migration bug at Squarespace, which had absorbed Google Domains, let attackers take over the DNS of several DeFi projects in a matter of days. Compound. Celer. A handful of others. That wasn't even social engineering. It was a botched handoff, and it produced the same outcome.

Numbers in context: Scam Sniffer tracked roughly $494 million drained through wallet drainers in 2024 across about 332,000 victims. Chainalysis put total stolen crypto near $2.2 billion for the year. The overwhelming majority of those approvals happened on a website somebody trusted. If even a low single-digit share of that flow passed through a hijacked front end, you're looking at nine figures of damage from a vector that gets maybe one line in a security budget.

Across itself is a good case study in the asymmetry. The bridge runs on intents, with relayers competing to fill user orders, and its contracts lean on UMA's optimistic oracle for settlement. That architecture has moved billions in lifetime volume and it didn't move a dollar this week. The contracts worked. They just don't cover the part where a stranger tells a registrar he owns the place.

So who wins here? Registrars, oddly. They sit on the single point of failure for every protocol's brand and carry almost none of the downside. Who loses? Users, who can't tell a real approval screen from a fake one when the URL bar says the right thing. That's the part nobody's fixed.

The Steelman

Here's the case against my own framing, and it's not weak.

Domain hijacks are loud. A phishing page needs live traffic to convert, and live traffic evaporates the moment the team posts a warning. The window is measured in hours, sometimes minutes. Compare that to a bridge exploit, where the loss is permanent and the attacker walks away with the whole pool. On a risk-adjusted basis, the expected value of a DNS attack is small.

Registrars also aren't standing still. Registry locks exist. DNSSEC exists. Hardware-key 2FA exists. And the detection side has gotten genuinely good, with wallet extensions flagging known drainer addresses before a user signs. Most people who landed on the fake Across page probably bounced.

And honestly, the architectural answer is already out there. Teams can serve front ends from IPFS, publish an ENS record, and ship signed manifests so a compromised domain can't silently swap the app. A few serious projects already do it.

Which raises the question worth sitting with. If the fix is known, cheap, and documented, why does the same incident keep landing in my incident log every few months?

The Verdict

Because security spend follows prestige, not risk.

A team will happily write a $200,000 check for a contract audit and put the domain on an account with SMS 2FA and one shared password in a team chat. I've seen the pattern across enough of these post-mortems to call it a cohort effect. Audits are status. DNS hygiene is chores. The chart tells the story, and the story is that everyone is guarding the vault and leaving the front door on a latch.

My position: the front end should be treated as part of the protocol, not as marketing infrastructure. That means hardware keys on the registrar account, a registry lock, DNSSEC, and an out-of-band confirmation step with the registrar before any nameserver change goes through. It means a signed front end served from a content-addressed store, so a hostile DNS record can't serve a hostile app. And it means a canary contract that the real interface reads from, so users have something to check that a phishing clone can't fake.

None of that's exotic. All of it's boring. Boring is the point.

The counterargument I'll concede is that this can't be mandated. DeFi has no regulator handing out DNS compliance checklists, and registrars have little incentive to make domain transfers painful for the 99.9% of customers who aren't bridges holding billions. So the burden lands on teams, voluntarily, forever, with no visible reward until the day it saves them.

Fine. That's still cheaper than a Curve-style $570,000 morning. And it's far cheaper than the reputational hit of a user base that learns your URL means nothing.

Here's the takeaway I'd put on a slide: the next nine-figure loss in this industry probably won't come from a reentrancy bug. It'll come from someone answering a familiar-sounding email with a password. One chart, one takeaway. Guard the door.