Name.com Domains Redirected in DeFi Front-End Wallet-Drainer Attack

A shared registrar record, but no confirmed entry point

The clearest thread in a wallet-drainer attack against DeFi websites runs through their domain registrar: all 12 domains named by project teams or security researchers were registered at Name.com, and each public registry record showed a change dated Oct. 31. That common record gives investigators a concrete place to focus, but it doesn't establish what was changed, who changed it or how access was obtained. The distinction matters: a domain can be registered with one company while its DNS is managed elsewhere, so identifying the registrar alone doesn't explain how visitors were sent to malicious pages.

Name.com said Saturday that several domains on its platform had been improperly redirected late Friday in an effort to access visitors’ crypto wallets. It restored the domains and said it was investigating, but hasn't identified the affected domains or explained how the attackers gained control. Restoration addresses the visible symptom; it doesn't, by itself, answer whether the underlying account or system was secured, or whether every affected project had verified its records.

Vercel, a hosting company and Name.com registration partner, reported that 10 Vercel-associated domains were affected. It said Name.com had restored them and that customers didn't need to take action. The affected domains used four DNS providers: six were on Vercel, two on Cloudflare, three on NS1 and one on Name.com’s nameservers. That spread complicates any simple account of the incident: the domains shared a registrar, while their DNS traffic was handled across several services.

Name.com said on X that it would post updates in the same thread. Vercel outlined the incident in a security bulletin. Those statements establish what the companies have publicly acknowledged so far, but leave the central technical question open: which control point was compromised?

Get Unchained’s crypto news in your inbox with the free Unchained Daily newsletter.

Front ends were redirected, projects said

Flap reported that its site had been hit by DNS hijacking and was sending visitors to an unauthorized destination. Kintsu said the incident involved a frontend takeover rather than a smart contract exploit. Origami Finance likewise said its website was redirected, while its smart contracts and vault funds were unaffected. The distinction is consequential for users: an application can present a malicious interface even when the contracts that hold or manage funds haven't themselves been altered.

A redirected site can put a familiar-looking page in front of a visitor and prompt actions that expose a wallet. In this case, the projects described a risk at the website level, while the reports don't establish that the underlying contracts were breached. That's a narrower finding, but it doesn't make the threat trivial. A misleading front end can still make routine wallet interactions dangerous.

Origami paused its vaults and advised people who had connected a wallet or signed on the site after 00:00 UTC on Oct. 31 to revoke unfamiliar approvals. Blockaid warned that nine other sites were actively serving the Step Drainer: stonkfun.xyz, pickle.finance, echelon.market, fluxbeam.xyz, stakepoint.app, supswap.xyz, longbow.cash, shprd.finance and apexdefi.xyz. The advice to review unfamiliar approvals reflects a common risk in wallet-drainer incidents: users may have authorized actions while believing they were interacting with the legitimate service.

Flap described the redirect, while Kintsu characterized it as a frontend takeover. Origami’s security notice detailed its response, and Blockaid listed the other sites. For readers checking whether they were exposed, those project notices and the security provider’s list offer more useful detail than the shared registrar clue alone.

Responsibility is still unclear

Project accounts have pointed toward Vercel infrastructure. Kintsu said the incident happened on Vercel’s end and was outside its control; Origami attributed the redirects to an active attack on Vercel-associated nameservers. Vercel’s bulletin instead describes a Name.com takeover campaign that Name.com is investigating, with Vercel assisting. The accounts aren't necessarily incompatible: hosting, DNS and registration are separate parts of a domain’s delivery path, and a weakness or change at one layer can affect what a visitor sees.

Independent researcher punkquidity said 10 hijacked sites were switched off at the registrar within five seconds at 12:32 UTC on Saturday. That rapid action suggests the registrar was able to intervene at a shared point, but it doesn't show what enabled the redirects in the first place. The researcher said it wasn't yet possible to determine whether Name.com or a reseller such as Vercel was responsible. A change visible in a registry record is evidence of a change, not proof of who initiated it or why.

Vercel separately confirmed a breach of its internal systems in April. Neither Vercel nor Name.com has connected that breach to the domain redirects. The earlier breach is relevant background because it raises questions readers may reasonably ask, but the available statements don't establish a link. Treating the two incidents as connected would go beyond the evidence presented so far.

What the incident leaves to resolve

For affected teams, the immediate priority is the registrar and DNS investigation: the shared registration records offer a lead, but the cause has yet to be established. Investigators will need to explain how the redirects were authorized, which accounts or systems were involved and whether the observed changes affected all of the named domains in the same way. Until that account is public, assigning responsibility to a particular provider would be premature.

This is more significant than it looks because a DeFi service depends on more than its contracts. Users reach those contracts through websites, and the website can shape what a wallet asks them to approve. If you're working in this space, the episode is a reminder that incident response has to follow the whole chain from domain registration through DNS and the user-facing application. The weak point may sit outside the code that teams usually describe as their product.

Here's the thing: restoring a domain can bring a site back, but users and projects still need a clear explanation of what changed and what precautions were taken. (And this is the part most people overlook.) Attribution is only one part of that account; affected projects also need to communicate which user actions may have exposed wallets and what steps users should take. The unanswered questions. Until the companies clarify the cause, the shared registrar records remain a useful lead, not a complete explanation.

Related Listen: Why Calling Out Bad Security Practices in DeFi Isn’t ‘Grave Dancing’