Voting "Yes" indicates support for introducing a protocol upgrade that will transfer the funds frozen due to the attack on Cetus to a wallet controlled by multi-signature.
Author: Sui Network
Cetus has requested to initiate a community-led vote to recover the funds frozen during last week's attack. In response, the Sui Foundation agreed to assist in initiating a vote among Sui validator nodes, which represent the interests of their staked users and the entire network. Sui token holders and stakers can also participate in the vote directly through staking delegation.
🗳️ Cetus:
https://x.com/CetusProtocol/status/1926021460214026568
This proposal is to execute a protocol upgrade that will recover all funds currently frozen in two hacker addresses without requiring the hacker's signature. If the proposal passes, these funds will be transferred and held in a multi-signature custody wallet until they can be returned to accounts that had holdings in Cetus. This protocol upgrade proposal is part of a larger recovery plan for Cetus, which also includes utilizing Cetus treasury funds and obtaining loans from the Sui Foundation to ensure the integrity of all account users' assets.
🌟 Cetus Proposal:
https://github.com/MystenLabs/sui/pull/22237
Voting starts at: 1:00 PM Pacific Time on May 27 (which is 4:00 AM Beijing Time on May 28). Voting will last for up to 7 days and can end early if the results are determined after a minimum of 2 days.
How to Participate in Voting
How to Check the Current Voting Status
The block explorer Space and Time has set up a dedicated voting page to track the voting decisions of validator nodes and the current staking status. To maintain neutrality, the Sui Foundation's staking share will be excluded.
🗳️ Voting Link:
As of May 28, 10:38 (GMT+8) voting results
For Sui Token Holders and Stakers
You can express your position by transferring your stake to a validator node that aligns with your voting preference. Check the link above to see the voting status of each validator node.
You can use a wallet or browser to stake, unstake, or transfer your stake. For guides on multiple wallets, please refer to: https://www.notion.so/mystenlabs/Staking-with-the-popular-Sui-wallets-2006d9dcb4e980b3b29dc09f203bd61c. Be cautious of fake voting websites and never disclose your private key: https://blog.sui.io/private-key-security
Voting code and tools: Source code and tools related to voting can be found at https://github.com/sui-foundation/recovery-vote; Mainnet voting package ID: 0x4eb9c090cd484778411c32894ec7b936793deaab69f114e9b47d07a58e8f5e5d
Instructions for Validator Nodes
Please visit the following page to see how to create and sign voting transactions:
https://github.com/sui-foundation/recovery-vote
Voting Process
Sui is a decentralized system governed by a Delegated Proof of Stake (DPoS) mechanism. Sui token holders delegate their stakes to trusted validator nodes, hoping these nodes will operate correctly and represent their will in governance matters (such as protocol parameters and upgrades).
When validator nodes vote, they represent not only themselves but also the Sui token holders and stakers.
Voting Mechanism Details
Voting is conducted through a transparent Sui smart contract that records and counts the amount of staked votes for each position.
Voting start time: May 27, Tuesday, 1:00 PM (PST) (which is 4:00 AM Beijing Time on May 28).
Voting duration: up to 7 days.
Validator node voting options are: "Yes," "No," "Abstain." Once submitted, votes cannot be changed.
Voting weight is determined by the amount staked by the validator nodes, excluding the Sui Foundation's staking share.
Stakers are encouraged to delegate their stakes to validator nodes that align with their position.
Conditions for proposal approval:
(1) More than 50% of the total staked amount (excluding abstentions) participates in the vote.
(2) The weight of "Yes" votes exceeds the weight of "No" votes.
If the remaining unstaked votes can no longer affect the final result and the minimum duration of 2 days is met, voting can end early.
If no conclusion is reached by 11:30 AM PST on June 3 (2:30 AM Beijing Time on June 4), voting will close, and no protocol upgrade will occur.
Ultimately, as long as you hold SUI or have staked SUI, you can participate in the vote by delegating your stake to a validator node that aligns with your position.
The above voting process is a general overview; authoritative descriptions are based on the smart contract source code. The source code for the voting contract and validator node voting tools can be viewed here, and the Move package has also been released (available on SuiScan and SuiVision), allowing validator nodes to vote using CLI tools and their validator node account private keys.
Source Code:
https://github.com/sui-foundation/recovery-vote
SuiScan:
SuiVision:
https://suivision.xyz/package/0x4eb9c090cd484778411c32894ec7b936793deaab69f114e9b47d07a58e8f5e5d
Proposal: Return Stolen Funds through Protocol Upgrade
Voting "Yes" indicates support for introducing a protocol upgrade that will transfer the funds frozen due to the attack on Cetus to a wallet controlled by multi-signature. These funds will be held in trust until Cetus returns them to the affected accounts.
The Cetus trust wallet will be controlled by a multi-signature wallet requiring 4 out of 6 signatures: Cetus holds 2 keys; the Sui Foundation holds 2 keys; OtterSec (a trusted auditing agency within the Sui community) holds 2 keys. The wallet address will be announced later.
The expected responsibilities of each signatory are as follows: Cetus will propose and sign transactions based on its determined recovery plan; OtterSec will verify that the transactions align with the publicly stated plan intentions and sign if compliant; the Sui Foundation will not sign any transactions unless the other signatories are unable to complete the signatures.
Voting "No" indicates opposition to introducing this protocol upgrade.
Technical Details of the Protocol Upgrade
The specific details of the protocol upgrade are as follows:
A specific address will be allowed to act on behalf of the two hacker addresses in only two predefined transactions (one transaction for each address).
In other words, we will specify two (hackeraddress, aliasedaddress, TransactionDigest) tuples. For each tuple, the aliasedaddress is only permitted to act as the hackeraddress in the specific transaction.
This mechanism is only applicable to these two recovery transactions and cannot be used for any other purposes.
Once the recovery addresses are finalized, these two transactions will be constructed and published.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
