Gno interprets deterministic Go so smart contracts can be ordinary Go code

Deterministic Go, interpreted rather than compiled

Gno is described as a blockchain platform that interprets a deterministic variant of Go for writing smart contracts, built on Tendermint consensus, and more precisely as an interpreted and fully deterministic implementation of the Go programming language designed to build succinct and composable smart contracts. Two words carry the design. Deterministic means the same input produces the same output on every node, which is what a consensus engine requires and what ordinary Go cannot promise, because Go has map iteration order, concurrency and a runtime with floating point and random number generation. Interpreted means the contract is executed by a virtual machine rather than compiled, and the repository has a gnovm/ directory that holds the GnoVM and the Gno language, with the node in gno.land/ and the consensus engine in tm2/. The consequence for a developer is a language that looks like Go and behaves predictably, which is the point of the whole project.

gno.land is a contribution-based chain, not a fork

The first blockchain using it is gno.land, a contribution-based chain backed by a variation of the Tendermint consensus engine, and the mainnet has been live since 12 September 2026 with the chain id gnoland-1 and the RPC endpoint at rpc.gno.land on port 443. Two details in that sentence matter. It launched as a fresh chain rather than a fork of betanet, so there is no legacy state to reconcile, and there is no mainnet faucet, so you cannot obtain tokens the way you would on a test network. The practical way to build and deploy for free is a testnet, and the project deliberately does not name one in the README because testnets are renamed and replaced regularly, and points at the Gno networks documentation page instead, which always lists the current network, its RPC endpoint and the archives of past networks. Tokens for a testnet come from the faucet. For anyone reading this in order to build something, the network churn is a factor to plan around, since a script that hard codes a testnet RPC endpoint will break when that network is replaced.

The features that shape the developer experience

The key features list is short, and each one maps to a specific developer pain. Go syntax means that if you know Go you know Gno, which removes the largest barrier to writing a contract. Deterministic execution means fully predictable contract behaviour, which is what makes the contract safe to run on many nodes that must agree. Composable packages mean you can import and reuse code like regular Go, so a contract library is a Go package rather than a bespoke mechanism. Auto-persisted state means global variables are automatically saved between calls, which removes the ceremony of manually persisting state after every message. The contribution system is the odd one out, because it is about the chain rather than the language, with the project described as a blockchain for timeless code and fair open-source, and a proof-of-contribution topic in the repository. Developer experience is listed too, with comprehensive tooling including testing, debugging and hot-reload development.

One repository, four tools

The repository is a monorepo of the whole stack. The docs/ directory is the official documentation portal, examples/ holds sample contracts and guides, gnovm/ is the virtual machine and the language, gno.land/ is the blockchain node and its tools, tm2/ is the Tendermint2 consensus engine, contribs/ holds additional tools and utilities, and misc/ has various scripts and utilities. The build tooling follows the same shape, and the Makefile gives you the shortcuts. A single make install target builds the three main binaries:

make install

which delegates to install.gnokey, install.gno and install.gnodev, each of which recurses into the relevant subdirectory, the node tools, the virtual machine and the development server. The Docker build in the repository compiles the same set of binaries, gnoland, gnokey and gnoweb, from a golang 1.25 alpine base, with the build version written into a file and injected with ldflags so that a new tag only invalidates the layers that depend on it. The Makefile also disables cgo by default, on the grounds that cgo requires additional dependencies and is not strictly required by any tm2 code.

Running a node is the last resort, not the first step

The documentation is organised around the idea that most people are not running infrastructure. The For Users section covers how to use Gno applications, manage accounts and interact with the blockchain. The For Builders section covers writing smart contracts, understanding the Gno language and deploying applications. The References section holds technical specifications, best practices and advanced topics. And the running a node page carries an instruction that says start here if you were about to run one, most use cases don't need it. That is a useful piece of guidance, because a consensus node is a commitment of compute and a key management exercise, and the path from trying the language to shipping a contract does not run through it. The alternative is the Gno Playground at play.gno.land, a web app for writing, sharing and deploying Gno code, where developers can test, debug and deploy realms and packages, and collaborate with peers, with the key feature being that you can get started without installing any tools or managing any services. The README does add a caveat that the playground may not always reflect the latest changes in the repository.

The ecosystem around the language

Beyond the core repository, the project points at a set of community resources, and they show that the toolchain is bigger than the VM. Gnoverse collects community projects and initiatives, and Awesome Gno is a curated list of resources. Gnoscan is a blockchain explorer. Gno Studio is a web IDE for Gno development. The workshops repository holds educational materials, with a Discord for real-time support and development discussions, an X account for announcements, a YouTube channel with tutorials, workshops and development calls, a Reddit forum, and a community-run Telegram group. The repository also carries a .gitpod.yml, so a cloud development environment can be started from the project page, and the top-level entries include PHILOSOPHY.md, PLAN.md, TERMS.md, SECURITY.md, RELEASING.md and an AGENTS.md, which is a sign that this is a project with process as well as code. The releases are frequent, with v1.5.1 and its release candidate published on 2026-10-13 and a chain/onyx genesis tag on 2026-09-28, and the last push was on 2026-10-15.

It is not Gnosis, and the licence is not a standard one

The README puts a note near the top that is worth repeating in any summary, that this is not the same project or token as the Gnosis project. The two names are close enough to cause confusion, and the name of the chain, the token and the language all carry the Gno spelling. The licence is the other thing to check. The badge in the README describes it as a GNO GPL v5, and GitHub cannot classify the licence, so the terms are in the LICENSE.md file at the root rather than in an identifier the tooling recognises. That means you have to read it yourself, and it also means the usual automated licence checks in a procurement or security review will not resolve it. The repository's licence is separate from the licence of each contract you deploy, which is a distinction worth keeping in mind, since the chain's rules govern the chain and your own repository's licence governs the code you publish there. If you are evaluating this for a commercial deployment, that is the document to read first.

Editorial conclusion

Gno is worth a look if you write Go and want to deploy smart contracts without learning a new language, because the compatibility is the whole pitch and the composability model, with packages imported like regular Go, is what makes shared contract code practical. It is the wrong tool if your contract logic needs unbounded computation, since determinism is a hard requirement of the chain and the interpreter is the price of that, and the wrong tool if you need the mainnet today without dealing with the fact that there is no mainnet faucet and that testnets are renamed and replaced regularly. Before you start, read the documentation's split between users, builders and references, use the Playground or a testnet rather than a node, since the README says most use cases do not need one, and check the licence, which is a custom GNO GPL variant rather than a standard identifier.

Frequently asked questions

Official sources

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