Notice: Polkadot has migrated to AssetHub. Balances, data, referenda, and other on-chain activity has moved to AssetHub.Learn more
DotFuzz - Hardening Polkadot through TryState invariants and CI-fuzzing
Proposal Overview
We propose to harden Polkadot and increase its hacking resilience by:
- Embedding TryState invariants across high-impact pallets, and
- Launching an OSS-Fuzz-style framework, DotFuzz, for continuous runtime fuzzing, leveraging the invariants to transparently find deep logic bugs in new feature requests.
During the 6-month effort, we will collaborate closely with Polkadot’s core developers and ecosystem stakeholders, with whom this proposal is closely aligned.
The effort’s first value contribution is embedding standardized TryState invariants into Polkadot SDK pallets (starting from prioritized high-impact logic), ensuring that critical code changes are systematically verified. This strengthens the network’s safety without slowing development.
The second pillar involves leveraging industry-leading fuzzing technologies, specifically: Adapting Google’s OSS-Fuzz approach into a Polkadot-specific DotFuzz. The project will reach near-complete coverage of the codebase logic, with robust reporting and a reproducible test corpus that fosters security assurance and continuous improvement at an early development stage.
Funding is sought to support the end-to-end development and deployment of these advanced security capabilities over the course of six months.
Deliverables
- Month 1: Technical specification of the fuzzing farmwork; documents outlining the prioritization of pallets for the next steps
- By month 3: TryState invariants merged into polkadot-sdk
- By month 6: Fully open-source pipeline for continuous fuzzing of substrate-based runtimes, and a public dashboard for polkadot-sdk fuzzing
About Us
Security Research Labs is a cybersecurity consultancy committed to making the world more secure. Discover more about us on our website.
We have created two projects through referenda in the past (942 and 1045), and have collaborated with Parity and other Polkadot ecosystem partners since 2019.
We Appreciate Your Feedback
How can we improve our proposal? Your input will help us refine our approach to better serve the Polkadot community.
Comments (12)
Requested
Proposal Failed
Summary
0%
Aye
0%
Nay
Aye (6)0.0 DOT
Support0.0 DOT
Nay (43)0.0 DOT
Why is fuzzing Polkadot-sdk a priority when the latest biggest vulnerability in the polkadot ecosystem in terms of value abstraction was a governance attack on a parachain. Not a lot of the biggest value transfers security bugs in web3 has been found using fuzzing(None of the latest 15 defi vulnerabilities where found with fuzzing), according to https://rekt.news/ , shouldnt it be a higher priority to focus on static code analysis instead?
@Rust Syndicate - Thank you very much for the feedback!
To clarify: We would not pit fuzzing against static analysis. Both are crucial in ensuring the protection of our DOT ecosystem in complementary ways:
Your observations is very valid: Many bugs that make it "into the wild" could not have been found through fuzzing. But that is because Parity and other main players apply fuzzing to find and fix many bugs before the code goes live. Our fuzzing work alone has discovered over a hundred important parachain issues in polkadot-sdk, and through the Alpha Program and Substrate Builders Program. See the 2024 statics.
The proposed effort will democratise fuzzing capabilities and make them available to everyone in DOT.
Thanks again.
The SRLabs Crypto Team
Saxemberg has voted NAY on the Polkadot referendum 1715 DotFuzz - Hardening Polkadot through TryState invariants and CI-fuzzing. Notes: Funding through the PAL bounty could be sought. Polkadot-sdk audits specially independent ones, should have fellowship/core team approval and/or be heavily requested by 'em.
This referendum is eligible for vote overrule:
https://voting.opensquare.io/space/the-sax-guild/proposal/QmUzndbMoKpXg1irsBLJRTbQPg72i9rScyAA9rQBVT6B8b
@SAXEMBERG - Thank you for the feedback!
This is not an independent audit but upstream SDK hardening (TryState invariants + CI-fuzzing) to be integrated in polkadot-sdk. We are closely aligned with the core maintainers on this — Parity (Pierre Aubert, VP of Engineering) supports the approach.
Hope this clarifies. Please let us know if you have any questions or concerns.