candidates

members

proficients

fellows

senior_fellows

experts

senior_experts

masters

senior_masters

grand_masters

Miscellaneous

What Are The People at W3F Actually Doing?

Mnemonic rejection

bill_w3f

Polkadot, Community, Transparency, OpenGov, and Poor Decisions

Mike

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:

Welcome to the Polkadot Forum 👋

Getting started: Read this first

Arwen Smit

Deleted item, no longer of concern

Jan-Jan

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

Tech Talk

Robonomics 5.0: a runtime-only repo on polkadot-omni-node, and a resource model for cyber-physical systems

Sergei Lonshakov

About 937 DOT in XCM v3 asset traps becomes unclaimable when chains drop v3

XCM Incident Review: What happened and what we learned

darkbeacon586

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

US$104M a year of Bolivian mining revenue, settled on Polkadot — 10M+ transactions a year

Collaborative decision deposits: live on Kusama, open for review

Proposal to Recalibrate Validator Rewards for a Smaller Set and the Move to Metanodes

Tuna

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

Ecosystem

Sensors.social: an open air-quality network on Polkadot is growing across the EU

Polkadot Socials Daily Digest: 2026-11-10

OpenShore

Polkadot Socials Daily Digest: 2026-11-04

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

Hi all — EnsRationis from Robonomics.
Sensors.social is an open environmental data network I designed, and it is now growing across the EU. Everything is open source: the Altruist sensors that feed it, the software that collects the readings, and the map.
Web3 does one job here, the one it is good at: it settles the data as a common good anyone can check, not a vendor’s database.
How it works on Robonomics
<ul>
<li>Owners who choose to share their Altruist’s data join the network; each sensor has its own key and signs every measurement it sends.</li>
<li>A connectivity node checks the signature and that the sensor has an active subscription on Robonomics, a parachain on Polkadot, then passes the reading to the live map.</li>
<li>The node collects readings into batches, stores each batch on IPFS and writes its hash to Robonomics. Anyone can fetch a batch and check it against the chain.</li>
<li>The network is federated: a city or a lab can run its own connectivity node, and its sensors still show up on the common map.</li>
<li>Next, with Robonomics 5.0: the reading the sensor signed goes on chain itself, so there is no need to trust the node at all.</li>
</ul>
Try the map: <a href="https://sensors.social" rel="noopener nofollow ugc">https://sensors.social</a>
<img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/8/8f135c0ee53e4584c0bc4dcc6622c50702e53f0b.gif" alt="sensors-social-europe" data-base62-sha1="kpHKSbjre8IggsiK9hxSGy70zbB" width="690" height="340" class="animated">
Happy to hear from anyone who wants to run a sensor in their city or build on the data.

Of course. It’s visible for everyone. And we talked to many others too. We have build at the end on Polkadot. So you guys should be really happy about this
<table>
</table><table>
<tbody><tr>
<td>
<svg class="fa d-icon d-icon-link-slash svg-icon" aria-hidden="true"><use href="#link-slash"></use></svg>
</td>
<td>
Paul Schmidt 
CEO | Heitaria Swiss AG 
<img src="https://dub1.discourse-cdn.com/flex005/images/transparent.png" alt="" role="presentation" width="1" height="1">Rigistrasse 1, 6374 Buochs 
<img src="https://dub1.discourse-cdn.com/flex005/images/transparent.png" alt="" role="presentation" width="1" height="1"> 
<img src="https://dub1.discourse-cdn.com/flex005/images/transparent.png" alt="" role="presentation" width="1" height="1"><a href="mailto:schmidt@heitaria.ch">schmidt@heitaria.ch</a>
</td>
</tr>
</tbody></table>

dandan

<h2><a name="p-42096-general-updates-1" class="anchor" href="#p-42096-general-updates-1" aria-label="Heading link"></a>General Updates</h2>
<ul>
<li>Polkadot’s treasury model remained a topic of education and community discussion, with explainers highlighting how ecosystem funding is structured through OpenGov (via <a href="https://x.com/BSCNews/status/2119624768622322056" rel="noopener nofollow ugc">BSCNews</a>, <a href="https://x.com/DGHUBCrypto/status/2119632849603056064" rel="noopener nofollow ugc">DGHUBCrypto</a>).</li>
</ul>
<h2><a name="p-42096-ecosystem-product-updates-2" class="anchor" href="#p-42096-ecosystem-product-updates-2" aria-label="Heading link"></a>Ecosystem &amp; Product Updates</h2>
<ul>
<li>Polkadot Hub mainnet now supports two production-ready Solidity paths: EVM via REVM for existing contracts, and PVM via <code>resolc</code> for PolkaVM, both using the same Ethereum RPC and accounts (via <a href="https://x.com/PolkadotDevs/status/2119766987450552789" rel="noopener nofollow ugc">PolkadotDevs</a>, <a href="https://x.com/TTT_News_/status/2119789281942344101" rel="noopener nofollow ugc">TTT_News_</a>).</li>
<li>Bifrost highlighted vDOT’s use on Hydration, where DOT can continue earning staking yield while being used as collateral, enabling strategies such as borrowing DOT against vDOT and minting additional vDOT (via <a href="https://x.com/Bifrost/status/2119612657414410406" rel="noopener nofollow ugc">Bifrost</a>).</li>
<li>Aventus reaffirmed its commitment to building on Polkadot, citing the ecosystem as its chosen foundation after years of blockchain infrastructure experience (via <a href="https://x.com/AventusNetwork/status/2119742308631364069" rel="noopener nofollow ugc">AventusNetwork</a>, <a href="https://x.com/AventusNetwork/status/2119916293759631846" rel="noopener nofollow ugc">AventusNetwork</a>).</li>
</ul>
<hr>
<h2><a name="p-42096-processing-log-3" class="anchor" href="#p-42096-processing-log-3" aria-label="Heading link"></a>PROCESSING LOG</h2>
<ul>
<li>Report Generated: 2026-11-10 10:02:13</li>
<li>Total X posts curated: 495</li>
<li>Posts Filtered and Analysed: 452</li>
<li>Data Source: X (Twitter)</li>
</ul>
<hr>
This report is auto-generated and provided for informational purposes only by OpenShore, a Pala Labs initiative. The content is based on posts from X and may contain inaccuracies. We do not guarantee its completeness or correctness.

The X25519 piece caught my attention — the detail that the XMTP gateway is designed so it cannot read message contents is the part worth highlighting, since encrypted messaging claims often rest on trust rather than architecture. The SDK notes on Revive receipt-log bounds and exact deposit refunds seem less flashy but likely matter more to anyone building on that path. Curious how the capped DOT supply model mentioned in the SubWallet summary interacts with the staking changes.

The prdoc for the XCMv3 removal (<a href="https://github.com/paritytech/polkadot-sdk/blob/50124eb50d23f76c84a27af2cbfa5790629989f9/prdoc/pr_13629.prdoc" rel="noopener nofollow ugc">pr_13629.prdoc</a>) has a line the announcement here doesn’t have: “Assets trapped under a v3 hash become unclaimable.” I wanted to know how much that is on Polkadot, so I pulled every <code>AssetsTrapped</code> event for the relay and Asset Hub from Statescan and checked each hash against <code>AssetTraps</code> storage today.
On the relay, 299 trap entries from the v3 period are still unclaimed, with 673.7 DOT in them. On Asset Hub there are 177, with 263.2 DOT and a bit of USDT and USDC. On both chains the v3 period runs from June 2023 to April 2024, when the runtimes moved to v4.
Most of it belongs to ordinary accounts, not parachains. That’s 636.9 DOT across 224 accounts on the relay and 262.6 DOT across 116 accounts on Asset Hub.
<h3><a name="p-42088-how-it-got-there-1" class="anchor" href="#p-42088-how-it-got-there-1" aria-label="Heading link"></a>How it got there</h3>
All but one of those account traps came from <code>limitedTeleportAssets</code> between the relay and Asset Hub. On the relay, most of the ones I opened show <code>KilledAccount</code>, then <code>AssetsTrapped</code>, then <code>Attempted</code> failing with <code>FailedToTransactAsset</code>. The account sent its whole balance, got reaped in the same transaction, and what the program had withdrawn went into the trap. On Asset Hub they fail with the same error, but the accounts weren’t reaped and most still hold DOT. A wallet team asked about these here in May 2024, and the answer then was <code>claim_assets</code> with the exact assets from the event.
<h3><a name="p-42088-why-the-removal-ends-it-2" class="anchor" href="#p-42088-why-the-removal-ends-it-2" aria-label="Heading link"></a>Why the removal ends it</h3>
pallet-xcm stores a trap as a count under <code>blake2_256(origin, VersionedAssets)</code>, so the version is part of the key. <code>claim_assets</code> reads the version from the assets you pass and makes it the ticket, <code>GeneralIndex(3)</code> for these, and <code>ClaimAsset</code> converts the assets to that version before hashing. Once v3 is removed, <code>VersionedAssets</code> has no V3 variant. The extrinsic can’t decode V3 assets and <code>into_version(3)</code> returns an error, so the count stays in storage and nothing can reach it.
Today it still works. I dry ran the claim with <code>DryRunApi_dry_run_call</code> against the live runtimes, for the largest account trap on each chain: 127 DOT on the relay, 52 DOT on Asset Hub. With the V3 assets exactly as in the event, both calls succeed and emit <code>AssetsClaimed</code> with the trap’s hash. One planck more and they fail with <code>UnknownClaim</code>.
XCM v5 already did this to v2. The same PR that added v5 removed v2, whose assets used index 1. The relay still holds 91 hashes from May 2022 to June 2023 under that index, 238 DOT across 1,384 traps, all trapped by parachains, and nobody has been able to claim them since v5 went live in May 2025.
Francisco’s post (<a href="https://forum.polkadot.network/t/xcmv3-to-be-removed-in-stable2612/19205">XCMv3 to be removed in stable2612</a>) puts stable2612 on 17 December and the first chains dropping v3 in early 2027.
<h3><a name="p-42088-what-can-still-be-done-3" class="anchor" href="#p-42088-what-can-still-be-done-3" aria-label="Heading link"></a>What can still be done</h3>
On Asset Hub it’s one call from the same account: <code>polkadotXcm.claimAssets</code>, assets as V3 with the exact amount from the event, any beneficiary. 109 of the 116 accounts there still hold DOT for the fee.
The relay is harder. All 224 accounts hold nothing on the relay today, so someone first has to teleport DOT from Asset Hub back to that account, more than the 1 DOT existential deposit plus the fee, and then call <code>xcmPallet.claimAssets</code> the same way. Parachain traps (60 on the relay, 52 on Asset Hub) need a message from that parachain, so each one goes through that chain’s governance.
On the runtime side, I recomputed every remaining v3 hash on both chains, and every index-1 hash on the relay, from the origin and assets in its event, and all of them match. So a one-off migration could take a list built off chain, check that each old key is in <code>AssetTraps</code>, and move its count to the hash of the same assets as V5. It needs no v3 types in the runtime, and the same list would also bring back the 238 DOT from the v2 period. I haven’t written it, and someone who works on pallet-xcm will probably see problems with it that I don’t.
I only checked Polkadot’s relay and Asset Hub. Kusama and every parachain running pallet-xcm have their own <code>AssetTraps</code>.
If you run a wallet or a parachain whose users teleported in early 2024, do you have a way today to find their traps and build the claim for them?

The circularity point lands for me. If “safeguarding assets” means the foundation’s own DOT, that’s an accountability question, not a mission statement. And “the ecosystem” needs a referent before it can anchor any decision about OpenGov proposals. What would help is concrete: which decisions, which actors, which accountable party. Without that, the language can’t be checked against behavior, which is exactly why the steering complaint above feels unresolved. Vague framing plus visible influence is a hard combination to defend.

Following the XCM incident, a portion of the value captured through arbitrage trading has been recovered because the bots involved were operated by known ecosystem partners and contributors. After identifying unusually large yields compared with their normal trading activity, these operators alerted Parity and cooperated with recovery efforts.
Approximately $280,000 has been recovered to date, reducing the estimated losses to $1.1 million at the time of writing. Efforts to recover further funds for the Polkadot Treasury remain ongoing.

Bastian Köcher

<h2><a name="p-42076-technical-governance-1" class="anchor" href="#p-42076-technical-governance-1" aria-label="Heading link"></a>Technical &amp; Governance</h2>
<ul>
<li>Polkadot’s infrastructure transition is moving through governance: Referendum 1966 is cited as the first step in reducing the active validator set from 600 (to 500 initially, with a longer-term target of 320), alongside expanded validator responsibilities via “metanodes” and a review of validator rewards for long-term sustainability (via <a href="https://x.com/leeky_k_crypt/status/2118512439620730880" rel="noopener nofollow ugc">leeky_k_crypt</a>, <a href="https://x.com/kleaweb3/status/2119046433659588698" rel="noopener nofollow ugc">kleaweb3</a>, <a href="https://x.com/TTT_News_/status/2119271195900043295" rel="noopener nofollow ugc">TTT_News_</a>).</li>
<li>Staked DOT reportedly reached a new record of 922,257,918 DOT on November 2, representing more than half of circulating supply, with over 40.7M DOT added since August 13 (via <a href="https://x.com/MSBIntel/status/2118984300783939754" rel="noopener nofollow ugc">MSBIntel</a>, <a href="https://x.com/KoreanCryptoKOR/status/2118988971204284546" rel="noopener nofollow ugc">KoreanCryptoKOR</a>).</li>
<li>Polkadot account privacy was highlighted through documentation showing that separate Polkadot products create separate, unlinkable accounts by default, helping limit cross-app tracking unless users opt to link them (via <a href="https://x.com/VRCI_Global/status/2119475363852026090" rel="noopener nofollow ugc">VRCI_Global</a>).</li>
</ul>
<h2><a name="p-42076-developer-technical-updates-2" class="anchor" href="#p-42076-developer-technical-updates-2" aria-label="Heading link"></a>Developer &amp; Technical Updates</h2>
<ul>
<li>Hydration released cl0wdit 1.0, an AI auditor for Rust/Substrate code adapted for FRAME, XCM, ORML and Hydration, with 17 audit lenses and repeated evidence-backed review passes (via <a href="https://x.com/hydration_net/status/2119049716831023295" rel="noopener nofollow ugc">hydration_net</a>).</li>
<li>Polkadot Devs highlighted <code>product-sdk</code> adapters for on-chain app data storage via Bulletin and pub/sub messaging via Statement Store, aimed at reducing reliance on hosted services for dapps (via <a href="https://x.com/PolkadotDevs/status/2118643800922791938" rel="noopener nofollow ugc">PolkadotDevs</a>).</li>
</ul>
<h2><a name="p-42076-ecosystem-community-3" class="anchor" href="#p-42076-ecosystem-community-3" aria-label="Heading link"></a>Ecosystem &amp; Community</h2>
<ul>
<li>Polkadot Assemble went live in Mumbai as a closing side event around Devcon week, with livestream access shared, and attendees highlighting the developer and community focus (via <a href="https://x.com/dotAssemble/status/2118965807023870220" rel="noopener nofollow ugc">dotAssemble</a>, <a href="https://x.com/n4bi10p/status/2119055581290098798" rel="noopener nofollow ugc">n4bi10p</a>, <a href="https://x.com/saurabhnage624/status/2118974039482110096" rel="noopener nofollow ugc">saurabhnage624</a>).</li>
<li>Community activity around Polkadot Assemble included developer networking, local ecosystem engagement and attendee giveaways (via <a href="https://x.com/moizzdoes/status/2119079075532980261" rel="noopener nofollow ugc">moizzdoes</a>, <a href="https://x.com/I_am_prathik/status/2119080229792809382" rel="noopener nofollow ugc">I_am_prathik</a>).</li>
</ul>
<hr>
<h2><a name="p-42076-processing-log-4" class="anchor" href="#p-42076-processing-log-4" aria-label="Heading link"></a>PROCESSING LOG</h2>
<ul>
<li>Report Generated: 2026-11-09 10:03:59</li>
<li>Coverage: 2026-11-07 – 2026-11-09 (weekend roundup)</li>
<li>Total X posts curated: 4358</li>
<li>Posts Filtered and Analysed: 4281</li>
<li>Data Source: X (Twitter)</li>
</ul>
<hr>
This report is auto-generated and provided for informational purposes only by OpenShore, a Pala Labs initiative. The content is based on posts from X and may contain inaccuracies. We do not guarantee its completeness or correctness.

Polkadot Socials Daily Digest: 2026-11-09

I read version 2 at c674a2c, and reclaim() now does what we talked about. Both the weighing and the execute sit inside the try, the balance decides, and payouts can’t open on a pool that never got the KSM back.
settle.ts never closes a full pool after its funding close, and the comment says the deposit could yet be placed. It can’t. place() and contribute() both revert with TooLate once fundingDeadline passes, in version 1 and 2, so abandon() is safe to send there. With the factory this case gets more common. A pool that fills after its referendum already got a deposit, from another pool or straight on governance, fails to place, and after the close it sits on FULL BUT NOT PLACED until someone presses the button on the page. Nobody’s KSM is at risk, it just won’t settle on its own.
checkPools refuses a pool whose funding closes more than six hours before the referendum’s timeout, but nothing caps it on the other side, in the factory or the check. A pool opened from a script with a close months out gets listed, and if it misses its referendum, abandon() can’t run until then, so each contributor has to withdraw by hand. An upper bound in checkPools, say the timeout plus the hour your page already adds, keeps refund after the close true for every pool you list.

birdbrain

why we not use the same system for #JAMKB as #CORETIME ? we already have an auction that works on limited resources
what i undertand and agree with gavin is that its sucks to use variable asset (as DOT) to price some fixed resource (as #JAMKB), but as this is for #JAMKB as this is for #CORETIME ..
i agree that both be priced in #dotUSD, users bid in USD, the system do the convertion internally to the equivalent DOT. This way we still create value for DOT (dotUSD comes from DOT DAO) and facilitates price bid using stable asset. For me its just an conversion layer, transparently from the user, price in USD, convert internally to DOT..
please, dont loose this revenue, JAM is an great asset, as is CORETIME, so sell both in the same way.. as limited resource as they are

jonas

Dynamically priced JAMKB via decaying deposits

Isn’t this route heading straight towards concentrating everything in the hands of a few big operators?
Reduction of active set is a diameteral oposite from where Polkadot was heading all these years, and will completely destroy small operators as a result.
Can someone please explain why this route is even considered?

Ross Bulat

Hi all,
Open USD (OUSD) went live on 30 September. It’s backed by Visa, Mastercard, Stripe and Coinbase, issued by Bridge, and nearly all reserve income goes back to partners. It runs on Ethereum, Solana, Base and Tempo, but not on Polkadot.
Is anyone working on bringing it to Polkadot Hub, natively or via Snowbridge?
Thanks, 
Paul Schmidt, Heitaria Swiss AG

Plans to bring Open USD (OUSD) to Polkadot Hub?

Thank you for catching this and sharing a solution! 
We’ve corrected the erroneous article and will certainly consider adding an extra layer of verification.
The digest is a young public good, with 341 reports published and 3 known errors found so far, sitting at 99% accuracy, but we understand the nature of the product demands 0 errors. We thus really appreciate any suggestions and contributions that would help improve it. Please feel free to raise an issue on <a href="https://github.com/Pala-Labs/polkadot-daily-digest/issues/" rel="noopener nofollow ugc">GitHub</a>
Thank you <img src="https://emoji.discourse-cdn.com/twitter/heart.png?v=16" title=":heart:" class="emoji" alt=":heart:" loading="lazy" width="20" height="20">

Polkadot Socials Daily Digest: 2026-11-06

Last week’s security notice on the Fearless Wallet browser extension (<a href="https://forum.polkadot.network/t/security-notice-fearless-wallet-browser-extension-leaked-private-keys/19058">notice</a>) says that from February 2025, unlocking the wallet sent your private key to a server run by the attacker. The notice links a write-up that walks through the code at fixed commits (<a href="https://hackmd.io/@gWEUMERvQZyR5MStsH26g/HyNOm782zg" rel="noopener nofollow ugc">write-up</a>). I read it and then went through the repo history myself. None of it was hidden. It sat in public source the whole time.
I audit smart contracts, not browser extensions, but the review lessons carry over to any code that touches keys. Like the write-up, I’m sticking to what the code and the history show, not who wrote it or why.
<h3><a name="p-42018-how-it-got-in-and-how-it-left-1" class="anchor" href="#p-42018-how-it-got-in-and-how-it-left-1" aria-label="Heading link"></a>How it got in, and how it left</h3>
The code arrived in PR #1022 of soramitsu/fearless-wallet-web, titled “Ton Service”. It was open for ten weeks and merged on 19 February 2025 as one squashed commit, “TON ecosystem”: 251 files, 4,690 lines added and 6,119 removed. The PR has no review comments.
The function that matters is about 25 lines, in a new 180 line file, inside a diff of almost 11,000 changed lines whose title says it adds TON.
It left the same way. The code was deleted from the source on 25 June 2026, inside a release commit with about 80,000 changed lines.
<h3><a name="p-42018-what-each-piece-looked-like-in-a-diff-2" class="anchor" href="#p-42018-what-each-piece-looked-like-in-a-diff-2" aria-label="Heading link"></a>What each piece looked like in a diff</h3>
<ul>
<li>The name. On every unlock the extension calls <code>fetchJettonInfo()</code>. Jettons are TON tokens, so in a TON PR that reads like a token info fetch. What it actually does is export the recovery phrase of every main account (or the keystore file plus the wallet password) and send it out.</li>
<li>The password. The keyring service keeps the typed password in <code>this.password</code> at unlock. That’s what lets later code call <code>exportMnemonic(this.password)</code> without asking the user anything.</li>
<li>The “encryption”. Each secret goes through <code>CryptoJS.AES.encrypt(value, '')</code>, an empty passphrase. Anyone can reverse it, but in a diff it looks like the data is encrypted.</li>
<li>The date check. In version 3.0.1 the function did nothing before 26 February 2025 at 20:00 UTC, and it only ran in production builds. Testing a dev build, or the release before that date, shows nothing.</li>
<li>The remote switch. From 3.0.3 the server address came from a JSON file on the <code>eth-enabled</code> branch of a separate public repo, soramitsu/shared-features-utils, read on every unlock. No <code>ton</code> value in the file, no request. So the extension’s own repo never had to change to turn it on or off.</li>
</ul>
<code>git log</code> for that file shows it changing twice since 2023: switched on in May 2025 and off on 10 October 2026. GitHub’s activity log for the same branch shows 12 force pushes between 7 March and 14 May 2025, and the write-up counts nine separate periods when the switch was on. If you review history with git only, you see almost nothing.
<h3><a name="p-42018-checks-id-want-on-any-repo-that-holds-keys-3" class="anchor" href="#p-42018-checks-id-want-on-any-repo-that-holds-keys-3" aria-label="Heading link"></a>Checks I’d want on any repo that holds keys</h3>
<ol>
<li>Key paths get their own PRs. Any change to the keyring, key export, or anything that reads the password goes in a small PR with a named second reviewer. CODEOWNERS on those folders helps. A 251 file PR should not be able to touch them quietly.</li>
<li>Follow secrets to the network. List every caller of the key export functions and every outgoing request from the background process. Any path from one to the other is the first thing to read, whatever the function is called. A CI check that fails when a new caller or a new host shows up is pretty cheap.</li>
<li>Don’t keep the password after unlock. Use it and drop it.</li>
<li>Treat a constant or empty key as plaintext. <code>encrypt(x, '')</code> is not encryption.</li>
<li>Ask about conditions on time and environment. A <code>Date.now()</code> compared to an odd constant, or a production only gate around code that isn’t UI, deserves a question in review. Test the production build with the clock moved forward.</li>
<li>Remote config is code. If a signed release reads a file from a branch, that branch is part of the release: protect it, block force pushes, review its changes, or pin and sign the config. And check the activity log, not only git log.</li>
<li>A source fix is not a user fix. The code left the source in June 2026, but the notice says installed copies of 3.0.3 to 3.0.5 still contain it and it could be switched on again. A fix only reaches people through a release they actually install, or by removing the extension.</li>
</ol>
Most of this is review discipline and a couple of CI scripts, not budget.
Has anyone here found a good way to review remote config that ships to signed builds? That’s the one I don’t have a clean answer for.

Fearless Wallet key leak: 16 months in public code, and the review checks that catch it

<ol>
<li>Cryptographic type - No, the PJS extension doesn’t even ask for this when importing.</li>
<li>Derivation path - Yes, if you enter an invalid derivation path, it will reject it. Or if you enter an incorrect but valid one, you will end up with a different address than expected.</li>
</ol>
The JSON file you could create has the cryptographic type embedded in it, but I’m not certain about derivation path. I assume it does somewhere, but it’s not obvious to me looking at the JSON file. I’m not sure about internal storage and how much information you could get from this.

After the first cut, I’d want to see how many operators who had just one seat are still in. We think about this at Humanode too. The biggest operators can keep roughly the same share while smaller operators lose their only seat. What would you need to see after the move to 500 to feel comfortable going down to 300?

Cyber Preacher

Robert Hambrock

Proposal discussion: Adapting Kusama to demand and its JAM future

Hi, first sorry for the late reply. I’ll try to answer your questions here.
<blockquote>
Is third-party parachain consumption of PoP results (e.g. via XCM-based origins, as mentioned in some of the docs) actually on the roadmap, or is the current focus solely on Polkadot-relay/People-Chain-native use cases for now?
</blockquote>
Currently, in <a href="https://github.com/paritytech/individuality-community" rel="noopener nofollow ugc">individuality-community</a>, we have a mechanism to share the ring roots required to allow the verification of people proofs (any proof of any member set actually), which is the <a href="https://github.com/paritytech/individuality-community/tree/main/pallets/members-notifier" rel="noopener nofollow ugc"><code>pallet-members-notifier</code></a> and <a href="https://github.com/paritytech/individuality-community/tree/main/pallets/members-subscriber" rel="noopener nofollow ugc"><code>pallet-members-subscriber</code></a> pair.
The notifier pallet transmits a subset of ring roots from their origin chain to subscribed parachains and these roots are then used in the proof verification on the destination chains (though the user must fetch the member keys from the original chain in order to create the proof on their machine, this is all off-chain). The problem is that it only works between sibling system parachains because both pallets can perform unpaid execution on the counterpart parachain, and there is no fee mechanism implemented. Furthermore, the XCM logic which uses this <code>UnpaidExecution</code> instruction in its body is currently hardcoded into the pallets.
In order to make these pallets work for any parachain accessible through XCM, even outside the set’s consensus system (for example Polkadot People → Kusama Asset Hub), the pallet pair needs to have 2 tiers of subscribers to the ring roots:
<ul>
<li>one for sibling parachains which share the same “root” and always trust each other (and thus allow unpaid execution from one another)</li>
<li>one for 3rd party parachains which would need to pay for the execution, so interested parties would need to fund pots from which fees are withdrawn to pay for the XCM logic (and obviously for the pallet to not use <code>UnpaidExecution</code> for these subscribers).</li>
</ul>
This is not in development right now and it is not planned, but I would support a contribution from yourself or someone else to add this capability.
<blockquote>
Roughly what stage is that at, and is there a better channel than this thread to follow as the interface stabilises — a tracking issue, mailing list, or similar?
</blockquote>
You can follow the latest developments in polkadot-sdk and <a href="https://github.com/paritytech/individuality-community" rel="noopener nofollow ugc">individuality-community</a>. As I said above though, this is not planned right now, so there is no tracking issue for it or anything similar. We have this issue <a href="https://github.com/paritytech/individuality-community/issues/197" rel="noopener nofollow ugc">here</a> which originated from this post, which can either stay open or you could open a new issue under the “enhancement” tag and we can talk more about the design details there if anyone wants to contribute.
<blockquote>
Would input from a concrete downstream use case like this be useful at this stage, or is it premature given where DIM1/DIM2 currently stand?
</blockquote>
As I said, we don’t plan to work on it actively right now, but I can see a scenario in the future where different projects consume the people set for various use cases and where this would be useful.

George Pisaltu

Parachain use case for pallet-people/PoP and questions on third-party consumption timeline

The Metanode direction makes sense to me overall, especially if it helps to consolidate infrastructure currently funded separately.
A few questions from the operator side:
<ul>
<li>how do we plan to measure the quality of RPC and light-client services, beyond simply checking that an endpoint is reachable? Latency, availability, geographical coverage and the ability to handle sustained load can vary quite significantly between operators.</li>
<li>what about rate limiting and request throttling? Any future validator should do this to prevent DDoS. Will there be an official guide on what limits to place on the RPC?</li>
<li>what if a validator fails to provide these additional services? How would you remove such a validator from the set?</li>
<li>what are the main targets for RPCs/light nodes? Polkadot JS, wallets, even 3rd parties?</li>
<li>is there already a plan for a pilot with existing validators, and will service quality eventually influence rewards?</li>
</ul>
Basically, my biggest concern is the order of operations. If we shrink the active set first before implementing Metanodes, we might exclude validators who would otherwise provide excellent service while keeping those who don’t really care, even though they have a higher stake now.

Petr Mensik

Metanode: 2026 Q4 target

Thanks Emiel.
Where you’re right. On 1, running our own infrastructure and holding political control are different things, and JAM Prime can leave KSM holders real authority. Our question is who enforces it once DOT DAO is the counterparty. On 2, 96 validators is untested, and it means far fewer than today’s 700 seats. So “keeping its validators” means keeping the role. On 3 and 4, asking for no funds today doesn’t make independence free. On 6, a KSM vote can revise #573. On 7, regarding the engineers and funding - this is part of the process - the talent to deliver and the money to enable are all in or around the project and so we see this as an emergent experiment in attracting the relevant resources to a point where the commitment is real - this is a slightly chicken and egg process, since people need a strategy they can commit to (with resources) and a strategy needs people… it is therefore necessarily a dance.
The arithmetic. These are assumptions. KSM at US$3.49 is set by the market, and it has ranged from US$2.87 to US$14.37 this year. 2.4% is #573’s figure, and holders can change it. 96 seats assumes 32 cores and three validators a core, a rule of thumb. Your US$3,000 has not been checked and tested in public and we believe variations of strategy can lead to meaningfully lower costs. On those inputs 2.4% is about US$1.6m a year, which pays for 44 seats at US$3,000 even if every coin went to operators.
Where we differ. Point 8 may be right, but it’s an assessment and not yet a budget. Your paper says “Actual independent-JAM costs remain unresolved” and that Appendix B supplies “neither a complete independent-JAM budget nor a quantified comparison of security”. Your allowance “excludes protocol development and the return required on bonded security capital”, so the maintenance in point 5 rests on DOT DAO and the Fellowship accepting it, and nobody has priced that work on either path. Your first option is 8 cores and #573 is 32, so independence should be priced at both - and also against other strategic needs. Regarding Kusama’s 54 collator slots on JAM Prime - since you lead a JAM team what would you say that work costs?
One vote won’t settle this. #671 to #674 were rejected, and #676 is still undecided. We now see this as a phased transition, where cores, seats, chains and who operates them change in steps, starting from what Kusama uses today. In the 28 days to <a href="https://hambro.ch/kusama/set-reductions/coretime/" rel="noopener nofollow ugc">25 October</a>, at most 25 of 140 cores produced blocks. We think routes should be compared as sequences, with each step costed.
Operator data. We’ll soon open the validator cost survey promised in the first post, whichever way #676 goes. Seat cost matters on every route, including yours, because your US$108,000 a core-year rests on it.
We’ll post the questions here for correction first.

Emiel Sebastiaan | JAMdot Technologies

A fifth option: an independent Kusama on a reduced JAM, keeping its validators

<h2><a name="p-41975-governance-network-1" class="anchor" href="#p-41975-governance-network-1" aria-label="Heading link"></a>Governance &amp; Network</h2>
<ul>
<li>Polkadot’s active validator set is scheduled to move from 600 to 500, with nominators encouraged to review nominations to maintain rewards eligibility (via <a href="https://x.com/rossbulat/status/2117831098487181568" rel="noopener nofollow ugc">rossbulat</a>).</li>
<li>Proposal #676 analysis outlines an independent Kusama running on a reduced JAM network with its own validators (via <a href="https://x.com/AndreyMcQueen/status/2117946750006653212" rel="noopener nofollow ugc">AndreyMcQueen</a>).</li>
</ul>
<h2><a name="p-41975-technical-infrastructure-2" class="anchor" href="#p-41975-technical-infrastructure-2" aria-label="Heading link"></a>Technical &amp; Infrastructure</h2>
<ul>
<li>Polkadot Devs highlighted the Product SDK, a TypeScript toolkit covering chain clients, transaction lifecycle tracking, multi-provider signing, typed contracts, and SS58/H160 utilities (via <a href="https://x.com/PolkadotDevs/status/2117927359487660091" rel="noopener nofollow ugc">PolkadotDevs</a>).</li>
<li>The new Polkadot testnet relay chain reportedly reduces infrastructure footprint, cutting validators from 152 to 58, cores from 56 to 19, and budget by 48.8% while hosting the Products Devnet (via <a href="https://x.com/VRCI_Global/status/2117890131793244292" rel="noopener nofollow ugc">VRCI_Global</a>).</li>
<li>Chainspect reported Polkadot has maintained a Nakamoto coefficient above 100 for 348 consecutive days (via <a href="https://x.com/chainspect_app/status/2118116088278069274" rel="noopener nofollow ugc">chainspect_app</a>).</li>
</ul>
<h2><a name="p-41975-ecosystem-3" class="anchor" href="#p-41975-ecosystem-3" aria-label="Heading link"></a>Ecosystem</h2>
<ul>
<li>Polkadot marked five years since its first parachain, Statemint — now Asset Hub — onboarded to the network (via <a href="https://x.com/BillLaboon/status/2117971056732352686" rel="noopener nofollow ugc">BillLaboon</a>).</li>
<li>Memport completed its first full beta-test journey, with a tester finishing all four quests: uploading a Memory, creating a SHARD, connecting an AI agent through MCP, and applying a mental model to a task (via <a href="https://x.com/memportHQ/status/2118028146511372444" rel="noopener nofollow ugc">memportHQ</a>).</li>
<li>Lumo Wallet added support for Polkadot and Kusama among its newly supported networks (via <a href="https://x.com/LumoWallet/status/2117977665710006388" rel="noopener nofollow ugc">LumoWallet</a>).</li>
<li>A Bolivia-focused lithium project is reportedly exploring Polkadot as settlement infrastructure for large-scale stablecoin payments (via <a href="https://x.com/PerpetuumError/status/2118055589200662565" rel="noopener nofollow ugc">PerpetuumError</a>).</li>
</ul>
<h2><a name="p-41975-market-4" class="anchor" href="#p-41975-market-4" aria-label="Heading link"></a>Market</h2>
<ul>
<li>Total staked DOT reached a new all-time high of 922M DOT; Bifrost reported vDOT yielding 4.43% APY versus 2.81% for direct staking (via <a href="https://x.com/Bifrost/status/2117797563227369525" rel="noopener nofollow ugc">Bifrost</a>).</li>
<li>Polkadot issuance is now roughly 153k–156k DOT per day, less than half the pre-March 14 pace; total supply is around 1.71B DOT, or 81.45% of the 2.1B cap (via <a href="https://x.com/MSBIntel/status/2118108532369207394" rel="noopener nofollow ugc">MSBIntel</a>, <a href="https://x.com/CryptoYieldPro/status/2117938029322985818" rel="noopener nofollow ugc">CryptoYieldPro</a>).</li>
<li>Polkadot transaction fees hit a 30-day low, with 100 transactions costing about $1.18 (via <a href="https://x.com/chainspect_app/status/2117768795951341771" rel="noopener nofollow ugc">chainspect_app</a>).</li>
</ul>
<hr>
<h2><a name="p-41975-processing-log-5" class="anchor" href="#p-41975-processing-log-5" aria-label="Heading link"></a>PROCESSING LOG</h2>
<ul>
<li>Report Generated: 2026-11-05 10:02:05</li>
<li>Total X posts curated: 100</li>
<li>Posts Filtered and Analysed: 74</li>
<li>Data Source: X (Twitter)</li>
</ul>
<hr>
This report is auto-generated and provided for informational purposes only by OpenShore, a Pala Labs initiative. The content is based on posts from X and may contain inaccuracies. We do not guarantee its completeness or correctness.

Polkadot Socials Daily Digest: 2026-11-05

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

Blockchain Alert Platform for Web3 | BlockPing

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)

# Kusama Treasury Proposal: Restoring Slashed KSM for LKSM Holders

## Summary

A request has been made to Kusama's government (governance) to send **36,246.53 KSM** to the Karura Homa staking account. This would refill the shared pool of KSM that backs LKSM holders.

## What Happened?

- A bad validator was slashed (punished) six times at 50% each.
- The slashes hit the shared Homa/LKSM pool, not just one person.
- The slash reports were kept secret off-chain and turned in very late.

## Why It Was Unfair

- The late reporting gave governance almost no time to review or cancel the slashes.
- Karura's insurance money had already been taken out before the reports came in.
- Reporters actually earn **more** by waiting, because the reward is 10% of a bigger slash.

## The Numbers

- Gross slash: about **40,273.92 KSM**
- Reporter reward (10%): about **4,027.39 KSM**
- Amount requested back: **36,246.53 KSM**

## What Is Being Asked

- Send **36,246.53 KSM** from the Kusama Treasury to the Homa staking subaccount.
- The money refills the shared LKSM backing — not any single holder, validator, or reporter.

## Bigger Picture

- Polkadot already fixed this problem with validator self-stake and no nominator slashing.
- Kusama has not made these changes and can be hurt the same way again.

Deciding

Restitution for Karura LKSM holders affected by delayed Kusama BEEFY offence reporting

# Kusama Proposal #675 (Simplified)

- This is a vote about keeping Kusama independent with its own validators.
- It wants the plan to be checked, priced, and shared openly.
- It wants this plan compared with another plan called JAM Prime.
- This must happen **before** Kusama's validators are retired.
- It asks for **no money** — no funds, no DOT, nothing from the Kusama Vision fund.
- It follows an earlier vote (#573) that passed on 21 August 2025.
- It works alongside proposals #671, #672, #673, and #674. You can vote for this one and any of those.
- If both this and another proposal pass, the comparison happens first.

An independent Kusama on a reduced JAM, keeping its validators

- Subscan is a tool to see what happens on Kusama.
- It will work for all of 2026.
- The community pays a small amount each month.
- If service is bad, the community can stop paying.
- The price is lower than before.

Kusama

referenda2

treasury45

discussions1394