# Rocq Prover: a proof assistant for machine-checked mathematics and verified code

> Rocq is an interactive theorem prover built in OCaml and distributed under LGPL-2.1. It is aimed at mathematicians and engineers who need definitions, algorithms and proofs checked by a machine rather than by a reader.

**rocq-prover/rocq** — The Rocq Prover is an interactive theorem prover, or proof assistant. It provides a formal language to write mathematical definitions, executable algorithms and theorems together with an environment for semi-interactive development of machine-checked proofs.

- Repository: https://github.com/rocq-prover/rocq
- Website: https://rocq-prover.org
- Stars: 5,594 · Forks: 764
- Language: OCaml
- License: LGPL-2.1
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/rocq-prover-rocq

## The gap Rocq fills: proofs that a machine checks

A mathematical proof written on paper is checked by human readers. Rocq is built for the cases where that is not enough. The README describes it as an interactive theorem prover, or proof assistant, that provides a formal language for writing mathematical definitions, executable algorithms and theorems together with an environment for semi-interactive development of machine-checked proofs. The claim is not that Rocq finds proofs for you. The claim is that once a proof is accepted, the kernel has checked it against the definitions you wrote.

The audience follows from that. Mathematicians use it to formalise results. Engineers use it when a specification matters more than a test suite, for example when the thing being specified is a compiler pass, a protocol, or an algorithm whose correctness argument is the deliverable. The repository topics list dependent-types alongside proof-assistant and theorem-proving, which points at the underlying style: types can mention values, so a type can express a property and a term of that type is the evidence.

Rocq is not a tool you adopt casually for a weekend. The formal language is the product, and learning to write in it is the cost of entry.

## How Rocq is put together: kernel, pretyping, tactics, STM

The repository layout is the clearest description of the architecture. The top-level directories include kernel/, pretyping/, tactics/, proofs/, interp/, library/, engine/, parsing/, printing/, stm/ and theories/. A proof assistant of this kind separates a small trusted core from a large body of machinery that produces terms for that core.

kernel/ is where the checking happens. Terms that survive the kernel are the ones the system stands behind. pretyping/ and interp/ handle elaboration, turning what you wrote into a term the kernel can consume. tactics/ contains the proof steps you invoke interactively. proofs/ holds the proof state and its manipulation. stm/ is the state transition machine, the layer that lets an editor step through a file and keep track of where the proof stands. theories/ carries the standard library, and doc/ builds the reference manual and the documentation of that library.

The build itself is Dune-based. The Makefile opens with a comment calling itself a Dune Makefile, and it notes that parallel build is not allowed there: it is a placeholder for dune commands. Targets are grouped in the file, including help, install, states, world, rocqide, watch, check, refman-html, refman-pdf, corelib-html, apidoc, test-suite, fmt, clean, dunestrap and release. That grouping tells you the project is maintained by its own developers with the same commands an outsider would run.

The opam files at the root split the system into pieces: rocq-core.opam, rocq-runtime.opam, rocqide.opam, rocqide-server.opam, rocq-devtools.opam and rocq-test-suite.opam, alongside coq-core.opam. The presence of both naming families is a hint about the project's history rather than its current identity.

## Installing Rocq and checking a first proof

The README does not inline install commands. It points to https://rocq-prover.org/install for packaged installs and to INSTALL.md for building and installing from sources. It also carries badges for repology, which tracks packaged versions, and for Docker Hub, where the image is rocq/rocq-prover. If you want the least setup, the container route is the one the README advertises.

For a source build, the repository ships a configure script and a Dune project, and the Makefile exposes an install target. A typical sequence looks like this:

```bash
./configure
dune build
```

The Makefile comment states that parallel build is not permitted at that level, which is why the file marks itself .NOTPARALLEL and delegates the real work to dune.

Once a binary is on your PATH, the README's bug-report section names two version commands: coqtop -v and rocq -v. Running one of them is the quickest way to confirm which version you actually have, and it is the same command the maintainers ask for in a report.

A first session is interactive. You state a goal and discharge it with tactics, and the STM keeps the state so an editor can move forward and backward through the file. The README does not walk through a sample proof, so treat the reference manual at rocq-prover.org/docs as the place to learn the concrete syntax rather than guessing at it.

If you build from source, the documentation sources live in doc/ and doc/README.md explains how to build them. The master-branch reference manual, standard library documentation and ML API documentation are continuously deployed.

## What Rocq does not promise: upgrades, compatibility and scope

The README is unusually direct about one thing. It links the Recent changes chapter of the reference manual and says that it explains the differences and incompatibilities of each new version, and that if you upgrade Rocq you should read it carefully because it contains important advice on how to approach problems you may encounter. That is a maintenance warning written by the maintainers themselves. Proof scripts depend on tactic behaviour and on library names, so a release that renames or changes a tactic can break developments that were perfectly correct before.

The version history backs this up. V9.2.0 shipped on 2026-03-27, V9.3+rc1 on 2026-07-22 and V9.3.0 on 2026-09-19, with the last push to master on 2026-09-22. Releases arrive on a cadence, and each one may carry incompatibilities. If you maintain a large development, pinning a version and reading the changes chapter before moving is the realistic workflow.

Scope is the other limit. Rocq is a proof assistant, not a general-purpose language you would reach for to build a service. The executable algorithms it supports exist so that they can be reasoned about, not so that they can replace your application code. And the README does not document rollback, so if an upgrade breaks a development, the recovery path is your own version control rather than a documented procedure.

## Rocq compared with an SMT-based checker

The obvious alternative for many verification tasks is an SMT solver used as a backend to a verification tool. The difference in approach is where the trust sits. An SMT-based tool typically encodes a problem into a logic the solver handles and asks whether it is satisfiable; you get an answer, and the answer depends on trusting the solver's implementation and on the encoding being faithful.

Rocq inverts that. You write the definitions and the proof yourself in a formal language, and the kernel checks the resulting term. Nothing is trusted except the kernel, and the work of finding the argument is yours. That is why Rocq developments read like mathematics rather than like a configuration file, and why they take longer to produce.

The trade is real in both directions. SMT-backed tools are faster to apply to bounded problems and usually need less expertise. Rocq handles statements that need induction, dependent types and reusable theory, which is exactly where encoding into a decidable fragment stops working. If your problem is a finite-state check, Rocq is the wrong tool. If your problem is a theorem, it is the right one.

## Licence and the cost of staying current

Rocq is distributed under LGPL-2.1. The Makefile header states that the file is distributed under the terms of the GNU Lesser General Public License Version 2.1 and points at the LICENSE file for the text. The practical consequence for most users is that using Rocq to check your own developments does not put your developments under the LGPL, while modifying and redistributing Rocq itself brings the licence's conditions into play. That is a description of the licence identifier, not legal advice; if you plan to redistribute a modified prover, read LICENSE and take your own counsel.

The upgrade cost is the ongoing one. The project ships releases on a regular cadence, the reference manual documents the incompatibilities of each, and the contributor guide and release plan live in CONTRIBUTING.md and on the wiki. Budget for reading the changes chapter at each bump, and for pinning a version in continuous integration so that a new release does not silently change what your scripts mean. The repository's own CI is split across GitLab and GitHub, which is a reminder that a development's toolchain is as versioned as its source.

## Conclusion

Adopt Rocq if you need definitions, executable algorithms and theorems to live in one formal language with machine-checked proofs, and if you can accept the upgrade work that the reference manual's changes chapter describes. Do not adopt it as a general-purpose programming language or as a quick scripting tool. Before committing, read the Recent changes chapter for the version you plan to pin, and confirm the install route at https://rocq-prover.org/install.

## FAQ

### What is the Rocq Prover?

It is an interactive theorem prover, or proof assistant, that provides a formal language for writing mathematical definitions, executable algorithms and theorems, together with an environment for semi-interactive development of machine-checked proofs.

### Is Coq renamed to Rocq?

The repository is named rocq-prover/rocq and the README uses Rocq throughout, but the root still contains coq-core.opam and the Makefile header refers to the Rocq Prover while the licence points at the same LICENSE file. The README does not state the rename explicitly, so treat the coexistence of both names in the repository as the observable fact.

### How do I install the Rocq Prover?

The README points to https://rocq-prover.org/install for packaged installs and to INSTALL.md for building from sources. It also carries a Docker Hub badge for the rocq/rocq-prover image.

### Which command tells me the Rocq version I am running?

The README's bug-report guidance names coqtop -v and rocq -v, and asks that a report include the version together with the OCaml version and the configuration used.

### Does upgrading Rocq break existing proofs?

The README says the Recent changes chapter of the reference manual explains the differences and incompatibilities of each new version and advises reading it carefully when upgrading, because it contains advice on problems you may encounter. It does not document a rollback procedure.

## Sources

- [License: LGPL-2.1](https://github.com/rocq-prover/rocq/blob/master/LICENSE)
- [Project website](https://rocq-prover.org)
- [README](https://github.com/rocq-prover/rocq/blob/master/README.md)
- [Releases](https://github.com/rocq-prover/rocq/releases)
- [rocq-prover/rocq on GitHub](https://github.com/rocq-prover/rocq)

---

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