candidates

members

proficients

fellows

senior_fellows

experts

senior_experts

masters

senior_masters

grand_masters

Miscellaneous

Proposal: Enable GitHub Discussions in paritytech/polkadot-sdk

Bastian Köcher

What happened to 2-day bonding?

Jonathan

What is the status of JAM development?

<strong>The Forum serves as a digital town square to co-create the future of Polkadot by the ecosystem, for the ecosystem. Suggestions on how to improve the Forum live here.</strong>

The Forum serves as a digital town square to co-create the future of Polkadot by the ecosystem, for the ecosystem. Suggestions on how to improve the Forum live here.

Polkadot Forum Meta

Welcome to the Polkadot Forum :waving_hand:

hantoniu (no dm)

Welcome to the Polkadot Forum 👋

Getting started: Read this first

Arwen Smit

Dotui — A Terminal User Interface for Polkadot

muddles

If you’re looking for discussion or discourse for anything and all things Tech related, then this is the place for you. .

Tech Talk

RISC-V is All You Need

Wei Tang

Runtime release notification for v2.3.0 [08.06.2026]

Anaelle LTD

Proposal: A Standard Developer Experience Layer for Revive Precompiles

Cisco

Whether you’re new to Polkadot’s Governance or an OpenGov OG, this is the place for you to get involved and join the discussion.

Governance

[Discussion] Retroactive Big Tipper: xcm-lens v0.0.2 — XCM debugging toolkit (136 tests, MIT)

What&rsquo;s broken in the Technical Fellowship (and a small set of fixes)

Jose NoName

What's broken in the Technical Fellowship (and a small set of fixes)

Should the Public RPC Initiative Implement a GeoDNS Load-Balancer?

Chris T

If you’re looking for discussion or discourse for anything and all things Ecosystem, then this is the place for you. .

Ecosystem

Pre-Web3 Summit Updates

State of Precompiles in Revive Ecosystem

ContribNet — decentralized contributor compensation and project governance on Kusama

If you’re looking for discussion or discourse for anything and all things Ambassador related, then this is the place for you. .

Ambassador Programme

Polkadot Ambassador Fellowship (PAF) Governance: Critical Questions Before On-Chain Implementation

Luke

Transition to the On-Chain Collective: Next Steps for the Ambassador Fellowship

Official statement of the Advisory Board of the Polkadot Ambassador Fellowship

If you’re looking for a resource, FAQ or guide, then this is the place to be. We urge all users of the forum to try and use this category when needed.

Resources & FAQs

How to P&lt;&gt;K bridge USDT or USDC

Alain Brenzikofer

How to P<>K bridge USDT or USDC

Good reads on proof-of-personhood

Asset Hub Migration - XCM FAQ

Remy Le Berre

<p>Pretty please, post a YouTube playlist when available! <img src="https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=15" title=":slight_smile:" class="emoji" alt=":slight_smile:" loading="lazy" width="20" height="20"></p>

<p>I <a href="https://github.com/paritytech/polkadot-sdk/discussions">enabled</a> them. Just added two categories for now, we can extend as we see a need.</p>

<p>I’m not sure what you mean by mentioned in minutes?</p>
<p>See Cappex’s earlier post from today: <a href="https://x.com/i/status/2063918834264752313">https://x.com/i/status/2063918834264752313</a></p>

<aside class="quote no-group" data-username="OliverTY" data-post="7" data-topic="17778">
<div class="title">
<div class="quote-controls"></div>
<img alt="" width="24" height="24" src="https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/oliverty/48/2986_2.png" class="avatar"> OliverTY:</div>
<blockquote>
<p>“just” use XCM::Transact and put a call into it. Can be any pallet. In my case it is `referenda::submit`.</p>
</blockquote>
</aside>
<p>Ahh good idea! <img src="https://emoji.discourse-cdn.com/twitter/smiley.png?v=15" title=":smiley:" class="emoji" alt=":smiley:" loading="lazy" width="20" height="20"> I did not thought about it. Then we don’t need what I said.</p>

<blockquote>
<p>Blows me away that no developers is interacting with your threads</p>
</blockquote>
<p>Probably just in the closed circle here.</p>
<p>Our Matrix room is quite active: <a href="https://matrix.to/#/#jar:matrix.org" rel="noopener nofollow ugc">https://matrix.to/#/#jar:matrix.org</a></p>
<p>And we actually also have interests from existing JAM implementation teams. Of course, before they receive JAM Prize and before I have their consent, I won’t disclose anything.</p>

<p><strong>Runtime release notification</strong></p>
<p>Hello,</p>
<p>This is to advise you that the Polkadot community is currently voting to upgrade the <em><a href="https://polkadot.subsquare.io/referenda/1902" rel="noopener nofollow ugc">Polkadot system</a></em> to the <a href="https://github.com/polkadot-fellows/runtimes/releases/tag/v2.3.0" rel="noopener nofollow ugc">v2.3.0 release</a>.</p>
<p>This is a major runtime upgrade that introduces a <a href="https://github.com/polkadot-fellows/runtimes/pull/1193" rel="noopener nofollow ugc">flexible minimum validator set size on Relay chains</a> and lowers the default limits to 100 validators for Kusama and 250 validators for Polkadot.</p>
<p>Adjusting the size of the active validator set is part of the <a href="https://forum.polkadot.network/t/polkadot-staking-changes-progress-timeline/17436">Dynamic Allocation Pool (DAP) roadmap</a> and will enable a more efficient use of the available resources by scaling the number of validators based on the demand for cores, smart contract interactions, and usage of Polkadot’s infrastructure.</p>
<p><img src="https://emoji.discourse-cdn.com/twitter/construction.png?v=15" title=":construction:" class="emoji" alt=":construction:" loading="lazy" width="20" height="20"> <strong>Important note for Ecosystem builders:</strong> <img src="https://emoji.discourse-cdn.com/twitter/construction.png?v=15" title=":construction:" class="emoji" alt=":construction:" loading="lazy" width="20" height="20"></p>
<p>This release provides an upgrade to the pallet recovery which allows users to have friends or family recover access to an account in the specific case of a lost seed phrase or private key.<br>
You can find more details about this change <a href="https://github.com/paritytech/polkadot-sdk/pull/10482" rel="noopener nofollow ugc">here</a>.</p>
<p>The projected enactment date for this runtime upgrade is around 15th June 2026.</p>
<p>Many thanks.</p>

<p>appreciated. this is roughly the frame i was trying to land on with the disclosure AI helped me ship faster and find more in adversarial review than i would solo, but the architectural calls and the decision to ship publicly with two open review passes are mine. the brush analogy fits.</p>
<p>best test is the code rather than the meta-argument. happy to walk through any part of the <span class="mention">@xcm-lens</span>/core or <span class="mention">@xcm-lens</span>/chain split with anyone who wants to dig in.</p>

<p>Parity and W3F reputation is breaking down and showing its true colors, if no-one can compete how the network how is it supposed to grown? we are living with that now, i can see this going the way EOS went. changes are needed and true leaders should engage, who will launch the technology to the masses is unknown yet, they have been trying for years, even creating their “own” paid community and they failed even at that. probably all of this starts at the top. leaders need to come down to where we are, not high with their inflated egos.</p>

Joby Reuben

<p>Stake-weighted reviews via current CP — that closes the Sybil concern cleanly, missed that in the OP. PoP on top is belt-and-braces, makes sense.</p>
<p>Appreciate the substantive responses. I’ll check out the task board this week — if I find a good-first-issue that fits, I might give it a go. Matrix group link?</p>

<p>As part of the team behind PayNuq Nigeria, I want to thank the Encointer team for not only building the infrastructure but also continuing to sustain it despite funding challenges.</p>
<p>For our community, Encointer has been more than a blockchain protocol. It has enabled us to bring people together, onboard local businesses, facilitate real transactions, experiment with community-driven economic activity, and introduce many participants to Web3 through practical use rather than speculation.</p>
<p>Like any grassroots initiative, we have faced challenges. Yet even through those challenges, we’ve seen businesses accept PayNuq, community members buy and spend it, and local economic relationships strengthen.</p>
<p>The new donation dApp is especially meaningful because support can now flow directly to the communities creating impact on the ground. For communities like ours, every contributions can help sustain participation, strengthen local economic activity, and create opportunities for growth.</p>
<p>To everyone who has supported Encointer so far, thank you. From where we stand, the impact is real, and we’re excited to continue building.</p>
<p>Exciting times ahead.</p>

Mubarak 

Donate KSM or USDC-p to Encointer communities directly — no intermediaries, no custody

<p>We have made a new infographic on why the number 178 is a lie.</p>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/2/234ccaf46ddc754230e5795df5add43b5cd0284b.jpeg" data-download-href="/uploads/short-url/52hePJm9hG8ng7LMQyCiB7Sgfs7.jpeg?dl=1" title="Screenshot 2026-06-05 at 02.08.05" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/2/234ccaf46ddc754230e5795df5add43b5cd0284b_2_690x481.jpeg" alt="Screenshot 2026-06-05 at 02.08.05" data-base62-sha1="52hePJm9hG8ng7LMQyCiB7Sgfs7" width="690" height="481" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/2/234ccaf46ddc754230e5795df5add43b5cd0284b_2_690x481.jpeg, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/2/234ccaf46ddc754230e5795df5add43b5cd0284b_2_1035x721.jpeg 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/2/234ccaf46ddc754230e5795df5add43b5cd0284b_2_1380x962.jpeg 2x" data-dominant-color="1D1D25"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">Screenshot 2026-06-05 at 02.08.05</span><span class="informations">1920×1339 267 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div></p>

Jeff Burdges

The Nakamoto Coefficient of Polkadot is At Most 25

<p>I’m glad you’re trying to improve the experience using precompiles in Polkadot!</p>
<p>Have you taken a look at <a href="https://lucasgrasso.github.io/solidity-scale-codec/" class="inline-onebox" rel="noopener nofollow ugc">Solidity Scale Codec</a> ? It solves the strongly typed interfaces part. You could use it or contribute back to it.</p>
<p>Address registries are good idea to make the process simpler.</p>
<p>I don’t know what validations could be done at this SDK layer, I imagine it depends on the precompile, but it’s definitely worth exploring.</p>
<p>Looking forward to see what you come up with <img src="https://emoji.discourse-cdn.com/twitter/grin.png?v=15" title=":grin:" class="emoji" alt=":grin:" loading="lazy" width="20" height="20"></p>

<p>Hi Polkadot community,</p>
<p>I would like to introduce <strong>FlowFarm</strong>, a project we are building to bring perpetual derivatives markets, USDC liquidity, and on-chain market infrastructure to the Polkadot ecosystem.</p>
<p>- X: <a href="https://x.com/flowfarmio" rel="noopener nofollow ugc">https://x.com/flowfarmio</a></p>
<p>- Telegram: <span class="mention">@flowfarmio</span></p>
<p>- Contact: <a href="mailto:contact@flowfarm.io">contact@flowfarm.io</a></p>
<p>This post is intended as an ecosystem and technical feedback thread. It is not a token sale announcement, investment solicitation, public fundraising campaign, or request for forum members to promote the project.</p>
<p>FlowFarm is being developed as a <strong>Polkadot-native perpetuals parachain</strong>, inspired by the GMX model but implemented with native Polkadot SDK / FRAME runtime logic instead of Solidity contracts. The goal is to build an app-specific chain for transparent perpetual markets, pooled liquidity, keeper-executed orders, oracle-priced execution, and risk controls designed directly at the runtime level.</p>
<p>We are still early, and the current implementation is intentionally local/devnet focused. We are sharing this now because we want feedback from the Polkadot community, especially around architecture, ecosystem fit, integrations, liquidity design, and what would make a derivatives protocol genuinely useful inside Polkadot.</p>
<p><strong>Why FlowFarm?</strong></p>
<p>Polkadot has strong infrastructure for app-specific execution, shared security, interoperability, and long-term modularity. We believe derivatives and liquidity infrastructure can benefit from that model.</p>
<p>Many perpetuals protocols are deployed as smart contracts on general-purpose chains. That can work, but it often means core trading logic, risk controls, execution flows, and operational assumptions are layered on top of a runtime that was not designed specifically for that market structure.</p>
<p>FlowFarm takes a different approach:</p>
<p>- Build the trading venue as an app-specific parachain.</p>
<p>- Put markets, liquidity, orders, fees, liquidation logic, ADL, referrals, and protocol accounting into native runtime modules.</p>
<p>- Use deterministic runtime-level checks for solvency, leverage, utilization, and execution constraints.</p>
<p>- Keep the MVP narrow enough to reason about and audit before any public launch.</p>
<p><strong>What FlowFarm is building</strong></p>
<p>The current FlowFarm architecture includes:</p>
<p>- Perpetual markets with USDC collateral.</p>
<p>- Pooled USDC liquidity backing trader positions.</p>
<p>- Two-phase order flow where users create requests and keepers execute them using fresh oracle reports.</p>
<p>- Market increase and decrease orders.</p>
<p>- Limit and stop-market order flows.</p>
<p>- TWAP order support.</p>
<p>- Take-profit / stop-loss sidecar order support.</p>
<p>- Runtime liquidation logic.</p>
<p>- Auto-deleveraging mechanics for extreme risk conditions.</p>
<p>- Protocol fee, LP fee, referral, and price-impact accounting.</p>
<p>- Rust indexer and GraphQL-compatible API for frontend and keeper workflows.</p>
<p>- Keeper service for local execution loops.</p>
<p>- Frontend and marketing site for early user-facing communication.</p>
<p><strong>Why Polkadot?</strong></p>
<p>We think Polkadot is a strong fit for this kind of product because:</p>
<p>- App-specific chains can encode domain logic directly into the runtime.</p>
<p>- Runtime upgrades allow protocol evolution without redeploying fragmented contract systems.</p>
<p>- XCM can eventually support asset movement and integrations across parachains.</p>
<p>- Polkadot’s shared security model can support specialized applications without every app needing to bootstrap its own validator set.</p>
<p>- The ecosystem has room for more DeFi primitives that are native to Polkadot rather than bridged from other ecosystems.</p>
<p>The long-term goal is not just to launch another perps UI, but to build derivatives infrastructure that feels native to Polkadot’s architecture.</p>
<p><strong>Current status</strong></p>
<p>FlowFarm is currently in active development.</p>
<p>The current implementation <strong>should be treated as a local/devnet-stage</strong> system. Before any public deployment, we expect the project to need further work across:</p>
<p>- Production oracle design.</p>
<p>- External audit.</p>
<p>- Public testnet process.</p>
<p>- Final tokenomics.</p>
<p>- Governance and admin-control hardening.</p>
<p>- Production keeper operations.</p>
<p>- XCM / live asset integration.</p>
<p>- Monitoring and incident runbooks.</p>
<p>- Liquidity and market launch planning.</p>
<p>We are being deliberate here because perpetuals protocols are high-risk systems. Solvency, oracle correctness, liquidation behavior, and accounting safety matter more than rushing to launch.</p>
<p><strong>What we would like feedback on</strong></p>
<p>We would appreciate feedback from Polkadot builders, governance participants, DeFi users, validators, and ecosystem teams on the following:</p>
<p>1. What would make a perpetuals protocol valuable specifically for the Polkadot ecosystem?</p>
<p>2. Which assets or markets would make the most sense after a `DOT_USD` `BTC_USD` `ETH_USD`?</p>
<p>3. What are the strongest expectations from the community before a DeFi protocol asks for trust?</p>
<p>4. Would a runtime-native perps chain be more compelling than deploying smart contracts on an existing execution environment?</p>
<p>5. What would you want to see before using, integrating with, or supporting FlowFarm?</p>
<p><strong>Near-term roadmap</strong></p>
<p>Our near-term focus is:</p>
<p>- Continue hardening the runtime logic.</p>
<p>- Improve test coverage around trading, liquidity, liquidations, ADL, and fee accounting.</p>
<p>- Prepare public-facing documentation.</p>
<p>- Improve frontend flows.</p>
<p>- Publish more technical architecture details.</p>
<p>- Engage with ecosystem teams around stablecoin, oracle, and liquidity integrations.</p>
<p>- Prepare for a testnet path once the core safety gates are stronger.</p>
<p><strong>Closing</strong></p>
<p>FlowFarm is being built with the belief that Polkadot can support serious, app-specific DeFi infrastructure.</p>
<p>We would appreciate any technical feedback, ecosystem suggestions, integration ideas, or criticism from the community.</p>
<p>Social links are listed at the top of this post.</p>

Introducing FlowFarm: Polkadot-native perpetual markets and USDC liquidity infrastructure

<p>You should ask the question in Element maybe <img src="https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=15" title=":slight_smile:" class="emoji" alt=":slight_smile:" loading="lazy" width="20" height="20"><br>
That’s where the JAM group is.</p>

<p>For block-, account-, and transaction-level data, the main providers I usually see developers using in the Polkadot ecosystem are Subscan, Subsquid, SubQuery, PAPI, and direct RPC providers, depending on their specific use case and data requirements.</p>
<p>If you’re looking for a comparison of use cases, capabilities, or API coverage across different providers, you may find PubFi Discovery’s Polkadot directory useful:</p>
<aside class="onebox allowlistedgeneric" data-onebox-src="https://pubfi.ai/discovery/chain/polkadot">
  <header class="source">
      <img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/8/81f06e4d1fe3fd1c0b79a7346d3ff28280d328cf.svg" class="site-icon" alt="" data-dominant-color="" width="500" height="500">

      <a href="https://pubfi.ai/discovery/chain/polkadot" target="_blank" rel="noopener nofollow ugc">PubFi</a>
  </header>

  <article class="onebox-body">
    <div class="aspect-image" style="--aspect-ratio:690/361;"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/b/ba964eae4cb301ad3f8a38d3ab6ecfc26cf49e2d_2_690x362.jpeg" class="thumbnail" alt="" data-dominant-color="0E1420" width="690" height="362"></div>

<h3><a href="https://pubfi.ai/discovery/chain/polkadot" target="_blank" rel="noopener nofollow ugc">Polkadot Data APIs | PubFi</a></h3>

  <p>Polkadot data APIs for indexed Substrate reads, governance visibility, and managed infrastructure comparison with claim-safe PubFi status labels.</p>


  </article>

  <div class="onebox-metadata">
    
    
  </div>

  <div style="clear: both"></div>
</aside>

<p>DotLake feels like a great fit for a different layer of the stack: aggregated ecosystem metrics rather than raw block-level data. I’ve already sent request to have the DotLake API listed in PubFi Discovery as well, since it fills an important gap for analytics and research use cases.</p>

Carl｜Subscan

Ross Bulat

Dotlake API Publicly available

<h1><a name="p-39302-summary-1" class="anchor" href="#p-39302-summary-1" aria-label="Heading link"></a>Summary</h1>
<p>The upcoming Proof of Personhood raises an important question for Kusama Society: what role should it play, if any?</p>
<p>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.</p>
<p>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, <code>kick_member</code> was introduced and made callable by the Founder. This works as an emergency measure, but gives too much power to the Founder.</p>
<p>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 <code>kick_member</code> be delegated to Society members instead of the Founder?</p>
<p>These questions need further discussion. However, at the very least, we should fix the following issues that emerged during V2:</p>
<ul>
<li><strong>No PoI exploit</strong>: a new candidate can become a member with a single approval without providing PoI. This already happened recently.</li>
<li><strong>False PoI exploit</strong>: 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.</li>
<li><strong>Bid/claim gap exploit</strong>: A coordinated long-range attack could potentially spend the whole treasury (&gt;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.</li>
<li><strong>Multiple identities</strong>: A single person could hold multiple identities (&gt;10) by tattooing themselves multiple times. Likely to be already happening.</li>
<li><strong>What’s more concerning is that some of these exploits can be combined.</strong></li>
<li>Finally, <strong>V1 payout migration issue</strong> and <strong>missing events</strong>: 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.</li>
</ul>
<p>Some initial propositions:</p>
<ul>
<li>Fixing the bid/claim gap through automatic claim, pot deduction when bidders become candidates, or both. The exact approach still needs to be decided.</li>
<li>A quorum requirement for approvals and rejections.</li>
<li>Updating the Society rules hash to explicitly require stronger PoI evidence.</li>
<li>Adding utility beyond v</li>
<li>Adding missing Society pallet events.</li>
<li>Discussing whether <code>kick_member</code> should be removed or changed after these fixes are deployed.</li>
</ul>
<p><strong>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</strong></p>
<h1><a name="p-39302-explanation-2" class="anchor" href="#p-39302-explanation-2" aria-label="Heading link"></a>Explanation</h1>
<h2><a name="p-39302-understanding-the-bidclaim-gap-3" class="anchor" href="#p-39302-understanding-the-bidclaim-gap-3" aria-label="Heading link"></a>Understanding the bid/claim gap</h2>
<p>To understand the gap, here are some considerations about the pot and bidding process:</p>
<ul>
<li>Every rotation, the pot grows constantly by <code>16.666 KSM</code>. This constant is defined <a href="https://github.com/polkadot-fellows/runtimes/blob/db4bb534cb411c0d6a2fe57eb331e6ec93ace825/relay/kusama/src/lib.rs#L1064" rel="noopener nofollow ugc">here</a> as <code>PeriodSpend = ConstU128&lt;{ 500 \* QUID }&gt;</code></li>
<li>The pot can only shrink when an approved candidate claims their membership, deducting their bid from the pot.</li>
<li>The pot is a mere limiter of how high a bid can go; it doesn’t limit payouts, even if it goes to <code>0 KSM</code>.</li>
<li>Payouts come from the treasury account, not the pot account. Even if the pot goes to <code>0 KSM</code>, the payouts are still deducted from the treasury account.</li>
<li>In every rotation, the <code>PeriodSpend</code> amount is added first, and then new bids are selected.</li>
<li>Any new bidder can assume their bids based on the current amount on the pot + <code>PeriodSpend</code>.</li>
<li>A candidate can remain indefinitely as long as there’s no clear rejection.</li>
</ul>
<h3><a name="p-39302-the-gap-between-bid-and-claim-4" class="anchor" href="#p-39302-the-gap-between-bid-and-claim-4" aria-label="Heading link"></a>The gap between bid and claim</h3>
<p>Suppose 2 full rotations go by without new bids and a 3rd round starts:</p>
<ul>
<li>The pot reaches <code>49.999 KSM</code></li>
<li>Someone bids <code>40 KSM</code> and becomes a candidate</li>
<li>The candidate provides PoI and reaches clear approval, but doesn’t claim membership (they can wait as long as they want)</li>
</ul>
<p>Next rotation:</p>
<ul>
<li>The pot will reach <code>66.666 KSM</code></li>
<li>Someone can still bid up to <code>66.666 KSM</code>, even if there’s a candidate in the queue with <code>40 KSM</code></li>
<li>Someone bids <code>60 KSM</code> and becomes a candidate</li>
<li>The 2nd candidate provides PoI and reaches clear approval</li>
</ul>
<p>Result:</p>
<ul>
<li>Both candidates claim membership, and they both get a reserved payout from the treasury. Their payout sum is <code>100 KSM</code>, even though the pot had only <code>66.666 KSM</code>. The pot goes to <code>0 KSM</code>, but their payouts are guaranteed (because the treasury holds a very large amount of KSM)</li>
</ul>
<p>This has been happening over the last months and can potentially be exploited in larger sums by a long-range attack.</p>
<h3><a name="p-39302-the-worst-case-scenario-a-long-range-attack-hypothesis-5" class="anchor" href="#p-39302-the-worst-case-scenario-a-long-range-attack-hypothesis-5" aria-label="Heading link"></a>The worst-case scenario, a long-range attack hypothesis</h3>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/3/3b65b98395cb0fe693d67e79f74dcabdba034f03.png" data-download-href="/uploads/short-url/8ts77szz1R6qhvoGDsumWC2DcWv.png?dl=1" title="worst-case-white-bg-padded" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/3/3b65b98395cb0fe693d67e79f74dcabdba034f03.png" alt="worst-case-white-bg-padded" data-base62-sha1="8ts77szz1R6qhvoGDsumWC2DcWv" width="517" height="123" data-dominant-color="F7F7F7"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">worst-case-white-bg-padded</span><span class="informations">752×180 2.96 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div></p>
<p>If candidates never claim their membership, Society can spend <code>c × sum(k from 1 to n)</code> every round, instead of just <code>c</code>. It’s very hard to pull off, but theoretically, this attack could spend the entire treasury in ~145 rounds (less than 3 years)</p>
<p>Currently, the treasury holds &gt;180K KSM:</p>
<ul>
<li>If the gap is fixed, the treasury will last enough for &gt;200 years of 16.666 KSM every rotation</li>
<li><strong>However, if the gap is not fixed, the treasury could theoretically be spent in less than 3 years, instead of the expected &gt;200 years (at current values)</strong></li>
</ul>
<h2><a name="p-39302-no-poi-incident-and-kick_member-6" class="anchor" href="#p-39302-no-poi-incident-and-kick_member-6" aria-label="Heading link"></a>No PoI incident and <code>kick_member</code></h2>
<p>The no-PoI exploit already happened in practice:</p>
<ul>
<li>A candidate had 1 rejection</li>
<li>All of a sudden, 2 accounts voted for approval</li>
<li>The candidate invoked `claim_membership`</li>
<li>The 2 approvals and the claim calls happened in the span of 1-2 minutes</li>
<li>The most likely explanation is that all 3 accounts were controlled by the same person, or at least tightly coordinated</li>
</ul>
<p>The timeline was:</p>
<ul>
<li>2025-06-17 06:18:54 (UTC): AYE from <code>EPyHYoCAw7DfJxa7azZ6Y11yKxoy9cvfCCUji5uNFu5oNdq</code></li>
<li>2025-06-17 06:19:24 (UTC): failed <code>claim_membership</code> from <code>HsD9zf6No7xtq6mWuQWrZU6FxJyVTKtofyPBNhvrM1b96wQ</code></li>
<li>2025-06-17 06:20:00 (UTC): AYE from <code>HEqo31Q969uBdaux5b9145rkHaXtu8rQN2CThfsmTVKiaGn</code></li>
<li>2025-06-17 06:20:48 (UTC): successful <code>claim_membership</code> from <code>HsD9zf6No7xtq6mWuQWrZU6FxJyVTKtofyPBNhvrM1b96wQ</code></li>
</ul>
<p>The PoI-less account was kicked with the new <code>kick_member</code> extrinsic. This solved the immediate incident, but <code>kick_member</code> gives too much power to the Founder.</p>
<h4><a name="p-39302-why-is-kick_member-too-powerful-7" class="anchor" href="#p-39302-why-is-kick_member-too-powerful-7" aria-label="Heading link"></a>Why is <code>kick_member</code> too powerful?</h4>
<p>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 <code>unfound</code> call for the entire society.</p>
<p>Once we fix the other issues, we should discuss either:</p>
<ol>
<li>Removing <code>kick_member</code></li>
<li>Or giving the responsibility to members through a vote</li>
</ol>
<p>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.</p>
<h2><a name="p-39302-lack-of-utility-8" class="anchor" href="#p-39302-lack-of-utility-8" aria-label="Heading link"></a>Lack of utility</h2>
<p>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.</p>
<p>We can use this opportunity to discuss possible additional utility. A few ideas:</p>
<ul>
<li>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.</li>
<li>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.</li>
</ul>
<p>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.</p>
<h2><a name="p-39302-possible-solutions-9" class="anchor" href="#p-39302-possible-solutions-9" aria-label="Heading link"></a>Possible solutions</h2>
<h3><a name="p-39302-no-poi-10" class="anchor" href="#p-39302-no-poi-10" aria-label="Heading link"></a>No PoI</h3>
<p>Possibilities:</p>
<ol>
<li>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)</li>
<li>Require an on-chain quorum (runtime upgrade needed)</li>
</ol>
<p>The proposed quorum:</p>
<ul>
<li>Quorum is based on total voting power, not member count</li>
<li>Requires at least 5% of total voting power to participate</li>
<li>Keep 2/3 majority</li>
</ul>
<p>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.</p>
<h3><a name="p-39302-false-poi-and-multiple-identities-11" class="anchor" href="#p-39302-false-poi-and-multiple-identities-11" aria-label="Heading link"></a>False PoI and multiple identities</h3>
<p>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.</p>
<p>Regarding multiple identities, we could specify a fixed set of allowed regions of the body, but this one needs further discussion.</p>
<h3><a name="p-39302-bidclaim-gap-12" class="anchor" href="#p-39302-bidclaim-gap-12" aria-label="Heading link"></a>Bid/claim gap</h3>
<p>Re-design the bidding and claiming process to fix the gap.</p>
<p>The gap can be fixed by either:</p>
<ul>
<li><strong>Option A</strong>: 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.</li>
<li><strong>Option B</strong>: 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</li>
<li><strong>Option C</strong>: Combining options A and B.</li>
</ul>
<p>Both options require runtime upgrades.</p>
<h3><a name="p-39302-in-a-nutshell-society-v21-would-include-13" class="anchor" href="#p-39302-in-a-nutshell-society-v21-would-include-13" aria-label="Heading link"></a>In a nutshell, Society V2.1 would include:</h3>
<ul>
<li>Bid/claim gap fix<br>
– The exact approach still needs to be decided<br>
– Option A: automatic membership claim<br>
— 2-round window<br>
— Remove manual claim<br>
— Rejection also automatic<br>
— Candidate remains indefinitely as long as there’s no clear rejection or approval<br>
– Option B: deduct the bid from the pot when the bidder becomes a candidate<br>
— Return the bid to the pot if the candidate is rejected<br>
– Option C: combine options A and B</li>
<li>No PoI fix: Require quorum<br>
– Quorum is based on total voting power, not member count<br>
– Require at least 5% of total voting power to participate<br>
– Keep 2/3 majority</li>
<li>False PoI fix: Change rules<br>
– Explicitly ask for a video<br>
– Require a predetermined region of the body</li>
<li>Revisit <code>kick_member</code><br>
– Remove it once these changes are deployed, or<br>
– Change it so member removal is decided by members through a vote</li>
<li>Additional utility</li>
</ul>
<h2><a name="p-39302-drawbacks-14" class="anchor" href="#p-39302-drawbacks-14" aria-label="Heading link"></a>Drawbacks</h2>
<ul>
<li>Automatic membership claim removes the candidate’s ability to choose when to claim membership</li>
<li>Making the intake flow more deterministic can make Society less interesting and less chaotic as an experiment</li>
<li>Quorum can slow down intake if members are not voting</li>
<li>Requiring videos and predetermined body regions can reduce privacy and increase friction for candidates</li>
<li>Removing <code>kick_member</code> can leave the Society without an emergency tool</li>
<li>Keeping <code>kick_member</code> gives too much power to the Founder</li>
<li>Moving <code>kick_member</code> responsibility to members through a vote is fairer, but complex</li>
</ul>
<h2><a name="p-39302-prior-art-and-references-15" class="anchor" href="#p-39302-prior-art-and-references-15" aria-label="Heading link"></a>Prior Art and References</h2>
<ul>
<li><a href="https://github.com/paritytech/polkadot-sdk/blob/a6871c6d1cba2be86b611ca1084bff2b28e7f16d/substrate/frame/society/src/lib.rs" rel="noopener nofollow ugc">Society Pallet</a></li>
<li><a href="https://github.com/paritytech/polkadot-sdk/pull/11154" rel="noopener nofollow ugc">PR introducing <code>kick_member</code></a></li>
<li><a href="https://github.com/polkadot-fellows/runtimes/blob/db4bb534cb411c0d6a2fe57eb331e6ec93ace825/relay/kusama/src/lib.rs#L1064" rel="noopener nofollow ugc">PeriodSpend value</a></li>
<li><a href="https://ksmsociety.io/explore/poi/rules" rel="noopener nofollow ugc">Proof-of-Ink rules</a></li>
</ul>
<h2><a name="p-39302-unresolved-questions-16" class="anchor" href="#p-39302-unresolved-questions-16" aria-label="Heading link"></a>Unresolved Questions</h2>
<h3><a name="p-39302-role-future-direction-and-additional-utility-17" class="anchor" href="#p-39302-role-future-direction-and-additional-utility-17" aria-label="Heading link"></a>Role, future direction, and additional utility</h3>
<ul>
<li>What role should Kusama Society play in Proof of Personhood, if any?</li>
<li>If Kusama Society still has a place in Proof of Personhood, how should it integrate<br>
with it?</li>
<li>What experiments should be done with Kusama Society?</li>
<li>Could Kusama Society work collectively as one of the curators for the art bounty?</li>
<li>Could Kusama Society vote collectively in OpenGov using part of its treasury?</li>
<li>What other ideas could be tested?</li>
</ul>
<h3><a name="p-39302-bidclaim-gap-18" class="anchor" href="#p-39302-bidclaim-gap-18" aria-label="Heading link"></a>Bid/claim gap</h3>
<ul>
<li>Should the bid/claim gap be fixed by automatic resolution alone, by deducting bids from<br>
the pot when bidders become candidates, or by both?</li>
</ul>
<h3><a name="p-39302-payout-history-issue-19" class="anchor" href="#p-39302-payout-history-issue-19" aria-label="Heading link"></a>Payout history issue</h3>
<ul>
<li>Should the V1 to V2 payout migration issue be fixed as part of Society V2.1, or handled<br>
separately?</li>
</ul>
<h3><a name="p-39302-quorum-20" class="anchor" href="#p-39302-quorum-20" aria-label="Heading link"></a>Quorum</h3>
<ul>
<li>Should we implement on-chain quorum?</li>
<li>Should quorum be exactly 5%, or configurable?</li>
<li>Should the 2-round window be fixed, or configurable?</li>
</ul>
<h3><a name="p-39302-proof-of-ink-rules-21" class="anchor" href="#p-39302-proof-of-ink-rules-21" aria-label="Heading link"></a>Proof-of-Ink rules</h3>
<ul>
<li>Is asking for a 3-minute video enough to prevent falsification?</li>
<li>Should the tattoo be required to be in one of 10 predetermined regions of the body?</li>
<li>If yes, which regions should be accepted?</li>
</ul>
<h3><a name="p-39302-member-removal-22" class="anchor" href="#p-39302-member-removal-22" aria-label="Heading link"></a>Member removal</h3>
<ul>
<li>Should <code>kick_member</code> be removed once the new changes are deployed?</li>
<li>If <code>kick_member</code> remains, should it be delegated to Society members instead of the Founder?</li>
<li>If member removal becomes a vote, how would it work?</li>
</ul>

Lauro Gripa

Let’s Talk About Kusama Society’s Future

root

whitelisted_caller

wish_for_change

staking_admin

treasurer

lease_admin

fellowship_admin

general_admin

auction_admin

referendum_canceller

referendum_killer

small_tipper

big_tipper

small_spender

medium_spender

big_spender

Encointer System Chain – Infrastructure Operations (Apr–Dec 2026)

Encointer Retroactive Treasury Proposal for July-Dec 2025

Subscan 2025 Q3-Q4 Funding Proposal: Basic service fee for the Kusama Relaychain and Kusama public parachain (AssetHub, Coretime, BridgeHub, People)

Pilot Proposal: RMTerra "Choose Green" RegenFi - RWA  (Small Spender, ~10k KSM)

ZKAMA - ZK Verifier SDK Proposal {Post-AssetHub Hackathon Curation}

Unlock Winning Strategies with Playzone

Encointer Outlook for Q4'25 and Onwards

Sol-XCM | A typed interface for interoperability from Solidity

Implement a Kusama Forum MVP (Content Pallet v2)

Discovering the Dynamic Features of JLJL99

Deciding

Runtime Upgrade 2.3

A proposal requests $65,724 to continue the Public RPC Provider service for Kusama for one year. It covers a previous tender period and the upcoming one. A GeoDNS system would connect users to the nearest available provider. Users can still connect directly to any provider.

Executed

Funding for Public RPC Providers (Kusama)

- Bloque lets people use stablecoins easily through a simple code tool.
- You can now watch real-time spending on Kusama Hub for the first time.
- They have processed over $405,000 in payments with more than 4,300 transactions.
- They are working with four fintech companies and have real customers.
- The team is asking for funding to keep growing and make their system stronger.
- They want to add support for local currencies like COP and MXN.
- Their goal is to help more companies use stablecoins for payments.

Kusama

referenda2

treasury22

discussions1388