←Back to Blog

Smart Contract Upgradability: Why DeFi Needs the Ability to Evolve

Smart Contract Upgradability: Why DeFi Needs the Ability to Evolve
6 min read3/11/2026

“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)

This quote, from a conversation about how quickly AI is getting better at finding and exploiting smart contract bugs, cuts at the heart of the design choices we make at Orion.

This post makes the case for upgradability: why it exists, why the arms race demands it, and why "code is law" alone is not enough.

Why Upgradability Exists

The original smart contract ideal was simple: code is law, and code doesn’t change. If nobody can rewrite the rules, nobody can cheat. A system that can never adapt sounds pure on paper, but it leaves you with no options when something breaks (and financial markets are full of unknown unknowns).

The pressure to stay adaptable has only intensified. AI is getting better at finding and exploiting smart contract bugs, faster than many in crypto have prepared for. Benchmarks like EVMBench, which tests whether AI agents can detect, patch, and exploit real fund-draining bugs, have seen a dramatic jump: from roughly 12-13% exploit-finding rates to well over 70%. That shift doesn’t just mean more bugs get found; it reframes the game. If the code can never change, the defenders have one hand tied behind their backs.

Real-world events have already signalled this. Balancer’s protocol was widely considered battle-tested, precisely the kind of system where you might assume you don’t need a pause button or a clear upgrade path. When a serious exploit appeared, they could not pause; the system had been built and operated on the belief that it was already secure. The exploit could take place because the ability to react had not been prioritised. The incident is a reminder that "battle-tested" is a snapshot in time. Attack techniques evolve; so must the ability to respond.

The same logic applies to the most immovable system in crypto: Bitcoin. Its proof-of-work design is often held up as the gold standard of "code is law" and minimal change. Yet when quantum computing eventually threatens the underlying cryptography, Bitcoin will have to upgrade. That upgrade will not be decided by in-protocol mechanisms. It will be decided by social consensus, the community agreeing that the rules have to change to preserve what the system is for. In other words, even the most immutable chain faces a moment where staying relevant means accepting that the rules can, and must, evolve. The question is whether that evolution is planned and governable, or chaotic and reactive.

Upgradability in DeFi is the same idea in a different context. It is not a betrayal of immutability; it is the only realistic way to keep playing the game when the other side keeps getting better.

From "Code Is Law" to "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 underlines an uncomfortable reality: today's standard security practice is still largely heuristic and case-by-case. You can't assume every bug was caught at launch.

The industry is moving away from patching individual bugs toward enforcing clear, design-level safety rules-principles that keep the whole system secure both before and after it's deployed. In practice, that means building systems that can check whether those rules are followed in real time and block anything that breaks them. Even new kinds of attacks then have to work around the same protective rules, making effective exploits much rarer and harder. The "code is law" mindset becomes "spec is law": the behaviour of the system is defined and limited by the specification, not just by the code that was written at launch.

Getting there requires the ability to improve. You need to be able to add those guardrails, tighten those properties, and respond when the environment changes. That is exactly what upgradability is for. Immutable code cannot grow into that model; upgradeable design can.

The Institutional Lens

Traditional finance already thinks in terms of operational risk: systems evolve, and someone has to be responsible for how they change. Upgradeable smart contracts are the same idea in a new form. For institutional allocators, the takeaway is that a one-off audit at launch is not enough. You need to understand how upgrades are approved, and executed; who holds the keys; and what transparency you get when changes happen. Protocols that publish upgrade proposals with clear explanations, enforce real timelocks, and route execution through a credible multi-sig are treating upgradability as a feature, one that lets them improve security and respond to a changing environment without abandoning the system.

The goal isn't to chase some imaginary perfectly immutable system. It's to recognise that upgradability is here because it has to be, and to insist that it is constrained, visible, and accountable.

Orion Finance Research

References