DeFi Doesn’t Just Need Better Code - It Needs a Better Control Plane
The next phase of onchain finance will be defined by risk-bounded composability, operational security, and insurance infrastructure.
This April was an important stress test for how we talk about DeFi security.
The lazy narrative is that DeFi was hacked again, and therefore, DeFi is unsafe. That framing is satisfying but technically incomplete, primarily because it collapses too many failure modes into a single bucket.
A private key compromise is not the same thing as a smart-contract bug. A bridge assumption failing is not the same thing as an oracle failure. A compromised founder device is not the same thing as a protocol design flaw. A bad-governance pathway is not the same as a lending-market exploit. These distinctions matter because if we misdiagnose the problem, we will overcorrect in the wrong places.
The better framing is this: DeFi’s application layer has matured faster than its control plane.
By control plane, we mean the systems and processes that surround the protocol, including its interface(s), functionality, governance, and upgrades: keys, signers, deployment workflows, access control, endpoints, CI/CD, secrets, upgrade authority, monitoring, pausing, incident response, and recovery coordination. In an increasingly onchain world, these need to be a part of the financial infrastructure itself.
The recent wave of exploits has shown that attackers are increasingly targeting the seams between protocols, and the humans and systems that operate them. That tells us something important. The issue is not just more attacks, but that a small number of highly targeted attacks can create enormous losses when they hit the right integration point.
Not Every Crypto Hack Is a DeFi Failure
A meaningful share of what gets described as “DeFi hacks” is better understood as failures of operational security, custody, governance, signer hygiene, or key management. These are security failures, but they are not always failures of decentralized finance as a design category.
A smart-contract audit does not solve reused passwords, stale GitHub permissions, compromised founder devices, leaked CI secrets, or weak deployer wallet hygiene. It does not solve a multisig where every signer is exposed to the same social-engineering path.
The security baseline for crypto companies has to become much more explicit. Password managers, company-wide MFA, SSO, role-based access, hardware keys for sensitive roles, managed secret storage, automatic API key rotation, and fast offboarding should be treated as non-negotiable infrastructure rather than “later-stage company” overhead.
A protocol managing nine figures of value should have as robust a security program as a large enterprise.
Composability Is DeFi’s Superpower and Its Transmission Mechanism
DeFi’s composability can turn a local failure into a networked failure. When one asset, bridge, oracle, lending market, or restaking token becomes collateral elsewhere, a failure can propagate across protocols an order of magnitude faster than it would in traditional finance. The same properties that make open systems powerful - permissionless integration, instant settlement, composable liquidity - can also amplify mistakes.
That does not mean we should regard DeFi as a failure. It means we need risk-bounded composability.
Composability should be earned, capped, monitored, and staged.
New collateral should have conservative limits. New integrations should have circuit breakers. Bridges should have explicit risk scores. Oracles should have sanity checks. Governance changes should have timelocks. Admin functions should sit behind multisigs. Protocols should have the ability to pause, isolate, wind down, or migrate specific components without turning every incident into a system-wide panic.
Audits Are Necessary but Not Sufficient
A project can point to an audit report and say, “we took security seriously,” but audits are snapshots. Protocols are living systems. The highest-impact failures increasingly sit outside the narrow frame of “Was this contract audited?” They ask different questions, related to the application’s control plane:
Who can sign? Who can upgrade? Who can deploy?
What happens if a signing device is compromised?
What happens if a bridge mints an asset that downstream protocols treat as good collateral?
What happens if an oracle degrades?
What happens if a dependency in the deployment pipeline is compromised?
What happens if a rogue employee or stale contractor still has access?
What happens if the protocol needs to pause one function without freezing everything?
The practical implication is that security has to become an operating system.
The Founder Security Stack
First, treat endpoints as the perimeter. Dedicated work devices and dedicated signing devices should be standard. Sensitive work should not happen on machines full of personal accounts, random apps, and unvetted browser extensions. Endpoint detection and response, login-anomaly monitoring, restricted software installs, and immediate session revocation are now table stakes.
Second, make identity boring. Use SSO. Use MFA. Use passkeys or hardware keys for sensitive roles. Organize access by groups. Keep admin privileges sparse. Offboarding should take minutes, not days. If someone leaves the company, the team should be able to quickly disable SSO, remove password vault access, revoke GitHub and Slack access, rotate credentials, and reassign repositories.
Third, move secrets out of places they do not belong. API keys should not live in Git. CI should not hold long-lived secrets. Production and development accounts should be separate. Use managed secret stores, OIDC-federated cloud credentials, encrypted configuration, and automatic key rotation.
Fourth, harden CI/CD. Require branch protection, signed commits, CI passing before merge, no forced pushes to main, separate test/build/security/deploy stages, enable security scanning, have deterministic builds where possible, stick to versioned releases, and make sure you have easy rollback.
Fifth, separate deployer wallets from admin wallets. Deployer wallets should have limited funds, limited authority, and no lingering admin privileges post-deployment. Admin roles should sit behind multisigs, timelocks, and emergency pause functions.
Sixth, use multisigs for anything material. Treasury and admin flows should have clear signer quorums, separate roles, cold backups, hardware wallets, and no mixing of personal and work wallets. Have a minimum 3-of-5 structure for treasury/admin flows, with appropriate separation and backup.
Seventh, prepare the incident response plan before the incident. Teams should know who to call for security firms, exchanges, analytics providers, stablecoin issuers, infra vendors, legal counsel, law enforcement, and chain or foundation contacts. A plan written during an exploit is a scramble, not a plan.
Insurance Is Not a Substitute for Security, but It Is a Prerequisite for Scale
If onchain finance wants institutional and conservative capital, it cannot stop at audits and dashboards. It needs mechanisms for retained risk, transferred risk, deductibles, limits, exclusions, reserves, and payouts.
This is where parametric insurance and onchain risk-transfer protocols become important.
DeFi insurance protocols are designed to pool risk and provide financial protection against adverse onchain events. We need systems that can use smart contracts and decentralized infrastructure to provide coverage for risks such as smart-contract vulnerabilities and protocol exploits.
The right stack is:
Prevent the obvious failure.
Detect abnormal behavior quickly.
Respond before losses cascade.
Transfer residual risk.
Parametric insurance is particularly interesting because blockchains can define measurable triggers and automate payouts. Stablecoin depegs, oracle deviations, validator slashing, bridge failures, and certain smart-contract events may be easier to encode than many traditional claims processes. But parametric cover also introduces basis risk: the trigger may not perfectly match the economic loss.
Of note in this topic is that the oracles used for protection and the executors of said policy should probably exist in different execution environments. The same way a satellite usually carries clusters of CPUs to check each other for bit flips (since you can’t know from the inside of one of them whether a bit flip happened or not), so should we verify these properties from outside the environment these properties exist in.
We believe the future includes a mix of discretionary cover, parametric insurance, tokenized reinsurance, protocol reserves, covered vaults, and hybrid structures that connect onchain markets with regulated insurance capital.
The deeper point is that blockchains should not only compose yield. They should compose risk intelligence.
The same transparency that allows protocols to create financial products should also make risk more legible: collateral risk, oracle risk, governance risk, liquidity risk, operational risk, bridge risk, and counterparty risk. Once those risks are exposed, segmented, and priced, the market can underwrite genuinely risk-adjusted yields.
Institutional DeFi Will Be More Transparent, Not Less Open
Ethereal, as a firm, has been backing teams building for institutions since 2022, and we believe that hacks slow down cyclical adoption but do not necessarily slow serious adoption.
Institutions do not need DeFi to be risk-free. They need risk to be measured, bounded, governed, reported, remediated, and, where possible, transferred.
The institutional version of DeFi would be more transparent than today’s market. But it will have clearer rules around what can plug into what, at what size, under what monitoring, with what backstop, and with what unwind path.
This is where “risk-bounded composability” becomes the key phrase.
Institutions may accept open systems, but they will not accept unlimited recursive exposure to assets, bridges, or protocols that have not been risk-scored.
This is also one of the clearest company-building opportunities in crypto.
The need extends beyond audit firms and requires a security and risk infrastructure that enables composability to scale without allowing risk to compound invisibly.
That includes:
DeFi risk engines (collateral risk scoring, protocol-level reserves)
Better monitoring infrastructure (bridge-risk monitoring, oracle anomaly detection, real-time protocol observability)
Key management (signer-policy infrastructure, secure wallet and key-management systems)
Tooling (governance-risk tooling, incident-response tooling, institutional reporting)
Insurance and risk-adjusted products (parametric insurance, tokenized reinsurance, covered vaults
Onchain recovery infrastructure
The winners will not simply help protocols find bugs. They will help protocols understand, price, monitor, cap, transfer, and report risk. We look forward to speaking to more founders who can help shape this future.
If you’re building in any of these categories, we’d love to hear from you.
This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by EV. (An offering to invest in an EV fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by EV, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Ethereal Ventures (excluding investments for which the issuer has not provided permission for EV to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://etherealventures.com/#portfolio.
Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://etherealventures.com/terms for additional important information.
 | A guest post by
|