Why can't DeFi rely on immutability alone?

Launch-time audits cannot anticipate every future attack technique. When bytecode is fixed, a team cannot patch disclosed vulnerabilities, add runtime guardrails, or respond to methods discovered by increasingly capable automated tooling, regardless of how thorough the original audit was.

What does "spec is law" mean?

Instead of trusting only the code written at deployment, the system's permitted behavior is bounded by a specification enforced at runtime. New attacks have to work around the same protective rules as everything else, which tends to make effective exploits rarer and harder to repeat.

What should institutional allocators evaluate about upgradability?

Who holds upgrade keys, how proposals are approved, what timelocks apply, and what transparency exists when changes execute. Operational risk in traditional finance already covers how systems evolve; upgradeable smart contracts raise the same question in a new setting.

Does upgradability contradict decentralization?

Not necessarily. An upgrade path routed through credible multi-sig governance, published rationales, and enforced delays can function as a governed feature rather than an opaque admin backdoor.

How does AI change the upgrade calculus?

As automated exploit discovery improves, the cost of immutability rises, since a fixed system cannot respond to a growing set of newly discovered techniques. Defenders need the ability to harden a system after launch, the same reason even maximally conservative chains eventually face moments where their own rules have to change to preserve their purpose.

Is a one-off audit at launch enough?

Recent exploits against diligent, well-audited protocols suggest it typically is not. Institutions should expect continuous work, monitoring, incident response, and governed upgrade paths, as part of the security posture.

Who should hold the keys to an upgrade process?

There is no single correct answer, but the pattern that tends to hold up is a credible multi-sig with published membership, combined with enforced timelocks. The specific structure still depends on the protocol's own risk profile and governance maturity.

Can a protocol be too conservative about upgrading?

Yes. A protocol that refuses to patch known issues out of a commitment to immutability is treating a design principle as more important than the outcome it was meant to protect. The harder, more useful discipline is upgrading deliberately and transparently, not avoiding upgrades altogether.

Smart Contract Upgradability: Why DeFi Needs the Ability to Evolve

Why upgradability exists in DeFi, how the security arms race demands it, and why "code is law" alone is not enough for systems that need to keep defending against evolving threats.

By: Orion Finance Research6 MIN READ | PUBLISHED AT 3/11/2026

Smart Contract Upgradability: Why DeFi Needs the Ability to Evolve

Key Takeaways

The original smart contract ideal, code is law and code does not change, leaves defenders without options when something breaks. Financial markets and attack techniques keep evolving; immutability alone does not keep pace with that reality.

AI is accelerating the offense. Benchmarks such as EVMBench have seen exploit-finding rates jump from roughly 12–13% to well over 70% on fund-draining bugs. If code cannot change, defenders cannot patch, add guardrails, or respond to novel methods.

The industry is moving from patching individual bugs toward "spec is law": systems bounded by enforceable safety rules that can be tightened before and after deployment. Reaching that model requires the ability to improve contracts over time, which immutable code structurally cannot do.

"Battle-tested" describes a snapshot, not a permanent state. Protocols that could not pause or upgrade when a serious exploit appeared illustrate the cost of treating launch-time security as a finished state rather than an ongoing one.

For institutions, upgradability needs to be constrained, visible, and accountable: clear governance, real timelocks, published proposals, and credible multi-sig execution, not unchecked admin keys standing in for a governance process.

The Case for Upgradability

"But nonetheless the people managing these contracts will still need to have agency to be on the defensive to make sure that they are winning the arms race against the offensive types." — Bankless podcast, on AI and smart contract security, with Alpin Yukseloglu (Paradigm)

That quote, from a conversation about how quickly AI is improving at finding and exploiting smart contract bugs, is close to the center of the design choices Orion makes.

The original smart contract ideal was simple: code is law, and code does not change. If nobody can rewrite the rules, nobody can cheat. A system that can never adapt sounds clean on paper, but it leaves a team with no options when something breaks, and financial markets keep generating unknown unknowns that a launch-time design cannot fully anticipate.

The pressure to stay adaptable has only intensified. AI is getting better at finding and exploiting smart contract bugs, faster than much of the industry was prepared for. Benchmarks like EVMBench, which test whether AI agents can detect, patch, and exploit real fund-draining bugs, have recorded exploit-finding rates rising from roughly 12–13% to well over 70%. That shift does more than surface more bugs; it changes the game itself. If code can never change, defenders are working with one hand tied behind their back, however careful the original design was.

Real-world events have already made the point concretely. Balancer's protocol was widely considered battle-tested, precisely the kind of system where a pause button or a clear upgrade path might seem unnecessary. When a serious exploit appeared, the protocol could not pause; it had been built and operated on the assumption that it was already secure. The incident is a reminder that "battle-tested" describes a point in time, not a permanent property. Attack techniques evolve, so the ability to respond has to evolve alongside them.

The same logic applies to the most conservative system in crypto: Bitcoin. Its proof-of-work design is often held up as the standard for "code is law" and minimal change. Yet when quantum computing eventually threatens the underlying cryptography, Bitcoin will have to change something. That change will not be decided by an in-protocol mechanism; it will be decided by social consensus, the community agreeing that the rules have to shift to preserve what the system is for. Even the most immutable chain in the space eventually faces a moment where staying relevant requires accepting that the rules can change. The open question is whether that change is planned and governable, or forced and reactive.

Upgradability in DeFi is a version of the same idea in a faster-moving context. It is not a betrayal of immutability as a principle; it is closer to a practical requirement for staying in the game once the other side keeps improving.

Spec Is Law

A related shift is under way in how the industry thinks about security. As a16z's Big Ideas 2026 notes, in a piece by Daejun Park, recent DeFi hacks have hit battle-tested protocols with strong teams, diligent audits, and years in production. That points to an uncomfortable reality: standard security practice today is still largely heuristic and case-by-case, and there is no way to assume every bug was caught before launch.

The industry is moving away from patching individual bugs, toward enforcing clear, design-level safety rules, properties that are meant to keep the system secure both before and after deployment. In practice, that means building systems that can check whether those rules hold in real time and block anything that would break them. New attack techniques then have to work around the same protective rules as everything else, which tends to make effective exploits rarer and harder to construct. "Code is law" becomes "spec is law": the system's behavior is bounded by its specification, not solely by whatever code happened to be deployed at launch.

Reaching that model requires the ability to improve a system over time, adding guardrails, tightening properties, and responding as the environment changes. That is what upgradability is for. Immutable code cannot grow into that model on its own; upgradeable design can, provided the upgrade process itself is disciplined.

What Institutional Allocators Should Evaluate

Traditional finance already thinks in terms of operational risk: systems change, and someone is accountable for how they change. Upgradeable smart contracts are a version of the same idea. For institutional allocators, the practical takeaway is that a one-off audit at launch is not enough on its own. What matters is understanding how upgrades are approved and executed, who holds the keys, and what transparency exists when a change happens. Protocols that publish upgrade proposals with clear explanations, enforce real timelocks, and route execution through a credible multi-sig are treating upgradability as a governed capability, one that lets them improve security and respond to a changing environment without quietly abandoning the system's original commitments.

The goal is not to chase an imaginary, perfectly immutable system that does not need to change. It is to recognize that upgradability exists because it has to, and to insist that where it exists, it is constrained, visible, and accountable to someone. Orion's private security research program is one part of building that accountability in practice, ongoing adversarial testing that feeds directly into what gets patched and when. The layered-permissioning argument in Orion's research on permissionless consensus is related: both pieces are about deciding, deliberately, which layer of a system is allowed to change and under whose authority.

References

Bankless (2026). AI Finds 70% of Smart Contract Exploits. Podcast episode with Alpin Yukseloglu (Paradigm).
a16z (2026). Big Ideas 2026, Part 3. Section on DeFi security and "spec is law" by Daejun Park.

Frequently Asked Questions

Why can't DeFi rely on immutability alone?: Launch-time audits cannot anticipate every future attack technique. When bytecode is fixed, a team cannot patch disclosed vulnerabilities, add runtime guardrails, or respond to methods discovered by increasingly capable automated tooling, regardless of how thorough the original audit was.
What does "spec is law" mean?: Instead of trusting only the code written at deployment, the system's permitted behavior is bounded by a specification enforced at runtime. New attacks have to work around the same protective rules as everything else, which tends to make effective exploits rarer and harder to repeat.
What should institutional allocators evaluate about upgradability?: Who holds upgrade keys, how proposals are approved, what timelocks apply, and what transparency exists when changes execute. Operational risk in traditional finance already covers how systems evolve; upgradeable smart contracts raise the same question in a new setting.
Does upgradability contradict decentralization?: Not necessarily. An upgrade path routed through credible multi-sig governance, published rationales, and enforced delays can function as a governed feature rather than an opaque admin backdoor.
How does AI change the upgrade calculus?: As automated exploit discovery improves, the cost of immutability rises, since a fixed system cannot respond to a growing set of newly discovered techniques. Defenders need the ability to harden a system after launch, the same reason even maximally conservative chains eventually face moments where their own rules have to change to preserve their purpose.
Is a one-off audit at launch enough?: Recent exploits against diligent, well-audited protocols suggest it typically is not. Institutions should expect continuous work, monitoring, incident response, and governed upgrade paths, as part of the security posture.
Who should hold the keys to an upgrade process?: There is no single correct answer, but the pattern that tends to hold up is a credible multi-sig with published membership, combined with enforced timelocks. The specific structure still depends on the protocol's own risk profile and governance maturity.
Can a protocol be too conservative about upgrading?: Yes. A protocol that refuses to patch known issues out of a commitment to immutability is treating a design principle as more important than the outcome it was meant to protect. The harder, more useful discipline is upgrading deliberately and transparently, not avoiding upgrades altogether.