Think about the security stack protecting your crypto project right now.
- Smart contract audits — completed.
- Bug bounties — funded.
- Testnets — run. Multisig — deployed.
- Cold storage — configured.
- Endpoint detection — active. S
- OC monitoring — around the clock.
Now consider this:
The name your users type into a browser to access your protocol, connect their wallets, and move their funds serves as the front door to all of it. Yet, it was probably registered through a website builder that primarily sells templates to wedding photographers and food bloggers.
In July 2024, that’s exactly how a dozen Web3 projects had their domains hijacked. Not through a zero-day. Not through a smart contract exploit. Through a flaw in a registrar migration process that nobody on those teams flagged as a risk event.
W’ve been in the domain and DNS business for over 25 years. Our CEO, Mark E. Jeftovic, wrote this book — Managing Mission Critical Domains and DNS — in which he observed that…
Organizations routinely… “spend thousands, hundreds of thousands, even millions of dollars on redundancy, high availability, firewalls, disaster recovery plans, and even cyberthreat insurance — and yet the entire technical infrastructure of the organization is held up by a couple of unpatched, forgotten nameservers.”
That was 2018. In 2024, the same pattern played out again, but this time the nameservers weren’t forgotten. They were force-migrated to a platform that wasn’t built to protect them.
This post isn’t a technical teardown of the Squarespace incident. Those already exist, and the security researchers at MetaMask and Paradigm, Taylor Monahan, and Andrew Mohawk published an excellent analysis. What follows is a leadership failure analysis. It’s about the decisions, and non-decisions, that created the conditions for this to happen, and what executives running crypto projects should be doing differently.
July 9–12, 2024: 72 Hours That Should Have Been Preventable
Here’s the sequence of events, told at the altitude a CEO needs to understand them.
In June 2023, Squarespace acquired roughly 10 million domain registrations from Google Domains. Domain owners had no say in the transaction. Over the following year, Squarespace migrated those domains to its own platform. It was an enormous operational undertaking, and in the interest of making it “seamless,” Squarespace pre-linked email addresses from Google Domains accounts to new Squarespace accounts, assuming that domain owners and their collaborators would log in via social authentication — “Continue with Google” or “Continue with Apple.”
But Squarespace also offered email-and-password account creation. And it didn’t require email verification. And it didn’t require a password for accounts that hadn’t been claimed yet. And multi-factor authentication, which had been enabled on many of these accounts at Google was not carried forward into the migration.
The result was a breathtakingly simple attack path:
If a domain owner hadn’t yet claimed their Squarespace account, anyone who knew (or guessed) the associated email address could register the account themselves. No password to crack. No MFA to bypass. No verification to intercept. Just supply an email and set a new password. The account, and with it, full control of the domain, was yours.
Between July 9 and July 12, attackers exploited this flaw to hijack domains belonging to Compound Finance, Celer Network, Pendle Finance, Unstoppable Domains, and others. DNS records were modified. Users were redirected to phishing frontends running the Inferno wallet drainer kit. Affected teams scrambled publicly on X, warning users to stay away from their own websites. Some couldn’t even reach Squarespace support to begin recovery.
Squarespace was silent for days. When they finally published a post-mortem on July 23, they attributed the hijacks to “a weakness related to OAuth logins” and claimed the migration involved no changes to multi-factor authentication…a characterization that directly contradicted the findings of the independent researchers who had actually analyzed the incident.
Security Alliance estimated that hundreds of cryptocurrency domains, controlling access to billions of dollars in assets, had been migrated from Google Domains to Squarespace and were potentially at risk through this same vector.
No Zero-Day. It Was a Series of Decisions Nobody Questioned.
Every post-mortem is a story about choices.
The Squarespace incident involved at least five distinct governance failures, and every one of them was catchable at the executive level.
The migration was involuntary — and nobody flagged it as a risk event.
Google sold the domain business. Domain owners were migrated whether they consented or not. For any organization with a risk framework, a forced change of registrar should trigger a vendor risk review: Who is the new entity? What are their security capabilities? What changes to our access controls, authentication, and monitoring will result from this transition? For most of the affected projects, this migration triggered nothing more than an ignored email notification.
We see this constantly across the crypto space. Domain registrations are treated as commoditized infrastructure, meaning one provider is as good as the next. Nobody asks whether the new registrar has the depth of experience or the affinity with crypto that would enable them to provide adequate safeguards. The registrar is, functionally, a single point of failure for your entire domain, and yet it rarely appears on anyone’s risk register.
MFA was stripped during migration — and nobody noticed.
Whether Squarespace actively disabled 2FA or simply failed to carry it forward, the practical result was the same: accounts that had been protected by multi-factor authentication at Google were suddenly accessible without it. This should have been a showstopper. MFA isn’t an advanced security feature. It’s the most basic requirement for any account that controls where your users go when they type your domain name into a browser. If your team didn’t verify that MFA was intact after the migration, that’s a process failure at the executive level.
Account ownership was assumed, not verified.
Squarespace assumed domain owners would claim their accounts. Many never did because the billing admin had left the company, because the email got filtered, because nobody realized inaction had security implications. Attackers simply beat them to it. Worse, even lower-privileged roles like “domain manager” had the ability to modify DNS records and transfer domains. Most teams didn’t even know these shadow accounts existed.
As Taylor Monahan of MetaMask observed during the incident response:
“Most teams DO NOT REALIZE these accounts even exist, let alone theoretically have access.”
There were no audit logs, no notifications, no visibility.
Squarespace provided no audit trail for domain-level actions, no email notifications for critical changes, and no mechanism for domain owners to see who had access to their accounts. You had a platform with full control over your DNS, and no way to know what it was doing. In the domain registrar world, this is the equivalent of handing someone the keys to your building with no security cameras, no visitor log, and no way to change the locks.
There was no incident response playbook for a registrar-level compromise.
When the hijacks happened, affected teams resorted to posting warnings on social media, trying to reach Squarespace through standard support channels, and hoping the community would self-organize a response. The independent researchers at SEAL 911 ended up coordinating the incident response that Squarespace should have been leading. If your organization doesn’t have a specific, rehearsed plan for “our domain registrar has been compromised,” you were in the same position as every team that got hit in July 2024.
Your Registrar Wasn’t Built for This. It Was Built to Sell Website Templates.
The Squarespace incident isn’t an isolated case.
It’s the loudest example of a structural problem that’s been playing out across the crypto industry for years.
Most domain registrars are ill-equipped to effectively mitigate against an Advanced Persistent Threat actor, even in general cases. They are at an even worse disadvantage when it comes to crypto domains. The domain registrar industry, by and large, is the most institutionally lethargic, rentier class of operators on the entire internet. Thinking in terms of unit economics only, the most important element in many customer interactions distills down to “closing the ticket” at the lowest possible expense.
Some registrars are themselves hostile toward crypto projects, and for all practical purposes become threat actors in their own right. Arbitrary domain suspensions and takedowns are not isolated incidents…
They are routine. For example, MyEtherWallet, ETH.limo, ETH.link, Balancer, Yearn.Finance, the list goes on.
The reasons range from arbitrarily seizing domains to monetize them via pay-per-click ads, to suspending them without notice for unspecified terms-of-service violations, to complying with fabricated takedown requests without reading the underlying documents.
There’s also a subtler misalignment that executives need to understand:
There are critical times in the domain registration life-cycle when the registrar’s interests are misaligned with the registrant’s to the point where your domain becomes more valuable to them if you don’t renew it, or are somehow prevented from being able to. The crypto industry, in particular, operates within a registrar ecosystem that was underwritten by the very system crypto was created to make obsolete. Most legacy registrars don’t understand crypto, don’t support it, and don’t have the operational security posture to protect it.
Registrar selection should be treated as a tier-one vendor decision, evaluated with the same rigor you’d apply to choosing a custody provider or an infrastructure partner. In any event, here’s what you and your team can do.
A Checklist for Monday Morning
Here are five things your leadership team can act on this week.
Not a 40-page security framework. Here are some concrete decisions that close the gaps the Squarespace incident exposed.
1. Audit your registrar account.
Who has credentials? Is MFA enabled with hardware keys, not SMS? Is there a registry lock in place? When was the last time anyone reviewed contributor access? If you can’t answer these questions in five minutes, you have a problem. Transfer locks and registry locks should be enabled at all times. The latter requires out-of-band verification for any changes and is virtually impossible to bypass through social engineering.
2. Evaluate whether your registrar is fit for purpose.
At minimum, your registrar must support multi-factor authentication, domain and registry locks, private WHOIS with an active proxy, event notifications across multiple channels (not just email), and account-level ACLs with role-based permissions. If it can’t do all of these, you have a vendor problem, not just a configuration problem.
3. Implement continuous, independent monitoring.
Do not rely on your registrar to tell you when something changes. Monitor your DNS records like these ones: A, AAAA, MX, NS, TXT, CNAME, and SOA at minimum. Monitor WHOIS records for ownership changes. Monitor certificate transparency logs for unauthorized certificate issuance.
And get those alerts through channels that aren’t dependent on the infrastructure being monitored:
Slack, webhooks, dedicated dashboards.
4. Build a registrar-level incident response playbook.
Not a general IR plan. A specific, rehearsed plan for “our domain has been hijacked.” Who contacts the registrar, and through what escalation channel? Who contacts the registry operator directly? Who communicates to users, and through what out-of-band infrastructure? What’s the process for revoking fraudulent certificates? How quickly can you lower TTLs to accelerate propagation of corrected records?
5. Treat any forced migration as a critical risk event.
If your registrar is acquired, merged, or migrates your account to a new platform do not ignore the administrative email to file and forget. That’s a change in your security posture that requires executive-level review: verification of authentication settings, audit of account access, assessment of the new provider’s security capabilities, and a decision about whether to stay or transfer out before something goes wrong.
Your Protocol Is Decentralized. Your Front Door Isn’t.
Unfortunately, the Squarespace incident was the logical consequence of an industry-wide blind spot:
Crypto projects investing millions to secure the on-chain layer while leaving the off-chain layer (the domain, the DNS, the registrar account) to whichever commodified, unspecialized vendor happened to be there when someone registered the domain three years ago.
Your smart contracts may be decentralized and immutable. Your domain names, DNS records, and frontend hosting are managed through conventional, centralized infrastructure often with unclear ownership and inconsistent security practices. The gap between the security model of your protocol and the security model of your web presence is exactly where attackers live.
The same pattern has been repeating since MyEtherWallet in 2018.
PancakeSwap in 2021.
Curve Finance in 2022.
The Squarespace wave in 2024.
It’s the same structural weakness and…
The same operational blind spot. The only variable is which registrar fumbles next.
Your team and your project have the opportunity to address this now, before you become a trending hashtag for all the wrong reasons.
DomainSure provides domain registration, DNS management, and continuous monitoring built specifically for crypto, DeFi, and Web3 ecosystems — by the team behind easyDNS, with 25+ years of DNS expertise.
If the Squarespace incident made you uncomfortable, that’s the right instinct. Schedule a free Domain Threat Assessment →
Apply for a Domainsure Invite
Get a Free Domain Health Check
Due to high demand: allow up to 24 hours for report delivery.
