[Crab Chain] Sunset Preparation & Establishment of Alternative Liquidation Governance Process

[hackfisher]

Summary

This proposal aims to align Crab Chain with the strategic direction outlined by RingDAO. It seeks formal community approval to commence the sunsetting process of Crab Chain and introduces a lightweight, Alternative Governance Process to handle the subsequent liquidation steps efficiently and cost-effectively.

Important Note on Execution

• Current Proposal: This specific proposal will be submitted and voted upon via the standard Crab Chain On-Chain Referenda (accessible via Polkadot.js) to ensure legitimate authorization.
• Future Proposals: Once this framework is approved, subsequent liquidation-related proposals will utilize the lightweight Alternative Governance Framework described below.

Context & References

• RingDAO Proposal: 0x3efafbbbeaf172f9a45c3826fc97135817e28c04c01bb7d6399e065a469870a9
• Community Discussion: RingEcosystem Discussion #39

---

Proposal Content

1. Acceptance of RingDAO Sunset Plan

We propose to formally accept the guidance provided by RingDAO regarding the shutdown of Crab Chain. By approving this proposal, the community agrees to:

• Officially initiate the preparation work for closing Crab Chain.
• Minimize technical maintenance and governance costs during this transition.
• Prioritize the preservation of asset value over complex governance formalities.

2. Establishment of Alternative Governance Framework

To ensure the sunset process (including Treasury liquidation) is accessible, transparent, and low-cost, we establish the following Alternative Governance Framework for all future liquidation-related decisions.

A. Venue & Naming Standards

• Platform: Future proposals will be published and discussed on the RingEcosystem GitHub Discussions (link). This will serve as the primary space for communication and result announcements.

• Naming Convention: To maintain clear organization, all future proposal titles must strictly follow this format:
  [Crab Sunset][Coin or Token Group][Proposal-ID]

  Example: [Crab Sunset][CRAB+gCRAB][Proposal-1]

B. The Mechanism: Snapshot-Based On-Chain Signaling

This process utilizes historical block data and simple on-chain transfers to conduct voting.

Step 1: Snapshot Definition & Data Sources
The proposal initiator must select and finalize a specific Block Height (recommended to be the height at the time of proposal initiation).

To avoid dependency on a single service provider, multiple forms of snapshot evidence are acceptable, provided they accurately reflect the chain state at the finalized block height. Accepted formats include:

• Data Files: CSV/JSON files exported from explorers (e.g., CrabScan, Subscan) or other indexers.
• Visual Evidence: Screenshots of holder lists (acceptable if the number of relevant addresses is small).
• Raw Data: Data indexed directly from the chain nodes.

The proposal initiator is responsible for providing this baseline data summary.

Step 2: Voting Addresses (Burn Addresses)
Voting addresses are strictly defined as Burn Addresses (addresses with no private keys) to ensure neutrality. The funds sent to these addresses are effectively destroyed.

• Generation Rule: Prefix(Zero Padding) + Proposal ID + Option
• NO Address (Ends in 00): e.g., for Prop 1: 0x0000000000000000000000000000000000000100
• YES Address (Ends in 01): e.g., for Prop 1: 0x0000000000000000000000000000000000000101

Step 3: Voting Rules (Strict Enforcement)

1. The 1 CRAB Rule: A transfer of exactly 1 CRAB to the target address is required. Transfers of more or less than 1 CRAB are invalid.
2. EOA Only (No Smart Contracts/CEX): Votes must originate from a personal EOA (Externally Owned Account) where the user holds the private key.
   • Invalid Sources: Votes sent directly from Centralized Exchanges (CEX), Smart Contracts, Liquidity Pools, or Multisig Wallets will be disqualified. This is to prevent the balances of pooled funds from distorting the voting weight.
3. First Vote Finality: Multiple votes from the same address are not cumulative. Only the first valid transfer (lowest transaction index in the earliest block) detected on-chain is counted. Subsequent transfers are ignored.
4. Verification: The voting power is determined by the sender's balance at the Snapshot Block Height, not the amount transferred.

Step 4: Result Verification

• The proposal initiator will summarize the results on the GitHub Discussion thread.
• Community members can independently verify the results using any tool capable of reading chain data (Explorers, Scripts, or direct RPC checks).

[hackfisher]

sunset_proposal.md

sha256 hash: 2955c479db4f9b3469cbedac226d3a50abe0a8748a2169bb37655b683ffb853c

Proposal submitted, vote here: https://polkadot.js.org/apps/?rpc=wss://crab-rpc.darwinia.network/#/referenda

Referenda 39

Polkadot JS friendly EVM wallets:

https://docs.polkadot.com/develop/smart-contracts/wallets/#subwallet

https://docs.polkadot.com/develop/smart-contracts/wallets/#talisman

[sonoferin2000]

Thanks for pushing the sunset proposal forward. Referenda 39 is now live on Polkadot.js, so we finally have an actionable path.
For anyone planning to vote, EVM-compatible wallets that work cleanly with Polkadot.js are listed here:
• SubWallet
• Talisman
This gives everyone a simple way to participate, and it clears the bottleneck that’s been delaying the unwind. With the vote now active, we can proceed to the next steps as soon as this passes. I appreciate you,

[2xJDubs]

As a reminder, voters will need to unstake their Crab to participate in this on-chain vote. gCrab is not recognized.

@hackfisher there is an issue with unstaking on Crab right now.

[sonoferin2000]

i had same issue trying to claim staking rewards on the collator staking app.. ckton staking app still working though.

[hackfisher]

@fewensa is working on fixing this issue.

[fewensa]

related: darwinia-network/collator-staking-ui-v2#57

[sonoferin2000]

it is now working.

[hackfisher]

The proposal has been approved and executed.