Mina Protocol: a constant-size blockchain built in OCaml using recursive zk-SNARKs

The chain that stays constant by replacing full history with a single proof

Conventional blockchains grow with every block. Each participant who wants to validate the chain from scratch must download and verify all historical transactions. Mina encodes its entire transaction history as a single, recursively composed zk-SNARK proof so the chain size stays constant regardless of how many transactions have occurred. The project description calls it "the first cryptocurrency with a lightweight, constant-sized blockchain." The technical design is documented in the Mina whitepaper at https://eprint.iacr.org/2020/352.pdf.

The repository at MinaProtocol/mina holds the OCaml implementation, wallet code and the Mina Protocol website. Released under Apache-2.0 (commits before 2018-10-03 lack a LICENSE file but carry the same terms), the repository's most recent mainnet build is 4.0.0-mainnet-mesa from 2026-09-03 and the last push was on 2026-09-28.

Three branches serve different states of mainnet compatibility

Three mainline branches exist in this repository, each with distinct semantics, and this is the detail that determines which version you work with when you clone.

Compatible is the default branch. It holds code that does not need a hardfork in order to apply to mainnet. Master contains the current mainnet code. Develop carries code that may not be compatible with current mainnet and may require a major upgrade (a hardfork) to deploy. Cloning without specifying a branch gives you compatible, not master. Someone who wants to examine what mainnet currently runs must check out master explicitly.

This structure creates a clear decision point for contributors. Changes targeting compatible can reach mainnet without a coordinated protocol upgrade. Changes targeting develop accept that they may require one. Build status badges for all three branches appear in the README header, pointing to Buildkite CI at buildkite.com/o-1-labs-2/mina-mainline-branches-nightlies. The README-branching.md file at the repository root documents the branching model in detail, and README-ci-failures.md covers how to handle CI failures. Both files exist because the branching model is complex enough to need written guides.

Direct node APIs are evolving; the Rosetta interface is the stable path for applications

The README is direct about API stability: "Mina is still under active development and APIs are evolving. If you build on the APIs, be aware that breaking changes can occur."

For application developers who need predictability, the documented alternative is the Rosetta API. The README describes it as offering "a more stable and useful interface for retrieving the blockchain's state." Rosetta runs as a separate process and requires an archive node connected to a Mina node. Its source code is at src/app/rosetta, and the archive code is at src/app/archive.

The README adds a cautionary note about those paths: "Be sure to follow updates in the project if these resources are relocated." That advisory is worth taking at face value. If you reference those paths in build scripts or tooling, check them after major protocol upgrades, since the project's own documentation does not guarantee the paths stay fixed.

For developers who prefer the native GraphQL interface directly, the current schema is in graphql_schema.json at the repository root. Given the evolving warning, treat it as a point-in-time snapshot rather than a stable contract.

Archive node database defaults in the Makefile are local-only values

The archive node stores historical blockchain state in a PostgreSQL database. The Makefile defines five default connection values: user mina, password minaminamina, database archive, host localhost, and port 5432. These defaults are designed for local development convenience, not for any network-facing deployment.

All five values use the ?= operator in the Makefile, meaning any environment variable with the same name overrides the default. Anyone standing up an archive node outside a local machine should override all five before the node connects to anything. This default configuration is not mentioned in the main README; it appears only in the Makefile. Someone reading only the README would be unaware of the database layer entirely until they tried to run the archive or Rosetta components.

Rosetta depends on the archive node being connected to a live Mina node, so the Rosetta API setup involves three components: a Mina node, an archive node with a PostgreSQL instance, and the Rosetta process itself. The separation into multiple processes is a deliberate design choice, but it adds operational complexity compared to a single-process deployment.

Building from source pins OCaml to 4.14.2, with opam and Nix as the two supported paths

The Makefile pins OCaml to version 4.14.2. Two build environments are documented through the repository structure. The opam path uses a local switch at _opam/, and the Makefile checks for the OPAMSWITCH and IN_NIX_SHELL environment variables before setting opam paths, which shows the build is primarily tested in CI environments. The repository also provides a Nix flake through flake.nix, shell.nix and default.nix for a fully reproducible environment.

For the developer setup, the README delegates to README-dev.md at the repository root. That file is not reproduced in the main README, so setting up a development environment requires reading it separately. OCaml compilation for a codebase of this size is not a short process, and the Makefile structure reveals a project designed with CI tooling in mind.

For anyone who wants to explore the protocol locally without a full source build, the repository references MiniMina, described as a "CLI tool for spinning up local Mina networks," with documentation at src/app/minimina/README.md. A demo node document is also linked at docs/demo.md. Neither document is reproduced in the top-level README.

Node operation and zkApp development go through external documentation

No install commands for running a Mina node appear in the repository README. Node operation is covered at docs.minaprotocol.com, which documents installing a third-party wallet, sending a payment via the CLI, and running a block producer node. The README links to these pages rather than reproducing any steps inline. This split between repository documentation and external documentation is intentional given the scope, but it means evaluating the project requires navigating both.

The zkApp development tooling for writing applications on Mina is also not part of this repository. The README points to docs.minaprotocol.com for the zkApp developer documentation. Someone who wants to build an application on Mina but not contribute to the protocol itself will find that the repository is not the starting point; the documentation site is.

Mina is a live production network, not a general-purpose ZK library

Mina runs a live mainnet with real economic activity and a real validator set. Working with this codebase means accepting the constraints of a consensus protocol: hard forks require coordination across the network, API changes affect running applications, and the branch model exists precisely because breaking changes need careful staging.

Teams looking for a ZK proof system to add to an existing application without blockchain dependencies are looking at the wrong repository. Mina bundles its proof system with a full cryptocurrency protocol, and the two are not separable from this codebase.

For comparison, developers from the Ethereum ecosystem who want ZK capabilities typically consider zkEVM chains that maintain EVM compatibility. Mina has its own zkApp execution model, its own account structure and its own consensus rules. Porting existing Ethereum contracts is not the path; the zkApp model requires learning a different programming model from the start, and the documentation for that is outside this repository at docs.minaprotocol.com.

Editorial conclusion

Mina suits teams who want to build on a live ZK-native blockchain with a constant-size chain and are prepared to work within its OCaml codebase. It is the wrong tool for teams that need API stability outside of the Rosetta interface, for developers expecting a quick local setup, or for those wanting a private permissioned chain. Before writing a zkApp or running a node, read README-dev.md, decide which branch to target: compatible for near-mainnet code, master for current mainnet, develop for the latest but possibly hardfork-requiring changes, and confirm that the Rosetta archive node has a PostgreSQL instance on port 5432.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. MinaProtocol/mina on GitHub
3. Project website
4. README
5. Releases