Grin: A Minimal Rust Node for the Mimblewimble Chain Format

What Grin Is and Who It Is Built For

Grin is a cryptocurrency node written in Rust that follows the Mimblewimble protocol. The README describes it as an in-progress implementation and lists the choices made so far: hidden amounts, scaling advantages, Cuckoo Cycle proof of work in two variants called Cuckaroo and Cuckatoo, a one minute block time, a fixed block reward with decreasing dilution, fees based on the number of outputs created or destroyed plus total transaction size, and a smooth difficulty adjustment curve.

The audience is narrow. This is not a library you import into a service, and the README points to a build guide rather than a hosted endpoint. If you want to run a node, mine, or read how a Mimblewimble chain is assembled from Rust crates, Grin is the reference. If you want a wallet with a support team, the README does not offer one. The project states it is live on mainnet, and the release history shows v5.5.1 tagged on 2026-08-11, with v5.5.0 and v5.4.1 earlier that summer. The last push to master was on 2026-09-16.

The README also carries a philosophy section that is unusual for this kind of repository. It says Grin "likes itself small and easy on the eyes" and that it may hold strong opinions to stay in line with its objectives. Read that as a design constraint, not marketing: the minimalism is enforced in the crate boundaries, and it is the reason some features you would expect from a general purpose chain are simply absent.

The Ten Crate Workspace and How a Node Fits Together

The Cargo.toml declares a workspace with ten members: api, chain, config, core, keychain, p2p, servers, store, util and pool. The root package is itself a binary named grin, built from src/bin/grin.rs, and it depends on the workspace crates by path at version 5.5.1. That layout tells you most of the architecture before you read a line of code.

core holds the Mimblewimble primitives. chain holds the chain state and validation. store is persistence. p2p is the peer layer. servers is the long running service that ties them together, which is why the binary's default command is server run. api exposes the node over HTTP, and config owns the TOML files the node reads at startup. keychain sits apart from core because key material has different handling requirements. pool is the mining pool side.

The dependency list in the root manifest is deliberately thin: chrono, thiserror, clap 2.33 with the yaml feature, ctrlc, serde, serde_json, log, term, tokio with only the sync feature enabled, and cursive for the terminal UI. Note that tokio is pulled in with sync alone, not the full async runtime. The node is not built as an async service, and anyone expecting a tokio-based server will be surprised. The build script is src/build/build.rs and it uses the built crate with the git2 feature, so version strings are stamped from git metadata at compile time.

Building Grin and Running a First Node

The README does not contain install steps. It says to see the build docs at doc/build.md, and the repository ships a Dockerfile that shows the intended toolchain. That file is the most concrete build recipe in the tree, so start there. It builds on rust:slim-trixie, installs libncurses5-dev and libncursesw5-dev, and runs a release build.

FROM rust:slim-trixie AS builder
WORKDIR /usr/src/grin
COPY . .
RUN apt update && \
    apt install -y libncurses5-dev libncursesw5-dev
RUN cargo build --release

The runtime stage copies the single grin binary onto debian:trixie-slim and installs libncursesw5-dev and ca-certificates. That tells you the binary links against ncurses even when you disable the terminal UI, so a bare scratch image will not work.

Configuration is generated, not hand written. The Dockerfile creates a mainnet config by running grin server config inside /root/.grin/main, then edits two keys with sed: run_tui is set to false and api_http_addr is set to 0.0.0.0:3413. The testnet config is generated the same way under /root/.grin/test with the flag grin --testnet server config, and its api_http_addr becomes 0.0.0.0:13413.

grin server config
grin --testnet server config
grin --no-tui server run

The container exposes 3413 and 3414 for mainnet, 13413 and 13414 for testnet, and 3416 for Stratum. It declares /root/.grin as a volume and sets the entrypoint to grin --no-tui with the default command server run. If you build natively instead, expect to produce the same grin-server.toml yourself in the same location before the first start, because the node reads that file rather than accepting every setting as a flag.

Cuckoo Cycle, Cuckaroo and Cuckatoo: What the Two Variants Mean for You

Grin's proof of work is Cuckoo Cycle, implemented in two variants the README names directly: Cuckaroo, described as ASIC-resistant, and Cuckatoo, described as ASIC-targeted. That is an unusual arrangement. Most chains pick one posture and live with it. Grin carries both, which means the hardware question does not have a single answer, and the README does not explain how the two are scheduled against each other or which one applies to a given block. If mining economics matter to your decision, doc/build.md and the introduction at doc/intro.md are where you would look, and neither is summarised in the README.

The block time is one minute, which is fast for a chain that validates every transaction against hidden amounts. The reward is fixed with decreasing dilution, so the emission schedule is not a halving curve. Fees are computed from the number of outputs created or destroyed plus total transaction size, not from a simple byte count. That fee model is a direct consequence of Mimblewimble: outputs are what the chain stores, so charging per output aligns the fee with the actual cost of carrying a transaction.

Difficulty adjusts on what the README calls a smooth curve. Nothing in the repository files given here quantifies that curve, and the README does not state the target block interval tolerance. Treat any specific difficulty figure you see elsewhere as unverified against this source.

Where Grin Is the Wrong Tool

The README is candid that much is left to be done, and the gaps matter more than the feature list. There is no documented wallet recovery procedure. The Dockerfile generates configs and starts a server; it does not show how to back up or restore key material, and the keychain crate existing as a separate workspace member tells you keys are handled distinctly, not that recovery is solved. If your users cannot afford to lose funds, verify recovery against the keychain crate's own tests before you build anything on top of it.

Second, there is no hosted API and no managed node. The api crate exposes an HTTP interface, and the Dockerfile binds api_http_addr to 0.0.0.0, which means the container is reachable from outside by default once you publish the port. That is a deployment decision you have to make consciously, because the generated config does not restrict the bind address on its own.

Third, the project is opinionated about staying small. The README states this outright. Features that a general purpose chain accumulates over time, such as a broad smart contract surface, are not part of the stated objectives. If your requirement is programmability rather than confidential transfers, Grin is the wrong layer, and no amount of configuration will change that.

Finally, the build is not trivial. A Rust workspace with a git-based build script, an ncurses runtime dependency and generated TOML config is a real toolchain commitment. The Dockerfile exists precisely because the native path has enough moving parts to be worth containerising.

How Grin Differs from Transparent-Chain Node Software

The obvious comparison is a transparent-chain full node, such as a Bitcoin Core style implementation. The difference is in what the chain stores. In a transparent chain, every transaction leaves a permanent record of inputs, outputs and amounts, and the node's job is to index and serve that record. In Mimblewimble, as the README describes it, amounts are hidden and the format provides scaling advantages. The chain can discard intermediate state that a transparent chain must keep, which is why Grin can afford a one minute block time without the storage growth you would expect.

That changes what the software is for. A transparent-chain node is largely a query engine over a public ledger. A Mimblewimble node is closer to a validator of hidden commitments, and the interactive parts of a transaction happen between the parties rather than being broadcast as a script. If you have built tooling against a transparent chain's RPC surface, expect the mental model to transfer poorly even where the endpoint names look familiar.

The trade-off is verification cost and complexity. Hiding amounts means the node does more cryptographic work per transaction, and it means external auditing of the ledger is not possible in the way it is on a transparent chain. Grin chose confidentiality and chain size; it gave up the ability for a third party to inspect the books.

Licence, Maintenance and the Cost of Upgrading

Grin is licensed under Apache License v2.0, stated in the README, declared as license = "Apache-2.0" in Cargo.toml, and shipped as a LICENSE file at the repository root. Apache-2.0 includes an explicit patent grant and requires that you preserve notices and state changes you make. That is a permissive licence, and it is compatible with commercial use, but the details of attribution in a distributed product are a matter for your own counsel rather than something this article can settle.

On maintenance, the facts are these: the repository is not archived, the last push was on 2026-09-16, and the most recent tagged release is v5.5.1 from 2026-08-11, preceded by v5.5.0 on 2026-06-16 and v5.4.1 on 2026-06-11. The version string in Cargo.toml is 5.5.1, matching the tag, and every workspace crate is pinned to that same version. That pinning is the upgrade cost in one line: because the root package depends on api, config, chain, core, p2p, servers, util and store by path at 5.5.1, moving to a new release means moving all of them together. You cannot take a patch to core without rebuilding the binary, and any fork you maintain has to be rebased across the whole workspace.

The README also points contributors at CONTRIBUTING.md and notes that a SECURITY.md exists at the root, which is where a disclosure process would be described. The README itself does not document a rollback procedure for a bad upgrade, and neither does the Dockerfile, which always builds from the copied source tree.

Editorial conclusion

Grin suits engineers who want to read or modify a Mimblewimble node rather than call a hosted API, and who are comfortable building a Rust workspace from source. It does not suit anyone expecting a managed service, a token with a company behind it, or a wallet with a documented recovery procedure, because the README does not describe one. Before committing, run grin server config and read the generated grin-server.toml, then read doc/build.md and confirm the toolchain it names still matches the Rust edition in Cargo.toml.

Frequently asked questions

Official sources

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