Sui fixed a withdrawal panic on mainnet last week. Protocol 126 is the hardening cycle it triggered.
A node that panics instead of failing cleanly has a deeper problem than the patch that fixed it. MystenLabs is now working the withdrawal and epoch paths properly.
CryptoVibe Desk · sui · protocol · validators
- →On May 29, Sui shipped two emergency mainnet releases: v1.72.4 fixed a panic bug in withdrawal settlement, and v1.72.5 added a break-glass lever to force-close a stuck epoch.
- →Both failures were edge cases that should have returned clean errors but instead crashed or wedged the network, pointing to gaps in error-handling coverage on critical paths.
- →Watch whether Protocol Version 126 reaches mainnet before the end of June without a follow-up emergency release on the withdrawal or epoch-close paths, which would confirm the hardening held.
- epoch → A fixed time window on Sui during which validators process transactions together; at the end, they agree on the final state before starting the next window.
- panic (in software) → When a program hits an unexpected state and crashes completely rather than returning an error that other code can handle.
- Protocol Version → A number that tracks breaking changes to Sui's core rules; all nodes must agree on the same version to stay in sync with the network.
- settlement → The final step of transaction processing where gas fees are deducted and a transaction's effects are written to account balances.
Sui's settlement code panicked on a withdrawal edge case on May 29. Not an error return. A crash.
v1.72.4 explains what happened: a transaction tried to withdraw more than its account held, and the settlement layer hit an unhandled state. Instead of returning an error and charging zero gas, it crashed. After the patch, those transactions fail cleanly with zero gas charged. Before: crash. After: predictable error. That's the correct behavior. It just wasn't wired up.
The same day, v1.72.5 added `force_epoch_close`. This is a break-glass lever for a specific failure: a validator set that gets wedged and can't advance to the next epoch. When that happens, an operator can force the epoch closed at a pinned consensus commit index. The release notes say it's no-op when unset, which is the right design. But an operator tool for closing a stuck epoch is still a centralization point, and that's the catch. The lever is invisible in normal operation. The tradeoff only shows up in the one moment you actually need it.
Two emergency releases in 24 hours doesn't prove the protocol is fragile. It means two separate edge cases surfaced together and MystenLabs patched both quickly. That's fine incident response. The harder question is why both failure modes reached mainnet without clean error handling in the first place.
Testnet-v1.73.1 now ships with Protocol Version 126, per the release notes, carrying the withdrawal fix into the formal protocol version cycle. The difference between a hotfix and a hardening cycle is exactly this. A hotfix closes the immediate hole. A protocol version bakes the fix into the canonical state machine. This is the follow-through.
If you're building against Sui's withdrawal path or running a validator, read the `force_epoch_close` spec now. It's no-op today. It won't be the day you need it.
MystenLabs is shipping Protocol 126 without a public post-mortem on the May 29 failures. That's the gap. Validators who need `force_epoch_close` won't know if it covers all stuck-epoch cases or only the one from May 29.
If Protocol Version 126 reaches Sui mainnet before the end of June without triggering a follow-up emergency release on the withdrawal or epoch-close paths, the hardening held.
Primary links and supporting reads used by the desk for this story.
Forward this.
