candidates

members

proficients

fellows

senior_fellows

experts

senior_experts

masters

senior_masters

grand_masters

Miscellaneous

2025-03-18 Technical Fellowship OpenDev Call

Tommi Enenkel / Alice und Bob | Mangata

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

<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

Ideal Labs | Updates &amp; Next Steps

Carlos M

Ideal Labs | Updates & Next Steps

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

Governance discussion about the future of Polkadot and Kusama.

Governance

2025-Q1 Polkadot Treasury Report

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

April 2025 Coretime Purchase

ParityTech update for September 2024

Daan van der Plas

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>Dear community,</p>
<p>We’ve been deeply focused on advancing the trustless Drand bridge, the randomness subscription management, the indexer component, and the delivery mechanisms. We’re also excited to share that <strong>audits have officially started</strong>. Full details in our latest <a href="https://drive.google.com/file/d/11b9AkxY5uxdy8zaO-HJsdjEfF0vAl51r/view?usp=sharing" rel="noopener nofollow ugc">progress report</a></p>

<p>Seems a simpler solution would be for the Polkadot DAO to buy HDX on the open market. Easier to parameterize it’s influence over Hydration’s OpenGov that way + it’s unilateral and therefore simpler in design.</p>

Filippo

<aside class="quote no-group" data-username="josep" data-post="15" 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 was under the impression that the goal was to empower Ethereum DApp devs to use their usual tooling (Viem, or Etherjs, or Web3js, etc.) to interact directly with Polkadot AssetHub. E.g. build a staking DApp entirely with Ethereum tools.</p>
</blockquote>
</aside>
<p>The most important goal is to allow Ethereum native Apps to run with minimal changes on the PolkadotHub. And yes, those can use their existing javascript tooling. I don’t think people already in the Polkadot ecosystem should migrate away from Papi or Polkadot.js in order to build a staking Dapp.</p>
<p>That said, my hope is that the staking pre-compile exposes enough functionality to build a staking Dapp using Viem if people want to. Not sure if that can be done from the got go or we need to iterate. If you have insight into which functions are missing please speak up now.</p>
<aside class="quote no-group" data-username="josep" data-post="15" 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>What I’m hearing now is more like: since Solidity contracts can’t expose every bit of functionality you’d need for a full-featured DApp on AssetHub, Ethereum DApp devs will have to either:</p>
<ol>
<li>Mix their Ethereum tooling with non-Ethereum tools to bridge the gaps,</li>
<li>Lean heavily on indexers/aggregators,</li>
<li>Or most likely, do both.</li>
</ol>
<p>Is that a fair summary of what you’re saying?</p>
</blockquote>
</aside>
<p>No. I mean that we need to think hard of how level level the pre-compile API can be so we can guarantee its stability. And this is probably not possible in the first deliverable. The earlier we get feedback the better (from you for example). We should expose as much as we have to and as little as we can to still allow writing a useful frontend. This includes simple things like error codes: In the pre-compile we should just map them to success/failure since it will be hard to keep them stable. Error handling should not happen on-chain.</p>
<p>I can’t predict all the possible use cases. And I don’t have time to put myself in a builders shoes, sorry. I rely on feedback. Therefore what I can do is start with the minimal API I can guarantee to be stable. And add more stuff on demand. The last thing we want is top break existing Apps. As a matter of fact this will be considered a bug.</p>

<p>Even before this incident we had protection for dispute spam. However we did not really take into consideration restarts when we implemented off-chain disabling.</p>
<p>With the offchain disablement persistence fix, honest nodes will ignore dispute spam even after restart, and will not participate to create storms.</p>

<h2><a name="p-29366-timeline-1" class="anchor" href="#p-29366-timeline-1"></a>Timeline</h2>
<p>This timeline spans multiple days observing two incidents of prolonged and significant degradation of block times affecting all parachains on Polkadot. Both incidents shared the same root cause.</p>
<h2><a name="p-29366-first-incident-2" class="anchor" href="#p-29366-first-incident-2"></a>First incident</h2>
<h3><a name="p-29366-h-2025-05-02-1537-disputes-start-3" class="anchor" href="#p-29366-h-2025-05-02-1537-disputes-start-3"></a>2025-05-02 15:37 Disputes start</h3>
<p>The first dispute was seen onchain at <a href="https://polkadot.subscan.io/event?page=1&amp;time_dimension=date&amp;module=parasdisputes&amp;page_size=25&amp;date_start=2025-05-02&amp;date_end=2025-05-03" rel="noopener nofollow ugc">2025-05-02 15:37 UTC</a> at block <span class="hashtag-raw">#25832586</span>, almost seven hours before the parachain block times degrade.</p>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/0/0951fd8b2687e0b92b4ec8d9ccfdaf68d2e37a86.png" data-download-href="/uploads/short-url/1krXzzavLlRVfQXWQDtJfkziCr4.png?dl=1" title="image" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/0/0951fd8b2687e0b92b4ec8d9ccfdaf68d2e37a86_2_690x173.png" alt="image" data-base62-sha1="1krXzzavLlRVfQXWQDtJfkziCr4" width="690" height="173" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/0/0951fd8b2687e0b92b4ec8d9ccfdaf68d2e37a86_2_690x173.png, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/0/0951fd8b2687e0b92b4ec8d9ccfdaf68d2e37a86_2_1035x259.png 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/0/0951fd8b2687e0b92b4ec8d9ccfdaf68d2e37a86_2_1380x346.png 2x" data-dominant-color="202226"><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">2690×676 76 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>Offchain there are many unconfirmed disputes, coming from just a single validator, but these were not yet affecting block times.</p>
<p>We have logs from the originating validator, but only for the second incident. For the first one, no one had trace log level enabled. The dispute spam can be seen indirectly as <code>error=AuthorityFlooding</code> logs on other validators. This originating validator should already be disabled offchain because it had already lost a dispute which was recorded onchain as seen in the chart.</p>
<pre><code class="lang-auto">May 06 22:28:28 DisputeRequest(UncheckedDisputeMessage { candidate_receipt: CandidateReceiptV2 { descriptor: CandidateDescriptorV2 { para_id: Id(2043), relay_parent: 0x8df79ebedb8e78b33853becea9cc8cbbe3418e32d05e986df72ef534949941c5, pov_hash: 0xc18367b17ea6313efb417b48809bc4af2b1bb2f582f186a3cfb869499574e97a, erasure_root: 0xfd262abacb8e990f675109f0c701670bf96615ce929859b135a1678bf30dd620, para_head: 0x566735719ff93a553c86892c76dc8bbfa5d513d5991e8a442f8d9f00c88a5c8c, session_index: 10834, 
invalid_vote: InvalidDisputeVote { validator_index: ValidatorIndex(186), signature: Signature(246417e9823b188ab9749bdab303bfc1ff722f38238924444f37ec60bc1fe868359cc684ab1fe70cf37af856304941984cfa3d90963784a1b6a27b5459141181), kind: InvalidDisputeStatementKind::Explicit }, 
valid_vote: ValidDisputeVote { validator_index: ValidatorIndex(375), signature: Signature(9a308907ddf2e5012c26225957236bda7b604500d0ec02b7c50ebea0ff8eed53b075ecdf8ed396c8073b60b6ce1ee7ab8361c186e75772e4c8767e008b7eae8d), kind: ValidDisputeStatementKind::Explicit } })

May 06 22:28:28 DisputeRequest(UncheckedDisputeMessage { candidate_receipt: CandidateReceiptV2 { descriptor: CandidateDescriptorV2 { para_id: Id(2043), relay_parent: 0xb6b0d2c70b9ab9d5eddcc031287487555ae44e62a66315b6e5f9c235d33cbc2c, pov_hash: 0x1b8cdc6415c3a26f4f94757020c73b9f366144ca1c2c9d171589248dd235bbe8, erasure_root: 0x2f0252f234653d9c6997c9ceae5e650ce453bb03eb33a7ae01e7f2557e56eba1, session_index: 10834, 
invalid_vote: InvalidDisputeVote { validator_index: ValidatorIndex(186), signature: Signature(2e544e4335cb698f2ed6013421fc0e04fefc03a5fa3956f70aa8933ec5aed454d289260525aaa2f28ba9e2be636745c1a4f865fe3967c22cf26c1cc6c2af2b84), kind: InvalidDisputeStatementKind::Explicit }, 
valid_vote: ValidDisputeVote { validator_index: ValidatorIndex(375), signature: Signature(4a4f7894717dbbadf7f5a06024edfaeee69722ae19e165cbdd995975c28741539d613a6e30646e354b744b71370d031d3cad849f51f9775456f1d8c9a3e94689), kind: ValidDisputeStatementKind::Explicit } })

</code></pre>
<h3><a name="p-29366-h-2025-05-03-0215-parachain-block-times-degrade-4" class="anchor" href="#p-29366-h-2025-05-03-0215-parachain-block-times-degrade-4"></a>2025-05-03 02:15 Parachain block times degrade</h3>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/8/8a2b8d3a22ed055fe31a9060f39696138845670b.png" data-download-href="/uploads/short-url/jIjcozycoRPQpToNNDQUHhMjV4D.png?dl=1" title="image" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/8/8a2b8d3a22ed055fe31a9060f39696138845670b_2_690x192.png" alt="image" data-base62-sha1="jIjcozycoRPQpToNNDQUHhMjV4D" width="690" height="192" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/8/8a2b8d3a22ed055fe31a9060f39696138845670b_2_690x192.png, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/8/8a2b8d3a22ed055fe31a9060f39696138845670b_2_1035x288.png 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/8/8a2b8d3a22ed055fe31a9060f39696138845670b_2_1380x384.png 2x" data-dominant-color="1E2123"><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">2684×750 93.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></p>
<p>All Polkadot parachain block times suffered significant degradation. The  block times increased from an average of 10s to as high as 30s during spikes.</p>
<p>At this point we don’t have much data to identify the root cause. All logs provided by validators show heavy dispute spam, but validators were not participating and there are no signs of high network or CPU load.</p>
<p>We asked a few of the validators to restart with debug logs and we then observed that, following a restart, there were no further dispute spam flood logs.</p>
<h3><a name="p-29366-h-2025-05-03-0730-more-validator-restarts-5" class="anchor" href="#p-29366-h-2025-05-03-0730-more-validator-restarts-5"></a>2025-05-03 07:30 More validator restarts</h3>
<p>We asked even more validators to restart gradually with the hope that this would mitigate the dispute flood.</p>
<h3><a name="p-29366-h-2025-05-03-0745-block-times-return-to-normal-6" class="anchor" href="#p-29366-h-2025-05-03-0745-block-times-return-to-normal-6"></a>2025-05-03 07:45 Block times return to normal</h3>
<p>Validators gradually stopped spamming and all parachain block times returned to normal after five hours, 30 minutes.</p>
<h2><a name="p-29366-second-incident-7" class="anchor" href="#p-29366-second-incident-7"></a>Second incident</h2>
<h3><a name="p-29366-h-2025-05-06-738-first-dispute-8" class="anchor" href="#p-29366-h-2025-05-06-738-first-dispute-8"></a>2025-05-06 7:38 First dispute</h3>
<p>The first dispute is seen onchain in block <a href="https://polkadot.subscan.io/block/25884954" rel="noopener nofollow ugc">#25884954</a> and second in block <a href="https://polkadot.subscan.io/block/25887326" rel="noopener nofollow ugc">#25887326</a> at 2025-05-06 11:36.</p>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/1/1e37e3459c472d87381bcec876a98b7e0989f153.png" data-download-href="/uploads/short-url/4jk3UG5EoxlpOprAPq22EV8SFB9.png?dl=1" title="image" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/1/1e37e3459c472d87381bcec876a98b7e0989f153_2_690x193.png" alt="image" data-base62-sha1="4jk3UG5EoxlpOprAPq22EV8SFB9" width="690" height="193" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/1/1e37e3459c472d87381bcec876a98b7e0989f153_2_690x193.png, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/1/1e37e3459c472d87381bcec876a98b7e0989f153_2_1035x289.png 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/1/1e37e3459c472d87381bcec876a98b7e0989f153_2_1380x386.png 2x" data-dominant-color="202226"><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">2678×752 148 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>
<h3><a name="p-29366-h-2025-05-06-1115-new-node-release-stable2503-1-9" class="anchor" href="#p-29366-h-2025-05-06-1115-new-node-release-stable2503-1-9"></a>2025-05-06 11:15 New node release: stable2503-1</h3>
<p>Validators were notified and some validators automatically started the upgrade process, restarting their nodes. Other validators gradually restarted while further disputes were <a href="https://polkadot.subscan.io/event?page=1&amp;time_dimension=date&amp;module=parasdisputes&amp;page_size=25&amp;date_start=2025-05-04&amp;date_end=2025-05-07" rel="noopener nofollow ugc">raised</a>.</p>
<p>Similarly to the first incident, unconfirmed disputes were being spammed.</p>
<p>The originator of these disputes was the same validator as in the first incident. As more validators restarted, they started participating and increasing the volume of dispute spam.</p>
<h3><a name="p-29366-h-2025-05-06-1245-parachain-block-times-degrade-10" class="anchor" href="#p-29366-h-2025-05-06-1245-parachain-block-times-degrade-10"></a>2025-05-06 12:45 Parachain block times degrade</h3>
<p><div class="lightbox-wrapper"><a class="lightbox" href="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/original/2X/f/fe971a3616cb5da130f88f340e044eab2b7032be.png" data-download-href="/uploads/short-url/Akd0NsyeNqyw8r9N23DxMfS2WN8.png?dl=1" title="image" rel="noopener nofollow ugc"><img src="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/fe971a3616cb5da130f88f340e044eab2b7032be_2_690x191.png" alt="image" data-base62-sha1="Akd0NsyeNqyw8r9N23DxMfS2WN8" width="690" height="191" srcset="https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/fe971a3616cb5da130f88f340e044eab2b7032be_2_690x191.png, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/fe971a3616cb5da130f88f340e044eab2b7032be_2_1035x286.png 1.5x, https://europe1.discourse-cdn.com/flex005/uploads/polkadot2/optimized/2X/f/fe971a3616cb5da130f88f340e044eab2b7032be_2_1380x382.png 2x" data-dominant-color="202425"><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">2678×742 58.8 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>We asked validators to restart, but it had no effect on dispute spam and block times.</p>
<h3><a name="p-29366-h-2025-05-07-0745-parachain-block-times-recover-11" class="anchor" href="#p-29366-h-2025-05-07-0745-parachain-block-times-recover-11"></a>2025-05-07 07:45 Parachain block times recover</h3>
<p>The block times recovered exactly 24 hours after the first dispute that we believe triggered the block time degradation. This is exactly the size of the dispute session window on Polkadot (6 * 4h)</p>
<h2><a name="p-29366-why-did-validators-initiate-disputes-12" class="anchor" href="#p-29366-why-did-validators-initiate-disputes-12"></a>Why did validators initiate disputes?</h2>
<p>We currently have few logs and information about dispute initiation, or the amount of unconfirmed disputes. However, we saw that on rare occasions, dispute events have occurred on Polkadot over time.</p>
<p>The single validator raising disputes reported disk failures. We know that disk corruption can lead to disputes as documented <a href="https://github.com/paritytech/polkadot-sdk/issues/677" rel="noopener nofollow ugc">here</a>. Another data point is that we have seen one validator disputing because it fails the storage root checks, documented in this <a href="https://github.com/paritytech/polkadot-sdk/issues/8508" rel="noopener nofollow ugc">ticket</a>.</p>
<p>However, just one single validator spamming disputes should not overload nodes, nor increase parachain block times.</p>
<h2><a name="p-29366-why-did-the-others-validators-spam-with-disputes-13" class="anchor" href="#p-29366-why-did-the-others-validators-spam-with-disputes-13"></a>Why did the others validators spam with disputes?</h2>
<p>All the other validators that participated and spammed with disputes are the ones that restarted. Nodes started with an empty list of offchain disabled validators and populated the list from future concluded disputes. The nodes did not ignore the messages from the originator and started the spam.</p>
<p>Offchain disablement lasted for just one session. So, at the beginning of every session the initiator was disabled again as soon as it lost the first dispute. Validators which restarted in the previous session would mark the validator as disabled for the current session.</p>
<p>However, if a validator was disabled in session N, other validators would accept and participate in disputes raised by the same validator in prior sessions where the validator was not marked as disabled.</p>
<p>This created a dispute storm of variable intensity depending on how many validators restarted and participated, and relay messages for the unconfirmed disputes.</p>
<h2><a name="p-29366-why-did-parachain-block-times-degrade-14" class="anchor" href="#p-29366-why-did-parachain-block-times-degrade-14"></a>Why did parachain block times degrade?</h2>
<p>The root cause of the degradation can be traced back to a long standing bug in the candidate backing pipeline.</p>
<p>The statement distribution subsystem handles backed candidate statements from various forks. Upon importing a new block, it queries the runtime API (<code>disabled_validators</code>) for a list of validators disabled onchain for all blocks where the node must accept candidates. If this query fails for any block, the process is interrupted.</p>
<p>During the incident, some of these queries failed due to block pruning. Consequently, the subsystem skipped processing the most recently imported blocks and any backed candidates built on top of them. This explains the absence of backed candidates in many Relay Chain blocks.</p>
<p>Normally, pruning is not a problem as <code>disabled_validators</code> runtime API does not fail. The result of the call can still be found in the LRU cache of the runtime-api subsystem. However, during dispute spamming with old disputes, the LRU cache evicted the block in favour of the blocks with disputes, so the call failed.</p>
<p>Full detailed root cause explained <a href="https://github.com/paritytech/polkadot-sdk/pull/8510" rel="noopener nofollow ugc">here</a>.</p>
<h2><a name="p-29366-why-did-offchain-disablement-fail-15" class="anchor" href="#p-29366-why-did-offchain-disablement-fail-15"></a>Why did offchain disablement fail?</h2>
<p>Offchain disablement failed because the list of disabled validators was not preserved at restart. After restart, nodes participated and sent dispute messages for the unconfirmed disputes for an entire session, unless another dispute concluded against the originator.</p>
<h2><a name="p-29366-how-do-we-prevent-future-similar-incidents-16" class="anchor" href="#p-29366-how-do-we-prevent-future-similar-incidents-16"></a>How do we prevent future similar incidents?</h2>
<p>Fixes:</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 offchain disabled validators at startup has been merged.</li>
<li>A statement distribution <a href="https://github.com/paritytech/polkadot-sdk/pull/8510" rel="noopener nofollow ugc">fix</a> has been merged. It ensures that backed candidate statements are processed even under heavy dispute spam.</li>
</ol>
<p>Testing:</p>
<ul>
<li>Improve dispute activity monitoring and alerting</li>
<li>Create a long-duration dispute testing pipeline covering offchain disablement, slashing and validator restarts</li>
<li>Regular dispute load tests</li>
</ul>
<h2><a name="p-29366-h-2025-05-15-root-cause-fixed-17" class="anchor" href="#p-29366-h-2025-05-15-root-cause-fixed-17"></a>2025-05-15 Root cause fixed</h2>
<p>Polkadot validators started to upgrade 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 release includes fixes for dispute spam and statement distribution (<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>

[2025-05-03] Polkadot parachain block time degradation

<p>Hello everyone,</p>
<p>We have executed the sale of one Polkadot core for 2,000 DOT. Core 64 was assigned to paraID 3415 upon receipt of payment.</p>
<p>Payment transaction: <a href="https://polkadot.subscan.io/extrinsic/26028880-2" rel="noopener nofollow ugc">https://polkadot.subscan.io/extrinsic/26028880-2</a></p>
<p>Core assignment transaction: coretime- polkadot.subscan. io/extrinsic/1791677-2</p>
<p>ParaID 3415 now holds a renewable core under the following cost projections, illustrating the benefit of purchasing now versus waiting for the next sale:</p>
<h2><a name="p-29365-h-9227-dot-core-1" class="anchor" href="#p-29365-h-9227-dot-core-1"></a>92.27 DOT Core</h2>
<ul>
<li>Initial purchase: 2,000 DOT</li>
<li>Renewal 1: 95 DOT (total 2,095 DOT)</li>
<li>Renewal 2: 98 DOT (total 2,193 DOT)</li>
<li>Renewal 3: 101 DOT (total 2,294 DOT)</li>
<li>Renewal 4: 104 DOT (total 2,398 DOT)</li>
</ul>
<h2><a name="p-29365-h-922-dot-core-2" class="anchor" href="#p-29365-h-922-dot-core-2"></a>922 DOT Core</h2>
<ul>
<li>Initial purchase: 922 DOT</li>
<li>Renewal 1: 950 DOT (total 1,872 DOT)</li>
<li>Renewal 2: 978 DOT (total 2,850 DOT)</li>
<li>Renewal 3: 1,007 DOT (total 3,857 DOT)</li>
<li>Renewal 4: 1,038 DOT (total 4,895 DOT)</li>
</ul>
<p>To remind everyone of our current offerings, we have the following for sale:</p>
<ul>
<li>
<p>One Polkadot core for 2,000 DOT</p>
<ul>
<li>Originally acquired for 92 DOT; renewal schedule as detailed above</li>
<li>The purchaser will save money after 2 months versus buying a core on the open market next month</li>
</ul>
</li>
<li>
<p>Polkadot chain with 9 cores</p>
<ul>
<li>Available for lease-swap via transfer of paramanager proxy account to support elastic scaling</li>
<li>Renewal cost approximately 9 DOT per core</li>
</ul>
</li>
<li>
<p>Five Kusama chains (12 cores each) at 800 KSM per chain</p>
</li>
<li>
<p>One Kusama chain with 13 cores</p>
</li>
</ul>
<p>We will continue our activities within these markets and welcome any inquiries at <a href="mailto:coretimenegotiation@protonmail.me">coretimenegotiation@protonmail.me</a></p>

<p>I believe that the lack of communication around Polkadot Hub resulted into <a href="https://forum.polkadot.network/t/can-pallet-revive-help-improve-polkadots-ux/12923/12">this forum post thread</a> .</p>

<p>I think I have highlighted <a href="https://forum.polkadot.network/t/can-pallet-revive-help-improve-polkadots-ux/12923/12">here</a> another problem, with ideas to move forward, that is worth discussing. Sounds I would need backing from the community to validate that but in general I think we can agree that there is very little sparring back and forth on the direction of Polkadot Hub.</p>

Update on Ethereum compatible smart contracts

<h2><a name="p-29358-polkadot-news-1" class="anchor" href="#p-29358-polkadot-news-1"></a>Polkadot News</h2>
<p>Asset Hub migration on Westend has successfully completed. Account balances, staking, and governance have moved off the relay chain to a parachain. <a href="https://westend.subscan.io/block/26047261?tab=event&amp;event=26047261-0" class="inline-onebox" rel="noopener nofollow ugc">Subscan | Westend Block Details</a></p>
<p>This will eventually occur on Kusama and Polkadot as well, making it both easier to interact with these systems as well as allowing for more scalability. For details, see the FAQ here: <a href="https://docs.google.com/document/d/1XR3vL2p4QV0wC7FrlC8eN-q62BqNFTFElbj21wEmMGg/edit?tab=t.0#heading=h.vxykbd6ai7n7" class="inline-onebox" rel="noopener nofollow ugc">Asset Hub Migration FAQ - Google Docs</a></p>
<p>The 2025 Q1 Treasury Report from alice_und_bob was published on the Polkadot Forum. <a href="https://forum.polkadot.network/t/2025-q1-polkadot-treasury-report/12951" class="inline-onebox">2025-Q1 Polkadot Treasury Report</a></p>
<p>Key insights: This was the first positive quarter for Treasury flow since reporting began, and Polkadot currently has 10 years’ worth of reserves. But note the Treasury is a renewable resource.</p>
<h2><a name="p-29358-kusama-news-2" class="anchor" href="#p-29358-kusama-news-2"></a>Kusama News</h2>
<p>Referendum 521, setting an asset conversion rate and thus allowing DOT Treasury spends on Kusama, is passing with 79.1% in favor. <a href="https://kusama.polkassembly.io/referenda/521" class="inline-onebox" rel="noopener nofollow ugc">Set Asset rate for DOT/KSM to enable treasury spends of DOT through Kusama OpenGov | Polkassembly</a></p>

bill_w3f

Polkadot Digest 16 May 2025

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

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

Abinash Sahoo

Introducing Dotme: Support Your Favorite Creators with DOT

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

<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

referenda6

fellowship2

treasury15

discussions1363