Proposal: Distribute CKTON Treasury CRAB to CKTON Stakers Pro Rata

[sonoferin2000]

Proposal: Distribute CKTON Treasury CRAB to CKTON Stakers Pro Rata
Treasury can be viewed here: https://crab-scan.darwinia.network/address/0xB633Ad1142941CA2Eb9C350579cF88BbE266660D
seeking to Return all CRAB held in the CKTON Treasury to CKTON stakers based on a fixed snapshot of CKTON balances.

Snapshot:
Use block X to capture: (to be determined)

Staker address

CKTON staked amount

Total CKTON staked
Only balances at this block determine payout.

Distribution Formula:
payout = (staker_ckton / total_ckton_staked) × total_crab_in_ckton_treasury

Scope:
Applies only to CKTON stakers and CRAB in the CKTON Treasury.
No changes to CKTON mechanics.

Execution:
Perform a one-time CRAB distribution to all CKTON stakers exactly according to the snapshot ratios.

Reasoning:
Simple. Fair. Minimal work. Returns treasury value to the participants who provided CKTON stake before sunset.

[sonoferin2000]

I want to get the cKTON treasury distributed to all cKTON stakers prior to sunsetting. this is streight forward, pro rata. we shouldnt allow those funds go to waste,

[2xJDubs]

So I want to express my appreciation for you putting so much effort into both of the proposals you have put forth. It is great to see someone from the community be involved.

I do have concerns with this proposal though. I understand you are looking to make sure cKTON get's its far share in the transition and in by doing that you want to maximize the CRAB cKTON holders have since CRAB will pretty much be converted to RING. The biggest concern I have with this proposal is that along with your proposal in discussion #39 we effectively are double counting the value of cKTON. cKTON's value right now is based on the staking rewards it generates and pretty much nothing else. So this does help establish a market value of cKTON in CRAB but if we now also consider that each cKTON is entitled to a portion of the CRAB in the treasury we are giving it an additional value that is not set by the market and thus double counting its valuation.

So I see it that cKTON's value can be determined two way but only one of these should be used:

1. The current value of 1 cKTON to WRING that i noted on 11/9 in my response to post RingDAO Proposal Draft (Tempcheck): Sunset of Crab Chain #37.
2. The amount of crab 1 CKTON would get in CRAB from a disbursement from the treasury

If we do both of these I feel like we are over valuing cKTON and could possible create a short term market run on cKTON to maximize RING airdrop from the sunset.

As a note, the CRAB the cKTON treasury holds is chain emissions and not something was provided by cKTON holders. Thus it does not needs to be returned but we could use this idea to generate a market value for cKTON instead of using the snowswap.xyz values I pulled in the early stages of this discussion.

[sonoferin2000]

JDubs, thanks for spelling out your concerns so clearly. Let me clarify what this proposal is and is not.

This discussion is only about the CKTON sub-treasury. That CRAB was accumulated as a tax on CKTON staking rewards, routed by design into a dedicated CKTON DAO pot that was meant to fund CKTON-specific activity. That activity never really materialized. So we are left with a sub-DAO treasury funded by CKTON stakers, sitting idle on a network that is being wound down.

In that context, the strongest claim on this CRAB is from the people whose staking created it. These tokens are not some abstract extra bonus; they are effectively withheld staking income. Leaving them in the contract is not neutral. While they sit, stakers are diluted and lose momentum because part of their reward base is frozen and cannot be restaked, used for liquidity, or rotated into other positions. A pro rata distribution just returns that trapped capital to the participants who generated it.

On the “double-counting” concern: the global Crab sunset and the CKTON sub-treasury cleanup should be treated as two separate layers. The sunset needs one consistent method to value CKTON relative to other exposures (price or formula), and I agree that should not be mixed with treasury accounting tricks. This proposal does not touch that. It does not change CKTON’s role or weight in the main sunset math. It only addresses what happens to a ring-fenced CKTON treasury that is otherwise destined to sit unused.

On incentives and gaming: any snapshot-based distribution creates some short-term incentive surface, but that can be managed by how and when the snapshot is taken. If the community is comfortable with a defined snapshot height and a narrow window, then we can keep this from becoming an open-ended farm. Either way, “do nothing” is also a decision with consequences: it strands earned rewards in a dead contract and erases the original purpose of the CKTON DAO pot.

If someone later wants to argue that this CRAB should go somewhere else, they should also explain why that destination has a stronger claim than the stakers whose rewards funded the treasury in the first place. Until then, a simple pro rata return to CKTON stakers is the most direct and least arbitrary way to close this out.

[2xJDubs]

I appreciate your clarification on your idea and based on this I can see your reasoning and now agree that cKTON Treasury should be dispersed to cKTON holders prior to the RING airdrop to Crab holders. We then also will still need to define the value of cKTON in RING for this drop as well. This should be done soon so to avoid gaming.

[sonoferin2000]

Thanks — agreed on sequencing and the need to avoid gaming.

I’m preparing a formal execution proposal that:

Disperses the CKTON treasury prior to the Crab/RING distribution

Uses a fixed snapshot and short transition window

Locks timing and eligibility explicitly

With the transition away from Polkadot.js governance, execution timelines will materially shorten. Given the long voting cycles under the current system as a choke point, it’s important to lock sequencing and snapshots cleanly now so the remaining steps can execute efficiently under the new system.

The valuation and exact mechanics will be defined in that proposal rather than in comments, so everything is clear, auditable, and not gameable.

[hackfisher]

Execution:
Perform a one-time CRAB distribution to all CKTON stakers exactly according to the snapshot ratios.

The distribution to CKTON stakers can be carried out as a pre-step before the RING airdrop on Darwinia.
Bundling these steps together will reduce the overall execution cost.

Suggestion:

**Execution:**  
If the Crab Chain is being sunset and a RING airdrop to CRAB holders on Darwinia is confirmed,  
add the following as a pre-step in the execution plan:

- Perform a one-time CRAB distribution to all CKTON stakers, exactly according to the snapshot ratios.

Bundling this pre-step with the RING airdrop preparation will avoid redundant operations and reduce execution cost.

[sonoferin2000]

Bundling everything into a single execution flow makes sense as long as the steps happen in the proper order.
The CRAB distribution should come first, followed by a short window for CKTON stakers to organize their balances, since those funds were collected through the tax mechanism. A brief period of around 24–48 hours would give people in different time zones a fair chance to review and manage their CRAB without slowing the process down.
After that window, taking one governance snapshot for the sunset process would give us a clear and consistent baseline.

[sonoferin2000]

This discussion has been open for a long time and appears to have converged without any unresolved blocking objections.

To move this forward, I intend to submit a minimal execution proposal that formalizes the following, in a single ordered execution flow:

• CKTON treasury unwind via CRAB distribution
• A short, fixed 48 hour transition window
• A final governance snapshot to serve as the authoritative baseline for the sunset process

The intent is to close CKTON accounting cleanly, allow a brief and fair repositioning period, and then establish finality so subsequent sunset execution proposals can proceed without ambiguity.

If there are specific blocking concerns with this direction, please raise them now. Otherwise, I will proceed with submitting the formal proposal.

[sonoferin2000]

the combined sunset that was asked for. https://github.com/orgs/ringecosystem/discussions/42

[hackfisher]

Revised and proposed via https://github.com/orgs/ringecosystem/discussions/43