Across Protocol Goes Dark After Namecheap Domain Takeover

Across Protocol's team said an attacker gained control of the protocol's website domain through a social-engineering attack targeting registrar Namecheap, and the decentralized finance platform pulled the site offline within minutes to prevent further damage. Namecheap manages Across Protocol's domain, and the team said the attack on the registrar enabled an unauthorized party to control its web address.

What did the attacker actually gain?

Control of a domain is not control of a protocol, and Across Protocol's account keeps that line clear. The team's response centered on three things: control of the domain, access to the site and efforts to block a phishing page. The statement cites no change to protocol contracts, no interruption to the cross-chain routes the platform operates and no figure for user losses.

The distinction matters because registrar compromise differs from a smart-contract exploit in one respect: the attacker needs no code, only the record that points browsers at the protocol's interface. The team described the vector as social engineering against Namecheap and did not say how the attack succeeded.

Why the registrar matters

A domain registrar holds the registration record mapping a protocol's name to a network address, along with the credentials permitting changes to it. An attacker who takes over a registrar account can point a familiar name at a host they control, and every visitor who trusts the name lands on the attacker's copy. That is the phishing shape described here: a trusted address serving an untrusted page.

Who stopped the phishing page?

Cloudflare and SEAL911 helped flag the domain as risky and block a phishing site, the team said. Both names sit on the blocking side of the incident — Cloudflare in the request path for the domain, SEAL911 alongside it as the service that flagged the address. The look-alike page was blocked rather than merely reported.

What remains unresolved?

The website stayed offline while the team secured its systems and ran a deeper investigation, and users were told to avoid it until further notice. Two workstreams are open. One covers exposure: which users reached the phishing page and which integrations received approvals. The other covers the front end, which cannot restart safely while the registrar-level access path is still under examination.

What should users do right now?

The team's guidance ran to two instructions: avoid the website until further notice, and revoke permissions granted to suspicious integrations. The second instruction carries the sharper deadline, because a look-alike page can trigger a wallet prompt that grants an ERC-20 allowance, and that allowance stays recorded on-chain until the owner revokes it.

• Avoid the Across Protocol website until the team publishes further notice.
• Revoke permissions granted to suspicious integrations, as the team advised.
• Treat wallet connections made through the site while the domain was under unauthorized control as suspect, rather than waiting for a loss to confirm the exposure.

What does an offline front end cost a cross-chain protocol?

For a platform built around cross-chain transactions, a dark web interface is an operational cost rather than a cosmetic one, and users hunting for a replacement domain are pushed toward the phishing risk the team is trying to close. Across Protocol said its response centered on control of the domain, site access and blocking the phishing page while the security work continued.

Restoration now depends on two items the team has not dated: the outcome of its investigation into the registrar compromise and the completion of the security work behind the offline page. Until further notice, users should treat the domain as hostile and revoke any approvals tied to the phishing page.