Router Upgradeability vs Pool Immutability in STON.fi Architecture Why STON.fi deliberately makes some contracts impossible to change while leaving exactly one upgradeable — and what that spl
Why STON.fi deliberately makes some contracts impossible to change while leaving exactly one upgradeable — and what that split actually buys you as a user.
Most explanations of smart contract security treat "immutable" as an unambiguous good and "upgradeable" as a slightly suspicious compromise. STON.fi's architecture pushes back on that framing in an interesting way: it doesn't choose one philosophy across the board. It splits its contracts deliberately, making some permanently frozen and one specifically flexible, and that split isn't an accident or an inconsistency — it's the actual design decision worth understanding if you want to know where your trust is really being placed when you use the protocol.
I want to walk through why this split exists, what each side of it actually protects against, and where the real trust assumption still sits once you've mapped the whole thing out. Because "audited and immutable" sounds like the end of the security conversation, and it really isn't — it's just the beginning of a more specific one.
I used to treat "immutable" as basically a synonym for "safe." Then I actually looked at what STON.fi leaves upgradeable, and realized the interesting question was never "immutable vs not" — it was "which specific piece, and why that one."
STON.fi's documentation describes its DEX architecture as a set of distinct contract types, each handling a specific responsibility rather than one monolithic contract doing everything. The router acts as the entry point, receiving incoming swap and liquidity messages and directing them to the correct pool. Pool contracts hold the actual reserves for a trading pair and execute the AMM pricing calculation. Account and wallet contracts track individual users' liquidity positions and handle LP token operations separately from either of the other two.
Separating responsibilities this way isn't just good software hygiene — it's what makes the immutability question answerable at all. You can't sensibly ask "is STON.fi upgradeable?" as a single yes/no question, because the honest answer is "some of it, very specifically, and not the parts you'd probably worry about most."
Pool contracts are where your actual deposited funds live, where the AMM pricing math happens, and where the core, high-stakes logic of the entire protocol sits. STON.fi's documentation states these contracts cannot be modified once deployed — no admin key, no upgrade path, no future version of the logic that could silently change how your funds are priced or handled.
This matters for a few concrete reasons. A pool that can't be modified can't have its logic quietly changed to redirect funds, alter fee splits unfavorably, or introduce a backdoor after you've already deposited — there's no rug-pull-via-upgrade vector to worry about at this layer. It also means what gets audited stays audited: a review like Trail of Bits' examination of STON.fi v2 looked at specific, immutable pool logic, and because that logic can't change afterward, the audit's findings remain permanently applicable to those exact contracts rather than describing a snapshot that might drift over time. And it buys genuine predictability — anyone who deposited liquidity a year ago is interacting with mathematically identical pool logic today, with no "the rules changed while my funds were locked in" risk sitting at this layer.
The trade-off, and it's a real one, is that immutability also means any undiscovered bug in the pool logic is permanent too. If something's wrong, it can't be patched in place — the only fix is deploying an entirely new pool and migrating liquidity into it manually, which is slower and messier than a simple upgrade would be. STON.fi's model accepts that trade-off deliberately: permanent correctness risk in exchange for permanently eliminated admin-override risk.
Immutability isn't "this contract is definitely bug-free." It's "if there's a bug, at least nobody can quietly make it worse on purpose."
The router is different, and deliberately so. STON.fi's architecture documentation identifies the router as the DEX's entry point and explicitly as the only upgradeable contract in the described architecture, with upgrades subject to a seven-day time-locked process rather than an instant change.
Why leave exactly this piece flexible when everything else is frozen? Because it's the coordination layer, not the value-holding layer — the router directs traffic and decides which pool a given swap request should reach, while pool contracts hold the actual reserves, so upgrading routing logic doesn't require touching the funds themselves. Ecosystems also evolve in ways routing logic needs to keep pace with: new pool types, new fee structures, integration with additional infrastructure like Omniston, all of which can require updates to how requests get directed without needing to touch the immutable pools those requests eventually reach. And fixing a routing-level bug shouldn't require migrating every pool in the ecosystem — if a flaw is discovered in how the router directs traffic, as opposed to a flaw in AMM math itself, an upgrade path lets that get fixed without asking every liquidity provider to move their funds to freshly deployed pools.
The seven-day time lock is the mechanism that makes this flexibility tolerable rather than alarming. Any proposed router upgrade has to sit publicly visible for a full week before it activates, giving developers, security researchers, and attentive users a real window to inspect the change and react — withdraw, raise concerns publicly, or simply pay closer attention — before it goes live.
A router upgrade with no delay would just be an admin key with extra steps. Seven days is what turns "trust us" into "verify us, you actually have time."
This is the part worth being precise about, because a clean architectural split doesn't automatically mean every risk is eliminated. The design genuinely protects a few specific things: your deposited funds' core pricing logic can't be altered after the fact, since the math determining your swap output or your LP share's behavior is permanently fixed the moment a pool deploys. Router changes can't take effect instantly or silently either, since the seven-day window guarantees a public gap between an upgrade being proposed and it actually going live. And an audit of pool logic remains valid indefinitely, rather than needing constant re-verification, precisely because the audited logic literally cannot change underneath it.
But it's equally worth naming what this split does not eliminate. Router upgrades still represent a real trust point, even with the time lock — the seven-day window gives you the opportunity to notice and react to a bad upgrade, but it doesn't guarantee anyone actually will in time, especially users who aren't actively watching governance activity. The router's own administrative capabilities matter too: STON.fi's architecture documentation notes it handles matters related to trading, pool fees, and upgrades, meaning even a well-intentioned router change touches genuinely consequential levers, not just cosmetic routing logic. And immutable pools can still contain undiscovered bugs — immutability guarantees the logic won't be maliciously changed later, but it says nothing about whether the original logic was flawless to begin with. That's precisely what audits are for, and audits have their own limits regardless of what they examined.
The time lock buys you a warning. It doesn't buy you a guarantee that you'll actually read it in time, or that seven days is always enough runway to act.
Understanding the split changes what's actually worth watching, rather than treating "STON.fi" as one undifferentiated black box you either trust entirely or don't:
Treat pool-level audit findings as durable, since a review stays relevant for as long as the pool exists precisely because it can't be silently altered afterward
Pay closer attention specifically during router upgrade windows, since that seven-day period is exactly the moment worth reading proposed changes rather than skimming past a governance notice as routine noise
Understand that "non-custodial" and "no admin risk at all" aren't the same claim — pool immutability handles one category of risk thoroughly, while router upgradeability still requires a baseline of trust in the process
Remember bug risk persists at the pool level regardless of upgrade policy, since no architecture decision substitutes for genuine security review of the original code
None of this is meant to make STON.fi's design sound worse than it is — quite the opposite. A protocol that pretended everything was equally immutable, with no mechanism at all for fixing routing-layer issues over time, would eventually face a much worse problem: either staying permanently stuck with a routing flaw, or resorting to the messy, disruptive process of migrating an entire ecosystem to a freshly deployed system just to patch something that didn't need to touch user funds at all.
What this architecture really demonstrates is that "immutable" and "upgradeable" aren't competing philosophies where one is simply correct — they're tools suited to different jobs within the same system. Value-holding, fund-pricing logic benefits enormously from being frozen solid, because the cost of a maliciously altered pool is catastrophic and irreversible in the worst way. Coordination and routing logic benefits from staying flexible, because ecosystems evolve and rigid infrastructure eventually becomes a liability of its own, unable to adapt without painful, disruptive migrations.
The genuinely good design decision here isn't "make everything immutable" or "keep everything flexible" — it's correctly identifying which category each specific contract falls into, and applying the right constraint to each one individually rather than a single blanket policy applied out of either excessive caution or excessive convenience. STON.fi's split between locked-down pools and a time-locked, transparently-upgradeable router is exactly that kind of deliberate, considered choice, and it isn't unique to STON.fi either — plenty of mature DeFi protocols across different chains arrive at some version of the same split once they've operated long enough to feel the pain of the alternative extremes. A fully immutable system eventually hits a routing bug or an integration need it simply cannot adapt to without a disruptive full migration. A fully upgradeable system, with no immutable core at all, asks users to trust an ongoing promise rather than a fixed, independently verifiable set of rules. Splitting the difference deliberately, rather than defaulting to one extreme out of ideology, is what separates a considered architecture from one that just picked a philosophy and stuck with it regardless of the actual trade-offs involved.
The interesting question was never "immutable vs upgradeable." It's "which specific piece, and why that one" — and once you can answer that, you understand the protocol's actual risk profile instead of a one-word label.
Can STON.fi's pool contracts ever be changed after deployment? No. STON.fi's documentation describes pool contracts as immutable — the core AMM pricing logic and reserve-handling code cannot be modified once a pool is deployed, permanently locking in whatever logic was originally reviewed and deployed.
What can actually be upgraded in STON.fi's architecture? Only the router contract, which serves as the entry point directing swap and liquidity requests to the appropriate pools. It's explicitly the one upgradeable component, and any proposed upgrade goes through a seven-day time-locked process before activating.
Does router upgradeability mean STON.fi has an admin backdoor to user funds? The router doesn't hold user reserves directly — pool contracts do, and those are immutable. Router upgrades affect trading, fee, and routing logic rather than directly seizing deposited funds, and any change is subject to the public time-lock window before taking effect.
Does pool immutability guarantee there are no bugs in STON.fi's contracts? No. Immutability means the deployed logic cannot be maliciously altered afterward — it says nothing about whether the original code was flawless. That's precisely the role of independent security audits, which examine the logic before and at deployment, not a guarantee immutability provides on its own.
