Sui just fixed a transaction bug before it hit users. Reliability is moving into the code.
Protocol v130 is a pre-release, but the shape is clear: fewer recovery paths should depend on validators doing the right thing by hand.

CryptoVibe Desk · sui · protocols · validators

- →MystenLabs published Sui devnet-v1.76.0 on July 20, with Protocol v130 fixing a specific withdraw deadlock.
- →The bigger shift is automatic fork recovery, but only after the network certifies the correct outcome.
- →Watch whether testnet takes v130 within 6 weeks, with the withdraw fix and fork recovery still included.
- devnet → A devnet is an early testing network where teams ship changes before they reach normal users.
- consensus commit → A consensus commit is the moment validators agree on a batch of transactions and lock in the result.
- fork recovery → Fork recovery is how a validator gets back onto the accepted chain after its local view splits from the network.
Sui Protocol v130 fixes a deadlock before mainnet sees it.
MystenLabs published devnet-v1.76.0 on July 20, according to its GitHub release notes. The release is marked as a pre-release, so this is not live on mainnet. Sui mainnet is still on Protocol v129 as of the July 15 mainnet-v1.75.2 release.
The narrow bug is in object-funds withdraw accounting. The old model tracked a running maximum of withdraw amounts. Protocol v130 moves that accounting to per-account net amounts from transaction effects. In plain English: if one transaction both deposits and withdraws, that offset should not block another withdraw from the same account in the same consensus commit.
That sounds small because good accounting bugs usually do. At the contract level, this is a concurrency problem. Parallel execution only works if the bookkeeping understands which operations actually conflict. If you're building on Sui's object-funds model, this is the kind of fix you want before a user turns it into a stuck path.
The larger change is fork recovery. The new release adds automatic validator recovery on restart when the network has certified the canonical outcome and a new binary is deployed. That qualifier matters. Forks caused by the currently running binary, or forks without a certified outcome, still halt the node and need operator overrides or corrected code.
So this is not magic self-healing. It is narrower and more useful. Sui is moving one class of known recovery work out of human runbooks and into node behavior. The tradeoff is less operator discretion for more protocol-enforced correctness.
The same release removes the admission-queue-bypass-fraction escape valve. All transactions now go through the gas-price priority queue. The release notes say the old config field is ignored if it remains, but should be deleted. That is a quiet reliability tell: fewer special paths means fewer weird states under load.
Protocol v130 also stabilizes filtered subscription APIs for checkpoints, transactions, and events. Indexers care about that because filtered streams are how apps avoid drinking the whole firehose. But the only number that matters here is 130, because it marks the next protocol package after mainnet's v129.
Read the PR diff, not the thread, when it lands beyond devnet. The announcement says reliability. The mechanics say something sharper: Sui is treating parallel execution as a system that needs fewer operator choices when it fails.
MystenLabs' choice to put certified fork recovery into validator restart logic is correct because parallel chains cannot scale if every known split becomes a manual operator drill.
Within 6 weeks, watch whether Sui testnet ships Protocol v130 with both the net-withdraw accounting change and automatic fork recovery still present.
Primary links and supporting reads used by the desk for this story.
Forward this.











