Evmos v20 is a Cosmos SDK chain that stopped being LGPL

The stack is Cosmos SDK on CometBFT with an EVM

Evmos is described as a scalable, high-throughput proof-of-stake EVM blockchain that is fully compatible and interoperable with Ethereum. The architecture sentence in the README is the informative one: it is built with the Cosmos SDK, which runs on top of the CometBFT consensus engine.

That layering explains both the opportunity and the cost. The EVM sits inside that application layer as a module, which is why the repository has an `ethereum/` directory alongside the usual Cosmos `x/` layout, plus `precompiles/` and an `indexer/`.

The interoperability claim has a concrete mechanism behind it rather than being a slogan. IBC is present, with `ibc/` in the tree and `ibc-go` in the module requirements, so the chain can talk to other Cosmos chains. Ethereum compatibility runs through the go-ethereum library, which appears in the dependencies at v1.11.5, and protobuf definitions live under `proto/` with `buf.gen.proto.yaml` and `buf.work.yaml` describing how they are generated. There is a `contracts/` directory, which in a Cosmos EVM chain is where the precompiled or Solidity-visible contracts live.

The description also positions Evmos as the flagship implementation of evmOS, a stack for building forward-compatible EVMs, which is a claim about a family of projects rather than about this repository alone.

The Go module path is `github.com/evmos/evmos/v20`, which tells you two things without reading further: the major version is baked into the import path, so a consumer must write the suffix, and the module targets Go 1.22.8.

Building is one make target, running is a different problem

The install section is brief because the prerequisites live in separate documentation. The README sends you to the installation instructions for prerequisites and detailed build instructions, and then the actual command is short:

make install

There is also a releases page with prebuilt binaries, which is the route most operators take rather than building from source.

Running a node is a separate document again, reached through the evmos-cli page, and the README points at the protocol overview first for people who want the model before the commands. That split is deliberate: the project has a separate documentation repository at evmos/docs and a site at docs.evmos.org, and the README here stays short on purpose.

The Makefile is where the build's real options live, and one of them is a genuine fork in the road. `DB_BACKEND` is a build argument that defaults to `goleveldb`, and the Dockerfile takes it as a build argument defaulting to the same value. Set it to `rocksdb` and the build path changes completely: the Dockerfile then runs `make build-rocksdb` and copies `/usr/lib`, `/usr/local/lib` and `/usr/include` into the target, because a RocksDB build needs those artefacts carried into the runtime image. The Dockerfile pins a RocksDB version of 9.8.4 as a build argument.

That is a decision you make once, at build time, and it is not reversible without rebuilding. The default is fine for a testnet; a production operator picking a database backend should decide deliberately.

The container image is two-stage, built on golang:1.23.4-alpine3.20 and run on alpine:3.21, and it runs as a non-root user with uid 1000. It exposes six ports, 26656 and 26657 for CometBFT, 1317 and 9090 for the API and gRPC, and 8545 and 8546 for the EVM JSON-RPC and websocket. The health check curls the CometBFT RPC endpoint:

HEALTHCHECK CMD curl --fail http://localhost:26657 || exit 1

A local single-node environment is set up by `local_node.sh` in the repository root, and there is also an `init.bat` for Windows.

The licence changed and the README asks you to email before use

This is the part of the repository that will decide whether it is relevant to you, and it is not a detail at the bottom of the file.

From 21 April 2023, the repository licence moved from the GNU Lesser General Public License v3.0 to the Evmos Non-Commercial License 1.0, identified as ENCL-1.0. The change applies to all software released from version 13 onwards, with two named exceptions that remain under LGPLv3: `x/erc20/keeper/proposals.go` and `x/erc20/types/utils.go`. Versions before v13 remain LGPLv3.

The permissions and prohibitions are laid out in a two-column table. Permitted: private use including distribution and modification, commercial use on designated blockchains, and commercial use with an Evmos permit that is separately negotiated. Prohibited: commercial use other than on designated blockchains, without an Evmos permit.

So the licence is not a blanket open source grant and it is not a blanket commercial ban either. It draws a line around designated blockchains, and everything about whether your use falls inside or outside that line is a matter for you and the project rather than for this description.

The README does not leave that to inference. There is a warning block that says, in effect, if you are interested in using this software, email [email protected]. That is an unusual instruction in an open source README and it signals where the project expects commercial conversations to happen.

The mechanics are worth noting too, because they are handled properly. Files under ENCL-1.0 carry an SPDX header identifying it, and the exempted files carry the LGPL identifier instead:

// Copyright Tharsis Labs Ltd.(Evmos)
// SPDX-License-Identifier:ENCL-1.0(https://github.com/evmos/evmos/blob/main/LICENSE)

A dedicated `LICENSE_FAQ.md` holds the expanded answer, and `SECURITY.md` sits alongside it. The SPDX headers in these files identify which licence applies to them.

v20 is the newest tag and the module has moved on since

There is a gap in the release history that anyone evaluating this should notice.

The most recent tags are v20.0.0-rc2 on 2024-09-27, v20.0.0-rc3 on 2024-10-08 and v20.0.0 on 2024-10-21. Nothing later appears in the release list. The repository is not archived, and the last push was on 2026-08-24, so work continues on main, but the tags tell a story of a major version line that was cut and then not obviously extended with further tagged releases in what we can see.

That combination, active pushes but no recent tags, has a specific meaning for a chain. A validator or a node operator needs tagged releases because that is what upgrade coordination is based on.

The module path `github.com/evmos/evmos/v20` confirms the current major, and the presence of a `CHANGELOG.md` at the root means the history is written down rather than only tagged. There is also a `SAFU.md` at the root, which the repository listing includes without explanation in this README.

Go version requirements are also layered. The module declares Go 1.22.8, while the Dockerfile builds with golang:1.23.4-alpine3.20. The module and container configurations therefore use different Go toolchain versions.

The build tooling around the project is unusually complete for a chain, and it is a signal about how the project expects contributors to work: a `.golangci.yml` for linting, `.semgrepignore` and a `mlc_config.json` for secret and licence scanning, `.checkov.yml` for infrastructure checks, `.clang-format` alongside `.solhint.json` for the Solidity side, `tox.ini` and `default.nix` for reproducible environments, and a `Dockerfile` that already handles the awkward parts of building a Go binary that needs native libraries.

evmOS against running your own EVM or using an existing chain

The realistic alternatives are not other Cosmos EVM chains, which are variations on the same idea. They are two much more different options.

The first is to run your own EVM inside an existing chain framework. That is what evmOS-as-a-stack is pointing at: Evmos is described as the flagship implementation of a stack for building forward-compatible EVMs, so the same integration pattern may be available as a library rather than as a chain you have to adopt wholesale. For a team whose blocker is specifically EVM compatibility on Cosmos, that distinction is the difference between a library dependency and a fork of someone's blockchain.

The second is not to run a chain at all. Deploy to an existing EVM chain and accept its security, its fees and its ecosystem. For most contract deployments, this is what you should do, and a Cosmos EVM chain has to earn its existence on properties like throughput, cost and access to Cosmos liquidity rather than on contract compatibility alone.

The trade is therefore about finality and ecosystem rather than tooling. Cosmos-style consensus gives fast finality and predictable fees, and IBC gives a path to Cosmos liquidity and to chains Ethereum has no connection to. What you give up is the Ethereum developer ecosystem's depth, the tooling and the liquidity, and you take on the operational work of running and upgrading a chain, which the Dockerfile and Makefile in this repository are evidence of.

Against building a chain from scratch on the Cosmos SDK directly, Evmos is a shortcut with a price: you inherit its precompiles, its indexer and its configuration surface, and you accept ENCL-1.0 on anything from v13 onward. That is a reasonable trade for a team that wants the EVM working and would rather not debug it, and a poor one for a team that needs to own every line.

Editorial conclusion

Adopt Evmos if you are operating a chain in the Cosmos ecosystem that needs EVM compatibility and are content to work inside a non-commercial licence, or if you are studying how an EVM is integrated into the Cosmos SDK rather than planning to reuse the code. Do not adopt it as an open source dependency for a commercial product outside the designated blockchains, because the terms are explicit and the README directs interested users to email the project before use. Verify first which version you need, since the newest tagged release here is v20.0.0 from 2024-10-21 while the Go module path already carries a `/v20` suffix and the last push was on 2026-08-24, then confirm with your own reading of `LICENSE` and `LICENSE_FAQ.md` what your intended use counts as.

Frequently asked questions

Official sources

1. evmos/evmos on GitHub
2. Issues
3. Project website
4. README
5. Releases