Vulnerability in Kona fallback proof system

Communications đź“Ł
1

Summary

An audit found three instances where kona-proof’s derivation logic could differ from the canonical chain. No funds were at risk on OP Stack chains because no OP Stack chains using permissionless fault proofs are using kona-proof yet as the active proof system (the “respected game type”). It is currently a fallback proof system.

These have been fixed and all chain operators using permissionless fault proofs have upgraded. The fix became public in PR #19775 and is included in kona-client/v1.2.13.

No further action is necessary.

The fixes have been reviewed and confirmed by the auditors and the audit report is available here.

Timeline

  • 27 Jan, 2026: Audit identified findings.

  • 19 Feb, 2026: Fixes confirmed by auditors and made available to permissionless chain operators and other chains using Succinct and Boundless proof systems.

  • 26 Mar, 2026: Fixes became public after the last (non-Superchain) chain operator confirmed they had upgraded.

Context for evaluating fault proof vulnerabilities

  • Our security posture for fault proofs focuses on fundamental safety mechanisms first – we take a defence in depth approach assuming that bugs in the fault proof system do exist.

  • We have safeguards in place: monitoring, the air gap, the ability to blacklist games, and potentially fall back to permissioned dispute games.

  • It’s very expensive for an adversary to attempt to exploit a fault proof vulnerability if it requires playing a full dispute game down to the step() function (they will require ~300 ETH in bonds which they will forfeit if they don’t win the dispute game), so they only have incentive to do so if they know they can succeed. So knowing that we can blacklist games is a strong deterrent.

5 Likes
2

Thanks for the transparent disclosure on this. It’s reassuring to see that the vulnerability was caught through a structured audit process and that no funds were at risk at any point.

A couple of things I appreciated here — the timeline was clearly laid out, and the fix was already deployed before the public disclosure. That’s responsible security practice.

One thing I’d be curious about: as Kona moves closer to becoming the primary proof system (rather than just fallback), will there be additional audit rounds or a formal security review before that transition happens? Given that this is a critical piece of OP Stack’s fault proof infrastructure, understanding the readiness criteria would be helpful for governance participants and chain operators alike.

Looking forward to seeing Kona mature the OP Stack’s permissionless proof direction is genuinely exciting.

1 Like