In How To ·

Another test post

Testing the TOC feature, especially!



Our mission at Web3 Foundation is to facilitate the next generation of the web: a decentralized and fair internet where users control their own data and markets benefit from network efficiency and security.

This post is part of an ongoing series of blogs where we report the security audits carried out to strengthen our system.

This audit was carried out by Atredis Partners, an information security company with extensive experience in penetration testing, reverse engineering, hardware/software exploitation, and embedded systems design assessment.

What was audited?

We engaged Atredis to perform a security assessment of the integrity, confidentiality, and availability of the Polkadot Runtime and the security and reliability of Polkadot validators.

Read the entire auditor’s report here.

Specifically, they sought to:

  • identify and define key attack chains against the Polkadot Runtime
  • identify any events that could compromise Polkadot transactional integrity
  • identify cases where attacker-supplied code execution could be possible
  • identify any scenarios that could affect the trustworthiness of Polkadot
  • confirm that Polkadot Runtime architecture, development, and transactional functionality align with accepted cryptographic and security best practices
  • try to disable or otherwise interfere with a validator’s role on the network
  • try to determine the specific validators selected
  • see if it was possible to force the selection of a malicious validator

Report Summary

The assessment was carried out by Atredis Partners between January 20th and February 11th, 2020. This included a bottom-up analysis of the communication stack, Polkadot runtime source code, and dynamic testing of the Kusama network. Particular attention was paid to Denial-of-Service (“DOS”) scenarios and fraudulent activity. The assessment resulted in one critical, one high, one medium and three informational findings.

The critical finding was a logic issue in the Substrate layer that allowed the generation of zero-cost transactions. As the platform is dependent on all transactions having a cost factor, this issue could allow a malicious party to delay time-sensitive actions, such as voting, by spamming the network with potentially free transactions which consume storage.

This issue was amended by updating the logic around calculating the weight and fees so that passthrough calls always pay a fee, and by standardizing the way custom weight information is calculated.

The other issues identified could not be exploited to disrupt or subvert the network as a whole. It was observed that the use of Rust programming language greatly reduced the likelihood of many classes of attack, and that the use of a WASM runtime was effective in sandboxing dynamic code.

Responses to Findings


Fixed. Verified by Atredis on local test nodes.


Fixed. Verified by Atredis through code review.


Won’t Fix.

Secure gossip-based broadcast in a public open network is an open problem, with various proposed semi-solutions which all come with different tradeoffs. Bitcoin protects against insecure gossipping by placing the burden on node operators to perform network-level monitoring, which is reasonably effective in terms of empirical performance. Polkadot has the concept of staking which allows more checks to be performed. Additionally, solutions based on in-built networking monitoring done by the nodes themselves are currently being researched. In the meantime, node operators can apply the typical checks on connection and bandwidth usage that large Bitcoin node operators do.


Won’t fix.


Won’t fix.


Won’t fix.

To stay informed of developments in the Polkadot ecosystem, subscribe to our newsletter.