🧩 WHY STONfi CAN UPGRADE THE ROUTER BUT NOT YOUR POOL
In DeFi, “upgradeable” can sound simple. On STONfi, it is not. Router and Pool have different upgrade models because they do different jobs.
➡ THE ROUTER IS THE MOVING PART
The Router is the DEX entrypoint. It receives Jetton messages, decodes swap instructions and forwards them to the correct pool. It does not store pair-specific reserves or pricing state.
That makes the Router the logical place for evolution. STONfi can change routing logic without rewriting existing pool liquidity. But upgradeable does not mean instant: a Router code upgrade uses a two-phase process with a minimum seven-day delay, while pending state remains publicly visible.
➡ A POOL IS DIFFERENT
A Pool contains the state that actually belongs to a pair: reserves, fees and AMM pricing logic. Once deployed, its code does not get replaced through the Router.
The key TON detail is that the Router stores the pool code template, while a pool address is derived from its code and initial state. Changing that template does not upgrade an existing pool; it creates a different pool at a different address.
Liquidity deposited under one pool's rules stays governed by those rules. New pool designs can coexist instead of forcing every LP into migration.
➡ THE PART DEVELOPERS SHOULD NOT MISS
Not every change requires an upgrade. The Router can adjust pool fees and lock or unlock trading without replacing its code. For integrators, do not hardcode a Router address; resolve the current Router through the API because it can change.
The architecture is easier to understand as a separation of responsibilities:
Router = upgradeable coordination layer.
Pool = persistent market state.
The security property is not simply immutability really, either. It is separating the contract that can evolve from the one holding liquidity state.
NFA - DYOR
$BTC
In DeFi, “upgradeable” can sound simple. On STONfi, it is not. Router and Pool have different upgrade models because they do different jobs.
➡ THE ROUTER IS THE MOVING PART
The Router is the DEX entrypoint. It receives Jetton messages, decodes swap instructions and forwards them to the correct pool. It does not store pair-specific reserves or pricing state.
That makes the Router the logical place for evolution. STONfi can change routing logic without rewriting existing pool liquidity. But upgradeable does not mean instant: a Router code upgrade uses a two-phase process with a minimum seven-day delay, while pending state remains publicly visible.
➡ A POOL IS DIFFERENT
A Pool contains the state that actually belongs to a pair: reserves, fees and AMM pricing logic. Once deployed, its code does not get replaced through the Router.
The key TON detail is that the Router stores the pool code template, while a pool address is derived from its code and initial state. Changing that template does not upgrade an existing pool; it creates a different pool at a different address.
Liquidity deposited under one pool's rules stays governed by those rules. New pool designs can coexist instead of forcing every LP into migration.
➡ THE PART DEVELOPERS SHOULD NOT MISS
Not every change requires an upgrade. The Router can adjust pool fees and lock or unlock trading without replacing its code. For integrators, do not hardcode a Router address; resolve the current Router through the API because it can change.
The architecture is easier to understand as a separation of responsibilities:
Router = upgradeable coordination layer.
Pool = persistent market state.
The security property is not simply immutability really, either. It is separating the contract that can evolve from the one holding liquidity state.
NFA - DYOR
$BTC
