Most providers treat upgradeability as a benefit. We see it as a tradeoff our customers shouldn't be forced to make, because the safest code is code that can't unexpectedly change. Your risk team will want to know if the code behind your users' trades can change after approval. API wrappers using facet-based proxies will answer yes, 0x answers no.
“Can the code behind your users’ approvals change after they’ve approved it?”
0x’S ANSWER?
No.
— immutable contracts with single-use, precise approvals.
/ ASK THE RIGHT QUESTION
Upgradeability on approvals is a liability
When users grant a token approval, they’re trusting the specific code that lies behind it. An upgradeable contract, such as the Diamond Proxy Pattern used by third-party API wrappers and other providers, means those users are also trusting every future upgrade and the keys that authorize it. Convenience today becomes a risk tomorrow.
0x previously used a diamond architecture and deliberately tore it out. Settlement now runs through immutable 0x Settler contracts: behavior can’t change after approval, the blast radius stays chain-local.
When allowances are involved, upgradeability is an anti-pattern. And multiple upgradeability, as with a diamond proxy pattern, compounds it.
/ TWO PHILOSOPHIES
Upgradeable versus immutable
What each design optimizes for and why 0x prioritises security through simplicity.
DESIGN PRINCIPLE
OPTIMIZES FOR
0x’S STANCE
Upgradeability
Flexibility & feature velocity
Declined
Immutability
Security & reduced trust assumptions
Chosen
Complexity
Extensibility (at audit cost)
Declined
Simplicity
Auditability & reduced risk surface
Chosen
Patchability
Trust in future governance
Declined
Formal verification
Confidence in present correctness
Chosen
/ WHY WE DISCONTINUED DIAMOND PROXY PATTERN
Four risks you inherit with a facet-based proxy
01
Combinatorial complexity
Auditors must reason about every separate implementation contract (facet), the interactions between them, and the upgrade and routing logic, not a single implementation.
02
Larger attack surface
Removing the 24kB contract-size ceiling invites much bigger codebases; risk compounds with complexity.
03
Cascading blast radius
On a multi-chain facet-based system, one dispatcher or facet bug can cascade across every chain it spans (see the ~$8M LI.FI exploit, July 2023).
04
Upgrade risk on top of approvals
An allowance trusts not just today’s code, but every future upgrade and the keys that authorize it.
Every provider has audits to show you, but not everyone has answers to the questions that matter. We do.
Are your core contracts upgradeable? Can behavior change after a user grants approval?
+
No. Settlement runs through immutable Settler contracts. The active deployment address can rotate, but each deployed contract is immutable and resolved at request time. The code behind an approval cannot change underneath the user.
How many upgrade paths exist, and who controls the upgrade keys?
+
No in-place upgrade path exists. Settler contracts are immutable. New features ship as newly deployed contracts, and that deployment is gated by a multisig, so no single key can change live code.
How is contract complexity measured and actively controlled over time?
+
We keep the on-chain surface intentionally small, making opinionated settlement choices instead of exposing configuration.
.png)