# Anoma: the default branch is base, a merge is not a release, and enacl needs a foreign branch

> Anoma is the Elixir reference implementation of the Anoma protocol, built against externally published specifications and merged into a branch called base on a bi-weekly cycle. Its README is unusually candid about three things: two of its four documentation links are placeholders, two dependency builds are documented as broken with workarounds that involve checking out someone else's git branch, and a pull request the maintainer calls merged will stay open until the next scheduled release.

**anoma/anoma** — Reference implementation of Anoma

- Repository: https://github.com/anoma/anoma
- Website: https://anoma.net
- Stars: 33,588 · Forks: 4,113
- Language: Elixir
- License: MIT
- Published: 2026-08-17 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/anoma-anoma

## The default branch is base, and a merge is not a release

The git section at the end of the README answers a question that will otherwise confuse you. New code should be based on base, and no attempt should be made to keep it in sync with main; when a topic is ready you submit a pull request and a maintainer handles any merge conflicts. The codebase follows a git style similar to git itself or the Linux kernel's.

Then the part that saves an afternoon. There are bi-weekly releases, so you should not be afraid if a maintainer says your pull request is merged but it is still open, because that just means it is merged into next or main and will be included in the next scheduled release.

The repository's default branch is base, and work is merged into it on a schedule described as bi-weekly, once every two weeks. So there are three states a change can be in: open, merged into a staging branch, and released. The last of those is the only one you can pin to, and the most recent release tag is v0.35.1 from 2026-02-22 while the last push to the repository was 2026-06-15. The branch is ahead of the last release.

## Two of the four documentation links are placeholders

The docs section lists four things. There is a contributors documentation site, there is the specification, and then developer docs and user docs, both of which are labelled Coming Soon with a trademark symbol attached to the word.

That is worth reading as a map of the project's shape. This repository is an implementation, not a product, so the specification is the normative document and the contributors documentation is the practical one. A developer who wants to know what the protocol does will find it in the specification; a developer who wants to know how this codebase is laid out will find it in the contributor guide. What does not exist is the layer in between, the documentation for someone using the node once it is running.

The consequences are practical. If you are integrating against Anoma, the specification is the contract and this repository is one implementation of it, which means another implementation may behave differently in ways the documentation here would tell you about. If you are evaluating the project as a place to contribute, the contributors documentation is the one to read first.

## protoc-gen-elixir has to be 0.11.0, and the README says so twice

The build dependencies are Elixir, Rust, Protobuf, and the Elixir plugin for protobufs. The plugin is installed with a command that pins the version:

```shell
mix escript.install hex protobuf 0.11.0
```

The README then says, in so many words, that the version is important, tells you to ensure the plugin is available in your path, and gives two ways to do that: reshim it if you are using asdf, or add the escript directory to your path in your shell profile. It finishes with a verification step and the expected output, so you can tell whether the install worked before you try to compile anything.

That is a small thing to be careful about and a common way to lose an hour, because a protobuf plugin at the wrong version fails in a way that looks like a problem with the project rather than with your machine. The verification step exists so you can rule that out in five seconds, and it is worth doing before the first compile rather than after the first error.

## Two documented build failures, and one fix is a foreign git branch

The known issues section is short and specific, and both entries are dependency problems rather than project problems.

The first is a failure to compile a dependency called enacl, which for some versions of macOS and Linux may have compilation issues. The workaround given is to check out a branch, then clean, fetch dependencies and compile again:

```sh
git checkout mariari/no-libsodium
mix clean
mix deps.get
mix compile
```

That first line is the remarkable part. The fix for a failing dependency is to check out a branch inside that dependency's repository, named after the person who wrote it, with a name that describes the approach, no-libsodium. It is the kind of fix that only works for as long as that branch exists, and it tells you the project is tracking an upstream problem rather than solving it.

The second entry is a failure to compile a dependency called cairo, with a Rust dependency that the compiler can be picky about, likely caused by an incompatible toolchain. The fix is to add a specific toolchain version with rustup, and on macOS a specific target triple variant of it.

Both entries end with a short reassurance that the issues should go away afterwards. That is a reasonable expectation and a real dependency on two people's branches.

## The Makefile pins an old glibc for releases, and its default target does nothing

The Makefile opens with two lines that look like a mistake and are not. The first sets the environment for release builds with compiler flags targeting a specific glibc version, and the comment above it says the choice is somewhat arbitrary, made to be an oldish glibc version. The second defines a default target that does nothing at all.

That second line is deliberate. It means typing make with no arguments tells you nothing rather than starting a build, which is a courtesy for a repository where the obvious command is a release build that removes the build and dependency directories before recompiling.

The other targets are the build, the test run, and two documentation targets, one of which shells out to a script to generate a table of contents and another to collect documentation files, with a separate release variant that additionally runs a version-stamping script.

There is also a certificate target, and it is the most interesting line in the file. It generates a self-signed certificate with a ten year lifetime using an elliptic curve key on a named curve, with no nodes, writing a key and a certificate, and a subject common name of none. That is what you run when you need a local TLS identity for a node, and the CN=none is the correct choice for one.

## The interactive shell is the recommended way to work in it

Once the dependencies are installed, compiling is two commands:

```bash
mix deps.get
mix compile
```

And starting a node is one of two, depending on whether you want a shell:

```bash
iex -S mix # starts an interactive shell
mix run --no-halt # starts a non-interactive shell
```

The README then points you at the contributing section for how to get the best use out of the interactive shell, which is a stronger recommendation than it sounds. In an Elixir project, the interactive shell is not just a convenience, it is the normal way to inspect state, and for a protocol node it is how you poke at a running instance.

Two files in the repository root support that. There is a shell startup file, which is where you put the things you want loaded every time the shell starts, and there is a global dependencies file alongside the project manifest, which suggests the project separates dependencies that the application needs from those that only the tooling needs.

The contributor guide itself is a pair of documents written in a notebook format rather than plain Markdown, so the deep details about the codebase and about working with git inside it are executable documents rather than prose.

## Four ways to follow a project that would rather you did not read the issue tracker

The development section is the longest part of the README and it is a list of dashboards rather than a link to a tracker. There is a project overview board where issues are placed, described as a good way to see what work is assigned and the various views into how goals are being met. There is a second board called What's Cooking on Anoma, described as a good view of how topics progress throughout a cycle. There are research forums, described as good for discussions on the direction of Anoma, with the architecture posts called out in particular as a practical vision for how the codebase's architecture will evolve, at a rate of around two posts a week. And fourth there are issues and pull requests.

The README's own comment on the fourth item is the one to notice: it is good for viewing new issues and work coming in, but the other views are typically a better way to view this.

So the project's stated preference is that you read a board or the research forums rather than the issue tracker. That is a reasonable way to run a research-driven protocol project, where the direction of the design is the interesting part and a list of open bugs is not. It also means a newcomer who wants to find something to work on should start with a board, and a user who wants to know whether a problem is known should read the research forums as well as the tracker.

## Conclusion

Use this repository if you are implementing against the Anoma protocol specifications and you want a running Elixir node to test against, and if you can tolerate a project where the reference implementation moves on a two week cycle and dependency builds need workarounds. Do not use it as a library you depend on without checking the version, because the most recent release tag is v0.35.1 from 2026-02-22 while the last push was 2026-06-15, so the branch has moved past its last tag. Before you build: install protoc-gen-elixir at exactly 0.11.0 and put it on your path, because the README says the version matters; read the known issues section before you debug your own mistake, since enacl and cairo both fail for reasons that have nothing to do with your code; and remember that a pull request described as merged but still open is merged into next or main and waiting for the next release.

## FAQ

### What is the Anoma reference implementation?

It is an Elixir implementation of the Anoma protocol, whose specifications are published separately at specs.anoma.net. Work is merged into a branch called base on a bi-weekly schedule, and the most recent release tag is v0.35.1 from 2026-02-22 while the last push to the repository was 2026-06-15. The tree carries a Makefile, a changelog, a usage file, a configuration directory, documentation written as notebooks, and a test directory.

### How do I run Anoma from a pre-built release?

Download the Anoma release for your platform, extract it, and run `bin/anoma`. The release dependencies are the Apple command line developer tools installed with `xcode-select --install` plus MacPorts or an equivalent, ncurses on macOS only, and OpenSSL from a package manager on macOS and Linux, which is not required on Windows.

### How do I compile Anoma from source?

Install Elixir, Rust, Protobuf, and the Elixir protobuf plugin with `mix escript.install hex protobuf 0.11.0`, which the README says must be that version, then put it on your path and confirm it reports 0.11.0. Platform dependencies are installed with brew on macOS, with apt on Ubuntu and Debian, or with the Visual Studio 2022 build tools and PowerShell on Windows. Then run `mix deps.get` and `mix compile`, and start a node with `iex -S mix` or `mix run --no-halt`.

### Why does my Anoma build fail on enacl or cairo?

Both are known issues with dependencies rather than with the project. For enacl, on some versions of macOS and Linux, the workaround is to check out a branch in that dependency, run mix clean, mix deps.get and mix compile again. For cairo, the cause is likely an incompatible Rust toolchain, and the fix is to add a specific toolchain version with rustup, with a target-specific variant on macOS.

### Why is my merged Anoma pull request still open?

Because there are bi-weekly releases. The README explains that if a maintainer says your pull request is merged but it is still open, that just means it is merged into next or main and will be included in the next scheduled release. It also notes that new code should be based on base, and that you should not try to keep your branch in sync with main yourself.

## Sources

- [Official documentation](https://anoma.net)
- [Official README](https://github.com/anoma/anoma#readme)
- [Project repository](https://github.com/anoma/anoma)
- [Release notes](https://github.com/anoma/anoma/releases)

---

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