🏛 Router Upgradeability vs Pool Immutability in STONfi Architecture
STONfi separates contracts by responsibility. Pool contracts hold reserves and execute AMM logic, while the Router coordinates swaps and liquidity operations. The important point is which component can change, and why.
🔒 WHY POOLS ARE IMMUTABLE
Pool contracts contain reserves and core AMM pricing logic for a trading pair. Once deployed, their code cannot be modified. Existing liquidity therefore remains governed by the same pool logic.
- Core AMM logic stays fixed after deployment.
- Existing liquidity remains under the same deployed logic.
The trade-off is clear: an undiscovered bug cannot simply be patched inside that pool. Immutability removes a later upgrade path, but it does not prove that the original code is flawless.
🔧 WHY THE ROUTER IS UPGRADEABLE
The Router is the DEX entry point. It receives swap and liquidity messages and directs them to the appropriate Pool. Unlike Pools, it is designed to evolve.
Routing infrastructure can change as the ecosystem develops without replacing every existing pool.
But the process is not instant. Router upgrades use a seven-day timelock, giving users time to inspect a proposed change before activation.
⚖ TWO DIFFERENT TRUST MODELS
In simple terms:
Pool = fixed AMM and value-holding logic.
Router = adaptable coordination layer.
Pool immutability prevents later changes to deployed AMM logic. The Router's timelock preserves upgrade flexibility while making changes observable before activation. That distinction defines the trust model.
Neither property removes every risk. Immutable code can still contain bugs, while a timelocked Router upgrade still requires attention.
The key question is not whether STONfi is “immutable.” It is which contract is immutable, which is upgradeable, and what controls exist around that upgrade?
Not investment advice - research on your own! 🚀
$SOL
STONfi separates contracts by responsibility. Pool contracts hold reserves and execute AMM logic, while the Router coordinates swaps and liquidity operations. The important point is which component can change, and why.
🔒 WHY POOLS ARE IMMUTABLE
Pool contracts contain reserves and core AMM pricing logic for a trading pair. Once deployed, their code cannot be modified. Existing liquidity therefore remains governed by the same pool logic.
- Core AMM logic stays fixed after deployment.
- Existing liquidity remains under the same deployed logic.
The trade-off is clear: an undiscovered bug cannot simply be patched inside that pool. Immutability removes a later upgrade path, but it does not prove that the original code is flawless.
🔧 WHY THE ROUTER IS UPGRADEABLE
The Router is the DEX entry point. It receives swap and liquidity messages and directs them to the appropriate Pool. Unlike Pools, it is designed to evolve.
Routing infrastructure can change as the ecosystem develops without replacing every existing pool.
But the process is not instant. Router upgrades use a seven-day timelock, giving users time to inspect a proposed change before activation.
⚖ TWO DIFFERENT TRUST MODELS
In simple terms:
Pool = fixed AMM and value-holding logic.
Router = adaptable coordination layer.
Pool immutability prevents later changes to deployed AMM logic. The Router's timelock preserves upgrade flexibility while making changes observable before activation. That distinction defines the trust model.
Neither property removes every risk. Immutable code can still contain bugs, while a timelocked Router upgrade still requires attention.
The key question is not whether STONfi is “immutable.” It is which contract is immutable, which is upgradeable, and what controls exist around that upgrade?
Not investment advice - research on your own! 🚀
$SOL
