# Quint: a TypeScript-friendly language for executable specifications

> Quint is an executable specification language for distributed systems, combining TLA foundations with type checking, effects, simulation, REPL access, LSP tooling, and Apalache model checking. It fits engineers who need to specify protocol behavior before or alongside implementation.

**quint-co/quint** — An executable specification language  with delightful tooling based on the temporal logic of actions (TLA)

- Repository: https://github.com/quint-co/quint
- Website: https://quint.sh
- Stars: 1,868 · Forks: 153
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/quint-co-quint

## Why Quint targets protocol specifications

Quint addresses a specific gap between ordinary application code and formal system descriptions. It is intended for engineers who need to express the behavior of distributed systems such as blockchain protocols, distributed databases, and peer-to-peer protocols before those behaviors are encoded in an implementation. The repository describes Quint as inspired by TLA+, while presenting a syntax intended to be easier for engineers to read and write. Its syntax borrows lexical ideas from C-like languages, uses functional-language constructs at the syntax level, and adds nondeterminism and temporal formulas to the usual programming model. Those additions matter when a specification must represent an environment that can choose messages, inject faults, change timing, or select among permitted actions. A specification can therefore describe what participants may do without pretending that execution follows one deterministic program path. This makes Quint relevant to protocol design and formal verification, but it also means that adopting it requires a modeling mindset. The author must decide which details belong in the model and which are intentionally abstracted.

## The state and action model behind the bank example

The README's bank specification makes Quint's data flow concrete. A variable named `balances` has the type `str -> int`, representing account balances. `ADDRESSES` is a pure set containing `"alice"`, `"bob"`, and `"charlie"`. The `init` action assigns each address a zero balance. The `deposit` action uses `balances.setBy(account, curr => curr + amount)`, while `withdraw` subtracts the requested amount. The `step` action selects an address and an amount nondeterministically, then chooses either operation through an `any` block. This separation between state updates and action selection gives the simulator or verifier a finite transition model rather than a single hard-coded sequence. The invariant `no_negatives` states that every address in `ADDRESSES` has a balance greater than or equal to zero. According to the README example, running the model with that invariant finds a violation in which `"alice"` reaches balance `-79`. The example is useful because it shows how a readable specification can still encode an important missing check. It does not claim that the bank model is complete, and the README points to the Getting Started guide for fixing and formally verifying the result.

## From local exploration to symbolic verification

Quint provides several ways to work with a model. The repository lists a REPL for interactive exploration, a simulator for tests, trace generation, and system exploration, and a symbolic model checker through Apalache. These tools address different questions. The simulator can produce an execution, expose a reachable state, or test an invariant against explored behavior. A REPL is useful while constructing expressions and inspecting values. Apalache is the symbolic verification route, allowing a model to be checked with a model checker rather than relying only on selected executions. The README's violation output includes a reproducibility seed, `--verbosity=3` for showing executions, and an error indicating that the invariant was violated. This distinction matters for adoption. A simulator finding a counterexample proves that the displayed search reached a bad state, but the README example does not establish that every reachable state has been explored. Formal verification has a different burden because it requires suitable finite-state assumptions or model-checking conditions that the README does not describe. Quint acts as the specification language and integration point, while Apalache performs the symbolic checking.

## Installing Quint and running the first invariant check

The README identifies npm as the quickest installation method and says to install Node/npm first. The documented global installation command is:

```bash
npm i @informalsystems/quint -g
```

After installation, the documented example uses a file named `bank.qnt` and invokes the Quint CLI with an invariant name:

```bash
quint run bank.qnt --invariant=no_negatives
```

The expected result shown in the README is an execution with an initial zero-balance state followed by a state where `"alice"` has balance `-79`, followed by an invariant violation report. The same output documents a reproducibility seed and suggests `--verbosity=3` to show executions.

The repository Makefile also provides a source-build route for the Quint executable and VSCode plugin. It uses `npm install`, `npm run compile`, and `npm link` inside the `quint` directory, followed by compilation of the `vscode/quint-vscode` extension. The README points to the full Getting Started guide for alternative installation methods and advanced setup. Those documented steps are enough for a first command-line use, but the README does not provide the exact contents of `bank.qnt` as an installation prerequisite, so a reader must create or obtain that specification before reproducing the example.

## Static checks and editor feedback around Quint code

Quint's tooling includes an expressive type system, a novel effect system, and IDE support through LSP. The type system is intended to keep the domain model coherent. The effect system is intended to check that state updates are coherent, which is especially relevant in a language where actions explicitly relate current and next state. LSP support gives developers feedback while writing specifications instead of requiring every issue to be discovered during a later run. The repository also contains a Visual Studio Code extension, referenced by the README badge and by the `vscode/` directory, and the Makefile describes compiling that extension and linking it into a VSCode extensions directory. This combination changes the adoption decision for teams. Quint is not only a command-line model checker with a file format. It is designed to support an editing workflow in which specifications can be checked, explored, and connected to executable state-transition models. However, the README does not document editor version requirements, the complete feature set of the extension, or whether all checks execute in the editor exactly as they do in the CLI. Those details should be checked before making editor support a procurement requirement.

## Maintenance, licensing, and the cost of adopting Quint

The repository is not archived, and its last push was on 2026-10-13. Recent releases include v0.33.0 on 2026-09-28 and evaluator/v0.7.0 on 2026-09-28, with v0.32.0 dated 2026-03-31. The release history and recent push indicate current project activity, but the repository does not define a compatibility policy or a long-term support window. Upgrade planning should therefore account for changes in the Quint CLI, evaluator, Apalache integration, and editor extension rather than assuming that the npm package can be upgraded without reviewing the changelog. The repository license is Apache-2.0. That identifier indicates the project's published license, but it does not answer questions about a user's particular distribution, dependency, or compliance situation. The repository layout also includes documentation, examples, tutorials, evaluator code, and plugins, which suggests that adoption may involve several artifacts rather than one standalone binary. Teams should account for learning TLA-derived modeling concepts, maintaining specifications alongside implementation changes, and running verification through the Apalache integration.

## Conclusion

Adopt Quint when a team needs executable specifications for protocol state, nondeterminism, faults, or invariants, and when engineers need static feedback alongside simulation. Do not treat it as a production implementation language or assume that one successful run proves a model. Verify first that your modeling abstractions, nondeterministic choices, invariants, and Apalache integration match the system you actually intend to reason about.

## FAQ

### How do I install Quint?

The README says to install Node/npm, then run `npm i @informalsystems/quint -g`. It also links to the Getting Started guide for alternative installation methods and advanced setup.

### What is Quint used for?

Quint is an executable specification language suited to distributed systems such as blockchain protocols, distributed databases, and peer-to-peer protocols. It supports nondeterminism, temporal formulas, simulation, and formal verification.

### How do I check an invariant in Quint?

The README example runs `quint run bank.qnt --invariant=no_negatives`. The example reports a violation and provides a seed for reproducing the search.

### Does Quint provide a REPL and simulator?

The repository's feature list includes a REPL for interactive exploration and a simulator for tests, trace generation, and exploring a system.

### Which model checker does Quint use?

The README states that Quint verifies specifications through a symbolic model checker using Apalache. The repository also lists Apalache as a related project.

## Sources

- [License: Apache-2.0](https://github.com/quint-co/quint/blob/main/LICENSE)
- [Project website](https://quint.sh)
- [quint-co/quint on GitHub](https://github.com/quint-co/quint)
- [README](https://github.com/quint-co/quint/blob/main/README.md)
- [Releases](https://github.com/quint-co/quint/releases)

---

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