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.

---

Related reading

• Hardening a crypto exchange: what comes first — the same five-category question, answered with a different priority order because a custody backend exists to harden.
• Managed SOC for a DeFi protocol: why your alert has to beat the next block — the detection layer this hardening plan doesn't cover.
• Incident response for a DeFi protocol: there's no wallet to freeze — what happens once an exploit has already settled on-chain, which no hardening order prevents.