What order should a non-custodial DeFi protocol harden registrar/DNS control, admin-key custody, timelock configuration, off-chain infrastructure, and front-end deploy pipeline in?

Registrar and DNS account control first (the front-end domain is the single most externally-reachable dependency and doesn't require touching a contract), admin-key custody and multisig configuration second, timelock configuration on privileged contract functions third, off-chain infrastructure — RPC nodes, keeper bots, oracle relayers — fourth, and front-end build/deploy pipeline integrity fifth. That's the reverse of a crypto exchange's order, because a non-custodial protocol has no custody backend to harden in the first place — the actual centralized-control points are the domain, the keys, and the delay before those keys' actions take effect.

Why doesn't the same hardening order that fits a crypto exchange or a bank also fit a DeFi protocol?

A crypto exchange's highest-consequence loss path runs through custody and signing infrastructure it hosts itself — cloud configuration leads. A bank's runs through network segmentation under regulatory severability rules. A non-custodial DeFi protocol doesn't custody user funds at all; funds sit in the protocol's own contracts, reachable only by the user's own wallet or by whichever address holds a privileged contract role. There's no custody layer to harden, so the order has to start with what actually is centralized: the front-end domain and the keys that can call privileged functions.

Isn't a smart contract audit enough security for a DeFi protocol — why does hardening matter separately?

No, and this engagement doesn't replace one. A contract audit reviews the Solidity/Rust code itself for logic bugs. It doesn't review who controls the registrar account for the domain the audited contract's front-end lives at, how many signers a multisig actually requires in practice, or whether a keeper bot's private key sits in a plaintext environment variable on an unpatched host. The Squarespace-driven front-end hijacks that hit Compound, Celer Network, and PendleFi in July 2024 didn't touch a single line of audited contract code — they hijacked the domain the audited front-end was served from.

How does the 2024 Squarespace DNS hijack actually illustrate a hardening gap, not a contract bug?

Squarespace's migration of Google Domains accounts left two-factor authentication disabled on migrated accounts, and attackers used password spraying — not a smart-contract exploit — to take over registrar accounts and repoint DNS records. Visitors to the real domain landed on a pixel-perfect fake front-end running a wallet-drainer kit. Compound and PendleFi were confirmed compromised; Celer Network's takeover attempt was caught and reversed. None of it required breaking the protocol's contracts, because the contracts were never the target — the domain was.

Will this hardening order interfere with an active governance or upgrade process?

It shouldn't, and in one respect it protects that process rather than slowing it down. Registrar and off-chain infrastructure changes run in the same change-windowed, staging-first sequence as any hardening engagement, independent of contract governance. Multisig and timelock reviews don't change the outcome of a legitimate governance vote — they change how much runway exists to catch an illegitimate one before it executes, which is the entire point of a timelock in the first place.

Hardening a DeFi Protocol: What Comes First

The short answer

For a non-custodial DeFi protocol working through a hardening plan with no server fleet or cloud custody backend to patch, the priority order is: registrar and DNS account control first, admin-key custody and multisig configuration second, timelock configuration on privileged contract functions third, off-chain infrastructure fourth, front-end build/deploy pipeline fifth. That's close to the reverse of what fits a crypto exchange, because a crypto exchange's highest-consequence loss path runs through custody infrastructure it hosts itself, and a non-custodial protocol has no custody infrastructure at all. The actual centralized-control points on a DeFi protocol are the domain the front-end is served from and the keys that can call a privileged contract function — not a cloud IAM role, not a corporate network, not a customer's login.

Who this is for

This is written for whoever owns the operational security roadmap at a live (or about-to-launch) non-custodial DeFi protocol — a lending market, a DEX, a liquid-staking protocol — who has already completed or scheduled a smart-contract audit and is now asking a narrower question: what's left to harden outside the contract code itself. It assumes the audit is handled separately; this engagement covers the operational and infrastructure layer around the protocol, not a Solidity or Rust code review. It's not for you if the open question is on-chain detection during a live incident — Managed SOC for a DeFi protocol covers the monitoring layer, and Incident Response for a DeFi protocol covers what happens once an exploit has already settled on-chain.

The five categories, on a DeFi protocol

A crypto exchange's five hardening categories are server, network, identity, application, and cloud configuration — because an exchange runs a conventional backend behind those funds. A non-custodial protocol doesn't have that backend. The five categories that actually carry the risk look different:

Category	What's in scope	Why it exists on a protocol with no traditional backend
Registrar / DNS	Domain registrar account access, DNS provider 2FA/SSO, registrar-lock status	The front-end domain is the single point where a user's browser decides which contract address to trust — and it sits at a conventional registrar, not on-chain
Admin-key custody	Multisig signer set, hardware vs. software key storage, per-function role separation (pause, upgrade, parameter changes, mint)	The on-chain equivalent of an IAM role — whoever holds enough signer keys can act on the protocol directly
Timelock configuration	Delay window on privileged actions, whether the delay is enforced in code or only by convention	The equivalent of a change window — the only thing standing between a compromised or malicious admin action and its execution
Off-chain infrastructure	RPC endpoints, keeper/liquidation bots, oracle relayers, indexers	The closest analog to conventional server hardening — these run continuously, hold operational keys, and can be exploited the way any unpatched host can
Front-end deploy pipeline	Build server access, CI/CD secrets, dependency supply chain for the dApp UI	A second, less externally-visible path to the same outcome as a registrar hijack — a compromised build step can ship a malicious front-end without ever touching the registrar

A full engagement eventually touches all five. The question is which gets the first change window.

Why the exchange and bank order doesn't fit

Hardening a crypto exchange leads with cloud configuration because an exchange's highest-consequence loss path runs through custody and signing infrastructure it hosts itself — an over-scoped IAM role or an unrestricted custody-API caller can move funds directly. Hardening a digital bank leads with network segmentation because DORA's severability requirement makes an unsegmented network the specific regulatory gap. Both orders assume a custody backend exists to harden.

A non-custodial DeFi protocol doesn't hold user funds in a backend at all — funds sit in the protocol's own smart contracts, reachable directly by the user's wallet except where an admin, pause, or upgrade function exists. That removes "steal the custody credentials" as an attack path entirely, because there's no custody to steal. What's left is exactly two ways to move funds without the legitimate owner's consent: get between the user and the real contract at the interface layer, or get control of whichever keys can execute a privileged contract function. Everything else — off-chain infrastructure, the build pipeline — is a secondary path into one of those same two outcomes.

That first path isn't theoretical. In July 2024, attackers took over Squarespace-hosted DNS accounts for Compound Finance, Celer Network, and PendleFi. The root cause, per Blockaid's own incident report, was that Squarespace's migration of Google Domains accounts had left two-factor authentication disabled on migrated accounts — attackers used password spraying, not a contract exploit, to get in. Once they controlled the registrar account, they repointed DNS A records so the real domain served a pixel-perfect fake front-end running the Inferno drainer kit, which Decrypt reported left roughly 228 DeFi protocol front-ends at risk industry-wide. Compound and PendleFi were confirmed compromised; Celer Network caught and reversed its own takeover attempt before DNS propagated. No audited contract was touched in any of it, because the contracts were never the target.

The priority order for a DeFi protocol, and why

Order	Category	Why this position
1	Registrar / DNS	Requires no contract change, no signer coordination, and no community communication to fix — and it's the exact path that already compromised Compound, Celer Network, and PendleFi in 2024
2	Admin-key custody	Whoever holds enough signer keys can act on the protocol directly; hardware-wallet custody and a signer set that isn't concentrated in one team or one individual closes the second of the two real attack paths
3	Timelock configuration	The delay window is what gives users and the community a chance to react to a malicious or compromised admin action before it executes — it doesn't prevent a bad transaction, it buys the time to catch one
4	Off-chain infrastructure	RPC nodes, keeper bots, and oracle relayers run continuously and hold operational keys, but a compromise here usually degrades service or triggers a detectable anomaly rather than moving funds directly
5	Front-end deploy pipeline	A second route to the same outcome as a registrar hijack, but it requires compromising a build step or a dependency rather than a single account takeover, which is a narrower and harder attack surface than the registrar itself

This is a starting default, not a fixed rule. A threat-modeling pass against your actual setup — how many signers, whether the timelock is enforced in code, who has console access to the RPC provider — can and should move a category up the list regardless of this general order.

What this looks like in an actual engagement

The order above answers "what first," but the engagement runs the same sequence regardless of which category leads: current-state assessment — who has registrar and DNS provider access, what the actual multisig threshold and signer set is versus what's documented, whether the timelock delay is enforced on-chain or only assumed — threat-modeling against the paths above, changes applied in change-windowed phases starting with whichever requires the least coordination, then a retest against the same paths the assessment used. Our Security Hardening engagements hand back a reproducible baseline — in this case a documented registrar-security configuration, a key-custody runbook, and an escalation path — rather than a one-time PDF of findings.

Registrar and DNS changes are the fastest to schedule precisely because they don't touch a contract or require a governance vote — which is also why they belong first rather than waiting for a broader remediation cycle.

Limitations

This engagement doesn't include a smart-contract code audit — that's a specialized review of the Solidity or Rust code itself, out of scope here and not something to substitute this hardening work for. It's also not a detection control: hardening reduces what an attacker can reach, it doesn't watch for the attempt in real time, which is what the Managed SOC detection layer referenced above actually does. And no hardening order, however sequenced, undoes a transaction that has already settled on-chain — that's the boundary Incident Response for a DeFi protocol is built around, not something this engagement changes.

How to decide

Start with whichever category a recent audit, incident, or specific finding already flagged — that overrides the general order every time. Absent a specific finding, work registrar and DNS account control first, since it requires no contract redeployment and the least coordination, then admin-key custody, then the remaining three categories in the order above. Tell us what your current setup looks like and we'll build the change-windowed hardening plan around it rather than a generic checklist built for a platform with a conventional backend.

Sources and review

The July 2024 Squarespace DNS hijack details — the disabled 2FA during the Google Domains migration, the password-spraying attack method, and the Compound/Celer Network/PendleFi outcomes — are drawn from Blockaid's own incident report and independently corroborated by Decrypt's reporting, including the ~228-protocol at-risk estimate. Both are third-party reported facts about a public incident, not an AnySec engagement or claim. Multisig, timelock, and key-custody practices referenced are widely published industry consensus, not proprietary AnySec data. The crypto-exchange hardening order referenced for contrast is AnySec's own published analysis, linked above rather than restated. Hardening methodology and deliverable format are AnySec's own published Security Hardening service terms; no third-party vendor pricing or performance statistic is cited as fact. Author: AnySec Engineering. Published 2026-09-26; last reviewed 2026-09-26.

Frequently asked questions

What order should a non-custodial DeFi protocol harden registrar/DNS control, admin-key custody, timelock configuration, off-chain infrastructure, and front-end deploy pipeline in?: Registrar and DNS account control first (the front-end domain is the single most externally-reachable dependency and doesn't require touching a contract), admin-key custody and multisig configuration second, timelock configuration on privileged contract functions third, off-chain infrastructure — RPC nodes, keeper bots, oracle relayers — fourth, and front-end build/deploy pipeline integrity fifth. That's the reverse of a crypto exchange's order, because a non-custodial protocol has no custody backend to harden in the first place — the actual centralized-control points are the domain, the keys, and the delay before those keys' actions take effect.
Why doesn't the same hardening order that fits a crypto exchange or a bank also fit a DeFi protocol?: A crypto exchange's highest-consequence loss path runs through custody and signing infrastructure it hosts itself — cloud configuration leads. A bank's runs through network segmentation under regulatory severability rules. A non-custodial DeFi protocol doesn't custody user funds at all; funds sit in the protocol's own contracts, reachable only by the user's own wallet or by whichever address holds a privileged contract role. There's no custody layer to harden, so the order has to start with what actually is centralized: the front-end domain and the keys that can call privileged functions.
Isn't a smart contract audit enough security for a DeFi protocol — why does hardening matter separately?: No, and this engagement doesn't replace one. A contract audit reviews the Solidity/Rust code itself for logic bugs. It doesn't review who controls the registrar account for the domain the audited contract's front-end lives at, how many signers a multisig actually requires in practice, or whether a keeper bot's private key sits in a plaintext environment variable on an unpatched host. The Squarespace-driven front-end hijacks that hit Compound, Celer Network, and PendleFi in July 2024 didn't touch a single line of audited contract code — they hijacked the domain the audited front-end was served from.
How does the 2024 Squarespace DNS hijack actually illustrate a hardening gap, not a contract bug?: Squarespace's migration of Google Domains accounts left two-factor authentication disabled on migrated accounts, and attackers used password spraying — not a smart-contract exploit — to take over registrar accounts and repoint DNS records. Visitors to the real domain landed on a pixel-perfect fake front-end running a wallet-drainer kit. Compound and PendleFi were confirmed compromised; Celer Network's takeover attempt was caught and reversed. None of it required breaking the protocol's contracts, because the contracts were never the target — the domain was.
Will this hardening order interfere with an active governance or upgrade process?: It shouldn't, and in one respect it protects that process rather than slowing it down. Registrar and off-chain infrastructure changes run in the same change-windowed, staging-first sequence as any hardening engagement, independent of contract governance. Multisig and timelock reviews don't change the outcome of a legitimate governance vote — they change how much runway exists to catch an illegitimate one before it executes, which is the entire point of a timelock in the first place.