Table of Contents

RFC-0169: Kusama Society V2.1

RFC-0169: Kusama Society V2.1


Start Date	2026-06-02
Description	Fix identified exploits, add quorum, change PoI rules, and add missing events
Authors	Lauro Gripa

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.

Currently, we are in V2, 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, this RFC proposes fixing 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 in smaller scales. 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.
Missing events: a few code paths in the Society pallet are missing events, making some state changes harder to track from interfaces and indexers.
Finally, V1 payout migration issue: some payout history failed during the V1 to V2 migration.

The RFC proposes:

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 missing Society pallet events.
Revisiting whether kick_member should be removed or changed after these fixes are deployed.

Together, these changes are proposed as Society V2.1.

Motivation

Main concerns: V2 currently allows candidates to be approved with too few votes, and lets approved candidates abuse the pot limit by delaying claiming membership indefinitely.

Stakeholders

Society members: need to vote on candidates and verify PoI.
Candidates: need to know how long they have to provide PoI and what evidence is required.
Runtime developers: need to update the Society pallet behavior and runtime configuration.
Society interfaces and bots: need to show quorum, candidate status, PoI status, and automatic resolution.
Founder: currently has emergency power through kick_member, but this should be revisited.

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
Payouts come from the treasury account, not the pot account. Even if the pot goes to 0, 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 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
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 but their payouts are guaranteed (because the treasury holds a very large amount of KSM)
This has been happening for the last few months, but can potentially be exploited by a long-range attack

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

Worst-case: $c \times \sum_{k=1}^n k$ where $c = 16.666$ KSM
If candidates never claim their membership, society can spend $16.666×(1+2+3+…+n)$ KSM every round, instead of just 16.666 KSM
It’s very hard to pull off, but theoretically, this attack could spend the entire treasury in 142 rounds (less than 3 years)
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. Once the changes in this RFC are deployed, we should discuss either:

Removing kick_member
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.

Possible solutions

No PoI

Members preemptively vote NAY for new candidates and change to AYE once PoI is provided (no runtime upgrade needed)
Require a quorum at the protocol level (runtime upgrade needed)

This RFC proposes the protocol-level quorum.

The proposed 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

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:

Deducting the bid from the pot earlier — as soon as the bidder turns into 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.
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 member automatically. However, automatic resolution alone can still be exploited if members collude to keep the voting undecided.

Both options require runtime upgrades.

RFC behavior

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
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
Change rules hash
- Explicitly ask for a video
- Require a predetermined region of the body
- This needs to go through Society voting
Revisit kick_member
- Remove it once these changes are deployed, or
- Change it so member removal is decided by members through a vote

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
Deducting the bid from the pot earlier changes pot accounting and requires care when candidates are rejected
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

Testing, Security, and Privacy

Testing should cover:

If automatic claim is implemented:
- A candidate with clear approval and quorum becomes a member automatically after the 2-round window
- A candidate with clear rejection and quorum is rejected automatically after the 2-round window
- A candidate cannot reproduce the recent no-PoI incident by getting fast votes and invoking claim_membership
- Approved-but-unclaimed candidates cannot be used to multiply payout exposure across rotations
If bid deduction is implemented:
- The bid is deducted from the pot when the bidder turns into candidate
- The bid is returned to the pot if the candidate is rejected
- Multiple pending candidates cannot make the pot over-select new candidates across rotations
A candidate without quorum cannot become a member
A candidate with many approvals cannot become a member unless quorum is reached
Missing events are emitted for the relevant Society pallet state changes
If kick_member remains, tests should cover who can call it and what happens to the kicked member's payouts

Security improves because:

A single approval is no longer enough
Candidates cannot claim without quorum
Candidates cannot wait indefinitely after approval to claim at a strategic time
If bid deduction is implemented, the pot can be made to account for pending candidates (pot predictability increases)
The PoI rules become harder to bypass with AI-generated pictures

Whether quorum was reached
Whether the candidate is still inside the 2-round window
Whether the candidate is waiting for more votes
Whether the candidate will be automatically approved or rejected next rotation

Compatibility

This requires a runtime upgrade.

Interfaces that currently ask candidates to call claim_membership need to be updated.

If kick_member is removed or changed into a member-vote flow, interfaces need to be updated as well.

The rules hash change also needs coordination with Society communication channels and interfaces.

Prior Art and References

Unresolved Questions

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?
What other ideas should be tested?
Should the bid/claim gap be fixed by automatic resolution alone, by deducting bids from the pot when bidders become candidates, or by both?
Should the V1 to V2 payout migration issue be fixed as part of Society V2.1, or handled separately?
Should quorum be exactly 5%, or configurable?
Should the 2-round window be fixed, or configurable?
Should the tattoo be required to be in one of 10 predetermined regions of the body?
Which regions should be accepted?
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, what threshold should it use?

Stronger multiple-identity defenses may be needed later
Interfaces should expose:
- Current pot
- Quorum progress
- Time left in the 2-round window

Polkadot Fellowship RFCs