# Noir DSL: ACIR-based zero knowledge proof development

> Noir is a domain-specific language for programs that feed SNARK proving systems through ACIR. Its compiler and tooling cover native Rust, WASM, debugging, and browser integration, but the README says the implementation is unaudited and unsuitable for production.

**noir-lang/noir** — Noir is a domain specific language for zero knowledge proofs

- Repository: https://github.com/noir-lang/noir
- Website: https://noir-lang.org
- Stars: 1,439 · Forks: 414
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/noir-lang-noir

## Noir's target problem: circuits without a general-purpose prover

Noir addresses developers who need to express computations for zero knowledge proving systems but do not want to write every circuit as low-level cryptographic assembly. It is a domain-specific language rather than a general systems language, and its intended output boundary is an ACIR-compatible proving system. That boundary matters. Noir describes computations and compilation targets ACIR, but the README does not claim that Noir includes every possible proving or verification backend.

The repository is therefore most relevant to teams evaluating the design of an SNARK application, experimenting with proof-oriented code, or contributing to the compiler and its supporting tools. It can also serve as the language layer in a larger stack whose proving system accepts ACIR. The README does not identify a specific supported circuit target, production deployment platform, or complete proof lifecycle, so those details must be established through the linked documentation.

Noir should not be confused with a managed proof service. The repository contains compiler crates, CLI tools, standard-library code, integrations, examples, and JavaScript packages. That breadth does not establish operational readiness. In fact, the README gives a direct warning: the implementation is in early development, has not been reviewed or audited, is not suitable for production, and is expected to contain bugs. This limitation outweighs the convenience of the DSL for any deployment carrying real security or availability consequences.

## Compiler, ACIR, and tooling architecture

The repository layout shows a layered Rust workspace rather than a single compiler executable. Compiler crates include `noirc_frontend`, `noirc_arena`, `noirc_evaluator`, `noirc_errors`, `noirc_driver`, `noirc_printable_type`, and `noirc_span`. This division places parsing, semantic analysis, evaluation, diagnostics, source locations, and driver-level orchestration in separate components. The visible structure supports the language implementation, but the README does not provide a step-by-step account of the internal compilation pipeline.

The `acvm-repo/` workspace contains crates named `acir`, `acvm`, `acir_field`, `brillig`, `brillig_vm`, black-box solver crates, and JavaScript bindings. Based on those names and Noir's stated ACIR compatibility, the repository separates circuit representation and execution concerns from compiler tooling. It also includes `tooling/nargo_cli`, formatting, documentation, ABI generation, profiling, inspection, debugging, and a language server. The breadth is useful to language tooling work, although the README does not claim that every crate is a separately supported public interface.

JavaScript consumers have dedicated workspaces under `compiler/wasm` and several `tooling/` directories, including `noir_js`, `noir_codegen`, `noirc_abi_wasm`, and `acvm_js`. Repository examples also cover browser use, proving and verification, recursive programs, Solidity verifier generation, profiles, and coverage. These entries show intended integration surfaces, but they are not evidence that the current release candidate is ready for production.

## Installing Noir and reaching a first proof example

The README does not give a standalone installation command. It directs users to the installation section in the official documentation and then points them to `Awesome Noir` for community examples. Accordingly, the supported first step is to follow `https://noir-lang.org/docs/getting_started/quick_start/`, rather than invent a package name, installer flag, or backend configuration.

For contributors working from this checkout, the root `package.json` identifies `yarn@4.13.0` as the package manager and defines workspace-wide commands. The JavaScript workspace can be built with the repository script below. This builds package workspaces in topological order while excluding the root and browser example package.

```bash
yarn build
```

The command comes directly from `package.json`; the repository does not state what success output to expect. It should complete the build scripts declared by the selected workspaces. This is a contributor or workspace build step, not a documented end-user installation method for Noir.

The Rust workspace requires `rustc` 1.89.0 or later. The version is also recorded as `rust-version = "1.89.0"` in `Cargo.toml`. The root package scripts include integration tests and JavaScript tests:

```bash
yarn test:integration
```

That command runs the `integration-tests` workspace test script. The repository does not give a Noir source program, a CLI invocation, or the proving backend setup needed for a complete first proof. The official quick start and a community example are the documented paths for filling that gap.

## Repository maintenance and release-candidate risk

The repository is not archived, and the last push was on 2026-10-16. The most recent listed release is `v1.0.0-rc.5`, published on 2026-10-15, with nightly builds dated 2026-10-14 and 2026-10-15. These dates indicate recent repository activity, but the README still describes the implementation as early-stage and not production-suitable. Recent commits therefore cannot be treated as a substitute for review or audit.

The release name also calls for care. A version ending in `rc.5` is a release candidate according to its label, while the README refers to an alpha phase. The README does not explain the project's release classification or compatibility guarantees. Users should inspect `CHANGELOG.md` and the release notes before selecting a version. The repository contains `release-please-config.json`, `.release-please-manifest.json`, and release automation metadata, but their contents are not available here, so the precise upgrade policy remains unconfirmed.

Upgrade cost is potentially higher than for a small library because the workspace spans the compiler, ACVM, standard library, native CLI tooling, WASM bindings, debugging, formatting, ABI generation, and examples. Changes in one layer can affect artifacts or browser integrations, although the README does not document artifact compatibility, migration procedures, or rollback. It is also silent about production support windows.

## Dual MIT and Apache-2.0 licensing constraints

The repository is distributed under a dual MIT and Apache-2.0 license, with the license files named `LICENSE-MIT` and `LICENSE-APACHE`. Contributions are also dual licensed under those terms unless a contribution explicitly states otherwise. This makes the licensing model explicit at the repository level and gives adopters the option to evaluate the provisions of either included license.

No legal advice is needed to state the operational distinction: integrators must preserve applicable license notices and comply with the selected license's conditions. The repository does not specify how generated artifacts, standard-library code, examples, or dependencies are licensed beyond the general dual-license statement. It also does not provide a dependency inventory in the repository description. A production adoption review would need to inspect those files and the exact version being distributed.

The cryptographic context adds a separate review burden. Apache-2.0 governs licensing, but it does not establish that a circuit compiler is correct, that generated proofs are secure, or that the implementation has been audited. The README explicitly denies that status.

## Where Noir is constrained or the wrong choice

The clearest failure mode is misuse in production. The README directly says the implementation has not been reviewed or audited and expects bugs. A proof compiler can affect whether constraints, witness generation, artifacts, or integration behavior match a system's assumptions. The repository does not document a stable subset suitable for sensitive deployments, so there is no stated basis for treating this implementation as production-safe.

Noir is also the wrong tool when a team requires a generic application language, a proving backend that does not accept ACIR, or a deployment process already locked to another circuit representation. Its stated design target is an ACIR-compatible proving system. The README does not promise that ACIR itself guarantees portability across every prover, verifier, curve, or security configuration.

Documentation is another constraint. The README delegates installation to external documentation and provides no complete proof command, witness format description, backend setup, rollback policy, or production checklist. That is manageable for an evaluation, but insufficient for building an adoption decision from the README alone. The examples directory shows categories of intended use, yet the repository does not document which examples are current for `v1.0.0-rc.5`.

## Direct compiler stacks versus ACIR-centered language tooling

A real alternative is to use the native interface of a specific SNARK proving system and write circuits directly in its supported constraint format. The practical difference is architectural. Noir separates application-level computation from an ACIR boundary, allowing the language design and compiler tooling to target compatible proving systems. A direct backend stack instead couples circuit construction to one prover's syntax, APIs, and constraints.

That alternative may be better when an application already depends on one proving system and needs direct access to backend-specific features. It avoids relying on an additional DSL compiler before reaching the prover. The tradeoff is tighter coupling and less reuse if the project later wants another ACIR-compatible system.

Noir can be preferable when developers want language structure, compiler diagnostics, formatting, debugging, ABI tooling, and examples while retaining ACIR as the handoff. However, the repository does not quantify compilation overhead, generated-circuit size, proving performance, or compatibility across backends. No performance claim should be inferred from the number of compiler and tooling crates.

## Conclusion

Noir is appropriate for prototypes, experiments, contributor work, and teams evaluating an ACIR-centered proof toolchain. It is a poor fit for production systems that require audited code, stable release guarantees, or documented rollback procedures. Before adoption, verify the official installation route for the intended proving backend, compile and inspect a representative Noir program, and review `CHANGELOG.md`, `SECURITY.md`, and the target release notes for compatibility and upgrade requirements.

## FAQ

### What is Noir used for?

Noir is a domain-specific language for SNARK proving systems. It is designed to target ACIR-compatible proving systems.

### Is Noir suitable for production zero knowledge systems?

No. The README says the implementation is in early development, has not been reviewed or audited, and is not suitable for production use.

### How do I install Noir?

The README directs users to the official documentation at `https://noir-lang.org/docs/getting_started/quick_start/`. It does not provide a standalone installation command.

### What Rust version does the Noir workspace require?

The minimum supported `rustc` version is 1.89.0.

### What license does Noir use?

Noir is distributed under a dual `MIT OR Apache-2.0` license unless otherwise stated.

## Sources

- [License: Apache-2.0](https://github.com/noir-lang/noir/blob/master/LICENSE)
- [noir-lang/noir on GitHub](https://github.com/noir-lang/noir)
- [Project website](https://noir-lang.org)
- [README](https://github.com/noir-lang/noir/blob/master/README.md)
- [Releases](https://github.com/noir-lang/noir/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/noir-lang-noir