Succinct’s SP1 ZKVM prover had a security flaw that could have allowed incorrect proofs to be verified, potentially undermining the integrity of cryptographic proofs used in blockchain applications. Communication could have been better, but as far as we know, no user funds were at risk.

Quarterly stablecoin and trading volumes:

Stablecoin volumes and trading activity have surged to their highest levels since the 2021-22 bull run, with Q4 2024 hitting $1.86T in stablecoin transactions and $1.01T in trading volume.

Resilience or excess? That is the question.

Crypto has long thrived on cycles of exuberance and despair.

Today, the market faces a paradox. On one hand, the sheer velocity of capital suggests maturing financial infrastructure and rising utility; on the other, history warns of leverage-fueled mirages.

As we navigate 2025’s speculative maze, understanding the difference between fleeting narratives and real utility is the key to identifying winners amidst the chaos. (H/T Ryan Watkins.)

— Macauley Peterson

Code alongside peers in a high energy hackathon. Get hands on with the tools and tech defining the onchain world. Meet collaborators who could shape your next big breakthrough. Brooklyn in the summer will just hit different. Build with us at Permissionless IV.

📅 June 24–26 | Brooklyn, NY

Bug disclosure and industry best practices

Succinct’s SP1 ZKVM has come under scrutiny after LambdaClass disclosed a critical security vulnerability in its proof generation. The exploit in version 3 of SP1, discovered in collaboration with 3Mi Labs and Aligned, stemmed from the interaction of two separate security flaws.

Succinct previously disclosed the potential exploit to its customers via Github and Telegram.

Here’s what happened in simple terms:

1. Missing Verification Step — The system relied on a list to track key proof components but didn’t properly verify that the list was accurate. Consequently, a malicious prover could potentially manipulate it to produce invalid proofs. New checks were added to fix the oversight.

2. Incomplete Proof Flag — A key part of SP1’s proof-checking system included a flag meant to confirm that a proof was fully executed. However, this flag wasn’t always properly enforced, leading to a potential loophole. Succinct tightened up the checks.

3. Polynomial Evaluation Issue — An issue found in Plonky3 (a dependency of SP1), meant that it didn’t fully verify all calculations before confirming a proof was valid. Post-patch, all proof components are properly verified.

While the vulnerability was quickly addressed prior to the disclosure, the process has raised concerns about transparency in security practices for zero-knowledge virtual machines (ZKVMs). SP1’s technology is currently underpinning high profile upgrades in rollup infrastructure under development.

Transparency and implications

LambdaClass cautioned that the full implications of the flaw required further assessment. Notably, the exploit depended on the interplay between the two issues, meaning that fixing one might not be sufficient to prevent exploitation.

LambdaClass developer known as Fede, highlighted on social media that his team felt compelled to make the disclosure public after perceiving a lack of urgency in Succinct’s communication about the issue.

Succinct’s leadership acted responsibly in fixing the issue, according to Avail’s Anurag Arjun, but he agreed  better public disclosure practices are needed.

“ZKVM systems are very new and are constantly being updated, so you’d expect vulnerabilities,” Arjun told Blockworks. “In an open-source setting, anyone can run the prover, and if vulnerabilities aren’t disclosed properly, that’s definitely a risk.”

The Avail team, which uses SP1 for proof generation in its consensus mechanism, was informed about the issue privately ahead of public disclosure, Arjun confirmed.

Avail’s implementation was not exposed to risk, Arjun said, because they rely on Succinct’s proprietary prover, which remains permissioned. Avail’s rollup clients have also not yet begun using its SP1-powered bridge contract, so there was no practical impact.

Meanwhile, defenders of Succinct point out that responsible disclosure typically involves private reporting before public statements to avoid unnecessary panic and potential exploitation.

Succinct’s updated version 4 of SP1 — dubbed Turbo — resolves the identified vulnerability, and downstream projects have begun integrating these fixes. 

The case illustrates how even well-audited code can and does contain bugs. As Succinct put it, “while auditors provide valuable insights, they are not infallible, and we remain committed to continuously improving and working hard to ensure our systems are safe and secure for everyone.”

The more explicit, if belated transparency from Succinct drew praise. What remains is the question of how to best balance security, transparency, and user protection. And finding the line between due criticism and toxic infighting.

— Macauley Peterson

The Expansion podcast’s latest roundup episode tackled the recent discussion on native and based rollups, with guests Uma Roy (Succinct) and Jill Gunter (Espresso Systems).

Roy: Rollups “roll their own proof system” to prove their validity to the L1. So they need to have a way to upgrade proof logic on L1. That’s why they have a Security Council to approve upgrades to their all-important Ethereum bridge contract.

A sufficiently large council, like Arbitrum’s, with a timelock “is maybe not the worst thing in the world, but in practice it’s bad for a few reasons.”

• Liability of having a public list of multisig members

• The L2’s lack of L1 security — a bug in the proof system can result in a bridge drain, and the L1 can’t protect against this.

Remarkably, only 2% of ETH has been bridged to L2s (according to Jon Charbonneau), indicating that whales really do care about security — expressed by not bridging more ETH to rollups.

Native rollups could provide a solution. If the rollup proof system is enshrined in Ethereum mainnet, rollups making use of it would have the same security as L1 — protected by social consensus on Ethereum, via a fork in emergency cases. That, in turn, should make people more comfortable to hold assets on rollups.

Roy argues that no rollup has really differentiated itself based on its proof system. Other components matter more — UX, sequencing, available apps — so rollups can still differentiate in these other ways.

Jill: What about Polygon or Starkware, that have spent years developing their own proof systems?

Uma: Adapt or die. You can’t ignore reality. But it remains to be seen whether the EF ship actually ships native rollups, and on what timeline. But true L1 security should be a major competitive edge.

Nick: Does it limit customizability? The modular thesis doesn’t require total EVM-compatibility. Is this like sharding of L1 in a more permissionless way?

Uma: No. We can still have app-specific rollups, it’s just that Ethereum will “eat all general purpose, fully EVM compatible rollups.” That will push builders to differentiate via app-specific or more specialized rollups.

— Macauley Peterson