The Arweave server in Erlang: Blockweave storage, mining incentives, and a build you assemble yourself

The repository is a protocol implementation, not an app you install

The project states its scope in one line: this is the repository for the official Erlang implementation of the Arweave protocol. Arweave itself is described as a distributed, cryptographically verified permanent archive built on a cryptocurrency that aims, for the first time, to provide feasible data permanence.

The interesting technical claim in that description is the Blockweave data structure. By leveraging it, data is stored in a decentralised, peer-to-peer manner where miners are incentivised to store rare data rather than duplicate data. That distinction is the whole economic and storage design in one sentence. A system that rewarded copying would fill itself with copies of the most popular files; a system that rewards rarity pushes storage toward the long tail.

The primary language is Erlang, and the code layout reflects a server rather than a library. There is an `apps/` directory holding the OTP applications, a top level `arweave-server/` directory, `config/` for runtime configuration, `priv/` for assets, `bin/` for entry point scripts, and `deploy/` for deployment material. Two documentation files sit at the root, `http_iface_docs.md` and `http_post_unsigned_tx_docs.md`, which describe the HTTP interface and the flow for posting unsigned transactions.

A reader who wants to understand the protocol design rather than the code will also find `papers/`, a `yellow paper` link, and a `doc/` directory. The yellow paper is the canonical specification, and it is where the actual protocol rules live.

No build commands in the repository, only a pointer to the docs

The project documentation is unusually terse about building, and that is a deliberate choice rather than an oversight. For instructions on how to build and update the source, the repository points to the Development Docs at docs.arweave.org, under the developers section for development getting started.

What the tree itself reveals is the toolchain. The build is rebar3 based, with `rebar.config`, `rebar.lock`, and `rebar3` at the root, plus a separate `ar-rebar3` binary. Beyond that there is a Nix layer: `flake.nix`, `flake.lock`, `default.nix`, and a `nix/` directory, which together suggest the project supports reproducible, declarative environments rather than a single global install. A `.tool-versions` file points the same way, pinning the language runtime versions used by the project.

Because the repository does not spell out the commands, anyone planning to build should treat the external development docs as a required dependency of the workflow, not an optional convenience. The repository also carries a `scripts/` directory and a `deploy/` directory, so the operational steps around a release are code in the tree rather than prose in the repository.

One contributor detail is worth repeating because it is easy to miss and it affects every pull request. Extensive reformatting has been applied to the repository to keep `git blame` useful, and the reformatting commits should be ignored. The configuration to do that goes in place after cloning:

git config blame.ignoreRevsFile .git-blame-ignore-revs

The file `.git-blame-ignore-revs` is present at the root, which is the other half of that instruction.

Testnet, localnet, and genesis data live in the tree

A protocol implementation that has to be verifiable needs ways to run the network without joining the main one, and the tree carries both. There is a `testnet/` directory and a `localnet_snapshot/` directory, so you can bring up a local copy of the chain state, and a `genesis_data/` directory holding the data that seeds it.

That is a real differentiator for anyone who wants to understand the system or work on it. Reproducing a local network from a snapshot, or pointing a node at a testnet, is the difference between being able to experiment and only being able to read code. The `scripts/` and `deploy/` directories are where the wiring for those environments is likely to be maintained.

The project also keeps `release_notes/` as a directory, which is a signal about how releases are communicated. The tag history in the repository matches that. Recent tags include N.2.9.6, an N.2.9.7-alpha1, and then N.2.9.7-alpha1-dev-sync-performance-20260909, dated 2026-10-08. The naming shows both an alpha line and a development branch carrying a named change, sync performance, on the tag itself.

There are also `notebooks/` and a `.jupyter/` directory at the root, plus `erlang_ls.config` for the Erlang language server, which points to a project where analysis and experimentation sit alongside the server code.

Agent and assistant configuration files are now part of the tree

The root of the repository contains a cluster of files that would have been unusual in an Erlang project a few years ago: `AGENTS.md`, `CLAUDE.md`, `CANARY.md`, and directories named `.agents/`, `.claude/`, and `.cursor/`.

`AGENTS.md` and `CLAUDE.md` are instructions for coding assistants and agents working inside the repository, and `.claude/` and `.cursor/` hold per-tool configuration for Claude Code and Cursor. The presence of `CANARY.md` is more interesting, because canary files are a technique for detecting whether content has been copied into a model or an agent context. Placing one in the repository is a signal that the maintainers care about how their code and instructions travel.

For a contributor this has a practical consequence. If you use an assistant to work on the code, the repository already contains the rules it expects, in a form the tooling can read. The same is true for a human: `CONTRIBUTING.md` holds the contribution process, and the `AGENTS.md` file describes how agents should behave in the tree.

The rest of the root follows common Erlang project practice: `.github/` for workflows and templates, `.gitattributes`, `.gitignore`, `.gitmodules` for submodule dependencies, `.git-blame-ignore-revs`, and a `LICENSE.md` that holds the full licence conditions.

GPL-2.0 covers the whole implementation

The licence is stated plainly: the Arweave project is released under GNU General Public License v2.0, with the full conditions in the `LICENSE.md` file at the repository root.

GPL-2.0 is a copyleft licence with a real consequence for anyone planning to build on this code. If you distribute a modified version of the Arweave server, or a work that links to it in a way that creates a derivative work, you owe the recipients the corresponding source under the same terms. For a research protocol implementation used as a service or run internally without distribution, the obligations are far lighter. Whether a particular arrangement triggers them is a question for whoever handles licensing on your side, but the classification of the repository as GPL-2.0 rather than a permissive licence is the fact to plan around.

The project also publishes a yellow paper, linked from the repository, as the protocol specification, separate from the code and its licence.

For context on where this sits in the wider ecosystem, the project frames the server as the official implementation and points to the project site at arweave.org for general information, while the technical specification lives at the yellow paper address.

Where this repository stops and the ecosystem continues

It is worth being clear about what is not here, because the name invites assumptions.

This is the server and the protocol implementation. The project describes itself as the Arweave server and the App Developer Toolkit, and the tree contains the node implementation with its HTTP interface, transaction posting, mining, and the Blockweave data handling. What is not in the tree is a hosted storage product, a priced API, or a multi language client library. The Arweave project as a whole is larger than this repository, and the distinction matters when you are deciding whether to clone this or to sign up for a service.

The comparison that matters for an engineer is between running the node and talking to the network through a gateway. Running the node means owning a copy of the chain state, validating the data yourself, and accepting the operational cost that comes with the `deploy/`, `config/`, and `scripts/` directories. Using a gateway means trusting that operator's validation and paying for the abstraction, at the cost of not controlling your own view of the data. For a team that needs to verify what it stored, the former is the only option the repository supports.

The protocol itself is documented in the yellow paper, and that document, not this code, is the reference when the two disagree about intended behaviour.

Editorial conclusion

This repository is the right starting point for anyone who needs to read from the Arweave network at the protocol level, run a node for verification, or contribute to the server, and it is the wrong place to look for a hosted storage API or a client library. Before cloning it, confirm three things: that you can follow the external development docs for the build, since the repository documentation itself contains no build commands, that your environment can run rebar3 and the Nix setup, and that GPL-2.0 is acceptable for your use, because the whole implementation is copyleft and any derived work inherits that obligation.

Frequently asked questions

Official sources

1. ArweaveTeam/arweave on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases