ZK development has a fundamental problem: fragmentation. Every language in the ecosystem targets a different proving system, requires its own compiler stack, and forces teams to build core infrastructure (such as compilers, optimizations, and security tools) from scratch for each new system. This has made ZK infrastructure hard to maintain, extend, and secure. LLZK is the shared intermediate representation built to fix this. It is built on top of MLIR, giving it a modular and extensible compiler foundation that allows tooling, transformations, and backends to be reused across the ecosystem instead of rebuilt for every language.. With V1.0, it is stable, community-driven, and ready to use.

TL;DR

• LLZK V1.0 is the first stable ZK intermediate representation release.
• Any ZK language targeting LLZK can use shared backends and tooling, such as Picus and ZK Vanguard,
• V1.0 adds Rust bindings, Halo2, and Picus backend support.
• Galois contributed a backend independently, showing real external traction.
• LLZK has its own GitHub org, funded by the Ethereum Foundation.

A fragmented stack with no common ground

The rapid evolution in the ZK ecosystem has produced a diverse landscape of languages, compilers, and proving backends, each of which has been designed and optimized for different arithmetizations and performance tradeoffs. While this innovation has accelerated progress, it has also caused fragmentation: every language defines its own compilation pipeline, constraint representation, and tooling interfaces. As a result, even standard infrastructure (i.e., tools for translating constraints, optimizing arithmetization, or analyzing circuit correctness) must be reimplemented repeatedly across ecosystems. What the ZK space lacks is a shared intermediate layer, a common representation that decouples front-end languages from back-end systems and enables transformation and analysis tools to operate across them without duplication.

This problem has a precedent. MLIR, developed at Google and now part of the LLVM project, gave the compiler ecosystem a shared intermediate representation that decoupled front-end languages from back-end targets. Instead of each framework rebuilding its own lowering passes, teams could target MLIR once and inherit a shared set of transformations and infrastructure. The ZK space is at the same inflection point. LLZK is the answer we built for it,  implemented directly on top of MLIR as a family of dialects that model ZK-specific constructs (such as constraints and witness generation), and using MLIR’s pass infrastructure to support lowering, optimization, and analysis across multiple abstraction levels. This allows LLZK to integrate naturally with existing compiler tooling while remaining extensible as new proving systems and arithmetizations emerge.

LLZK V1.0 and the shared intermediate representation for ZK

LLZK is a shared compilation target that sits between ZK languages and backend systems. Language developers support compilation to LLZK, and from that point, their programs can be transformed, analyzed, or executed across any backend that supports the IR. This decouples front-end language design from backend proving systems and creates a common layer where infrastructure can be built once and reused across the ecosystem.

Security tooling is one example of what this enables. Our own tools, Picus for formal verification of circuit determinism and ZK Vanguard for static analysis of constraints and witness generation logic, are built on this layer, so any language that targets LLZK can use them. LLZK turns a fragmented set of languages and systems into a unified, interoperable ecosystem.

Community traction: external contributions and a standalone GitHub org

We want to be clear: LLZK is not a Veridise product. It is open-source infrastructure, and V1.0 is an ecosystem milestone, not a company release.

The most concrete signal: Galois, a research company based in the United States, built a zkLean backend on top of LLZKand contributed it back to the project. They did not coordinate closely with us during the build. They worked from the public IR, built what they needed, and submitted for review.
This is exactly the behavior a shared IR is meant to enable: independent teams building interoperable components without coordination.

LLZK now lives in its own GitHub organization, separate from Veridise. Community projects built on top of the IR can be hosted there. The Ethereum Foundation made this possible: their first grant funded the initial build, their second grant is funding continued development and maintenance, and their network helped bring together the communities now working on top of it.

Who this is for

ZK language developers building compilers or DSLs can target LLZK as an output format and access a growing set of shared backends, transformations, and security analysis tools without building them from scratch.
ZK application teams working in languages that already compile to LLZK can run Picus or ZK Vanguard as part of their security workflow today.
Security researchers working on ZK vulnerability classes can build analysis tools once for LLZK rather than writing language-specific passes for each ecosystem they want to reach.

What is available now

Live now:

• LLZK repository and documentation
• LLZK Rust bindings for writing LLZK programs and running LLZK compiler passes
• Frontends: Circom, Halo2/PLONKish
• Backends: R1CS, zkLean, Picus, ZK Vanguard

Check here for the full list of available features and tools in the LLZK organization!

Coming soon:

• Formal specifications in LLZK
• Enhanced template support for generic structs and functions 
• Witness generation backend

Build on shared ZK infrastructure

If your ZK language or toolchain targets LLZK, it becomes part of a shared ecosystem where infrastructure is reusable and interoperable by default. Tools, backends, and transformations written once can be applied everywhere.

Security analysis is one example where this sharing really matters. Robust analysis tools can be written once, then made available to every language that compiles to LLZK IR. Over 96% of ZK circuit layer bugs stem from underconstrained logic. The ZK language a team chooses to use should not determine whether those bugs get caught.

Request Audit (https://veridise.com/request-audit/) – Work with the team that builds and maintains the ZK security tools that run on LLZK.

View Past Audits (https://veridise.com/audits-archive/) – See how Veridise has applied formal verification and static analysis across ZK systems at the circuit level.