candidates

members

proficients

fellows

senior_fellows

experts

senior_experts

masters

senior_masters

grand_masters

Miscellaneous

Request for Feedback - Web3 Ad Targeting Marketplace

2025-06-20 Technical Fellowship OpenDev Call

Tommi Enenkel / Alice und Bob | Mangata

2025-03-18 Technical Fellowship OpenDev Call

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.

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

Postmortem: XCM InitiateTransfer Origin Leak

Cisco

Grey/JAR Update: Lean 4 specification, linear memory model, faster than PolkaVM

Wei Tang

Introducing Polkadot-API v2

Victor Oliva

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

# 1 Wallet. 16 Ghost Validators. 50,000 KSM. Who Is Silently Killing Kusama&rsquo;s Only Revenue-Generating Project?

David barinas

# 1 Wallet. 16 Ghost Validators. 50,000 KSM. Who Is Silently Killing Kusama's Only Revenue-Generating Project?

Encointer Treasury Proposal: Unclear Value and Questionable Governance

Clarifying Kusama&rsquo;s Governance Direction: Independence or Integration?

Adrian Catangiu

Clarifying Kusama's Governance Direction: Independence or Integration?

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

Ecosystem

Suno - Yet another way to manage Substrate Node Operations from your terminal

paulo // turboflakes.io

Polkadot PR Workshops

Xiena

:turtle: Turtle - The unified app for token movement on Polkadot

swenthebuilder

🐢 Turtle - The unified app for token movement on Polkadot

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

Good reads on proof-of-personhood

Alain Brenzikofer

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

How to P<>K bridge USDT or USDC

Asset Hub Migration - XCM FAQ

Remy Le Berre

Hey everyone,
Last year, I started building a terminal user interface, I thought it was something missing in the ecosystem that could give node operators alternative options to manage their nodes.
It has now reached a stage that I’m happy to share it with you all. `suno` is designed to monitor live network data and manage your own or third-party nodes directly from your terminal.
As a node operator, you can monitor your validators, update staking details, set validate or chill intentions, and manage session (set or purge). All operations are executed through a proxy-only account.
As a nominator, you can just as easily track the validators you nominate, no proxy is required.
There are a few other features planned, you can read more about them in the project repo here: <a href="https://github.com/turboflakes/suno" rel="noopener nofollow ugc">https://github.com/turboflakes/suno</a>
If you’re willing to give it a try, let me know how it works for you. Any feedback or questions are all very welcome.
<img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/9/959b29ad2c46eb526259dc6c4f5b5c555b3ba576.gif" alt="suno-dark" data-base62-sha1="lltzPibw7chGHrzZyjIyC2BdBbg" width="690" height="336" class="animated">
Enjoy!

Coming back to this post as I’m currently architecting a hiring plan for a PR for our team. Even though these workshops were last year, the principles of newsworthiness and media engagement you outlined remain highly relevant.
I’m curious if the Distractive team has updated their “missteps to avoid” list based on the 2026 market cycle?
I’d be interested in seeing any legacy resources from these sessions as we vet potential PR superstars for our upcoming milestones.
And I would like some best advices which PR agencies are good in UK? I’m thinking of PR Superstar as I see is very famous for big projects.

I did Turtle. Like most Polkadot projects, these are mainly good for examples and setting standards. I think many example projects are needed to grow Polkadot to where new devs are excited to build on it.

I commissioned my good buddy Michael Bay to whip me up an action-packed <a href="https://youtu.be/veLg_Fu6elY?si=ddqUK-XsVHfd4l5e" rel="noopener nofollow ugc">demo</a> video

Liliana Mendez

<h2><a name="p-38472-summary-1" class="anchor" href="#p-38472-summary-1" aria-label="Heading link"></a>Summary</h2>
An XCM issue was reported via the bug bounty program. The issue allowed any account to act as any chain via XCM. In Asset Hub it means root access for many chains. In general it gives them access to the sovereign accounts. This was not exploited. The issue was patched on all system parachains, Polkadot and Kusama and communications established with all ecosystem teams who also patched. We’re now working on making sure these issues are found and fixed earlier.
<h2><a name="p-38472-the-bug-2" class="anchor" href="#p-38472-the-bug-2" aria-label="Heading link"></a>The bug</h2>
A reporter claimed the InitiateTransfer instruction in the XCM executor contains a logic flaw where ClearOrigin followed by InitiateTransfer { preserve_origin: true } produces an outbound message with no origin-modifying instruction (neither AliasOrigin nor ClearOrigin). This causes the destination chain to process user-supplied remote_xcm with the HRMP/UMP transport sender’s origin (e.g., Parachain(1000) for Asset Hub). Combined with the relay chain’s LocationAsSuperuser configuration for Asset Hub, this allows any signed account on Asset Hub to dispatch arbitrary calls as root on the Polkadot relay chain.
It also allows an account on any chain to impersonate it and control the sovereign accounts of that chain on other chains. For example, if a user on Parachain(2000) were to exploit this and send an XCM to Asset Hub, it could impersonate Parachain(2000) and take all the funds in its sovereign account.
<h3><a name="p-38472-affected-repository-3" class="anchor" href="#p-38472-affected-repository-3" aria-label="Heading link"></a>Affected Repository</h3>
polkadot-sdk (XCM executor: <a href="https://github.com/paritytech/polkadot-sdk/blob/bc42349097da2ad8e551e1dde174d3fc79fe8c5b/polkadot/xcm/xcm-executor/src/lib.rs#L1369-L1384" rel="noopener nofollow ugc">polkadot/xcm/xcm-executor/src/lib.rs</a>)
<h3><a name="p-38472-details-about-the-bug-4" class="anchor" href="#p-38472-details-about-the-bug-4" aria-label="Heading link"></a>Details about the bug</h3>
The bug is at lines 1369-1384 of the XCM executor:
<aside class="onebox githubblob" data-onebox-src="https://github.com/paritytech/polkadot-sdk/blob/bc42349097da2ad8e551e1dde174d3fc79fe8c5b/polkadot/xcm/xcm-executor/src/lib.rs#L1369-L1384">
 <header class="source">

 <a href="https://github.com/paritytech/polkadot-sdk/blob/bc42349097da2ad8e551e1dde174d3fc79fe8c5b/polkadot/xcm/xcm-executor/src/lib.rs#L1369-L1384" target="_blank" rel="noopener nofollow ugc">github.com/paritytech/polkadot-sdk</a>
 </header>

 <article class="onebox-body">
 <h4><a href="https://github.com/paritytech/polkadot-sdk/blob/bc42349097da2ad8e551e1dde174d3fc79fe8c5b/polkadot/xcm/xcm-executor/src/lib.rs#L1369-L1384" target="_blank" rel="noopener nofollow ugc">polkadot/xcm/xcm-executor/src/lib.rs</a></h4>

<div class="git-blob-info">
 <a href="https://github.com/paritytech/polkadot-sdk/blob/bc42349097da2ad8e551e1dde174d3fc79fe8c5b/polkadot/xcm/xcm-executor/src/lib.rs#L1369-L1384" rel="noopener nofollow ugc"><code>bc4234909</code></a>
</div>



 <pre class="onebox"><code class="lang-rs">
 <ol class="start lines" start="1369" style="counter-reset: li-counter 1368 ;">
 <li>					if preserve_origin {</li>
 <li>						// We alias the origin if it's not a noop (origin != `Here`).</li>
 <li>						if let Some(original_origin) = self</li>
 <li>							.origin_ref()</li>
 <li>							.filter(|origin| *origin != &amp;Location::here())</li>
 <li>							.cloned()</li>
 <li>						{</li>
 <li>							// preserve current origin for subsequent user-controlled instructions on</li>
 <li>							// remote chain</li>
 <li>							let reanchored_origin = Self::try_reanchor(original_origin, &amp;destination)?.0;</li>
 <li>							message.push(AliasOrigin(reanchored_origin));</li>
 <li>						}</li>
 <li>					} else {</li>
 <li>						// clear origin for subsequent user-controlled instructions on remote chain</li>
 <li>						message.push(ClearOrigin);</li>
 <li>					}</li>
 </ol>
 </code></pre>



 </article>

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

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

When preserve_origin = true and self.origin_ref() returns None (because ClearOrigin was executed earlier), the if let Some(…) fails silently. The code pushes nothing – no AliasOrigin, no ClearOrigin. The else branch (which pushes ClearOrigin) is unreachable because the outer if preserve_origin is true.
This is a regression introduced by <a href="https://github.com/paritytech/polkadot-sdk/pull/7423" rel="noopener nofollow ugc">PR#7423</a>, which was the fix for a security issue (fee bypass via UnpaidExecution ordering). Before PR #7423, preserve_origin: true with origin = None would return XcmError::BadOrigin. The refactored code silently skips instead.
<h2><a name="p-38472-timeline-5" class="anchor" href="#p-38472-timeline-5" aria-label="Heading link"></a>Timeline</h2>
All times are in UTC
<ul>
<li>
Monday 16 February - 15:54: Security team triages a report submitted to Parity’s Bug Bounty.
</li>
<li>
Monday 16 February - 15:59: Security confirms and validates the impact of the report, Engineers are informed of the report.
</li>
<li>
Monday 16 February - 16:11: Incident room channel in element created
</li>
<li>
Monday 16 February - 16:49: Mitigation with XcmExecuteFilter thought of
</li>
<li>
Monday 16 February - 17:02: Mitigation wouldn’t work for send
</li>
<li>
Monday 16 February - 17:48: Fix needs to go on unstable2507
</li>
<li>
Monday 16 February - 18:40: Fix needed changes to pass existing tests
</li>
<li>
Monday 16 February - 19:11: staging-xcm-executor patch version 23.0.1 published
</li>
<li>
Monday 16 February - 19:24: running PET against release 2.0.7 to make sure the fix introduced no regressions
</li>
<li>
Monday 16 February - 20:25: <a href="https://polkadot.subsquare.io/referenda/1840" rel="noopener nofollow ugc">Polkadot OpenGov Proposal</a> up
</li>
<li>
Monday 16 February - 20:27: <a href="https://collectives.subsquare.io/fellowship/referenda/476" rel="noopener nofollow ugc">Fellowship Whitelist Proposal</a> up
</li>
<li>
Monday 16 February - 20:30: Fellowship Whitelist Proposal decision deposit placed
</li>
<li>
Monday 16 February - 20:52: OpenGov Proposal decision deposit placed
</li>
<li>
Monday 16 February - 20:55: OpenGov Proposal decision started
</li>
<li>
Monday 16 February - 20:57: Fellowship Whitelist Proposal decision started
</li>
<li>
Monday 16 February - 22:14: Created list of affected non-system parachains for Security to reach out and help them patch.
</li>
<li>
Monday 16 February - 23:25: First batch of non-system parachains contacted by security to disclose the vulnerability details and offer version backports.
</li>
<li>
Tuesday 17 February - 13:46: stable2512 patched
<ul>
<li>
staging-xcm-executor 24.0.1
</li>
<li>
polkadot-sdk 2512.3.2
</li>
</ul>
</li>
<li>
Tuesday 17 February - 13:57: stable2503 patched
<ul>
<li>staging-xcm-executor 19.1.4</li>
</ul>
</li>
<li>
Tuesday 17 February - 16:55: Parachain patched
</li>
<li>
Tuesday 17 February - 21:41: Security confirms with the Data team there are no previous traces of exploitation.
</li>
<li>
Wednesday 18 February - 14:44: <a href="https://kusama.subsquare.io/referenda/635" rel="noopener nofollow ugc">Kusama OpenGov Proposal</a> submitted
</li>
<li>
Wednesday 18 February - 14:44: <a href="https://kusama.subsquare.io/fellowship/referenda/129" rel="noopener nofollow ugc">Kusama Fellowship Whitelist Proposal</a> submitted
</li>
<li>
Wednesday 18 February - 14:48: Kusama Fellowship Whitelist Proposal decision deposit placed
</li>
<li>
Wednesday 18 February - 15:54: stable2506 and stable2509 patched
<ul>
<li>
staging-xcm-executor 20.0.2
</li>
<li>
staging-xcm-executor 22.0.1
</li>
</ul>
</li>
<li>
Wednesday 18 February - 16:37: Fellowship Whitelist Proposal confirmation started
</li>
<li>
Wednesday 18 February - 17:08: Fellowship Whitelist Proposal confirmed
</li>
<li>
Wednesday 18 February - 17:13: Fellowship Whitelist Proposal executed
</li>
<li>
Wednesday 18 February - 16:36: Kusama OpenGov Proposal decision deposit placed
</li>
<li>
Wednesday 18 February - 18:42: Polkadot OpenGov Proposal confirmation started
</li>
<li>
Wednesday 18 February - 18:52: Polkadot OpenGov Proposal confirmed
</li>
<li>
Wednesday 18 February - 19:02: Polkadot OpenGov Proposal executed
</li>
<li>
Wednesday 18 February - 20:06: Polkadot system parachains patched
</li>
<li>
Wednesday 18 February - 21:58: Parachain patched.
</li>
<li>
Thursday 19 February - 18:32: Parity Security and Data teams set up transaction monitoring across the ecosystem to detect traces of exploitation.
</li>
<li>
Friday 20 February - 16:26: Parachain patched.
</li>
<li>
Saturday 21 February - 21:44: Parachain patched.
</li>
<li>
Monday 23 February - 06:38: Kusama Fellowship Whitelist Proposal executed.
</li>
<li>
Monday 23 February - 10:44: Kusama OpenGov Proposal executed.
</li>
<li>
Tuesday 24 February - 16:54: Parachain patched.
</li>
<li>
Friday 27 February - 21:24: Parachain patched.
</li>
</ul>
<h2><a name="p-38472-rca-root-cause-analysis-6" class="anchor" href="#p-38472-rca-root-cause-analysis-6" aria-label="Heading link"></a>RCA (Root Cause Analysis)</h2>
The root cause was pointed out by the bug bounty reporter.
<ul>
<li>
Why was this vulnerability not caught before the release of the code?
<ul>
<li>The original code was the introduction of XCMv5. That was reviewed and audited. The PR that introduced this vulnerability was a fix for an issue that arose during the audit. This PR was also reviewed as is customary. The process was followed as it should have been. However, the vulnerability was still not caught.</li>
</ul>
</li>
<li>
Why didn’t we find it earlier? After the review?
<ul>
<li>It was in an unhappy path we don’t expect any honest user to use. No system chain usage stumbled upon it, or community chain. This bug also only existed in XCMv5 and the transition to this new version took a long time on the majority of chains.</li>
</ul>
</li>
<li>
Why wasn’t it caught by a fuzzer?
<ul>
<li>The generated XCM can’t do anything on its own, it only results in malicious activity when sent to another chain.</li>
</ul>
</li>
<li>
Why couldn’t we catch this earlier than the Bounty Hunter, as the vulnerability was present for nearly a year?
<ul>
<li>We do actively search for security issues but the codebase is too big.</li>
</ul>
</li>
<li>
How did the Bounty Hunter catch it? Anything we can learn from that, or a tool we can use?
<ul>
<li>The reporter is planning to write a post detailing the process, we will review it after it’s out</li>
</ul>
</li>
</ul>
<h3><a name="p-38472-extra-7" class="anchor" href="#p-38472-extra-7" aria-label="Heading link"></a>Extra</h3>
<ul>
<li>
Why did it take ~21hs for the Fellowship Whitelist to execute?
<ul>
<li>There are many inactive fellows that while they don’t vote they raise the support threshold needed for proposals to pass faster</li>
</ul>
</li>
</ul>
<h2><a name="p-38472-action-items-8" class="anchor" href="#p-38472-action-items-8" aria-label="Heading link"></a>Action Items</h2>
<ul>
<li>
Improve the XCM fuzzer, include more chains and more invariants to check for.
</li>
<li>
Deploy pause-tx or safe-mode pallets to system parachains (issue: <a href="https://github.com/polkadot-fellows/runtimes/issues/1089" rel="noopener nofollow ugc">https://github.com/polkadot-fellows/runtimes/issues/1089</a>)
</li>
<li>
Maintain a list of invariants (LLMs can really help build it) and check against it in CI for each PR (also automatable through AIs)
<ul>
<li>Can be per-topic / per code area / per components (consensus, weights, runtime state, XCM, etc)</li>
</ul>
</li>
<li>
Do a first screening of all PRs against potential security vulnerabilities with LLMs
</li>
<li>
Kick a bunch of inactive fellows to decrease the whitelisting proposal duration by up to 25 hrs (in case of 2.0.7).
</li>
</ul>
<h2><a name="p-38472-acknowledgement-9" class="anchor" href="#p-38472-acknowledgement-9" aria-label="Heading link"></a>Acknowledgement</h2>
This vulnerability report was submitted and rewarded to <a href="https://x.com/gbrigandi" rel="noopener nofollow ugc">Gianluca Brigandi</a> (<a href="https://www.perimetersec.io/" rel="noopener nofollow ugc">Perimeter</a>) who wanted to be publicly acknowledged.

<a href="https://github.com/bitarray/grey" rel="noopener nofollow ugc">Grey</a> is an experiment for an LLM agent to write a JAM node implementation. You can read the initial announcement <a href="https://forum.polkadot.network/t/announcing-grey-0-1-llm-tries-to-build-a-jam-node-implementation/17284">here</a>.
Here are some updates I would like to report on behalf of Grey.
<h3><a name="p-38471-lean-4-formalization-1" class="anchor" href="#p-38471-lean-4-formalization-1" aria-label="Heading link"></a>Lean 4 formalization</h3>
We created the project <a href="https://github.com/bitarray/jar" rel="noopener nofollow ugc">JAR</a>. JAR is a Lean 4 formalization of the JAM protocol. Doing this would allow us to cross-check Grey’s implementation with JAR, and vice versa. JAR also contains its own testing framework, fuzzing framework, as well as a “variant” system to support multiple specifications.
We do this because we want to evolve the specification independently – try out new things, and get an “optimal protocol specification” that is faster than JAM. The “variant” system then allows us to keep testing against old versions, so that we know that whatever improvements we do, we won’t break things.
<h3><a name="p-38471-linear-memory-model-2" class="anchor" href="#p-38471-linear-memory-model-2" aria-label="Heading link"></a>Linear memory model</h3>
In JAR’s <code>jar080_tiny</code> specification, we implemented an experimental linear memory model. Linear layout packs all data into a single contiguous RW region at address 0:
<pre><code class="lang-auto"> [0, s) stack (SP = s, grows toward 0)
 [s, s + |a|) arguments
 [s + |a|, s + |a| + |o|) RO data
 [s + |a| + |o|, ... + |w|) RW data
 [... + |w|, heap_top) heap
</code></pre>
No guard zone, no read-only pages, no zone alignment gaps. We think those are unnecessary – the benefits to protocol security or even the PVM program correctness is entirely marginal.
The linear memory model allows us to do certain optimizations that is really close to native, even without requiring signal handlers. And we generally just like the simplicity of it.
<h3><a name="p-38471-grey-is-really-fast-faster-than-polkavm-3" class="anchor" href="#p-38471-grey-is-really-fast-faster-than-polkavm-3" aria-label="Heading link"></a>Grey is really fast, faster than PolkaVM!</h3>
In our benchmarks, we now beat PolkaVM consistently with pipeline gas metering. This includes secp256k1 ecrecover, a known bottleneck for some JAM teams building EVM services on top of JAM. For this, we’re around 1.4x faster.
Some architectural design of PolkaVM is really just incorrect. For example, we’re 36x faster than PolkaVM (Linux sandbox) on the hostcall benchmark.
<div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/e/e2c6ddf8970b62c4e3896848f5af9e6c037b43c7.png" data-download-href="/uploads/short-url/wm9YHwemDDtpi026SVZFoYIU1YX.png?dl=1" title="Screenshot 2026-03-19 at 04.49.10" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/e/e2c6ddf8970b62c4e3896848f5af9e6c037b43c7.png" alt="Screenshot 2026-03-19 at 04.49.10" data-base62-sha1="wm9YHwemDDtpi026SVZFoYIU1YX" width="690" height="234" data-dominant-color="333334"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg>Screenshot 2026-03-19 at 04.49.101076×366 26.2 KB<svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div>
To my surprise, Grey did write certain novel improvements. There’s at least one optimization in Grey that I know is NOT available anywhere else. Exactly which one that is, I invite the readers to check out the codebase!
<h3><a name="p-38471-community-and-links-4" class="anchor" href="#p-38471-community-and-links-4" aria-label="Heading link"></a>Community and links</h3>
<ul>
<li>Matrix: <a href="https://matrix.to/#/#jar:matrix.org" rel="noopener nofollow ugc">https://matrix.to/#/#jar:matrix.org</a></li>
<li>Grey: <a href="https://github.com/bitarray/grey" class="inline-onebox" rel="noopener nofollow ugc">GitHub - bitarray/grey: LLM tries to build a JAM node implementation. · GitHub</a></li>
<li>JAR: <a href="https://github.com/bitarray/jar" class="inline-onebox" rel="noopener nofollow ugc">GitHub - bitarray/jar: Join-Accumulate Refine · GitHub</a></li>
</ul>

hi <a class="mention" href="/u/bkchr">@bkchr</a>, happy to see you like our project!!! happy to onboard you and test our MCP.
We set-up few OKRS that we want to accomplish and we describe the roles we want to join to the team:
<h2><a name="p-38467-okrs-1" class="anchor" href="#p-38467-okrs-1" aria-label="Heading link"></a>OKRS</h2>
<pre><code class="lang-auto">Objective 0: Reach break-even
Result 1: Achieve monthly net profit ≥ $0 (revenue − COGS − OpEx).
Result 2: Maintain burn multiple ≤ 1.0 (net burn / net new ARR) for the period.
Objective 1: Scale local-currency payments volume
Result 1: Reach $500,000 USD-equivalent in processed volume across COP/MXN.
Result 2: Maintain weekly tracking/reporting of COP/MXN TPV (single source of truth).
Objective 2: Launch OpenClaw Agents debit card
Result 1: Ship the debit card for OpenClaw Agents to production (cards issuable).
Result 2: Complete first successful live transaction by an agent.
Objective 3: Run a highly reliable infrastructure
Result 1: Maintain ≥99.9% monthly uptime for production infrastructure.
Result 2: Track incidents with postmortems for 100% of Sev1/Sev2 events.
Objective 4: Expand distribution via company onboarding
Result 1: Onboard 15 companies to production (live + first transaction).
Result 2: Achieve 15/15 integrations with completed go-live checklist.
</code></pre>
<h2><a name="p-38467-hires-2" class="anchor" href="#p-38467-hires-2" aria-label="Heading link"></a>Hires</h2>
<pre><code class="lang-auto">....
11) Funds used for
Total: $72,000 = $3,000 × 4 × 6 months
Team allocation (example roles; final allocation may vary slightly by hiring availability):
Backend Engineer (Payments / Ledger): throughput, consistency guarantees, event processing.
Backend / Integrations Engineer: multi‑asset routing, local token support, partner onboarding.
DevOps / Reliability Engineer : observability, incident response, scaling, infra hardening.
Compliance Officer/ Legal Ops: spend controls, permissions, compliance automation, audit readiness.
</code></pre>

Bastian Köcher

Encointer has been experimenting for 5 years, receiving substantial funding and grants, yet it still has very few users. Why continue throwing money at it?
The project had its chance, but it is not viable to keep it on life support while continuing to experiment for another five years.

Chris T

Thanks a lot <a class="mention" href="/u/thomasr">@ThomasR</a>, <a class="mention" href="/u/stakeworld">@stakeworld</a>, <a class="mention" href="/u/shannonwells">@shannonwells</a>. I’m only building on top of what has been built so far, happy to see your support. <a class="mention" href="/u/stakeworld">@stakeworld</a> I saw your comments earlier, I think on Element, I agree it’s not a good look. I hope this effort contributes positively. I’ll keep improving it.

Kutsal Kaan Bilgin

🛠️ chainconsole.com - Polkadot JS Apps Fork with Bug Fixes and Improvements

<aside class="quote no-group" data-username="0xTaylor" data-post="4" data-topic="17340">
<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/0xtaylor/48/4242_2.png" class="avatar"> 0xTaylor:</div>
<blockquote>
took a look at it. FYI, anyone can bypass the waitlist if they know the API endpoint to sign-up. I’d suggest adding an invite token to the sign-up if you want to enforce that. The research agent was rate limited pretty quickly when it was trying to search the forum on a topic. I imagine you’ll have a similar issue given free subscan api and multiple concurrent users. You did a decent job of proper authorization control on endpoints at least which is better than most apps that popup in this eco.
It also goes into deep research no matter the question. I asked it to describe polkadot in 1 sentence and while it had an answer, it still tried to look on the Polkadot forum.
You’re gonna have a very hard time getting funding for this project though either way. OpenGov is dead, they have made participation percentages higher so W3F/Parity are required to vote or it won’t pass and W3F is no longer participating. <a href="https://x.com/BillLaboon/status/2033588420002369975?s=20" rel="noopener nofollow ugc">https://x.com/BillLaboon/status/2033588420002369975?s=20</a>
</blockquote>
</aside>
Thank you so much <a class="mention" href="/u/0xtaylor">@0xTaylor</a> for checking it out and for the detailed feedback, really appreciate it. 
I’m closing the waitlist bypass asap. I’ll add invite token validation to the signup endpoint.
The rate limiting concern is fair too. Right now I’m on free tier which won’t hold up with multiple concurrent users. I’ll upgrade and implement long term caching and other solutions before that becomes a real problem and for other sources such as subscan, I maintain a subsquid indexer as fallback, will add more events to that to resolve any dependencies on those sources.
I’ll also tweak the query classification so it only does deep research when the question actually needs it.
Thanks again for the honest review, this is useful stuff.
If you’re interested any further, I can give your email a tester role, with uncapped rate limits.
P.S. Waitlist is now mandatory. Signup now goes through a database-level hook that checks waitlist approval status before any account can be created. Direct API calls to the signup endpoint without an approved waitlist entry get a 403.
Polkadot Forum topics and posts are now indexed as well, to deal with rate limiting issues.

Mridul Arya

Blockpedia: plain English explorer for Polkadot with cited &amp; verifiable sources, looking for feedback

Blockpedia: plain English explorer for Polkadot with cited & verifiable sources, looking for feedback

Thanks for raising this and keeping the accountability bar high! <img src="https://emoji.discourse-cdn.com/twitter/+1/2.png?v=15" title=":+1:t2:" class="emoji" alt=":+1:t2:" loading="lazy" width="20" height="20">

Hi everyone!
First, a quick update: We’ve managed to secure funding for the basic maintenance of PAPI for 2026, for now covering just one of us. We’re still in conversations about bringing additional work for new features and improvements, though progress is slower than we would hope.
During the end of 2025 we worked on a Polkadot-API v2. This was one of the items included in our previous proposal, which brings a clearer and more consistent API across the library, along with performance improvements and new features.
Since January, we’ve focused on stabilizing the new API. We are currently on Release Candidate 5, and are planning to release the final version very soon.
You can try it out with:
<pre><code class="lang-auto">npm i polkadot-api@rc
</code></pre>
You can also find a migration guide in <a href="https://papi.how/v2migration" rel="noopener nofollow ugc">our docs</a> (which has been structured so that AI tools can also assist with migrations <img src="https://emoji.discourse-cdn.com/twitter/wink.png?v=15" title=":wink:" class="emoji" alt=":wink:" loading="lazy" width="20" height="20">).
We kept the breaking changes as lean as possible to make migration easier. We believe small, periodic breaking changes are preferable to accumulating technical debt, especially in an ecosystem that evolves quickly, while still maintaining valuable stability.
Here are some highlights of the v2 improvements.
<h3><a name="p-38439-websocket-enhancer-1" class="anchor" href="#p-38439-websocket-enhancer-1" aria-label="Heading link"></a>WebSocket enhancer</h3>
To support older <code>polkadot-sdk</code> nodes in v1, we offered a <code>withPolkadotSdkCompat</code> enhancer that translated and fixed the messages sent and received through those RPCs.
However, it was often confusing to know whether that enhancer was needed or not. In v2, PAPI automatically detects node capabilities and applies the necessary compatibility patches when required.
The end result is a simpler API, and for some operations a better performance overall. What previously required a few lines of code:
<pre data-code-wrap="ts"><code class="lang-ts">// v1
import { createClient } from "polkadot-api";
import { getWsProvider } from "polkadot-api/ws-provider";
import { withPolkadotSdkCompat } from "polkadot-api/polkadot-sdk-compat";

const client = createClient(
 withPolkadotSdkCompat(
 getWsProvider("wss://rpc.ibp.network/polkadot")
 )
);
</code></pre>
is now simply:
<pre data-code-wrap="ts"><code class="lang-ts">// v2
import { createWsClient } from "polkadot-api/ws";

const client = createWsClient("wss://rpc.ibp.network/polkadot");
</code></pre>
Less boilerplate, more focus on building things.
<h3><a name="p-38439-staticapi-2" class="anchor" href="#p-38439-staticapi-2" aria-label="Heading link"></a>StaticApi</h3>
For synchronous operations that don’t require a request to the node, such as accessing constants or building storage keys, v1 introduced a token that you would obtain after initialization, which could then be used to access those APIs synchronously.
However, this was often confusing and also hid an important detail: those operations depend on the runtime of a specific block.
For this reason, all synchronous APIs are now accessed through <code>await typedApi.getStaticApis({ at })</code>: This returns all the information available in the runtime of the block you select (defaulting to the finalized one).
<h3><a name="p-38439-uint8array-3" class="anchor" href="#p-38439-uint8array-3" aria-label="Heading link"></a>Uint8Array</h3>
Very early on, v1 introduced <code>Binary</code>, a class intended to provide a consistent API for working with binary data.
However, this added friction in some APIs. In v2, PAPI now uses JavaScript’s native <code>Uint8Array</code>, while <code>Binary</code> becomes a set of utilities to convert binary data into different formats (<code>HexString</code>, text, opaques, etc.).
<h3><a name="p-38439-chain-renames-4" class="anchor" href="#p-38439-chain-renames-4" aria-label="Heading link"></a>Chain renames</h3>
In v1 we used the chain name defined in the chain specs to identify networks. Some of these names were not very human-friendly (for example <code>ksmcc3</code> for Kusama or <code>westend2</code> for Westend).
They now use their actual names instead: <code>kusama</code>, <code>westend</code>, etc.
<h3><a name="p-38439-api-consistency-5" class="anchor" href="#p-38439-api-consistency-5" aria-label="Heading link"></a>API consistency</h3>
Finally, we reviewed several APIs that had similar functionality but slightly different interfaces.
For example, some interfaces (like storage queries) took the target block as an optional parameter, while others exposed that option as a property inside an <code>options</code> object.
Another example was:
<pre data-code-wrap="ts"><code class="lang-ts">client.watchBlockBody(at: HexString)
</code></pre>
The name didn’t really make sense since the body of a block is immutable. It has now been renamed to:
<pre data-code-wrap="ts"><code class="lang-ts">client.getBlockBody$(at: HexString)
</code></pre>
Small changes individually, but together they add up to a better developer experience.
<h3><a name="p-38439-try-it-out-6" class="anchor" href="#p-38439-try-it-out-6" aria-label="Heading link"></a>Try it out!</h3>
There’s plenty more explained in the <a href="https://papi.how/v2migration" rel="noopener nofollow ugc">migration guide</a>. Give it a try by upgrading with:
<pre><code class="lang-auto">npm i polkadot-api@rc
</code></pre>
We’ve already upgraded the <a href="https://staking.usepapi.app/" rel="noopener nofollow ugc">Staking Optimizer</a> and the <a href="https://dev.papi.how/explorer#networkId=polkadot_asset_hub&amp;endpoint=wss%3A%2F%2Fsys.ibp.network%2Fasset-hub-polkadot" rel="noopener nofollow ugc">PAPI Console</a>, as well as our examples, and we’re very happy with the results so far. We’ve also received positive feedback from some early adopters.
If you give the RC a try, we’d love to hear your feedback. It will help us polish things before the final 2.0.0 release.

It is a timely proposal and aligned with the times we are living in. These are the kinds of details we need to pay attention to if we want new developers (or perhaps even non-developers) to start exploring Polkadot and building here. I’ve always said it: we need to make things easier, not more complicated. We need to move forward with these kinds of implementations that will allow more experimentation within the ecosystem.
A lot of information about Polkadot out there is outdated, and as long as that remains the case, it will be very difficult to change the perception that Web3 users have of Polkadot.
If every time someone searches for “how to build on Polkadot” they find information with deprecated APIs or references to slot auctions that no longer exist, the damage to the reputation is silent but constant.
This could easily be funded under the supervision of Parity. I hope you have great success.

Polkadot Agent Mesh: Claude Code Skills for Polkadot &amp; JAM

Polkadot Agent Mesh: Claude Code Skills for Polkadot & JAM

one of the major disappointments in the ecosystem for me has been that after all these years we still do not have proper primitives for end-to-end encryption. every wallet extension can sign messages, but none hold primitives for e2ee. the entire toolchain stops at signatures.
the root cause as far as i can tell is that sr25519 never got a proper encryption scheme implemented around it. the underlying curve is fully capable - ristretto255 supports ECDH key agreement, and from there it’s standard symmetric crypto (chacha20-poly1305 or xchacha20-poly1305). so afaik the math is not the problem, but the implementation just never got done.
the evidence is scattered across years of dead github issues:
<ul>
<li>polkadot-js/extension#691 - asymmetric encryption feature request, closed with “there is no exposed asymmetric encryption/decryption in sr25519”</li>
<li>polkadot-js/common#1124 - encrypt/decrypt attempted with sr25519 keypairs, doesn’t work because ed2curve conversion fails on ristretto-encoded pubkeys</li>
<li>polkadot-js/common#1314 - follow-up confirming sr25519 encryption is broken, maintainer response: “have not seen it out in the wild, if it doesn’t work it will need to be removed”</li>
<li>polkadot-js/extension#928 - another attempt, same wall</li>
</ul>
there is a golang implementation (hodo.dev) that does ECDH over sr25519 by expanding the secret key and doing scalar multiplication on the ristretto point. a python ECIES implementation exists using libsodium’s crypto_scalarmult_ristretto255. so it’s clearly possible. it’s just that nobody shipped it as a standard primitive in the JS/wasm toolchain that wallet extensions actually use.
i have now built a few applications where i always hit this rock wall that i do not want to hold or relay unencrypted user data. for example building <a href="http://whodb.org" rel="noopener nofollow ugc">whodb.org</a> i lost motivation trying to figure out how to do encryption with PGP. it fucking sucks. anyone thinking that PGP would see mass adaption is just fucking delusional at this point. encryption has to happen under the hood without end user having to think one second about it or it fails. 
now im building an <a href="https://sonotxt.com" rel="noopener nofollow ugc">application</a>(1337) for text-to-speech, speech-to-text and end-to-end translation with the idea of an open competitive marketplace for inference providers, handling finances through state channels and smart contracts on asset hub. the main lacking feature is encrypting and attesting inference between parties. latest nvidia data center GPUs support inference in TEEs with just about 10% overhead, yet no frontier lab provides this because the game is all about data mining your way to <a href="https://kusamaxi.com/post/permissionless" rel="noopener nofollow ugc">the stars</a>.
having accounts be polkadot sr25519 accounts just won’t cater for this. one option is that i write my own extension with ed25519 keys that have broad support for encryption - but that means not catering the existing user base and slightly removing the purpose of using polkadot at all.
as an application developer the options today are:
<ol>
<li>ask users to derive a separate ed25519 keypair from the same mnemonic and use nacl box. works but terrible UX - users now manage two key types, extensions don’t expose this, and it’s not standardized. all extensions can only do signing and wont support ed25519 so its not really viable either.</li>
<li>do ECDH directly on sr25519 ristretto points <a href="https://protocol.penumbra.zone/main/addresses_keys.html" rel="noopener nofollow ugc">ideally with ovk and ivk keys</a>. works in theory but no audited JS/wasm library ships this. and this would require all extensions to adapt it to be viable. something we should really</li>
<li>ignore the wallet entirely and use a separate key exchange protocol. but that defeats the purpose of having an identity system.</li>
</ol>
i think mission statement was something along the lines of building post snowden web. snowden revelations were all about government having a permanent record of citizens through private companies. right now tools we offer is basicly getting to have keys to our own slavery by having permanent public record of all our actions. what the fuck is that for post snowden web? i do really hope that im wrong and have missed something crucial here.
so that said as a ecosystem we should probably think of a way how to salvage the sitution. do we double down on sr25519 working encryption on it or should we rotate to use more <a href="https://www.rfc-editor.org/rfc/rfc8410" rel="noopener nofollow ugc">standardized</a> x25519 by having wallet implementations to derive an x25519 keypair from the same mnemonic at a different derivation path. publish the x25519 public key somewhere discoverable - could be an on-chain identity field, a well-known derivation that anyone can verify, or just exchanged out-of-band. then ECDH + chacha20-poly1305 for the encrypted channel. afaik this is essentially what signal does.
doubling down on sr25519 would mean implementing ECIES natively on the ristretto255 group that sr25519 already uses.
so ive been sparring this issue with a clanker and opened a draft PR on schnorrkel (<a href="https://github.com/paritytech/schnorrkel/pull/116/changes#diff-e7c8f1cc02961a0deb7a8d1884fbb41faebe96d153b3eba8eab37abea3379429R1-R907" rel="noopener nofollow ugc">paritytech/schnorrkel#116</a>) that implements full ECIES over ristretto255 with a penumbra-inspired viewing key hierarchy:
<ul>
<li>IncomingViewingKey (IVK) - a separate ECDH scalar derived one-way from the signing secret via merlin transcript. senders encrypt to the IVK public key. the signing key never touches the encryption path.</li>
<li>OutgoingViewingKey (OVK) - a 32-byte symmetric key derived from the same secret. the ephemeral secret gets wrapped under the OVK and appended to every ciphertext so the sender can re-read their own outgoing messages.</li>
<li>FullViewingKey (FVK) - bundles IVK + OVK + signing pubkey. can decrypt everything but cannot sign.</li>
</ul>
the ECIES scheme: ephemeral keypair per message, ECDH on ristretto255, merlin-derived chacha20-poly1305 with domain separation, AAD binding both public keys. 120 bytes overhead per message. the OVK wrap uses a separate domain and binds to the main ciphertext so blobs can’t be swapped between messages.
what still needs to happen if this path is chosen:
<ol>
<li>probably some actual cryptographer should take a look on it</li>
<li>schnorrkel wasm bindings need to expose encrypt/decrypt/derive_ivk/derive_ovk</li>
<li>polkadot-js or papi? needs to surface these in the keyring API</li>
<li>wallet extensions need an injected API method - something like keypair.encryptMessage(plaintext, recipientIvkPublic) and keypair.decryptMessage(ciphertext)</li>
<li>a convention for publishing IVK public keys - on-chain identity field, or a well-known derivation that anyone can verify from the signing pubkey. would not be forward secure but simple</li>
</ol>
with european union going full facist mode with their <a href="https://fincrimecentral.com/eu-privacy-coins-anonymous-crypto-ban-2027/" rel="noopener nofollow ugc">2027 ban</a> i feel that this issue is more pressing more pressing than now than ever. well is always been on the very top of my list i did expect w3f to deliver for polkadot to be relevant place to build respectful agentic(clientside) applications. slightly frustrating that nothing has come into fruition in a decade.

Dystopia awaits, lets encrypt

Runtime release notification
Hello,
This is to advise you that the Polkadot community is currently voting to upgrade the <a href="https://polkadot.subsquare.io/referenda/1862" rel="noopener nofollow ugc">Polkadot system</a> to the <a href="https://github.com/polkadot-fellows/runtimes/releases/tag/v2.1.1" rel="noopener nofollow ugc">v2.1.1 release</a>.
This is a major runtime upgrade that provides support for Phase 1 of the <a href="https://polkadot.subsquare.io/referenda/1827" rel="noopener nofollow ugc">Dynamic Allocation Pool (DAP)</a>, an issuance buffer configured as a multi-asset account (or sets of accounts) that collects all newly minted DOT as well as protocol revenue to allow specific outflows both in DOT and other assets.
<img src="https://emoji.discourse-cdn.com/twitter/construction.png?v=15" title=":construction:" class="emoji" alt=":construction:" loading="lazy" width="20" height="20"> Important note for Ecosystem participants: <img src="https://emoji.discourse-cdn.com/twitter/construction.png?v=15" title=":construction:" class="emoji" alt=":construction:" loading="lazy" width="20" height="20"> 
This release introduces numerous changes around staking and issuance which will stop treasury burns and redirect slashes in the first instance.
This release also provides the pre-requisites for making nominators non-slashable, allowing nominators to unbond funds in two eras, as well as enforcing a minimum self-stake and a minimum commission for validators. All these new parameters will be activated through subsequent OpenGov referenda.
You can find more details about all these changes in this <a href="https://forum.polkadot.network/t/changes-on-polkadot-in-march-2026/17101">forum post</a>.
Additional note for Ecosystem builders: 
A <a href="https://forum.polkadot.network/t/polkadot-technical-fellowship-calendar/11598">Polkadot Technical Fellowship calendar</a> has been set up to log basic information about upcoming runtime releases. You can subscribe to the Google calendar to access advance notices in real time.
The projected enactment date for this runtime upgrade is around 26th March 2026.
Many thanks.

Anaelle LTD

Runtime release notification for v2.1.1 [17.03.2026]

The Kusamarian has removed the video.
A mirrored version can be found on the official Polkadot account here:
<div class="youtube-onebox lazy-video-container" data-video-id="a-6phfzWrWU" data-video-title="OpenDev Core Polkadot Call - November 2025" data-video-start-time="" data-provider-name="youtube">
 <a href="https://www.youtube.com/watch?v=a-6phfzWrWU" target="_blank" class="video-thumbnail" rel="noopener nofollow ugc">
 <img class="youtube-thumbnail" src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/2/2fa2ecb7efa4a65fbe601022a030fcf782d61f4e.jpeg" title="OpenDev Core Polkadot Call - November 2025" data-dominant-color="C9229E" width="690" height="388">
 </a>
</div>

2025-11-18 Technical Fellowship OpenDev Call

The Kusamarian has removed the video.
A mirrored version can be found on the official Polkadot account here:
<div class="youtube-onebox lazy-video-container" data-video-id="eHo4UNSIKM8" data-video-title="OpenDev Core Polkadot Call - October 2025" data-video-start-time="" data-provider-name="youtube">
 <a href="https://www.youtube.com/watch?v=eHo4UNSIKM8" target="_blank" class="video-thumbnail" rel="noopener nofollow ugc">
 <img class="youtube-thumbnail" src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/a/ae188f91e20d5d5b1825505197d898ec0cef4fc0.jpeg" title="OpenDev Core Polkadot Call - October 2025" data-dominant-color="684D58" width="690" height="388">
 </a>
</div>

2025-10-21 Technical Fellowship OpenDev Call

The Kusamarian has removed the video.
A mirrored version can be found on the official Polkadot account here:
<div class="youtube-onebox lazy-video-container" data-video-id="eGbubFmqm5A" data-video-title="OpenDev Core Polkadot Call - September 2025" data-video-start-time="" data-provider-name="youtube">
 <a href="https://www.youtube.com/watch?v=eGbubFmqm5A" target="_blank" class="video-thumbnail" rel="noopener nofollow ugc">
 <img class="youtube-thumbnail" src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/5/5be2697a75c846a85f78ad32dc437f74c64962d7.jpeg" title="OpenDev Core Polkadot Call - September 2025" data-dominant-color="665557" width="690" height="388">
 </a>
</div>

2025-09-15 Technical Fellowship OpenDev Call

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

Implement pallet_content

Can't transfer KSM to centralized exchange

PoP Bounty – February 2026 Transparency Report

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

Confirming

Support Bloque, the ONLY revenue generating project in Kusama:  72K USD in 6 installments, scale 5x.

- This is about keeping the Kusama Technical Fellowship as its own group.
- A new rule says you can't remove or merge it without a special vote by Kusama token holders.
- This rule is being made because some people want to combine it with the Polkadot Fellowship.
- The community that would be affected should get to decide.
- This does not stop the two groups from working together right now.
- It also doesn't mean the Kusama group needs its own separate money.
- It just says you need a vote before making it go away.

Deciding

[WFC] No Fellowship Removal Without Kusama Vote

- X-Crystal is a project on the Kusama network.
- Join by sending an invitation transaction.
- Members can mint XCT tokens.
- Sometimes, you might get a gem NFT called XCG.
- Check the Mint tab on the website for rules.
- Find the code on GitHub.
- Use the given contract addresses for membership, NFT, and token.
- Email for questions or bugs.

X-Crystal is now live

- Encointer is asking for funding to continue its work for the second half of 2025.
- They want 73,811 Swiss Francs (about 93,821 US Dollars).
- They created a stablecoin system that lets communities swap it for USDC.
- They made a documentary and got featured in an article about their work in Africa.
- Their app now has a "Bazaar" feature to help local businesses advertise.
- Their communities in Tanzania and Nigeria are still active despite real-world problems.
- They earned about 13,000 Swiss Francs from sources other than their treasury.

Kusama

referenda4

treasury15

discussions1391