Let’s Talk About Kusama Society’s Future

[laurogripa]

Summary

The upcoming Proof of Personhood raises an important question for Kusama Society: what role should it play, if any?

Kusama Society (Kappa Sigma Mu) is one of the oldest and most consistent experiments in the ecosystem. It was one of the first live pallets that composed other pallets and served as a battle test. In a strict sense, it has been successful: it fulfilled its purpose and works as intended. At the same time, it leaves a few missed opportunities, since there is not much to do after joining it besides voting.

We are currently in V2, which was created by Gavin Wood a couple of years ago. It has been better than V1 in general, but some issues have appeared. A few months ago, for example, coordinated accounts allowed a candidate to claim membership without providing Proof-of-Ink. As a short-term solution, kick_member was introduced and made callable by the Founder. This works as an emergency measure, but gives too much power to the Founder.

With all that in mind, there are several questions to answer. First and most important: Does the Kusama Society still have a place in the Proof of Personhood vision? If yes, how? What experiments should be done with it? For example, could the Society work collectively as one of the curators for the art bounty? What other ideas could be tested? More specifically, should kick_member be delegated to Society members instead of the Founder?

These questions need further discussion. However, at the very least, we should fix the following issues that emerged during V2:

• No PoI exploit: a new candidate can become a member with a single approval without providing PoI. This already happened recently.
• False PoI exploit: a new candidate can become a member by providing a false PoI generated by AI. Less likely, but getting more and more possible with time.
• Bid/claim gap exploit: A coordinated long-range attack could potentially spend the whole treasury (>180K KSM) in just a few years, instead of the expected 200 years. Hard to pull off in full, but can be done on a smaller scale. Already happening.
• Multiple identities: A single person could hold multiple identities (>10) by tattooing themselves multiple times. Likely to be already happening.
• What’s more concerning is that some of these exploits can be combined.
• Finally, V1 payout migration issue and missing events: some payout history failed during the V1 to V2 migration. Also, a few code paths in the Society pallet are missing events, making some state changes harder to track from interfaces and indexers.

Some initial propositions:

• Fixing the bid/claim gap through automatic claim, pot deduction when bidders become candidates, or both. The exact approach still needs to be decided.
• A quorum requirement for approvals and rejections.
• Updating the Society rules hash to explicitly require stronger PoI evidence.
• Adding utility beyond v
• Adding missing Society pallet events.
• Discussing whether kick_member should be removed or changed after these fixes are deployed.

Together, these changes can be proposed as Society V2.1, but first we need to discuss the best approach as there are many unresolved questions

Explanation

Understanding the bid/claim gap

To understand the gap, here are some considerations about the pot and bidding process:

• Every rotation, the pot grows constantly by 16.666 KSM. This constant is defined here as PeriodSpend = ConstU128<{ 500 \* QUID }>
• The pot can only shrink when an approved candidate claims their membership, deducting their bid from the pot.
• The pot is a mere limiter of how high a bid can go; it doesn’t limit payouts, even if it goes to 0 KSM.
• Payouts come from the treasury account, not the pot account. Even if the pot goes to 0 KSM, the payouts are still deducted from the treasury account.
• In every rotation, the PeriodSpend amount is added first, and then new bids are selected.
• Any new bidder can assume their bids based on the current amount on the pot + PeriodSpend.
• A candidate can remain indefinitely as long as there’s no clear rejection.

The gap between bid and claim

Suppose 2 full rotations go by without new bids and a 3rd round starts:

• The pot reaches 49.999 KSM
• Someone bids 40 KSM and becomes a candidate
• The candidate provides PoI and reaches clear approval, but doesn’t claim membership (they can wait as long as they want)

Next rotation:

• The pot will reach 66.666 KSM
• Someone can still bid up to 66.666 KSM, even if there’s a candidate in the queue with 40 KSM
• Someone bids 60 KSM and becomes a candidate
• The 2nd candidate provides PoI and reaches clear approval

Result:

• Both candidates claim membership, and they both get a reserved payout from the treasury. Their payout sum is 100 KSM, even though the pot had only 66.666 KSM. The pot goes to 0 KSM, but their payouts are guaranteed (because the treasury holds a very large amount of KSM)

This has been happening over the last months and can potentially be exploited in larger sums by a long-range attack.

The worst-case scenario, a long-range attack hypothesis

If candidates never claim their membership, Society can spend c × sum(k from 1 to n) every round, instead of just c. It’s very hard to pull off, but theoretically, this attack could spend the entire treasury in ~145 rounds (less than 3 years)

Currently, the treasury holds >180K KSM:

• If the gap is fixed, the treasury will last enough for >200 years of 16.666 KSM every rotation
• However, if the gap is not fixed, the treasury could theoretically be spent in less than 3 years, instead of the expected >200 years (at current values)

No PoI incident and kick_member

The no-PoI exploit already happened in practice:

• A candidate had 1 rejection
• All of a sudden, 2 accounts voted for approval
• The candidate invoked `claim_membership`
• The 2 approvals and the claim calls happened in the span of 1-2 minutes
• The most likely explanation is that all 3 accounts were controlled by the same person, or at least tightly coordinated

The timeline was:

• 2025-06-17 06:18:54 (UTC): AYE from EPyHYoCAw7DfJxa7azZ6Y11yKxoy9cvfCCUji5uNFu5oNdq
• 2025-06-17 06:19:24 (UTC): failed claim_membership from HsD9zf6No7xtq6mWuQWrZU6FxJyVTKtofyPBNhvrM1b96wQ
• 2025-06-17 06:20:00 (UTC): AYE from HEqo31Q969uBdaux5b9145rkHaXtu8rQN2CThfsmTVKiaGn
• 2025-06-17 06:20:48 (UTC): successful claim_membership from HsD9zf6No7xtq6mWuQWrZU6FxJyVTKtofyPBNhvrM1b96wQ

The PoI-less account was kicked with the new kick_member extrinsic. This solved the immediate incident, but kick_member gives too much power to the Founder.

Why is kick_member too powerful?

We have no reason to think the Founder will ever act in bad faith, but from a security point of view, it’s a problem: if the Founder’s account is compromised, it allows the removal of every member and the unfound call for the entire society.

Once we fix the other issues, we should discuss either:

1. Removing kick_member
2. Or giving the responsibility to members through a vote

The member-vote version is probably better socially, but rather complex. It needs a voting flow, a threshold, and clear rules for when member removal can be used.

Lack of utility

From a strict point of view, Kusama Society has been highly successful. The game works and has been running for over 5 years. However, it has struggled with a lack of practical utility after admission. Beyond voting on new candidates, there is not much for members to collectively do, which weakens the Society’s role as an active experiment.

We can use this opportunity to discuss possible additional utility. A few ideas:

• One possible direction would be for the Society to act as a curator for the art bounty, using its existing social layer to evaluate and support cultural work in the ecosystem.
• Another option would be to allocate a bounded portion of the Society treasury, perhaps 5% or 10%, to decisions made by Society members through OpenGov.

This would give membership a clearer purpose while keeping the experiment constrained. Society members would gain real collective responsibility, but only over a limited share of funds. This makes it possible to test whether the group can coordinate meaningfully beyond Proof-of-Ink and candidate approval, and it also aligns with the general goals of Proof of Personhood.

Possible solutions

No PoI

Possibilities:

1. Members preemptively vote NAY for new candidates and change to AYE once PoI is provided (no runtime upgrade needed, currently being done by some members)
2. Require an on-chain quorum (runtime upgrade needed)

The proposed quorum:

• Quorum is based on total voting power, not member count
• Requires at least 5% of total voting power to participate
• Keep 2/3 majority

For example, if Society has 400 members but total voting power is 520, quorum is 26 voting power. A candidate reaches quorum once participating votes add up to at least 26 voting power.

False PoI and multiple identities

Change the rules to explicitly ask for a long video of the process (at least 30 seconds, maybe 3 minutes to make it more future-proof). This should be a simple runtime upgrade to update the rules hash in the pallet constants.

Regarding multiple identities, we could specify a fixed set of allowed regions of the body, but this one needs further discussion.

Bid/claim gap

Re-design the bidding and claiming process to fix the gap.

The gap can be fixed by either:

• Option A: Implementing automatic claim for approvals and automatic rejection for rejections. This way, candidates still have enough time to present PoI, but once a clear approval is reached after the 2-round window, the candidate turns into a member automatically. However, automatic resolution alone can still be exploited if members collude to keep the voting undecided.
• Option B: Deducting the bid from the pot earlier — as soon as the bidder turns into a candidate — instead of waiting to deduct only when the candidate claims membership. The bid can be returned to the pot if the candidate is rejected
• Option C: Combining options A and B.

Both options require runtime upgrades.

In a nutshell, Society V2.1 would include:

• Bid/claim gap fix
  – The exact approach still needs to be decided
  – Option A: automatic membership claim
  — 2-round window
  — Remove manual claim
  — Rejection also automatic
  — Candidate remains indefinitely as long as there’s no clear rejection or approval
  – Option B: deduct the bid from the pot when the bidder becomes a candidate
  — Return the bid to the pot if the candidate is rejected
  – Option C: combine options A and B
• No PoI fix: Require quorum
  – Quorum is based on total voting power, not member count
  – Require at least 5% of total voting power to participate
  – Keep 2/3 majority
• False PoI fix: Change rules
  – Explicitly ask for a video
  – Require a predetermined region of the body
• Revisit kick_member
  – Remove it once these changes are deployed, or
  – Change it so member removal is decided by members through a vote
• Additional utility

Drawbacks

• Automatic membership claim removes the candidate’s ability to choose when to claim membership
• Making the intake flow more deterministic can make Society less interesting and less chaotic as an experiment
• Quorum can slow down intake if members are not voting
• Requiring videos and predetermined body regions can reduce privacy and increase friction for candidates
• Removing kick_member can leave the Society without an emergency tool
• Keeping kick_member gives too much power to the Founder
• Moving kick_member responsibility to members through a vote is fairer, but complex

Prior Art and References

• Society Pallet
• PR introducing kick_member
• PeriodSpend value
• Proof-of-Ink rules

Unresolved Questions

Role, future direction, and additional utility

• What role should Kusama Society play in Proof of Personhood, if any?
• If Kusama Society still has a place in Proof of Personhood, how should it integrate
  with it?
• What experiments should be done with Kusama Society?
• Could Kusama Society work collectively as one of the curators for the art bounty?
• Could Kusama Society vote collectively in OpenGov using part of its treasury?
• What other ideas could be tested?

Bid/claim gap

• Should the bid/claim gap be fixed by automatic resolution alone, by deducting bids from
  the pot when bidders become candidates, or by both?

Payout history issue

• Should the V1 to V2 payout migration issue be fixed as part of Society V2.1, or handled
  separately?

Quorum

• Should we implement on-chain quorum?
• Should quorum be exactly 5%, or configurable?
• Should the 2-round window be fixed, or configurable?

Proof-of-Ink rules

• Is asking for a 3-minute video enough to prevent falsification?
• Should the tattoo be required to be in one of 10 predetermined regions of the body?
• If yes, which regions should be accepted?

Member removal

• Should kick_member be removed once the new changes are deployed?
• If kick_member remains, should it be delegated to Society members instead of the Founder?
• If member removal becomes a vote, how would it work?