Key takeaways
- Across Protocol's domain across.to was hijacked at about 18:45 UTC on 10 November 2026 through a social engineering attack on its registrar, Namecheap.
- The bridge's smart contracts were not the target. The attacker changed where the domain pointed and served a wallet-draining copy of the site instead.
- Across says it was alerted within 15 minutes; control was regained with Namecheap's help and systems were restored at around 01:16 UTC on 11 November.
- What actually disabled the phishing site was Cloudflare removing the DNS records, with SEAL911 flagging the domain to wallet providers - centralised chokepoints, the same class of thing that enabled the attack.
- Losses are estimated at about $350,000 by one outlet, not independently confirmed. Across has said affected users will be fully compensated and has promised a detailed report.
On the evening of 10 November, someone took control of across.to. Users who typed the address they had always typed arrived at a copy of the site built to drain their wallets.
The bridge's smart contracts were never touched. Nobody found a reentrancy bug or a signature flaw. The attacker went to the domain registrar instead - Namecheap - and talked their way in.
Every standard piece of advice would have failed
This is the part worth sitting with, because the usual guidance is not merely unhelpful here. It is actively misleading.
"Check the URL." The URL was right. It was the real domain, correctly spelled, no lookalike characters, no extra hyphen.
"Use a bookmark instead of a search result." A bookmark stores a domain, not a destination. It pointed at exactly the same place as typing it.
"Look for the padlock." Whoever controls a domain's DNS can obtain a valid certificate for it, usually within minutes and automatically. The padlock certifies that you reached the domain you asked for. It says nothing about who is answering.
So a careful user doing all three correct things ended up in the same place as a careless one. The only signals available were out-of-band: the protocol's own warning on social media, and wallet software that had been told the site was dangerous.
A domain is rented, not owned
Underneath this is a fact that sits awkwardly beside the word "decentralised".
A protocol can deploy contracts that nobody can alter, hand control to a multisig, publish the source, and renounce the keys. Then it puts a name on all of it - and that name is leased annually from a company, transferable by that company's staff, and defended by whatever identity checks those staff apply.
Which means the practical security of an immutable system was, on 10 November, the quality of a support-desk verification procedure. Not the cryptography. Not the audits. A human being deciding whether the person on the other end was who they claimed to be.
Social engineering at the registrar is not an exotic attack. It is the oldest one there is, aimed at the softest part of the stack, and it bypasses every hard part completely.
The rescue came from the same place as the attack
Here is the detail that most coverage mentions and few draw out.
What actually stopped the bleeding was not a contract, a governance vote or a multisig. Across says it was alerted within about 15 minutes. The security group SEAL911 got the domain flagged with major wallet providers, and Cloudflare marked it at risk and then removed its DNS records, which made the phishing site unreachable. Control of the domain came back with Namecheap's assistance, and systems were restored around 01:16 UTC.
Read that list again. A registrar, a CDN, a volunteer security group, and wallet vendors. Every one of them a centralised intermediary with the power to act unilaterally.
That is not hypocrisy, and it is not an argument against decentralisation. It is a structural fact worth stating plainly: a chokepoint that can be used against you can also be used on your behalf. The registrar that lost the domain is the registrar that got it back. The CDN that could have kept serving the phishing page is the one that pulled the plug. You cannot remove the single point of failure without also removing the single point of rescue, and most projects quietly rely on both.
There is a caveat to that, though, and it cuts against the comfortable version of the story. Across said publicly that "despite our best efforts, @Namecheap has been unresponsive" during the incident, and reporting has the domain coming back with the assistance of Namecheap's founder, Richard Kirkendall - that is, through a personal escalation rather than the normal support path. I have not seen a response from Namecheap, and nothing indicates it has accepted liability.
So the single point of rescue did work, but not because the process worked. It worked because somebody could reach the top of the company. That is not a control a smaller project can count on, and it is worth being clear-eyed about: "the registrar helped us recover it" and "we got the founder's attention" are different sentences with very different implications for anyone planning their own incident response.
The window, and what it means for a user
The takeover was around 18:45 UTC. Restoration was around 01:16 UTC the next day. Call it six and a half hours, with detection inside the first 15 minutes.
During that window, there was no action a user could take at the site itself that would have been safe, because the site itself was the attack. The defences that existed were all elsewhere - a wallet that refused to connect, a warning seen on another platform, or simply not transacting that evening.
Which gives an unglamorous but real habit: when a protocol is mid-incident, the correct move is to do nothing at all. Not to check whether it is fixed yet. Not to move funds somewhere safer through the same interface. Waiting costs you nothing in a six-hour window; interacting can cost you everything.
What protects a domain, for anyone running one
The mitigations here are mundane and mostly unglamorous, which is probably why they get skipped.
Registrar and registry locks. A transfer lock at the registrar stops a routine transfer; a registry lock sits one level higher and typically requires an out-of-band, manual process to lift. The second is the one that defeats a support-desk compromise, because the support desk cannot lift it alone.
Separate the registrar account from everyday email. If the recovery address for a domain is a team inbox that dozens of people and services can reach, the domain is only as safe as that inbox.
Treat the registrar as part of the threat model. Most projects audit contracts and never once ask what their registrar's account-recovery procedure actually is. It is a published policy. It can be read.
For a user, the honest list is shorter: keep wallet software updated so provider-level warnings reach you, follow the protocol's own channels for incident notices, and treat any unexpected approval request as a reason to stop rather than a step to complete.
What is still unknown
Several things, and they matter.
How the attacker got past the registrar has not been disclosed. "Social engineering" is a category, not an explanation. Across has promised a detailed report, and until that exists, anyone claiming to know the specific method is guessing.
The loss figure is one outlet's estimate. About $350,000 is reported by crypto.news; I did not find independent confirmation, and early figures in incidents like this move in both directions.
Compensation is a commitment, not yet an event. Across has said affected users will be made whole. That is a good sign and it is a promise about the future; the mechanism and timing have not been published.
It is also worth saying what Across appears to have done well: detection inside 15 minutes, engaging an external security group, getting wallet-level warnings out, and recovering the domain inside seven hours. That is a competent response to something that was not primarily its own technical failure.
The transferable point
We keep rediscovering the same shape. Malicious extensions being pulled from a store does nothing for the person who already typed a seed phrase into one. A fix merged upstream is not a fix running on your machine. And now: a contract nobody can alter, reached through a name somebody else can give away.
In each case the strong part of the system was genuinely strong, and irrelevant, because the path users actually travelled ran through the weak part. Security is not the average of your components. It is the state of whichever one an attacker chose.
Details here come from the cited reporting of 10–11 November and from Across's own statements as those outlets describe them; the promised incident report may change or add to the picture. This is education, not investment advice.
Frequently asked questions
What actually happened to Across Protocol?
At about 18:45 UTC on 10 November 2026, attackers took control of the domain across.to through a social engineering attack on the registrar, Namecheap, and pointed it at a copy of the site designed to drain wallets. The protocol's smart contracts were not the target and were not altered.
Would checking the URL have protected me?
No. The domain was the real one, correctly spelled. A bookmark would have led to the same place, because a bookmark stores a domain rather than a destination. A valid TLS padlock would also have appeared, since whoever controls a domain's DNS can usually obtain a certificate for it automatically.
What stopped the attack?
Centralised intermediaries. Across says it was alerted within 15 minutes; SEAL911 had the domain flagged with major wallet providers, and Cloudflare marked it at risk and removed its DNS records, making the phishing site unreachable. Control of the domain was regained with Namecheap's help and systems restored around 01:16 UTC on 11 November - though Across said publicly that Namecheap had been unresponsive during the incident, and reporting credits the recovery to its founder's personal involvement rather than the normal support path.
How much was lost, and will users be repaid?
One outlet estimates about $350,000, which I could not independently confirm; early incident figures often change. Across has said affected users will be fully compensated, but the mechanism and timing have not been published, so treat it as a stated commitment rather than a completed process.
What can a project do to prevent this?
Transfer locks at the registrar and, more importantly, a registry lock, which generally requires an out-of-band manual process to lift and so cannot be undone by a compromised support interaction alone. Keep the registrar account's recovery address separate from shared team email, and read the registrar's account-recovery policy as part of the threat model.
What should a user do during an incident like this?
Nothing, through that interface. Do not check whether it is fixed, and do not try to move funds to safety through the same site - that was the attack surface. Waiting costs nothing over a few hours. Keep wallet software current so provider-level warnings arrive, and follow the protocol's own channels for notices.
Sources
Every figure and quote above traces to one of these. Checked on publication day.
- theblock.co — Crosschain protocol Across restores systems after domain hijack - The Block
- crypto.news — Across Protocol restores website after phishing attack, $350K in estimated losses - crypto.news
- cryptotimes.io — Across Protocol Domain Hijacked via Namecheap Social Engineering Attack, Users to Be Made Whole - The Crypto Times
- techflowpost.com — Cross-chain protocol Across: Domain Hijacked After Registrar Suffers Social Engineering Attack - TechFlow
- altcoinbuzz.io — Protocol Warns Users After Domain Hijack Sends Visitors to Phishing Site - AltcoinBuzz
Deepmoni Das, Editor
I read the primary filings, exchange notices and post-mortems behind each story and write up what they actually say — with every source linked so you can check me. I am not a trader and I do not hold positions in anything covered here. Research and drafting are AI-assisted; the sourcing, the edits and the mistakes are mine.
Not financial advice. Crypto assets are volatile and unregulated in many jurisdictions. In India, gains are taxed at 30% with 1% TDS on transfers. Do your own research and never invest money you cannot afford to lose.
Editorial note: Crypto Shakti uses an AI-assisted research and drafting workflow. Every article is grounded in the linked primary sources and live market data captured at publication time.