chain-main: the Cronos POS Chain full node source

A Cosmos SDK chain with Cronos-specific modules

Cronos POS Chain is a blockchain application built using Cosmos SDK and Tendermint, intended as a backbone for some of the existing and future Cronos ecosystem. The homepage is cronos-pos.org and the technical documentation lives in a separate chain-docs repository, with a hosted version at docs.cronos-pos.org.

The repository is a Cosmos SDK application in the standard shape. The Go module path is github.com/crypto-org-chain/chain-main/v8, and the /v8 suffix is the Go convention for a module whose major version has moved, which tells you this codebase has been through several incompatible generations already. The go.mod pins Go 1.25.8.

The dependency list shows the standard Cosmos stack alongside the parts that are specific to this chain. The Cosmos SDK itself is at v0.53.4, and there are the usual module packages, cosmossdk.io/api, collections, core, errors, log, math, store and tools/confix, plus the x/ modules for circuit, evidence, feegrant, tx and upgrade. The consensus engine is github.com/cometbft/cometbft at v0.38.22, which is the renamed Tendermint. The IBC stack is ibc-go/v10 at v10.5.1, and rosetta is present, which is the API layer many chains use for cross-chain indexing.

What is Cronos-specific in the dependency list is the storage layer: github.com/crypto-org-chain/cronos-store/store and the companion versiondb, both pinned to a commit from September 2025, and the RocksDB binding linxGnu/grocksdb. That is the part that will differ most from a stock Cosmos chain, and it is where a fork of this repository would diverge fastest.

Building the full node with make

The build is a make target, and the README gives the default invocation:

# COSMOS_BUILD_OPTIONS=rocksdb make build
make build

By default the command builds a binary with mainnet configurations. To build for a different network you provide the NETWORK variable to make:

NETWORK=testnet make build

That single variable is the switch between chain configurations, and it appears in the Makefile as NETWORK ?= mainnet. It also appears in the Dockerfile as a build argument defaulting to testnet, which is a difference worth noting: the container image you build without arguments is not the same configuration as the binary you build with make.

The Makefile shows how much of the build is conditional. Ledger support is on by default with LEDGER_ENABLED ?= true, and it requires a C compiler: the build errors out if gcc is missing on Linux and macOS, and if gcc.exe is missing on Windows, with the message telling you to install it or set LEDGER_ENABLED=false. OpenBSD is detected and ledger support is disabled with a warning pointing at the Cosmos SDK issue about it. The build tags accumulate from there.

The database backend is a second set of choices driven by COSMOS_BUILD_OPTIONS, with a branch for each of secp, cleveldb, badgerdb, rocksdb and boltdb. The rocksdb branch is the interesting one, because it sets CGO_ENABLED=1 and adds the rocksdb and grocksdb_clean_link build tags, and the secp branch adds libsecp256k1_sdk for the alternative secp256k1 implementation.

The version stamping is done in the Makefile itself, with VERSION derived from git describe and the tags stripped of the leading v, and COMMIT taken from the last commit hash. The binary name is chain-maind, and the image copies that binary into the final alpine stage.

Nix for a reproducible build and a container image

Nix is offered as the reproducible build path, and the README gives an install command:

$ curl -L https://nixos.org/nix/install | sh

There is a specific caveat for recent Macs with a T2 chip, where the plain installer may not work and the nix macos installation section is the thing to read.

With Nix in place, the build produces a container image directly:

$ make chaindImage

And there is an optional binary cache to speed the build up, using cachix:

$ nix-env -iA cachix -f https://cachix.org/api/v1/install
$ cachix use crypto-org-chain

That second block is worth pausing on, because it is a trust decision. Pointing a build at a remote binary cache means your build fetches prebuilt artefacts rather than compiling them, and the cache is served under the crypto-org-chain account on cachix. For a reproducible build that is exactly the point, since the cache is content-addressed, but it is a different trust model from building the source yourself.

The repository itself is heavily Nix-flavoured. There is a default.nix, a docker.nix, a proto.nix, a nix/ directory, a flake.lock and flake.nix, and a gomod2nix.toml, which is how Nix pins the Go module dependencies. A .gitmodules file is present as well, and the Dockerfile runs git submodule update --init --recursive before the build, so there are submodules to fetch in either path.

Running a local devnet with pystarport or compose

The README points to the documentation for running a local devnet, and separately gives a quick start for pystarport, the tool used to manage nodes for development.

Installing pystarport is a pip install, and the README's Python prerequisite section is unusually explicit, telling you to install Python 3.8 or above and showing a from-source build of CPython checked out at tags/v3.9.5. The path adjustment step then explains that with multiple Python versions installed, pystarport cannot be found, and that the fix is to put the local bin directory on the PATH:

export PATH=/usr/local/bin:$HOME/.local/bin:$PATH

Once installed, three commands run the devnet and manage it:

pystarport serve --data=./data --config=./integration_tests/configs/default.yaml

pystarport supervisorctl status

pystarport supervisorctl stop all

The serve command takes a data directory and a config file, and the default config lives in the integration_tests/configs directory of the repository, so the local devnet is described by a file you can read and edit rather than by flags.

The alternative is docker-compose, and the compose file in the repository is a good illustration of what a multi-node local network looks like. It defines four services, chainmainnode0 through chainmainnode3, all running the cryptocom/chainmaindnode image, each with its own ID and log file name, each mapping a distinct host port range onto the standard node ports, and each with a static IPv4 address in a localnet bridge network with the subnet 192.168.10.0/16. Node 0 maps 26656-26657, node 1 maps 26659-26660, node 2 maps 26661-26662 and node 3 maps 26663-26664, with the API ports 1317 through 1320 and the 9090 series for the node monitoring endpoints.

The result is a four-node network on one bridge network, which is enough to exercise multi-node behaviour without a cloud bill.

Testing, RocksDB and the operational surface

The test story is layered, and the README names each layer with its own target. Unit tests are make test. Simulations are make test-sim-* with a nondeterminism example given, make test-sim-nondeterminism. Integration tests are make nix-integration-test, with a pointer to the documentation in the integration_tests directory.

The simulation layer is the part that matters most for a chain. A Cosmos SDK application has a lot of state machine logic, and the nondeterminism simulations are how you check that a block executed on one node produces the same result as the same block executed on another.

The RocksDB path is the other build axis, and it is documented as a three-step process. The library is installed through Nix:

nix profile install -f ./nix rocksdb

Then the pkg-config paths are exported so the C bindings can find it:

export PKG_CONFIG_PATH=$HOME/.nix-profile/lib/pkgconfig 
export CGO_CFLAGS="$(pkg-config --cflags rocksdb)" CGO_LDFLAGS="$(pkg-config --libs rocksdb)"

And the build option is enabled:

export COSMOS_BUILD_OPTIONS=rocksdb

That last variable is the one that the Makefile reads, and it is also what the first build example in the readme had commented out, so the RocksDB path threads through the whole build system rather than being a separate make target.

The rest of the repository shows the operational surface: a Dockerfile with a two-stage build from golang:1.25-alpine to alpine:edge, running as a non-root chain-main user, a start-local-node.sh script, a networks/ directory, a proto/ directory with a makeproto.sh script and buf.work.yaml, an x/ directory for the chain's custom modules, app/ for the application wiring, and a pystarport/ directory with its own README.

Editorial conclusion

Adopt chain-main if you are working on the Cronos POS Chain itself, running a node for that network, or building on top of the Cronos ecosystem, and you are prepared to work with the Cosmos SDK and CometBFT. Do not adopt it as a general application chain template without accepting the Cronos-specific custom modules and the maintenance burden of a major-version upgrade path, since the module path already carries a v8 suffix. Verify first that your Go toolchain matches the go 1.25.8 the module declares, that the NETWORK variable selects the chain you intend to run, and that you have read the chain-docs repository rather than assuming this readme covers operation.

Frequently asked questions

Official sources

1. crypto-org-chain/chain-main on GitHub
2. Issues
3. Project website
4. README
5. Releases