Hey @MN0B, nice to meet you. First of all, I apologize for posting this here instead of opening a new thread, but I believe this is directly related to the broader goal of this thread, which is improving incident management and security coordination across the Polkadot ecosystem. The work you are doing here with the emergency contact protocols and the routing flow for incidents and vulnerabilities is exactly the kind of thing that makes an ecosystem attractive for security researchers like me.
I’m a security researcher with deep interest in the Polkadot ecosystem, Polkadot parachains and Substrate-based chains, and during the last few months I’ve helped a couple of them mitigate very serious vulnerabilities through their bug bounty programs. I value responsible disclosure a lot, and I believe it is always the right path to improve the ecosystem in a meaningful way.
I saw that there is an active bug bounty on Bug Bounty Program | Parity Technologies , and I would love to invest a significant amount of time doing a deep dive on the codebase, hunting for serious vulnerabilities and helping improve Polkadot’s security posture. However, after reading the program page carefully, I found some points I would be very grateful if you could address or clarify. Some of these are things I think could genuinely improve the program’s attractiveness to experienced whitehats:
Reward transparency
The program states that the minimum reward for eligible bugs is the equivalent of 100 USD in KSM, and that rewards beyond that are at the team’s discretion. I think this floor is quite low for a blockchain/DLT bug bounty of this scope and complexity. For reference, programs with comparable scope and codebase complexity in this industry typically start at around 1,000 USD for the lowest eligible severity and go up to 1 million USD or more for critical findings. I understand rewards are discretionary, but for whitehats like me who are trying to decide whether to commit weeks or even months to a codebase, having published reward ranges tied to severity levels makes a huge difference. It is basically what allows us to assess whether the time investment is justified. Would you consider publishing indicative ranges?
Severity classification
I could not find any reference on the program page to the method used for evaluating the severity of a submission. The page mentions that the team will assign a severity level, but does not specify what framework is used. Is CVSS 3.1 used? Or something like the Immunefi Vulnerability Severity Classification System v2.3 ( Immunefi - Immunefi Vulnerability Severity Classification System - v2.3 | Immunefi ), which has concrete definitions tailored specifically for blockchain bug bounties and ties each impact type to a severity and payout range? Knowing the framework upfront would help researchers calibrate their findings and write better reports aligned with your expectations.
SLA and triage process
I noticed the program asks to allow two business days for an initial response, which is great and appreciated. But beyond that initial acknowledgment, is there a defined SLA for triage, severity confirmation, and final resolution or payout? This might not seem like a big deal from the program side, but from the researcher’s perspective it matters a lot. Being stuck in limbo for weeks or months after submitting a serious finding with no updates is one of the main reasons experienced whitehats avoid certain programs. Even a rough commitment like “we aim to triage within X days and resolve within Y days” goes a long way.
Scope freshness and deprecated components
The scope currently includes Polkadot-JS (apps, extension, and common repos). However, from what I can see, the Polkadot.js API is officially in maintenance mode and no longer actively developed, and the extension has been rebranded to the Polkadot Developer Signer. Are findings in these repositories still being actively accepted and rewarded, or would they be deprioritized given their maintenance status? I ask because I want to make sure I focus my time on the areas that matter most to the team and where my findings would actually lead to fixes.
On the other end of the spectrum, the Polkadot ecosystem has evolved quite a bit recently with the introduction of Polkadot Hub, pallet-revive and PolkaVM for smart contracts, the new economic model with the DAP, and all the changes rolling out in March 2026. Are these newer components covered under the existing scope (for instance, under “Runtimes” or “Polkadot SDK”), or is there a plan to update the scope explicitly to reflect them?
Also, more generally, are there any components currently listed in scope that the team considers lower priority or that are scheduled for deprecation? I want to avoid spending weeks auditing something that is on its way out.
Submission channel
The program page links to a contact form and also mentions an email address. Is there a preferred channel for high-severity submissions, or are both equivalent?
I realize this is a lot of questions, but they all come from the same place: I genuinely want to invest serious time in this codebase and help make the ecosystem more secure, and having clarity on these points would make that commitment much easier.
Thanks in advance for taking the time to read this.
Cheers,
LoopGhost
Better routing for Incidents & Vulnerabilities
Why We Need This
Privacy (You choose the level)