candidates

members

proficients

fellows

senior_fellows

experts

senior_experts

masters

senior_masters

grand_masters

Miscellaneous

A real-world Polkadot wallet drain &amp; why we now need

A real-world Polkadot wallet drain & why we now need

Seeking Input: Developer Skill Pathways for DotCodeSchool

Ludovic_Domingues

Refund Request: Compensation for 57 DOT Lost Due to Missing Cross-Chain Swap Warning on Hydration/Nova Wallet

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

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

Polkadot Forum Meta

Welcome to the Polkadot Forum :waving_hand:

Elqmqn

Welcome to the Polkadot Forum 👋

Getting started: Read this first

Polkadot Forum Super Admin

Why not have a slogan for Polkadot?

HardTruth

A place for long-term, deep thinking on Polkadot technology.

Tech Talk

Can pallet revive Help Improve Polkadot&rsquo;s UX?

Alexander Theißen

Can pallet revive Help Improve Polkadot's UX?

[2025-05-09] Kusama dispute storm postmortem

Andrei Sandu

Implications of Ethereum compatible contracts on Polkadot Hub

Daan van der Plas

Governance discussion about the future of Polkadot and Kusama.

Governance

2025-Q1 Polkadot Treasury Report

Tommi Enenkel / Alice und Bob | Mangata

Sniping a proposal during Confirmation Period

UX Bounty - Enhancing Referenda Feedback loop: Introducing Section-Based Voting and Feedback Mechanism

Everything that’s going on in the ecosystem, and what you wish would be going on in the ecosystem.

Ecosystem

Wish For Change: Polkadot acquisition of Hydration

Introducing Dotme: Support Your Favorite Creators with DOT

Abinash Sahoo

Polkadot Digest 15 May 2025

bill_w3f

Welcome to the Ambassador Category! Please use this space to discuss anything and everything related to the Polkadot Ambassador Programme.

Ambassador Programme

Official statement of the Advisory Board of the Polkadot Ambassador Fellowship

Lucy Coulden

Hispanic Chapter of Polkadot Ambassadors Manifesto

World liberty financial

<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/5/5869f968cbc08e142b4cd9198b72533b9b021e2d.jpeg" data-download-href="/uploads/short-url/cC946rYmCh1CY6ORMt87aFLfIWp.jpeg?dl=1" title="Copia de Diseño sin título" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/5/5869f968cbc08e142b4cd9198b72533b9b021e2d.jpeg" alt="Copia de Diseño sin título" data-base62-sha1="cC946rYmCh1CY6ORMt87aFLfIWp" width="690" height="388" data-dominant-color="867572"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">Copia de Diseño sin título</span><span class="informations">1000×563 59.1 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div></p>

Filippo

<aside class="quote no-group" data-username="0xTaylor" data-post="26" data-topic="12934" data-full="true">
<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/60/4242_2.png" class="avatar"> 0xTaylor:</div>
<blockquote>
<p>What you don’t understand is that there are some cross-chain bridge/swap services that leverage CEX accounts to do the transfer. So while it looks like a normal CEX transfer, it’s really not. Thus it’s not possible to attribute that account to the attacker.</p>
</blockquote>
</aside>
<p>What exactly do you mean by that?</p>
<p>In my original message, this was already very clear: the attacker’s <strong>primary collection account</strong> is easily attributable whether it’s automated or not doesn’t really matter. The path is straightforward.</p>
<p>By the way, I should probably mention at this point that <strong>Binance did confirm identifying suspicious activity</strong> (I don’t have more details on that). As for the rest of the flow, I’m not claiming every wallet involved belongs to the same person what’s obvious, though, is that funds landed there “magically,” and the resulting activity is extremely intense.</p>
<p>Feel free to point out the specific accounts you’re referring to so we can clarify this I’ll gladly take a look and respond.</p>
<p>It’s clear check this<br>
<div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/d/d06148a3a6df4ffc2a7a71e756bfd6c28960b318.jpeg" data-download-href="/uploads/short-url/tJpK5k3oU9Ht2gULsLgyzblxdy0.jpeg?dl=1" title="IMG_4382" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/d/d06148a3a6df4ffc2a7a71e756bfd6c28960b318_2_349x499.jpeg" alt="IMG_4382" data-base62-sha1="tJpK5k3oU9Ht2gULsLgyzblxdy0" width="349" height="499" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/d/d06148a3a6df4ffc2a7a71e756bfd6c28960b318_2_349x499.jpeg, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/d/d06148a3a6df4ffc2a7a71e756bfd6c28960b318_2_523x748.jpeg 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/d/d06148a3a6df4ffc2a7a71e756bfd6c28960b318_2_698x998.jpeg 2x" data-dominant-color="201F21"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">IMG_4382</span><span class="informations">1179×1685 85.4 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div><br>
I can tell you and Binance knows it too it’s one and the same user account. It simply hadn’t been flagged for suspicious activity before. :<br>
<div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/8/882b5781f3585fed3997c220818e65add603767e.jpeg" data-download-href="/uploads/short-url/jqBNjzZHogQEtQboUu5CxkRTLH0.jpeg?dl=1" title="IMG_4383" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/8/882b5781f3585fed3997c220818e65add603767e_2_328x500.jpeg" alt="IMG_4383" data-base62-sha1="jqBNjzZHogQEtQboUu5CxkRTLH0" width="328" height="500" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/8/882b5781f3585fed3997c220818e65add603767e_2_328x500.jpeg, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/8/882b5781f3585fed3997c220818e65add603767e_2_492x750.jpeg 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/8/882b5781f3585fed3997c220818e65add603767e_2_656x1000.jpeg 2x" data-dominant-color="202021"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">IMG_4383</span><span class="informations">1179×1796 90.1 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div></p>
<p>Only Binance knows the truth. If you believe it’s a bridge used by multiple users, just know that in my personal experience, what I described is exactly how it works on Polkadot with Binance, Kraken, and others that much is obvious. And yes, you can indeed come across Binance user_wallets tied to swap/bridge services but you don’t need to study them for long to realize it. They usually show very regular, repetitive transactions. <img src="https://emoji.discourse-cdn.com/twitter/ok_hand.png?v=14" title=":ok_hand:" class="emoji" alt=":ok_hand:" loading="lazy" width="20" height="20"></p>
<p>If you’ve observed a CEX behaving differently on Polkadot than what I’ve explained, then I’m genuinely curious to hear it.</p>
<p>I might be surprised to see other types of behavior that are truly unexpected.</p>
<p>One thing’s for sure, my brother in this specific case, those are exactly the addresses that needed to be flagged. Nothing else.</p>
<p>If you think nothing should’ve been targeted, you’re mistaken.</p>
<p>This single transaction is enough to identify the main attacker for Binance end of story, if you will</p>
<aside class="onebox allowlistedgeneric" data-onebox-src="https://polkadot.subscan.io/extrinsic/25975883-2">
  <header class="source">
      <img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/4/4c10743df4d3c9b6cbc677c5d27e98ae59e08842.png" class="site-icon" data-dominant-color="FFAED5" width="192" height="192">

      <a href="https://polkadot.subscan.io/extrinsic/25975883-2" target="_blank" rel="noopener nofollow ugc">polkadot.subscan.io</a>
  </header>

  <article class="onebox-body">
    <img width="192" height="192" src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/9/9dde03b0b7edadee78aa3cc2e35bebc21b9512cc.png" class="thumbnail onebox-avatar" data-dominant-color="EB77D1">

<h3><a href="https://polkadot.subscan.io/extrinsic/25975883-2" target="_blank" rel="noopener nofollow ugc">Subscan | Polkadot Extrinsic Details</a></h3>

  <p>Extrinsic Index: 25975883-2. Involves balances_transfer_allow_death call. Detailed extrinsic information.</p>


  </article>

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

  <div style="clear: both"></div>
</aside>
<aside class="onebox allowlistedgeneric" data-onebox-src="https://polkadot.subscan.io/extrinsic/25975919-8">
  <header class="source">
      <img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/4/4c10743df4d3c9b6cbc677c5d27e98ae59e08842.png" class="site-icon" data-dominant-color="FFAED5" width="192" height="192">

      <a href="https://polkadot.subscan.io/extrinsic/25975919-8" target="_blank" rel="noopener nofollow ugc">polkadot.subscan.io</a>
  </header>

  <article class="onebox-body">
    <img width="192" height="192" src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/9/9dde03b0b7edadee78aa3cc2e35bebc21b9512cc.png" class="thumbnail onebox-avatar" data-dominant-color="EB77D1">

<h3><a href="https://polkadot.subscan.io/extrinsic/25975919-8" target="_blank" rel="noopener nofollow ugc">Subscan | Polkadot Extrinsic Details</a></h3>

  <p>Extrinsic Index: 25975919-8. Involves balances_transfer_all call. Detailed extrinsic information.</p>


  </article>

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

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

<p>Your only way to escape my radar is to use a mixer, my bro, end of story.</p>
<p><img src="https://emoji.discourse-cdn.com/twitter/pirate_flag.png?v=14" title=":pirate_flag:" class="emoji" alt=":pirate_flag:" loading="lazy" width="20" height="20">If you’re telling me I can’t prove anything or that I’m wrong, then listen carefully you handle your business, I’m here trying to support victims and help identify attackers. The CEXs can finish the job.</p>
<p>The attacker is a total rookie usually they try to complicate the trail, but here there’s no need to keep writing, it’s pointless.</p>
<p>Bridge or not, I’ve explained it to you there’s a very slim chance it’s a bridge, but that changes absolutely nothing about Binance already identifying this individual from it.</p>
<p>17 transactions with that kind of spacing the likelihood that this account is acting as a bridge, my friend, is extremely low. But hey, believe whatever you want, it won’t change the outcome.</p>
<p>The rest of the tree, of course, is harder to certify as attacker-owned but you can spot patterns and crossovers, and ultimately the CEX data can reveal much broader activity than we might initially imagine.</p>

<aside class="quote no-group" data-username="josep" data-post="13" data-topic="12923">
<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/josep/60/2619_2.png" class="avatar"> josep:</div>
<blockquote>
<p>I’m not trying to be contrarian here</p>
</blockquote>
</aside>
<p>Sure as hell sounds like you are. I don’t see any <strong>constructive</strong> criticism here. Just a rant how everything is unappealing and how it will never work out because of some “impedance mismatch”. Would really appreciate to have a discussion with you and not ChatGPT.</p>
<p>The pre-compiles are not meant to be a replacement for off chain code. They are meant to facilitate things like a DAO and such. And if you see them lacking important APIs please comment in the PR with some <strong>constructive</strong> feedback.</p>

<p>I am happy to share that my application, Dotme, hit 5 users in total.</p>
<p>Tiny achievement, but it’s real. <img src="https://emoji.discourse-cdn.com/twitter/tada.png?v=14" title=":tada:" class="emoji" alt=":tada:" loading="lazy" width="20" height="20"><img src="https://emoji.discourse-cdn.com/twitter/tada.png?v=14" title=":tada:" class="emoji" alt=":tada:" loading="lazy" width="20" height="20"></p>

<h2><a name="p-29294-timeline-1" class="anchor" href="#p-29294-timeline-1"></a>Timeline</h2>
<h3><a name="p-29294-h-09052025-123530-runtime-upgrade-2" class="anchor" href="#p-29294-h-09052025-123530-runtime-upgrade-2"></a>09/05/2025 12:35:30 - Runtime upgrade</h3>
<p>The runtime of Kusama was upgraded to v1.5.0 at block <a href="https://kusama.subscan.io/extrinsic/28279019-2?event=28279019-33" rel="noopener nofollow ugc">#28279019</a> after referendum <a href="https://kusama.subsquare.io/referenda/519" rel="noopener nofollow ugc">519</a> was successfully executed.</p>
<p>The new runtime included the enablement of the v2 candidate receipts (RFC-103) node feature flag. This configuration change was not applied immediately in session <span class="hashtag-raw">#47</span>,731; instead it was scheduled to be applied in session <span class="hashtag-raw">#47</span>,733.<br>
The upgrade was applied successfully and the network continued to function normally, until  session <span class="hashtag-raw">#47</span>,733 when the node feature bits changed to <code>0b11010000</code> signalling that v2 candidate receipts are now accepted by the runtime and nodes.</p>
<h3><a name="p-29294-h-09052025-1430-v2-receipts-are-enabled-3" class="anchor" href="#p-29294-h-09052025-1430-v2-receipts-are-enabled-3"></a>09/05/2025 14:30 - V2 receipts are enabled</h3>
<p>A small group (~40) of Kusama validators were running versions older than v1.17. These older validators do not support v2 candidate receipts and in v2 we removed the collator signature field from the receipt.</p>
<p>Collators running versions v1.17 or later started to produce blocks that use the new v2 receipts. These blocks were backed on-chain, as most of the validators are upgraded.</p>
<p>During approval checking, the old validators failed the checks on the collator signature fields of all v2 candidate receipts and constantly initiated disputes.</p>
<h3><a name="p-29294-h-09052025-1430-finality-lag-and-high-parachain-block-times-4" class="anchor" href="#p-29294-h-09052025-1430-finality-lag-and-high-parachain-block-times-4"></a>09/05/2025 14:30 - Finality lag and high parachain block times</h3>
<p>Finality started to lag at <strong>09/05/2025 14:30 UTC</strong> as soon as the disputes started and the network connectivity degraded.</p>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/7/7d2b0dd18891c56a34a0e6402005f127d7b05263.png" data-download-href="/uploads/short-url/hRhVrzWGhdFoNc6vrNdeeNFGHNV.png?dl=1" title="image" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/7/7d2b0dd18891c56a34a0e6402005f127d7b05263_2_690x313.png" alt="image" data-base62-sha1="hRhVrzWGhdFoNc6vrNdeeNFGHNV" width="690" height="313" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/7/7d2b0dd18891c56a34a0e6402005f127d7b05263_2_690x313.png, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/7/7d2b0dd18891c56a34a0e6402005f127d7b05263_2_1035x469.png 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/7/7d2b0dd18891c56a34a0e6402005f127d7b05263_2_1380x626.png 2x" data-dominant-color="262E33"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">image</span><span class="informations">1698×772 136 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div></p>
<p>Parachain block times started to degrade as on-chain backing of candidates slowed down due to dispute participation and approval checking being prioritised by nodes.</p>
<h3><a name="p-29294-h-09052025-1850-finality-stalls-5" class="anchor" href="#p-29294-h-09052025-1850-finality-stalls-5"></a>09/05/2025 18:50 - Finality stalls</h3>
<p>As CPU and network load increased due to the disputes and approval checking work, the nodes started falling behind and could not keep up with the incoming network message rate. The chart below shows that subsystems had a huge backlog of messages to process.</p>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/1/13011f2c04f70264ba90f8e361dde77eea29d0b3.png" data-download-href="/uploads/short-url/2I7tt5EB3KurS7pjXQD8gc3Q1Uf.png?dl=1" title="image" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/1/13011f2c04f70264ba90f8e361dde77eea29d0b3_2_690x313.png" alt="image" data-base62-sha1="2I7tt5EB3KurS7pjXQD8gc3Q1Uf" width="690" height="313" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/1/13011f2c04f70264ba90f8e361dde77eea29d0b3_2_690x313.png, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/1/13011f2c04f70264ba90f8e361dde77eea29d0b3_2_1035x469.png 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/1/13011f2c04f70264ba90f8e361dde77eea29d0b3_2_1380x626.png 2x" data-dominant-color="363332"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">image</span><span class="informations">1698×772 173 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div></p>
<p>Due to the load and network connectivity issues GRANDPA stopped finalising blocks at <strong>09/05/2025 18:50 UTC</strong>.</p>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/8/871f84ea225314cf0ba3228b029c855f2d2a1f2d.png" data-download-href="/uploads/short-url/jhlZgb8HCLEvt8rSIu4N0iJjoXb.png?dl=1" title="image" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/8/871f84ea225314cf0ba3228b029c855f2d2a1f2d_2_690x313.png" alt="image" data-base62-sha1="jhlZgb8HCLEvt8rSIu4N0iJjoXb" width="690" height="313" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/8/871f84ea225314cf0ba3228b029c855f2d2a1f2d_2_690x313.png, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/8/871f84ea225314cf0ba3228b029c855f2d2a1f2d_2_1035x469.png 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/8/871f84ea225314cf0ba3228b029c855f2d2a1f2d_2_1380x626.png 2x" data-dominant-color="24282A"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">image</span><span class="informations">1698×772 131 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div></p>
<p>The finality did not catch up for the next <strong>23 hours</strong>, as can be observed in the chart above.</p>
<h3><a name="p-29294-h-10052025-0531-finality-starts-to-recover-6" class="anchor" href="#p-29294-h-10052025-0531-finality-starts-to-recover-6"></a>10/05/2025 05:31 - Finality starts to recover</h3>
<p>The complete stall lasted around <strong>11 hours</strong> until the emergency fix deployment made significant progress and the network load started to trend downward. GRANDPA started slowly finalising blocks, but finality lag persisted for another 8 hours until enough validators applied the emergency fix.</p>
<h3><a name="p-29294-h-10052025-1330-finality-and-parachain-block-times-recover-7" class="anchor" href="#p-29294-h-10052025-1330-finality-and-parachain-block-times-recover-7"></a>10/05/2025 13:30 - Finality and parachain block times recover</h3>
<p>Finality was fully restored after the emergency fix deployment reached 2/3 of the validators.</p>
<p>As the load of the network decreased to normal operational levels, all parachains using v1 descriptors returned to normal block times.</p>
<p>Parachains running collators using v2 receipts still experienced high block times, as the v2 receipt candidates were not backed. More than 2/3 of the validators did not accept v2 receipts after the emergency fix.</p>
<h3><a name="p-29294-h-2025-05-11-1313-all-parachain-block-times-are-normal-8" class="anchor" href="#p-29294-h-2025-05-11-1313-all-parachain-block-times-are-normal-8"></a>2025-05-11 13:13 - All parachain block times are normal</h3>
<p>Eventually all parachain block times recovered as soon as the <a href="https://kusama.subsquare.io/referenda/524" rel="noopener nofollow ugc">referendum</a> for disabling v2 receipts was executed at block <strong><span class="hashtag-raw">#28</span>,304,492</strong></p>
<h2><a name="p-29294-the-emergency-fix-9" class="anchor" href="#p-29294-the-emergency-fix-9"></a>The emergency fix</h2>
<p>A <a href="https://kusama.subsquare.io/referenda/524" rel="noopener nofollow ugc">referendum</a> to disable v2 receipts on Kusama was posted at <strong>2025-05-09 20:30:36 UTC</strong>.</p>
<p>A <a href="https://github.com/paritytech/polkadot-sdk/pull/8483" rel="noopener nofollow ugc">temporary emergency fix</a> was created to fix finality. It included the following changes:</p>
<ul>
<li>disablement of the dispute logic on the node (effectively ignoring all dispute protocol messages) to prevent any new disputes being raised.</li>
<li>re-enablement of dispute logic in two weeks at block height <span class="hashtag-raw">#28</span>,486,744</li>
<li>disablement of v2 candidate receipt on the node side (overriding the runtime flags) to ensure that the fixed nodes could not back v2 candidate receipts</li>
</ul>
<p>The fix was released as a Kusama-only node release <a href="https://github.com/paritytech/polkadot-sdk/releases/tag/polkadot-stable2503-3" rel="noopener nofollow ugc">stable2503-3</a>.</p>
<h2><a name="p-29294-why-did-the-disputes-start-10" class="anchor" href="#p-29294-why-did-the-disputes-start-10"></a>Why did the disputes start?</h2>
<p>We expected that v2 receipt candidates would be disputed by old validators. But we also expected that off-chain disablement would mitigate the dispute spam, and prevent dispute load by ignoring disputes initiated by the old validators.</p>
<p>Off-chain disablement did not fully mitigate the dispute spam.</p>
<h2><a name="p-29294-why-off-chain-disabling-did-not-mitigate-the-issue-11" class="anchor" href="#p-29294-why-off-chain-disabling-did-not-mitigate-the-issue-11"></a>Why off-chain disabling did not mitigate the issue?</h2>
<p>Off-chain disabling only works for unconfirmed disputes, meaning disputes where 1/3 or less validators participate. Nodes participate even for spam disputes if they are confirmed.</p>
<p>The disable mechanism works by storing a list of validators in memory and then ignoring disputes initiated by any validator on that list. A validator that loses a dispute against a valid candidate is disabled for the current session only. These old validators repeatedly initiated disputes on every new session. We can see in the logs that around 40 validators are disabled at the beginning of each session.</p>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/f/fdaf732e163b9df36243596e66411db1c0bdb371.png" data-download-href="/uploads/short-url/AccHnPuUsYX8oBAf3PImjhl2ptD.png?dl=1" title="image" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/fdaf732e163b9df36243596e66411db1c0bdb371_2_690x45.png" alt="image" data-base62-sha1="AccHnPuUsYX8oBAf3PImjhl2ptD" width="690" height="45" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/fdaf732e163b9df36243596e66411db1c0bdb371_2_690x45.png, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/fdaf732e163b9df36243596e66411db1c0bdb371_2_1035x67.png 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/fdaf732e163b9df36243596e66411db1c0bdb371_2_1380x90.png 2x" data-dominant-color="373536"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">image</span><span class="informations">2672×176 68.3 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div></p>
<p>However, if a validator is restarted they come back online with an empty list of disabled validators. We believe that validator restarts contributed to reduce the effectiveness of off-chain disabling, causing more dispute participation and spam.</p>
<p>Additionally, with sufficient CPU load, even updated validators started to dispute valid candidates when the PVF execution timeout was hit.</p>
<h2><a name="p-29294-why-did-the-finality-training-wheels-not-work-12" class="anchor" href="#p-29294-why-did-the-finality-training-wheels-not-work-12"></a>Why did the finality training wheels not work?</h2>
<p>This mechanism is triggered when either disputes or approval voting are keeping finality from progressing for at least 500 blocks. This involves any unconcluded dispute or unapproved candidate in any unfinalised Relay Chain block. Once the 500 blocks threshold is hit, all the candidates included in the unfinalised chain are approved.</p>
<p>In our case, we did have dispute lag and approval voting lag larger than 500 blocks and the training wheels were activated.</p>
<p>The training wheels did nothing because GRANDPA stopped finalised blocks even before the training wheels were activated.</p>
<h2><a name="p-29294-why-did-grandpa-stop-finalising-blocks-13" class="anchor" href="#p-29294-why-did-grandpa-stop-finalising-blocks-13"></a>Why did GRANDPA stop finalising blocks ?</h2>
<p>From past testing, we know that under very high load or bad connectivity it is possible for GRANDPA to stop finalising. In our case we can see that the amount of GRANDPA messages validators are sending has significantly dropped during the finality stall.</p>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/9/9f35589b7fd0222e9a977f224e6b8841968fda0d.png" data-download-href="/uploads/short-url/mIqd6oLQRC8k5I3XD35DhJPkFE9.png?dl=1" title="image" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/9/9f35589b7fd0222e9a977f224e6b8841968fda0d_2_690x308.png" alt="image" data-base62-sha1="mIqd6oLQRC8k5I3XD35DhJPkFE9" width="690" height="308" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/9/9f35589b7fd0222e9a977f224e6b8841968fda0d_2_690x308.png, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/9/9f35589b7fd0222e9a977f224e6b8841968fda0d_2_1035x462.png 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/9/9f35589b7fd0222e9a977f224e6b8841968fda0d_2_1380x616.png 2x" data-dominant-color="232125"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">image</span><span class="informations">1718×768 107 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div></p>
<p>One important detail is that Kusama is running with the new <code>litep2p</code> stack. At this point we don’t know if this has had a positive or negative impact, and remains to be investigated further.</p>
<h2><a name="p-29294-why-did-parachain-block-times-degrade-14" class="anchor" href="#p-29294-why-did-parachain-block-times-degrade-14"></a>Why did parachain block times degrade?</h2>
<p>During the incident the block times degraded because of two reasons:</p>
<ol>
<li>Backing back pressure. Approval voting and disputes have priority on the node side re-execution of candidates. Approval voting no-shows caused by the existing load further increased the load of the system.</li>
<li>Processing many disputes evicted entries from the node runtime API cache, triggering a bug in statement distribution. More details on the root cause can be found <a href="https://github.com/paritytech/polkadot-sdk/issues/8414#issuecomment-2879383259" rel="noopener nofollow ugc">here</a>.</li>
</ol>
<p>After emergency fix was applied, not all parachain block times returned to normal. Parachains producing candidates with v2 receipts were discarded by the node fix and their block times were severely affected.</p>
<h2><a name="p-29294-how-do-we-avoid-similar-issues-in-the-future-15" class="anchor" href="#p-29294-how-do-we-avoid-similar-issues-in-the-future-15"></a>How do we avoid similar issues in the future?</h2>
<p>We are fixing the root causes of the issues:</p>
<ol>
<li>Prevent dispute spam when validators restart. A <a href="https://github.com/paritytech/polkadot-sdk/pull/8503" rel="noopener nofollow ugc">fix</a> that populates the off-chain disabled validators at startup was merged.</li>
<li>A statement distribution <a href="https://github.com/paritytech/polkadot-sdk/pull/8510" rel="noopener nofollow ugc">fix</a> was merged. It ensures that backed candidate statements are processed even under heavy dispute spam.</li>
</ol>
<p>We are implementing stronger dispute spam prevention:</p>
<ul>
<li>On-chain disablement of validators that vote against valid candidates</li>
<li>A validator re-enabling mechanism will ensure that we don’t disable too many (more than 1/3) validators on-chain.</li>
</ul>
<p>Additionally, we will improve our testing process to reduce the chances of similar issues occurring in the future:</p>
<ul>
<li>Run larger scale and longer duration dispute tests to understand failure modes and fix potential issues before they occur on live networks</li>
<li>Dispute load testing</li>
<li>Investigate how litep2p influenced the connectivity issues and GRANDPA stall.</li>
</ul>
<h2><a name="p-29294-h-2025-05-15-root-cause-fixed-16" class="anchor" href="#p-29294-h-2025-05-15-root-cause-fixed-16"></a>2025-05-15 Root cause fixed</h2>
<p>Kusama validators were upgraded to <a href="https://github.com/paritytech/polkadot-sdk/releases/tag/polkadot-stable2503-4" rel="noopener nofollow ugc">stable2503-4</a> on May 15th, 2025. This reverts the emergency fix and includes long-lasting fixes (<a href="https://github.com/paritytech/polkadot-sdk/pull/8503" rel="noopener nofollow ugc">1</a> and <a href="https://github.com/paritytech/polkadot-sdk/pull/8510" rel="noopener nofollow ugc">2</a>) as numbered in the section above.</p>

<h2><a name="p-29280-polkadot-news-1" class="anchor" href="#p-29280-polkadot-news-1"></a>Polkadot News</h2>
<p>The Kusama ZK Summit is coming to Web3 Summit on 17 July. Apply to attend or speak here - spots are limited. <a href="https://x.com/Web3foundation/status/1922672578444804153" rel="noopener nofollow ugc">https://x.com/Web3foundation/status/1922672578444804153</a></p>
<p>Referendum 1542, proposing a liquidity campaign for Hydration parachain, is currently passing with 60.6% in favor. <a href="https://polkadot.polkassembly.io/referenda/1542" class="inline-onebox" rel="noopener nofollow ugc">Polkassembly - Referendum #1542</a></p>
<h2><a name="p-29280-kusama-news-2" class="anchor" href="#p-29280-kusama-news-2"></a>Kusama News</h2>
<p>All Kusama validators are asked to update their node software as soon as possible. <a href="https://github.com/paritytech/polkadot-sdk/releases/tag/polkadot-stable2503-4" class="inline-onebox" rel="noopener nofollow ugc">Release Polkadot stable2503-4 Kusama validators fix · paritytech/polkadot-sdk · GitHub</a></p>
<p>Referendum 522, proposing to increase the number of usable cores to 140, is failing with 17.8% in favor. <a href="https://kusama.polkassembly.io/referenda/522" class="inline-onebox" rel="noopener nofollow ugc">Increase usable cores to 140 | Polkassembly</a></p>

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

Announcement  on the Discontinuation of OpenGov Twitter Bots

Set Asset Rate for KSM/DOT Conversion for spending DOT from Kusama Treasury

PolkaTalent: Recruiting Web3 freelance devs for early user journey interviews

.KSM Authority Registration

DotShield - Take back control of your community

Kusama Shield | Dotsama assets and ZK 

Online Educational Program for C-Levels : A future Kusama DAOs Academy proposal. 

0xb75B6e4007795e84a0f9Db97EB19C6Fc13c84A5E

0x1018d93C1C8Cd8d44B839E9c44C0b9eDE0192621

DISCUSSION: Acquisition of dUSD stablecoin for Kusama treasury on Asset Hub and set dUSD as a Sufficient Asset

Executed

Whitelist Ref#522

- A vote (Ref#511) increased the number of validators to 700, which also allows more cores (140) to be used.  
- More cores mean more teams can buy them fairly in the next sale.  
- One team, Kreivo, lost its core and now has to make blocks manually, which is slow.  
- Instead of asking for a special core, this vote makes it fair for everyone to get one.

Deciding

Increase usable cores to 140

- DOT can be used on Kusama through a special bridge.  
- Around 4900 DOT are on Kusama right now.  
- DOT can be sent to Kusama’s Treasury for spending.  
- A rate is set to control how much DOT can be spent (1 DOT = 10 USDC/USDT).  
- Kusama uses a rate of 1 KSM = 4 DOT for spending limits.  
- DOT and KSM have different decimal places (DOT: 10, KSM: 12).  
- This rate helps Kusama’s treasury understand DOT amounts correctly.  
- The rate is set by a governance vote.

Set Asset rate for DOT/KSM to enable treasury spends of DOT through Kusama OpenGov

Preparing

[Whitelisted Caller] DUPLICATE of 524

[Root] Referendum #523

- This referendum moves DOT funds to the Kusama Treasury track.  
- Polkadot and Kusama can share DOT using a bridge.  
- About 4900 DOT are already on Kusama.  
- The treasury needs rules to spend DOT properly.  
- A rate of 1 KSM = 4 DOT is set for spending limits.  
- This helps Kusama OpenGov understand DOT values.  
- The rate can be changed later if needed.

DO NOT PLACE DECISION DEPOSIT - Moving Ref to Treasurer Track

[Whitelisted Caller] Disable V2 descriptors node feature

[Whitelisted Caller] Upgrade Kusama to v1.5.0

<p>&nbsp;</p>
<p>&nbsp;</p>
<p>There was a security risk and the proposal was processed externally.</p>
<p>No further occurrences with this.</p>
<p>Thank you..</p>

UPDATE "Refunding MIDL.DEV's GOV1 Treasury Spend Deposit"

Kusama

referenda7

fellowship2

treasury15

discussions1357