Why STON.fi's Seven-Day Router Upgrade Delay Does Not Remove Smart-Contract Risk
STON.fi still carries smart-contract risk after a Router upgrade is proposed. The seven-day delay only changes the timing: new Router code cannot go live the moment an administrator submits it.
🔥 What changes on-chain
- The admin calls init_code_upgrade with proposed Router code.
- The change stays pending for at least seven days.
- Finalize_upgrades can then complete it, or cancel_code_upgrade can stop it.
🚀 Why the warning window matters
Without a delay, a bad or unexpected Router replacement could activate immediately. With STON.fi's v2 rule, observers get time to read the pending state, compare versions, and react before finalization. get_router_data even exposes whether a temp_upgrade is pending.
🧠 The trade-off users should see
- Instant upgrade surprise is reduced.
- A buggy or harmful upgrade can still be finalized after the wait.
- Emergency patches are also slower because the same timer applies.
💬 What else is not covered by seven days
Pool contracts are described as immutable, so do not treat the whole DEX as freely upgradeable. An administrator change uses a two-day delay. Router lock status can block swaps and liquidity flow through that Router, but locking is not the same as instantly replacing code.
My take: treat the STON.fi Router delay as a response window. The clock helps only if someone actually watches the pending upgrade and decides what to do before it can be finalized.
Would a seven-day STON.fi Router wait make you more likely to stay in a pool or more likely to review first? 👇
Share the first signal you would look for if a Router upgrade went pending.
Not investment advice - research on your own! 🚀
$GRAM @STONfi DEX
STON.fi still carries smart-contract risk after a Router upgrade is proposed. The seven-day delay only changes the timing: new Router code cannot go live the moment an administrator submits it.
🔥 What changes on-chain
- The admin calls init_code_upgrade with proposed Router code.
- The change stays pending for at least seven days.
- Finalize_upgrades can then complete it, or cancel_code_upgrade can stop it.
🚀 Why the warning window matters
Without a delay, a bad or unexpected Router replacement could activate immediately. With STON.fi's v2 rule, observers get time to read the pending state, compare versions, and react before finalization. get_router_data even exposes whether a temp_upgrade is pending.
🧠 The trade-off users should see
- Instant upgrade surprise is reduced.
- A buggy or harmful upgrade can still be finalized after the wait.
- Emergency patches are also slower because the same timer applies.
💬 What else is not covered by seven days
Pool contracts are described as immutable, so do not treat the whole DEX as freely upgradeable. An administrator change uses a two-day delay. Router lock status can block swaps and liquidity flow through that Router, but locking is not the same as instantly replacing code.
My take: treat the STON.fi Router delay as a response window. The clock helps only if someone actually watches the pending upgrade and decides what to do before it can be finalized.
Would a seven-day STON.fi Router wait make you more likely to stay in a pool or more likely to review first? 👇
Share the first signal you would look for if a Router upgrade went pending.
Not investment advice - research on your own! 🚀
$GRAM @STONfi DEX
