Sui Foundation launches on-chain community vote in response to Cetus security incident
TechFlow Selected TechFlow Selected
Sui Foundation launches on-chain community vote in response to Cetus security incident
Voting "in favor" indicates support for implementing a protocol upgrade that would transfer the funds frozen due to the Cetus attack to a wallet controlled by a multi-signature.
Navigating Web3 tides with focused insightsAuthor: Sui Network
Cetus has requested a community-led vote to recover funds frozen during last week's attack. In response, the Sui Foundation has agreed to assist in initiating a vote among Sui validators, who represent the interests of their stakers and the entire network. SUI holders and stakers can also participate directly in the vote through stake delegation.
🗳️ Cetus:
https://x.com/CetusProtocol/status/1926021460214026568
This proposal involves a protocol upgrade to reclaim all funds currently frozen in two hacker addresses without requiring signatures from the hackers. If approved, these funds will be transferred and held in a multi-signature escrow wallet until they can be returned to accounts that held positions in Cetus. This protocol upgrade is part of a broader Cetus recovery plan, which also includes using Cetus treasury funds and a loan from the Sui Foundation to ensure full asset restitution for all affected users.
🌟 Cetus Proposal:
https://github.com/MystenLabs/sui/pull/22237
Voting begins at 1:00 PM Pacific Time on Tuesday, May 27 (4:00 AM Beijing Time on May 28). The vote will last up to 7 days but may end early after a minimum of 2 days if the outcome is determined in advance.
How to Participate in the Vote
How to Check Current Vote Status
The block explorer Space and Time has launched a dedicated voting page to track validator voting decisions and current staking status. To remain neutral, the Sui Foundation’s stake share will be excluded.
🗳️ Voting Link:
Voting results as of 10:38 (GMT+8) on May 28
For SUI Holders and Stakers
You can express your position by delegating your stake to validators whose voting stance aligns with yours. Refer to the link above to see how each validator is voting.
-
You can stake, unstake, or redelegate using wallets or browsers. For guides on multiple wallets, visit: https://www.notion.so/mystenlabs/Staking-with-the-popular-Sui-wallets-2006d9dcb4e980b3b29dc09f203bd61c. Beware of fake voting sites and never disclose your private key: https://blog.sui.io/private-key-security
-
Voting code and tools: Source code and utilities related to voting are available at https://github.com/sui-foundation/recovery-vote; Mainnet voting package ID: 0x4eb9c090cd484778411c32894ec7b936793deaab69f114e9b47d07a58e8f5e5d
Instructions for Validators
Please visit the following page to learn how to create and sign a voting transaction:
https://github.com/sui-foundation/recovery-vote
Voting Process
Sui is a decentralized system governed via a Delegated Proof-of-Stake (DPoS) mechanism. SUI holders delegate their stake to trusted validators, expecting them to operate correctly and represent their preferences in governance matters such as protocol parameters and upgrades.
When validators vote, they represent not only themselves but also SUI holders and stakers.
Detailed Voting Mechanism
-
The vote occurs via a transparent Sui smart contract that records and tallies staked amounts for each voting position
-
Voting start time: 1:00 PM Tuesday, May 27 (PST), equivalent to 4:00 AM Beijing Time on May 28
-
Voting duration: Up to 7 days
-
Validator voting options: "yes", "no", or "abstain". Votes are final once submitted and cannot be changed
-
Voting weight is determined by validator stake amount, excluding the Sui Foundation’s stake
-
Stakers are encouraged to delegate to validators aligned with their position
-
Proposal passes if:
(1) Over 50% of total stake (excluding abstentions) participates in the vote
(2) "Yes" votes outweigh "No" votes in staked weight
-
If remaining unvoted stake cannot alter the outcome and the minimum 2-day period has passed, voting may end early
-
If no conclusion is reached by 11:30 AM PST on June 3 (2:30 AM Beijing Time on June 4), the vote will close and no protocol upgrade will occur
In summary, anyone holding or staking SUI can participate by delegating their stake to a validator that shares their position.
The above outlines the voting process; authoritative details are defined in the smart contract source code. The voting contract and validator voting tools' source code are available here. The Move package has been published (viewable on SuiScan, SuiVision), and validators may vote using CLI tools and their validator account private keys.
Source Code:
https://github.com/sui-foundation/recovery-vote
SuiScan:
SuiVision:
https://suivision.xyz/package/0x4eb9c090cd484778411c32894ec7b936793deaab69f114e9b47d07a58e8f5e5d
Proposal: Return Stolen Funds via Protocol Upgrade
Voting "yes" supports introducing a protocol upgrade that would transfer funds frozen due to the Cetus attack into a multi-signature controlled wallet. These funds will be held in trust until Cetus returns them to affected accounts.
This Cetus trust wallet will be a 4-of-6 multi-sig: Cetus holds 2 keys; Sui Foundation holds 2 keys; OtterSec (a trusted audit entity within the Sui community) holds 2 keys. The wallet address will be published later.
The expected responsibilities of each signer are as follows: Cetus will propose and sign transactions according to its recovery plan; OtterSec will verify that transactions align with the publicly stated plan and sign only when compliant; the Sui Foundation will not sign any transaction unless other signers are unable to complete the required signatures.
Voting "no" indicates opposition to introducing this protocol upgrade.
Technical Details of the Protocol Upgrade
The specific technical details of the protocol upgrade are as follows:
-
A designated address will be permitted to act on behalf of each of the two hacker addresses in exactly two predefined transactions.
-
In other words, two (hacker_address, aliased_address, TransactionDigest) tuples will be specified. For each tuple, the aliased_address is allowed to represent the hacker_address only in that specific transaction.
-
This mechanism applies exclusively to these two recovery transactions and cannot be used for any other purpose.
-
Once the recovery addresses are finalized, the two transactions will be constructed and published.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Sui Network
