candidates

members

proficients

fellows

senior_fellows

experts

senior_experts

masters

senior_masters

grand_masters

Miscellaneous

What happened to 2-day bonding?

Jonathan

What is the status of JAM development?

Request for Feedback - Web3 Ad Targeting Marketplace

<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

Polkadot Forum Super Admin

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

Jose NoName

Proposal: A Standard Developer Experience Layer for Revive Precompiles

Cisco

:rocket: Announcing Pallet-XP: Experience Points for Substrate (Polkadot-SDK) Runtimes

Joby Reuben

🚀 Announcing Pallet-XP: Experience Points for Substrate (Polkadot-SDK) Runtimes

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

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

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

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

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

ContribNet — decentralized contributor compensation and project governance on Kusama

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

Mubarak 

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

<p>will not be attending W3S, would love to but can’t make it. looking forward to seeing what is coming out of Parity this year.</p>

<p>Blows me away that no developers is interacting with your threads, regardless of their believes… what you are doing is a net positive to the ecosystem, and i highly support the conversation.</p>

<p>I’m seeing a lot of anti‑AI comments here (maybe because this is a dev‑heavy forum, not a visionary one), as if AI‑produced content can’t be good. Yes, a lot of it is useless, but saying everything AI touches is garbbage is silly and needs to change. To tell you the truht, if someone launches a solution that uses AI, I’m more inlcined to try it than not. Picasso used a brush… should he have painted with his fingers, otherwise he was “aided” by the brush… so do we credit the brush, too?</p>
<p>is not the brush who made the painting but the creative mind behind it, same applies to AI.</p>

<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/8/8adcfb4afb81730894cfb6441773e9cb6522bf63.jpeg" data-download-href="/uploads/short-url/jOrlc30DKguIvhIWXInTvodEfGH.jpeg?dl=1" title="34311"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/8/8adcfb4afb81730894cfb6441773e9cb6522bf63_2_678x500.jpeg" alt="34311" data-base62-sha1="jOrlc30DKguIvhIWXInTvodEfGH" width="678" height="500" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/8/8adcfb4afb81730894cfb6441773e9cb6522bf63_2_678x500.jpeg, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/8/8adcfb4afb81730894cfb6441773e9cb6522bf63_2_1017x750.jpeg 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/8/8adcfb4afb81730894cfb6441773e9cb6522bf63.jpeg 2x" data-dominant-color="121213"><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">34311</span><span class="informations">1080×796 120 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>
<aside class="onebox twitterstatus" data-onebox-src="https://x.com/i/status/2063308774291411232">
  <header class="source">

      <a href="https://x.com/i/status/2063308774291411232" target="_blank" rel="noopener">x.com</a>
  </header>

  <article class="onebox-body">
    <img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/f/f18dc40a22f905755873c4391325ef27fdb57698.jpeg" class="thumbnail onebox-avatar" alt="" data-dominant-color="5A5A5A" width="48" height="48">
<h4><a href="https://x.com/i/status/2063308774291411232" target="_blank" rel="noopener">Polkadot Cloud ☁️</a></h4>
<div class="twitter-screen-name"><a href="https://x.com/i/status/2063308774291411232" target="_blank" rel="noopener">@TheWeb3Cloud</a></div>

<div class="tweet">
    <span class="is-reply">
      <svg class="fa d-icon d-icon-reply svg-icon svg-string"><use href="#reply"></use></svg>
    </span>
  <span class="tweet-description"><a href="https://twitter.com/gokboruyalcin" target="_blank" rel="noopener">@gokboruyalcin</a> Timing depends on 2 referenda landing:
- Ref 1890 (MinValidatorBond = 10k DOT) is in its decision period → confirmation → enactment
- A separate ref for nominator-unslashable + fast unbonding still has to be drafted, voted, enacted</span>
</div>

<div class="date">
  <a href="https://x.com/i/status/2063308774291411232" class="timestamp" target="_blank" rel="noopener">5:15 PM - 6 Jun 2026</a>

    <span class="like">
      <svg viewBox="0 0 512 512" width="14px" height="16px" aria-hidden="true"><path d="M462.3 62.6C407.5 15.9 326 24.3 275.7 76.2L256 96.5l-19.7-20.3C186.1 24.3 104.5 15.9 49.7 62.6c-62.8 53.6-66.1 149.8-9.9 207.9l193.5 199.8c12.5 12.9 32.8 12.9 45.3 0l193.5-199.8c56.3-58.1 53-154.3-9.8-207.9z"></path></svg>
      2
    </span>

</div>

  </article>

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

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


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

<aside class="quote no-group" data-username="bkchr" data-post="6" 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/bkchr/48/27_2.png" class="avatar"> bkchr:</div>
<blockquote>
<p>They could. Just send the SCALE encoded bytes and decode them on the runtime side. Not the most elegant way, but enables you to experiment very quickly.</p>
</blockquote>
</aside>
<p>That is exactly what I did on <a href="https://chamber.tasty.limo/">https://chamber.tasty.limo/</a> and it works well.</p>
<p>“just” use XCM::Transact and put a call into it. Can be any pallet. In my case it is `referenda::submit`. You an see the TX <a href="https://assethub-paseo.subscan.io/extrinsic/9361924-2">here</a>, `revive::eth_transact` goes in and `referenda::submitted` event comes out.</p>
<p>I think it only makes sense to add precompiles to every pallet once it becomes clear which patterns the pallets are being used in. If we add precompiles for every pallet now, then we lock in their API for all eternity. And the chances are high that they don’t actually cover the usage patterns of developers.</p>
<p>I would personally wait to see how people use xcm::transact to interact with pallets, and then extract the most common patterns into shared contract libraries (not precompiles).</p>

Oliver Tale-Yazdi

State of Precompiles in Revive Ecosystem

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

Wei Tang

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

<p>This is a direct request to the Polkadot Community Foundation (PCF).</p>
<p>PCF is currently acting as a legal counterparty and execution layer for multiple Polkadot Treasury-funded initiatives. However, for many of these proposals, there is still <strong>no clear, consolidated progress reporting available to the community</strong>.</p>
<p>Given that PCF is handling a significant number of passed referenda, I am requesting a <strong>public, structured progress report for ALL PCF-related funded proposals listed below.</strong></p>
<hr>
<h2><a name="p-39301-requested-deliverable-1" class="anchor" href="#p-39301-requested-deliverable-1" aria-label="Heading link"></a>Requested Deliverable</h2>
<p>For each proposal listed, please provide:</p>
<ul>
<li>Current status (active / completed / stalled / abandoned)</li>
<li>What has actually been delivered so far</li>
<li>Links to products, code, reports, or outputs</li>
<li>Budget usage status (if possible: spent vs remaining)</li>
<li>Updated roadmap or next steps</li>
<li>Any delays or scope changes (if applicable)</li>
</ul>
<hr>
<h2><a name="p-39301-pcf-funded-pcf-executed-proposals-2" class="anchor" href="#p-39301-pcf-funded-pcf-executed-proposals-2" aria-label="Heading link"></a>PCF-Funded / PCF-Executed Proposals</h2>
<h3><a name="p-39301-proposal-1173-polkadot-giveaway-ledger-3" class="anchor" href="#p-39301-proposal-1173-polkadot-giveaway-ledger-3" aria-label="Heading link"></a>Proposal <span class="hashtag-raw">#1173</span> — Polkadot Giveaway &lt;&gt; Ledger</h3>
<h3><a name="p-39301-proposal-1462-polkadot-api-4" class="anchor" href="#p-39301-proposal-1462-polkadot-api-4" aria-label="Heading link"></a>Proposal <span class="hashtag-raw">#1462</span> — Polkadot API</h3>
<h3><a name="p-39301-proposal-1573-polkadot-app-treasury-funding-5" class="anchor" href="#p-39301-proposal-1573-polkadot-app-treasury-funding-5" aria-label="Heading link"></a>Proposal <span class="hashtag-raw">#1573</span> — Polkadot App Treasury Funding</h3>
<h3><a name="p-39301-proposal-1082-parity-mobile-apps-ip-legal-app-ownership-6" class="anchor" href="#p-39301-proposal-1082-parity-mobile-apps-ip-legal-app-ownership-6" aria-label="Heading link"></a>Proposal <span class="hashtag-raw">#1082</span> — Parity Mobile Apps (IP / Legal / App Ownership)</h3>
<h3><a name="p-39301-proposal-1122-treasury-centrifuge-investment-7" class="anchor" href="#p-39301-proposal-1122-treasury-centrifuge-investment-7" aria-label="Heading link"></a>Proposal <span class="hashtag-raw">#1122</span> — Treasury &lt;&gt; Centrifuge Investment</h3>
<h3><a name="p-39301-proposal-1416-marketing-bounty-framework-8" class="anchor" href="#p-39301-proposal-1416-marketing-bounty-framework-8" aria-label="Heading link"></a>Proposal <span class="hashtag-raw">#1416</span> — Marketing Bounty Framework</h3>
<h3><a name="p-39301-proposal-1078-polkadot-at-slush-2024-9" class="anchor" href="#p-39301-proposal-1078-polkadot-at-slush-2024-9" aria-label="Heading link"></a>Proposal <span class="hashtag-raw">#1078</span> — Polkadot at Slush 2024</h3>
<h3><a name="p-39301-proposal-1634-politecnico-di-milano-partnership-10" class="anchor" href="#p-39301-proposal-1634-politecnico-di-milano-partnership-10" aria-label="Heading link"></a>Proposal <span class="hashtag-raw">#1634</span> — Politecnico di Milano Partnership</h3>
<h3><a name="p-39301-proposal-1681-hong-kong-oases-strategic-cooperation-11" class="anchor" href="#p-39301-proposal-1681-hong-kong-oases-strategic-cooperation-11" aria-label="Heading link"></a>Proposal <span class="hashtag-raw">#1681</span> — Hong Kong OASES Strategic Cooperation</h3>
<h3><a name="p-39301-proposal-1608-polkadot-community-foundation-polkadot-payment-card-12" class="anchor" href="#p-39301-proposal-1608-polkadot-community-foundation-polkadot-payment-card-12" aria-label="Heading link"></a>Proposal <span class="hashtag-raw">#1608</span> — <strong>Polkadot Community Foundation: Polkadot Payment Card</strong></h3>

dandan

For Polkadot Community Foundation: What Has Been Delivered for Referenda #1573 and #1608?

<p>Thanks! ContribNet looks like a very thoughtful approach to contributor compensation, reputation, and project governance.</p>
<p>Pallet-XP is designed as a general reputation primitive at the runtime level. If you ever explore bringing contributor reputation into a Substrate runtime, we’d be happy to help with integrations through XP.</p>
<p>We’ve also built additional bonding and staking primitives that will be released as part of the broader FRAME-Suite ecosystem, which may be relevant for reputation-backed participation and governance models such as yours.</p>
<p>Looking forward to seeing how ContribNet evolves.</p>

<p><strong>Upcoming Tender Round — Tender 5</strong></p>
<p>Hi everyone,</p>
<p>The <strong>Public RPC Bounty Tender 5 Requirements Document</strong> is now available so providers have sufficient time to review the scope and prepare submissions ahead of the application window.</p>
<p>Public RPC Bounty — Tender 5 Requirements Document</p>
<aside class="onebox googledocs" data-onebox-src="https://docs.google.com/document/d/1RVScx8PlynZB6d9WCBvUG_XvNhzT96TBcZlOIdIYNLI/edit?usp=sharing">
  <header class="source">

      <a href="https://docs.google.com/document/d/1RVScx8PlynZB6d9WCBvUG_XvNhzT96TBcZlOIdIYNLI/edit?usp=sharing" target="_blank" rel="noopener">docs.google.com</a>
  </header>

  <article class="onebox-body">
    <a href="https://docs.google.com/document/d/1RVScx8PlynZB6d9WCBvUG_XvNhzT96TBcZlOIdIYNLI/edit?usp=sharing" target="_blank" rel="noopener"><span class="googledocs-onebox-logo g-docs-logo"></span></a>

<h3><a href="https://docs.google.com/document/d/1RVScx8PlynZB6d9WCBvUG_XvNhzT96TBcZlOIdIYNLI/edit?usp=sharing" target="_blank" rel="noopener">Public RPC Bounty - Tender 5 requirement document</a></h3>

<p>Public RPC Bounty - Tender 5 requirement document   The Public RPC Bounty - Tender Requirements Document outlines the criteria, processes, and standards for selecting and onboarding RPC service providers to support the Polkadot and Kusama ecosystems....</p>

  </article>

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

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

<p>Tender 5 improves the scope of Tender 4 and covers all major Relay and System chains in the Polkadot and Kusama networks.</p>
<p>Providers may submit offers for one or more of the following networks:</p>
<p><strong>Polkadot Networks</strong></p>
<p>• Polkadot — 4 providers</p>
<p>• Polkadot AssetHub — 6 providers</p>
<p>• Polkadot BridgeHub — 2 providers</p>
<p>• Polkadot Collectives — 1 provider</p>
<p>• Polkadot Coretime — 1 provider</p>
<p>• Polkadot People — 3 providers</p>
<p>• Polkadot Bulletin — 2 providers</p>
<p><strong>Kusama Networks</strong></p>
<p>• Kusama — 2 providers</p>
<p>• Kusama AssetHub — 1 provider</p>
<p>• Kusama BridgeHub — 1 provider</p>
<p>• Kusama Encointer — 1 provider</p>
<p>• Kusama Coretime — 1 provider</p>
<p>• Kusama People — 1 provider</p>
<p><strong>Testnet</strong></p>
<p>• Westend Testnet — 1 provider</p>
<p><img src="https://emoji.discourse-cdn.com/twitter/tear_off_calendar.png?v=15" title=":tear_off_calendar:" class="emoji" alt=":tear_off_calendar:" loading="lazy" width="20" height="20"> <strong>Key Dates — Tender 5</strong></p>
<p>• 3 June 2026 — Start of Tender 5 application process</p>
<p>• 20 June 2026 — Tender hash submission deadline, 23:59 UTC</p>
<p>• 23 June 2026 — Full tender document submission deadline, 23:59 UTC</p>
<p>• 28 June 2026 — Completion of scoring</p>
<p>• 30 June 2026 — Announcement of selected providers</p>
<p>• 30 June 2026 — End of Tender 4</p>
<p>• 1 July 2026 — Start of Tender 5 service period</p>
<p>• 1 December 2026 — Start of Tender 6 application process</p>
<p>• 31 December 2026 — End of Tender 5</p>
<p>• 1 January 2027 — Start of Tender 6 service period</p>
<p><strong>Important note on pricing</strong></p>
<p>Each tender must include a clear and final cost breakdown for every Relay and System chain proposed.</p>
<p>Conditional pricing will not be accepted. This includes any pricing structure such as “if A, then price B” or “if C + D are selected, then price E”. All submitted prices must be final, standalone, and directly scorable by curators.</p>
<p>Any tender containing conditional pricing may be rejected from the scoring process.</p>
<p>Thank you to all providers for the services delivered during Tender 4. We look forward to receiving your submissions for Tender 5.</p>
<p>-– RPC Bounty Curators</p>

Upcoming Tender Rounds for Public RPC Bounty Program

<h1><a name="p-39292-h-1-pallet-xp-1" class="anchor" href="#p-39292-h-1-pallet-xp-1" aria-label="Heading link"></a>(1) Pallet-XP</h1>
<h4><a name="p-39292-a-frame-pallet-for-programmable-xp-experience-points-and-reputation-systems-2" class="anchor" href="#p-39292-a-frame-pallet-for-programmable-xp-experience-points-and-reputation-systems-2" aria-label="Heading link"></a>A FRAME pallet for programmable XP (Experience Points) and reputation systems.</h4>
<p>The first FRAME Suite component is now available: <strong>Pallet-XP</strong>, a runtime-native reputation and progression primitive for Substrate runtimes.</p>
<p>Pallet-XP is designed for non-monetary reputation and progression systems such as contributor reputation, validator trust, governance participation, and skill progression.</p>
<h3><a name="p-39292-announcement-polkadot-forum-post-3" class="anchor" href="#p-39292-announcement-polkadot-forum-post-3" aria-label="Heading link"></a><img src="https://emoji.discourse-cdn.com/twitter/loudspeaker.png?v=15" title=":loudspeaker:" class="emoji" alt=":loudspeaker:" loading="lazy" width="20" height="20"> <strong>Announcement (Polkadot-Forum) Post</strong></h3>
<aside class="quote quote-modified" data-post="1" data-topic="17763">
  <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/jobyreuben/48/11204_2.png" class="avatar">
    <div class="quote-title__text-content">
      <a href="https://forum.polkadot.network/t/announcing-pallet-xp-experience-points-for-substrate-polkadot-sdk-runtimes/17763"><img width="20" height="20" src="https://emoji.discourse-cdn.com/twitter/rocket.png?v=15" title="rocket" alt="rocket" class="emoji"> Announcing Pallet-XP: Experience Points for Substrate (Polkadot-SDK) Runtimes</a> <a class="badge-category__wrapper " href="/c/polkadot-technology/6"><span data-category-id="6" style="--category-badge-color: #0088CC; --category-badge-text-color: #FFFFFF;" data-drop-close="true" class="badge-category --style-square " title="If you’re looking for discussion or discourse for anything and all things Tech related, then this is the place for you. ."><span class="badge-category__name">Tech Talk</span></span></a>
    </div>
  </div>
  <blockquote>
    <a name="p-39290-a-reputation-progression-primitive-for-substrate-1" class="anchor" href="#p-39290-a-reputation-progression-primitive-for-substrate-1" aria-label="Heading link"></a><img width="20" height="20" src="https://emoji.discourse-cdn.com/twitter/key.png?v=15" title="key" alt="key" class="emoji"> A Reputation &amp; Progression Primitive for Substrate
We are excited to release <a href="https://auguth.github.io/frame-suite/pallet-xp" rel="noopener nofollow ugc">Pallet-XP</a>, a new Substrate (Polkadot-SDK) FRAME pallet from Auguth Labs. 
<a href="https://auguth.github.io/frame-suite/pallet-xp" rel="noopener nofollow ugc">Pallet-XP</a> is a runtime-native reputation and progression system designed as an alternative to <a href="https://crates.io/crates/pallet-balances" rel="noopener nofollow ugc">pallet-balances</a> for non-monetary use cases. 
<a href="https://medium.com/p/building-reputation-as-a-runtime-primitive-the-architecture-behind-pallet-xp-e70bfb08a552" target="_blank" rel="noopener nofollow ugc"></a> <a href="https://medium.com/p/building-reputation-as-a-runtime-primitive-the-architecture-behind-pallet-xp-e70bfb08a552" target="_blank" rel="noopener nofollow ugc">
  
    [Medium]
    
      Check out our Medium Article (For detailed write-up)
    
  
</a>
XP behaves like reputation (experience), not money: 
// Create a new XP identity accessible by owner only with in…
  </blockquote>
</aside>

<hr>
<h3><a name="p-39292-homepage-4" class="anchor" href="#p-39292-homepage-4" aria-label="Heading link"></a><img src="https://emoji.discourse-cdn.com/twitter/house.png?v=15" title=":house:" class="emoji" alt=":house:" loading="lazy" width="20" height="20"> Homepage</h3>
<aside class="onebox allowlistedgeneric" data-onebox-src="https://auguth.github.io/frame-suite/pallet-xp/">
  <header class="source">
      <img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/8/8e2aae3f84cb6a5ff745967559c6ac439b972ebc.svg" class="site-icon" alt="" data-dominant-color="" width="500" height="500">

      <a href="https://auguth.github.io/frame-suite/pallet-xp/" target="_blank" rel="noopener nofollow ugc">auguth.github.io</a>
  </header>

  <article class="onebox-body">
    

<h3><a href="https://auguth.github.io/frame-suite/pallet-xp/" target="_blank" rel="noopener nofollow ugc">Experience Points (XP) for Substrate Runtimes | Pallet-XP</a></h3>

  <p>A reputation primitive for Web3.</p>


  </article>

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

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

<hr>
<h3><a name="p-39292-documentation-5" class="anchor" href="#p-39292-documentation-5" aria-label="Heading link"></a><img src="https://emoji.discourse-cdn.com/twitter/open_book.png?v=15" title=":open_book:" class="emoji" alt=":open_book:" loading="lazy" width="20" height="20"> Documentation</h3>
<p><a href="https://auguth.github.io/frame-suite/pallet-xp/docs" class="onebox" target="_blank" rel="noopener nofollow ugc">https://auguth.github.io/frame-suite/pallet-xp/docs</a></p>
<hr>
<h3><a name="p-39292-architecture-article-6" class="anchor" href="#p-39292-architecture-article-6" aria-label="Heading link"></a><img src="https://emoji.discourse-cdn.com/twitter/writing_hand.png?v=15" title=":writing_hand:" class="emoji" alt=":writing_hand:" loading="lazy" width="20" height="20"> Architecture Article</h3>
<p><a href="https://medium.com/p/building-reputation-as-a-runtime-primitive-the-architecture-behind-pallet-xp-e70bfb08a552" class="onebox" target="_blank" rel="noopener nofollow ugc">https://medium.com/p/building-reputation-as-a-runtime-primitive-the-architecture-behind-pallet-xp-e70bfb08a552</a></p>
<hr>
<h3><a name="p-39292-api-reference-7" class="anchor" href="#p-39292-api-reference-7" aria-label="Heading link"></a><img src="https://emoji.discourse-cdn.com/twitter/books.png?v=15" title=":books:" class="emoji" alt=":books:" loading="lazy" width="20" height="20"> API Reference</h3>
<aside class="onebox allowlistedgeneric" data-onebox-src="https://docs.rs/pallet-xp/latest/pallet_xp/">
  <header class="source">
      <img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/5/55783cc7da19d832089f170828e1cad1dd3d0f15.svg" class="site-icon" alt="" data-dominant-color="" width="32" height="32">

      <a href="https://docs.rs/pallet-xp/latest/pallet_xp/" target="_blank" rel="noopener nofollow ugc">docs.rs</a>
  </header>

  <article class="onebox-body">
    

<h3><a href="https://docs.rs/pallet-xp/latest/pallet_xp/" target="_blank" rel="noopener nofollow ugc">pallet_xp - Rust</a></h3>

  <p>Pallet XP - Experience Points for Substrate Runtimes</p>


  </article>

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

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

<hr>
<h3><a name="p-39292-crate-8" class="anchor" href="#p-39292-crate-8" aria-label="Heading link"></a><img src="https://emoji.discourse-cdn.com/twitter/package.png?v=15" title=":package:" class="emoji" alt=":package:" loading="lazy" width="20" height="20"> Crate</h3>
<p><a href="https://crates.io/crates/pallet-xp" class="onebox" target="_blank" rel="noopener nofollow ugc">https://crates.io/crates/pallet-xp</a></p>
<hr>
<h3><a name="p-39292-source-code-9" class="anchor" href="#p-39292-source-code-9" aria-label="Heading link"></a><img src="https://emoji.discourse-cdn.com/twitter/hammer_and_wrench.png?v=15" title=":hammer_and_wrench:" class="emoji" alt=":hammer_and_wrench:" loading="lazy" width="20" height="20"> Source Code</h3>
<aside class="onebox allowlistedgeneric" data-onebox-src="https://docs.rs/pallet-xp/0.1.1/src/pallet_xp/lib.rs.html#16-2537">
  <header class="source">
      <img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/5/55783cc7da19d832089f170828e1cad1dd3d0f15.svg" class="site-icon" alt="" data-dominant-color="" width="32" height="32">

      <a href="https://docs.rs/pallet-xp/0.1.1/src/pallet_xp/lib.rs.html#16-2537" target="_blank" rel="noopener nofollow ugc">docs.rs</a>
  </header>

  <article class="onebox-body">
    

<h3><a href="https://docs.rs/pallet-xp/0.1.1/src/pallet_xp/lib.rs.html#16-2537" target="_blank" rel="noopener nofollow ugc">lib.rs - source</a></h3>

  <p>Source of the Rust file `src/lib.rs`.</p>


  </article>

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

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

<hr>
<h3><a name="p-39292-xp-trait-family-10" class="anchor" href="#p-39292-xp-trait-family-10" aria-label="Heading link"></a><img src="https://emoji.discourse-cdn.com/twitter/puzzle_piece.png?v=15" title=":puzzle_piece:" class="emoji" alt=":puzzle_piece:" loading="lazy" width="20" height="20"> XP Trait Family</h3>
<aside class="onebox allowlistedgeneric" data-onebox-src="https://docs.rs/frame-suite/latest/frame_suite/xp/index.html">
  <header class="source">
      <img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/5/55783cc7da19d832089f170828e1cad1dd3d0f15.svg" class="site-icon" alt="" data-dominant-color="" width="32" height="32">

      <a href="https://docs.rs/frame-suite/latest/frame_suite/xp/index.html" target="_blank" rel="noopener nofollow ugc">docs.rs</a>
  </header>

  <article class="onebox-body">
    

<h3><a href="https://docs.rs/frame-suite/latest/frame_suite/xp/index.html" target="_blank" rel="noopener nofollow ugc">frame_suite::xp - Rust</a></h3>

  <p>Defines a interface for managing “Experience Points” (XP) as an abstract economic primitive or a constrained resource.</p>


  </article>

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

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

<hr>
<p>This is the first release under the <strong>FRAME Suite ecosystem</strong>, with more modular staking SDK pallets components planned in the coming month.</p>

FRAME Suite - Updates Thread

<p>I’m assuming that people were not selecting providers evenly and some were being overloaded whilst others under utilised and the load needs balanced? Is this the case? If so, couldn’t we add a check to RPC calls that ensures secure random selection on the client side before a call is made - e.g. you randomly generate a number that selects a provider from the known finite list and you sign that number + timestamp. This would ensure an even spread across nodes and places the load balancing resonsibility with the client. Obviously geolocation becomes an issue but you can add checks for that during selection and on the host side using ip dbs.</p>

Dusan Morhac

A New Chapter for ParaSpell XCM Tools

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

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

referenda1

treasury22

discussions1392