# Tamarin prover: mechanical security protocol verification with a library of models

> The Tamarin prover is a Haskell tool for verifying security protocols by mechanically analysing their symbolic traces, and its most reusable asset is not the binary but the example model library, which ships the case studies from a decade of published papers. Its version numbering encodes release stability in the minor component, and the develop branch is where the work happens.

**tamarin-prover/tamarin-prover** — Main source code repository of the Tamarin prover for security protocol verification.

- Repository: https://github.com/tamarin-prover/tamarin-prover
- Website: https://tamarin-prover.com/
- Stars: 553 · Forks: 169
- Language: Haskell
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/tamarin-prover-tamarin-prover

## The repository is organised for contributors, not for users

The README opens by saying it describes the organization of the repository of the Tamarin prover for security protocol verification and that its intended audience are interested users and future developers. It then points away from itself for what a user actually needs, since installation and usage instructions are chapter 2 of the manual, and the manual is published as PDF or HTML at tamarin-prover.github.io. That framing is worth noting before anything else, because it tells you what the repository is for. It is the upstream source of a prover, not a product page. The tree at the top level reflects the concerns of a research project rather than a library, with lib/ and src/ for the Haskell code, frontend/ for the web interface, manual/ for the book, doc/ for other documentation, data/ for the data files the tool serves, examples/ for the model library, misc/ for the experimental improved graph output, etc/ for editor support, tree-sitter/ for the external grammar, tests/ and case-studies-regression/ for the test harnesses, and images/ and the various regression scripts. There is a stack.yaml and a tamarin-prover.cabal, a version-change.sh, a ghci-dev.sh for a development REPL, and a testbed.maude. The default branch is develop and the repository is not archived, with the last push on 2026-10-19.

## The version scheme tells you what you installed

The versioning policy is the most useful paragraph in the README for anyone choosing a version, and it is unusual. Version numbers have four components. The first is the major version, which indicates complete rewrites of the codebase. The second is the minor version, and here is the convention, odd minor version numbers denote development releases intended for early adopters, while even minor version numbers denote public releases, which are also published. The third component indicates bugfix releases, and the fourth indicates documentation and meta-data changes. So the parity of the minor number tells you whether a build is a public release or an early adopter build, which saves you from having to read a changelog to find out. The compatibility guarantee is stated in terms of that scheme, that the external interface of a version of the Tamarin prover is backwards compatible with the external interface of all versions that agree on the major and minor version number. That is a strong promise, and it is what lets a paper's appendix or a protocol model keep working across patch releases. The release list shows 1.12 from 2026-03-07, 1.10 from 2024-10-30 and 1.8 from 2023-08-30, so the public line moves at an even minor number and the gaps are years rather than months.

## Building it means stack, npm and a web frontend

The Makefile is where the build shape becomes clear. The frontend target changes into the frontend directory, runs npm install and npm run build, and then copies the built graph scripts into the data directory, including the interactive dot graph, the static graph and the dynamic graph JavaScript files along with the stylesheet. The build target depends on the frontend and then runs stack setup followed by stack build, and the install target does the same with stack install so the binary lands in the local bin directory. The Makefile names the expected binaries, the prover and a second tool called sapic, both expected in the local bin path. There is a FAST setting that switches the test subdirectory to a faster set of tests, which tells you the test suite is large enough to need a quick mode. The versioned install target is the one to note, because it installs the binary under a name derived from the git describe output, with the sha256 of the binary appended when the working tree is dirty or broken, so that several versions can sit side by side without interfering. The comment explains that the naming stays unique even for builds with uncommitted changes, and the script is version-change.sh.

## The example model library is the part worth stealing

All example protocol models are found in the examples directory, and the ones considered stable are part of every installation of the prover, with the list of installed protocols given in the cabal file. That single fact makes the library the most reusable asset in the repository, because a model that ships with every installation is one that has been kept working. The subdirectories are organised by provenance, which tells you what has been formalised. There is accountability for the case studies from the paper on verifying accountability for unbounded sets of participants, csf12 for the AKE case studies from the CSF'12 paper, classic for classic security protocols like the ones from SPORE, loops for experiments testing loop invariants and protocols with non-monotonic state, related_work for examples from related work on protocols with loops or non-monotonic state, experiments for everything else, ake for more AKE examples including identity based and tripartite group key exchange based on bilinear pairing, features for small models that demonstrate a given feature, ccs15 for the observational equivalence case studies from the CCS'15 paper, and csf-18 for the XOR case studies from the CSF'18 paper. The tree goes on past those, with directories for the ASI, CCS, Cav, FM, Eurosp and other conference case studies, each named for the year and the venue. The conventions are explicit too, with descriptive file names, findings documented as comments in the model, and a standard header giving the protocol, the modelers, the date, the status and a description.

## Editor support and the experimental graph output

Two small features are worth knowing about because they affect the working experience. The project contains support for spthy syntax highlighting and support in the etc directory, covering Sublime Text, VIM and Notepad++, so the protocol modelling language has editor support rather than being a plain text format you edit in a bare editor. External tools may use the Tree-sitter grammar in the tree-sitter directory, which is the more important of the two for anyone who wants to build tooling on top of the language, since a grammar is what makes editor support and analysis possible without writing a parser. Separately, there is an experimental improved graph output which may be helpful for very large graphs that can be created for complicated protocols, and the README points to a separate document for enabling it. The word experimental matters, because the graph output is how a proof result reaches a human, and for a protocol with many rules the picture is where a reviewer actually looks, so a better layout there is not a cosmetic nicety. The instruction to read the documentation in the misc directory before enabling it also suggests the default path is the older one and the new one is opt-in.

## Where Tamarin is the wrong choice

The first limit is that the analysis is symbolic. The tool reasons about protocol traces as terms, so a property that depends on the concrete behaviour of a hash function or on the timing of a nonce is not something it can decide, and a model that abstracts away a bug the implementation introduces is a model that passes and a system that fails. That is the standard caveat of symbolic verification and it is not specific to Tamarin, but it is the first thing to establish before you invest in a modelling effort. The second is the modelling cost itself, and it is where most attempts end. A real protocol has to be reduced to the message flow, the state and the adversary assumptions, and the reduction is a piece of intellectual work that has to be got right, and a model that is wrong in the abstraction gives a confident answer about the wrong protocol. The third is the scope of the results. The tool proves properties about the model, and the translation from the paper's informal argument to the model's predicates is where a reader has to do work, so the output is not a verdict on a protocol but a starting point for a proof. The fourth is the toolchain, since the build needs stack and a Node build for the frontend, and the manual is a book rather than a page, and the fourth is the version spread, where the odd and even minor number scheme means a reader can easily end up with a development build without realising it. And the fifth is scale, since a protocol with many participants and complex state can produce the very large graphs the improved output exists to help with, and the analysis can take a long time, which means the loop of modify, model and check is slower than working with a linter.

## Conclusion

Adopt the Tamarin prover if you are designing or auditing a security protocol and want a mechanised argument about its traces rather than an informal one, and you are prepared to model the protocol symbolically. Skip it if your protocol depends on concrete cryptographic implementation details, since the tool reasons symbolically. Verify first which version you install, since odd minor numbers are development releases for early adopters while even ones are public, that the example model you want is one of the stable models installed with every distribution, and that the manual version you read matches the prover version you run.

## FAQ

### What is the Tamarin prover used for?

It is a Haskell tool for security protocol verification, mechanically analysing a protocol model to reason about its traces. The repository is the main source code, written in Haskell, and the README points users to chapter 2 of the manual for installation and usage rather than duplicating it.

### How does the Tamarin version numbering scheme work?

Versions have four components. The first is the major version, indicating complete rewrites. The second is the minor version, where odd numbers denote development releases for early adopters and even numbers denote public releases. The third indicates bugfix releases and the fourth documentation and meta-data changes, and the external interface is backwards compatible across versions sharing a major and minor number.

### What example protocol models ship with Tamarin?

The models considered stable are part of every installation, listed in tamarin-prover.cabal, and the directories are organised by provenance, with accountability case studies, the CSF'12 AKE studies, classic protocols, loop and non-monotonic state experiments, observational equivalence case studies from CCS'15, XOR case studies from CSF'18, and a features directory of small models, each file carrying a header with protocol, modelers, date, status and description.

## Sources

- [License: GPL-3.0](https://github.com/tamarin-prover/tamarin-prover/blob/develop/LICENSE)
- [Project website](https://tamarin-prover.com/)
- [README](https://github.com/tamarin-prover/tamarin-prover/blob/develop/README.md)
- [Releases](https://github.com/tamarin-prover/tamarin-prover/releases)
- [tamarin-prover/tamarin-prover on GitHub](https://github.com/tamarin-prover/tamarin-prover)

---

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