[Crab Sunset][CKTON+WCKTON+gCKTON][Proposal-1] CKTON Treasury Distribute in pre-sunset period

[hackfisher]

1. Summary
   This proposal seeks to distribute the CRAB tokens currently held in the CKTON Treasury to all holders of the CKTON Group (CKTON, WCKTON, and gCKTON) on a pro-rata basis.

This distribution will be executed as a virtual allocation during the final settlement. The Treasury's CRAB holdings will be mathematically added to the balances of eligible holders when calculating the final CRAB snapshot, ensuring a fair asset consolidation for the Crab Chain Sunset.

2. Governance Mechanism
   This proposal uses Snapshot-Based On-Chain Signaling.

A. Snapshot Definition
Snapshot Block Height:
https://crab-scan.darwinia.network/block/9623885

Data Source: The proposer will provide evidence of the aggregate balances (CKTON + WCKTON + gCKTON) at this height for community verification.
https://github.com/ringecosystem/crab-sunset-snapshot/blob/1a1d79fba028d62be5a65ac564f978c6cf37e32a/data/CKTON_0x0000000000000000000000000000000000000402.json
https://github.com/ringecosystem/crab-sunset-snapshot/blob/1a1d79fba028d62be5a65ac564f978c6cf37e32a/data/WCKTON_0x159933C635570D5042723359fbD1619dFe83D3f3.json
https://github.com/ringecosystem/crab-sunset-snapshot/blob/1a1d79fba028d62be5a65ac564f978c6cf37e32a/data/gCKTON_0xB633Ad1142941CA2Eb9C350579cF88BbE266660D.json

B. Voting Period
Voting Deadline: [2026-Jan-12 00:00 UTC]

Votes broadcasted after this time will not be counted.

C. Voting Addresses
Vote by transferring exactly 1 CRAB to the specific burn addresses below (replace [ID] with the proposal ID):

NO: 0x0000000000000000000000000000000000000100

YES: 0x0000000000000000000000000000000000000101

D. Voting Rules
1 CRAB Rule: Transfer exactly 1 CRAB. Other amounts are invalid.

EOA Only: Votes must come from an Externally Owned Account (EOA). Smart contracts and exchanges are disqualified.

First Vote Counts: Only the first valid transaction per address is counted.

Group Weighted Voting: Voting power is based on the sender's aggregate balance of [CKTON + WCKTON + gCKTON] at the snapshot height, not the transfer amount.

3. Proposal Details
   Rationale
   Target: CKTON Treasury (0xB633Ad1142941CA2Eb9C350579cF88BbE266660D)

Reasoning: The CRAB in the treasury was generated by the ecosystem. To ensure fairness, these assets should be distributed to all committed holders (CKTON, WCKTON, gCKTON) as part of the final settlement.

Distribution Logic
Method: Pro-rata virtual allocation based on the aggregate snapshot balance.

Formula:

Virtual CRAB Add-on = (User's Group Balance / Total Group Supply) * Total Treasury CRAB
Where Group Balance = CKTON + WCKTON + gCKTON

Execution Plan (Virtual Allocation)
To simplify the process and eliminate the need for an on-chain transition window, the distribution will be handled as follows:

Chain Halt: The Crab Chain stops producing blocks.

Calculation: During the final data processing, the CRAB share for each CKTON Group holder is calculated virtually using the formula above.

Consolidation: This calculated CRAB amount is added to the user's existing CRAB balance in the final dataset.

Final Snapshot: The consolidated balance (User's original CRAB + Virtual Treasury Share) is used for the final RING airdrop/migration. No physical CRAB transfers will occur on-chain for this specific distribution.

[hackfisher]

Replacing https://github.com/orgs/ringecosystem/discussions/40

[sonoferin2000]

This proposal cannot replace or supersede the canonical sunset settlement.

It materially alters the agreed framework by:

Changing the snapshot height

Expanding eligibility to CKTON + WCKTON + gCKTON

Replacing on-chain execution with discretionary off-chain “virtual” allocation

These changes modify economic outcomes and reintroduce maintainer discretion, which is explicitly what a final sunset settlement must avoid.

Proposal #42 defines a complete, atomic, and deterministic settlement with fixed snapshots, eligibility rules, and execution order.

If there are concrete technical or procedural blockers to executing #42, they should be raised explicitly within that proposal. Parallel proposals that rewrite scope, eligibility, or execution are not a valid substitute and cannot be treated as replacements.

[sonoferin2000]

I’m going to pause further back-and-forth here.

Proposal #42 is the canonical final settlement proposal. It is complete, atomic, and deterministic.

If maintainers believe there are concrete technical or procedural execution blockers, please state them explicitly in #42. Otherwise, the proposal should proceed to a vote.

I won’t be engaging on parallel or replacement proposals.

[hackfisher]

Please follow the established governance process and participate through voting, rather than attempting to unilaterally define or determine the outcome.

Such an approach is unlikely to gain community consensus or receive support at the execution level.

[sonoferin2000]

For the record:
Proposal #42 is currently in a discussion and clarification phase and has not initiated any voting mechanics.

Proposal #41 authorizes a lightweight signaling process for execution steps; it does not prohibit discussion-phase proposals from defining scope, snapshot parameters, or execution order prior to signaling.

Proposal #42 does not assert or enforce any outcome unilaterally. It explicitly defines a discussion window before any vote is initiated.

[sonoferin2000]

For the record and to avoid ambiguity:

Proposal #42 is the only proposal that defines a complete, atomic, and deterministic settlement of the Crab Network.

Proposal #43 introduces different snapshot parameters, expanded eligibility, and off-chain virtual allocation. As such, it is a parallel signaling exercise and cannot replace or supersede #42.

If there are concrete technical or procedural blockers to executing Proposal #42, they should be stated explicitly within that proposal.

Absent stated blockers, the next step is to initiate voting on #42.

I will not engage further on parallel or replacement proposals.

[sonoferin2000]

Proposal #42 is the only procedurally valid settlement proposal. It is correctly sequenced, operates entirely within approved on-chain governance, and does not assume or rely on unapproved authority or execution mechanisms. It neither references nor depends on any framework not yet approved at the time of authorship.
By contrast, Proposal #43 claims continuity from Proposal #40, which established no voting or execution authority, and implicitly relies on concepts introduced only in Proposal #41. This is a forward-reference of authority and a sequencing defect.
Therefore, Proposal #42 is the first and only proposal with a complete and internally coherent procedural foundation. Any subsequent proposals must be evaluated for procedural consistency with Proposal #41 and substantive consistency with Proposal #42, not the reverse.

[sonoferin2000]

These proposals redefine governance weight from demonstrated commitment to snapshot presence.
Long-term stakers assumed risk, illiquidity, and opportunity cost under an incentive model that rewarded depth and duration.
#43 and #44 flatten that model by aggregating liquid and wrapped balances, diluting committed positions.
That may increase short-term satisfaction among smaller or passive holders, but it retroactively changes the basis of influence.
This is not a question of legality. It is a question of fairness to those who carried the network through lock-ups and risk.

[sonoferin2000]

This comment is not intended to influence the vote or its result. It is to formally record a downstream effect and governance precedent created by Proposals #43 and #44.
These proposals retroactively reallocate value away from committed contributors and toward non-contributors.
Long-term holders entered multi-year locks under an implicit contract: illiquidity, time commitment, and opportunity cost would be respected. Under these proposals, long-term stakers are treated no differently than liquid or short-term holders, despite having assumed materially greater risk and having provided sustained network support.
This issue is amplified for CKTON. A portion of CKTON staking income was explicitly taxed as a cost borne only by active stakers. Those taxed funds were generated by, and taken from, participants who accepted that burden. Under the sunset mechanics, that accumulated value is redistributed to all CKTON holders, including those who neither earned it nor paid into it.
This is not a neutral sunset mechanism. It is a retroactive redistribution from contributors to non-contributors.
The precedent set is that long-horizon alignment, lockups, and sustained participation are liabilities rather than assets. Going forward, rational long-term capital will discount or avoid systems where commitment is not differentiated from passivity.

[hackfisher]

YES: https://crab-scan.darwinia.network/address/0x0000000000000000000000000000000000000101?tab=txs

with 15311.02956 votes.

NO: https://crab-scan.darwinia.network/address/0x0000000000000000000000000000000000000100?tab=txs

with 15174.14236 votes.

The proposal passed.