On January 22, Succinct Labs announced SP1 Turbo, marketing it as the fastest zkVM with near real-time Ethereum block proving capabilities. The announcements touted performance improvements, new precompiles for signature verification, and optimized GPU proving infrastructure. Four days later, security researcher Fede (@fede_intern), CEO of AlignedLayer, publicly disclosed the discovery of critical soundness vulnerabilities in SP1's codebase.
We followed the ensuing controversy with great interest. We think it illustrates something important about the intersection of security, engineering, and public media politics in the ZK space.
We believe it is of paramount importance to get this right, collectively, if the industry is to mature correctly. Succinct insisted that they publicly disclosed the issues through GitHub advisories and developer forums, but the critics say that's not enough. What is the right way to think about this?
The research team, comprising members from 3miLabs, AlignedLayer, and LambdaClass, identified two interconnected bugs enabling arbitrary program proof generation. The exploit was serious: "[it could] prove any arbitrary program. For example you can prove you have the private keys of somebody else." The vulnerability enabled proof forgery for invalid rollup transactions. Succinct Labs had implemented fixes for one vulnerability in SP1 Turbo (v4.0.0) but apparently left the second unaddressed for 40 days post-discovery.
Uma Roy, the CEO of Succinct Labs, initially defended their disclosure approach, which consisted of a GitHub security advisory and developer forum notifications. She argued: "Posting security disclosures on X is simply not 'standard practice'... multiple other high-quality teams have followed the exact same procedure as us," citing ostensibly similar practices by RiscZero and plonky3.
Fede contested this position, calling it "delusional," citing Zcash's comprehensive approach as the proper standard.
The controversy centered on SP1's deployment model. While Succinct Labs operated a permissioned proving network, SP1's open-source nature enabled unauthorized deployments. The main criticism centered around Succinct’s security assumptions: Although no user funds were at risk due to the permissioned nature of the platform, a user operating the system in a permissionless way would still be exposed to a critical exploit.
On January 27, Succinct Labs conceded the criticism and published a comprehensive disclosure acknowledging both vulnerabilities. The disclosure confirmed the researchers' findings regarding SP1's compromised soundness properties. The company implemented fixes in SP1 Turbo and mandated customer upgrades from v3.
Standard practice in the software industry is private disclosure with a public disclosure timeline (unless there is evidence of active exploitation). This norm gives developers time to fix vulnerabilities before blackhat hackers can exploit them.
After developers have time to fix the problem, in the ZK context especially, it seems to us that security vulnerabilities in public and developer-targeted systems deserve prompt, comprehensive public disclosure.
When a project markets itself as secure infrastructure for blockchain applications, soundness bugs that potentially compromise dependent systems must outweigh concerns about reputational damage. Moreover, disclosures need to include all members of the community—especially users who are operating the protocols in a permissionless way outside of the protocol’s main tech stack.
In the end, it seems that everyone agreed on the same principle. But the very occurrence of this debate, which played out live on social media, showed us that these principles are still far from obvious and universal in our industry. They ought to be, as the stakes are high, and our industry is still in the process of maturing.
