Skip to main content

Repository Structure

The file structure of the Mina repositorythe roles various files play:

  • dockerfiles/ Contains Docker-related scripts

  • docs/ Documentation for the code and processes for contributing are here. The documentation website with the walkthrough docs lives in frontend/website/docs.

  • frontend/ All code related to Mina frontend UIs and products

    • wallet/ Source code for the Mina wallet

    • website/ Code for https://minaprotocol.com

      • posts/ Markdown docs for blog posts

      • src/ Source code for the website

      • static/ Static files like images, etc.

  • rfcs/ This directory contains all accepted RFCs (or "requests for comments") made according to the RFC process.

  • scripts/

  • src/ All protocol source code, both application and library code, is in this directory.

    • *.opam These files are needed for our dune build system. There must be one for each library in lib. When you create a library lib/foo_lib with a dune file giving the library's name as foo_lib, you must create a foo_lib.opam file.

    • config/ Build time config - these .mlh files define compile time constants and their values.

    • app/ Applications live here.

      • cli/ This is the mina client/daemon. It is what you use to run a staker, a snarker, or a simple client for sending and receiving transactions.

      • website/ Soon to be deprecated directory for the website - most of the code has migrated over to frontend/website/

      • reformat/ This program runs ocamlformat on most of the files in the source tree, with a few exceptions.

      • logproc/ This utility reads from stdin and can filter and pretty print the log messages emitted by the mina daemon.

      • libp2p_helper/ This program uses go-libp2p to implement the peer-to-peer plumbing that Mina daemons need.

    • external/ Local copies of external libraries which we've had to make some tweaks to.

    • lib/ Libraries powering mina. The libraries here basically fall into two categories.

      1. General purpose data-types and functionality. This includes snarky, fold_lib, vrf_lib, sgn, and others.
      2. Application specific functionality, structured as a library. This includes syncable_ledger, staged_ledger, transaction_snark, and others.