# go-iost runs JavaScript smart contracts on the IOST blockchain

> go-iost is the official Go implementation of the IOST blockchain, embedding the V8 JavaScript engine so contracts are written in JavaScript, with sub second block times, free transactions and a Go based node, SDK and wallet. It suits developers targeting the IOST platform rather than a general purpose chain.

**iost-official/go-iost** — Official Go implementation of the IOST blockchain

- Repository: https://github.com/iost-official/go-iost
- Website: https://developers.iost.io/
- Stars: 567 · Forks: 114
- Language: Go
- License: LGPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/iost-official-go-iost

## V8 inside the chain, which is the whole design decision

IOST is described as a smart contract platform with a strong emphasis on performance and developer experience, and the first feature listed is that the V8 JavaScript engine is integrated directly into the blockchain, which lets developers write smart contracts in JavaScript. The reasoning given is twofold. JavaScript is a universally known language, which makes the development process easier and quicker, and V8, being the engine behind Google Chrome, is known for its speed, which the project says translates into extremely efficient smart contract execution. The repository layout backs this up. There is a vm/ directory containing a v8vm/ subtree with prebuilt libjs and libv8 artefacts copied into the runtime image, and the Makefile carries per-architecture paths for _linux_amd64 and _darwin_amd64. This is a deliberate, heavy choice. A chain that embeds a full browser JavaScript engine gets a familiar language and a mature JIT-capable runtime, at the cost of a large native dependency, CGO, and a supported architecture list of exactly one.

## The node is a Go binary with an embedded native V8

The implementation is Go, with the module path github.com/iost-official/go-iost/v3, a Go version line of 1.27.2, and a package layout that reads like a blockchain node written by someone who ships production infrastructure. The top level separates account/, chainbase/, cmd/, common/, consensus/, core/, crypto/, db/, ilog/, iserver/, itest/, iwallet/, metrics/, p2p/, proto/, rpc/, script/, sdk/, test/, tools/, verifier/ and vm/. The build is driven by a Makefile with named targets, and the base targets are:

```bash
build: iserver iwallet itest

iserver: $(eval SHELL:=/bin/bash) 
	$(GO_BUILD) -ldflags "$(LD_FLAGS)" -o $(TARGET_DIR)/iserver ./cmd/iserver
```

The three binaries are the node itself, a wallet named iwallet, and an integration test binary named itest, and the Makefile sets the build flags that stamp build time, git hash and code version into the binary at link time. The three Dockerfiles, Dockerfile, Dockerfile.dev and Dockerfile.run, cover the runtime and development images, and the runtime one is short enough to be worth reading in full because it shows exactly what a node image contains.

```dockerfile
FROM ubuntu:26.04

# Install project
WORKDIR /workdir
COPY target/iserver target/iwallet target/itest ./
COPY vm/v8vm/v8/libjs/ ./vm/v8vm/v8/libjs/
COPY vm/v8vm/v8/libv8/_linux_amd64/ /lib/x86_64-linux-gnu/
COPY config/docker/iserver.yml /var/lib/iserver/
COPY config/genesis/ /var/lib/iserver/genesis/

ENV PATH="/workdir:${PATH}"
CMD ["iserver", "-f", "/var/lib/iserver/iserver.yml"]
```

The prebuilt V8 shared library and the V8 engine itself are copied into the image, along with the node configuration and the genesis files, and the container simply runs the iserver binary with a configuration file. Note the base image, Ubuntu 26.04, and the architecture specific path for the engine.

## Building and running a local network with make targets

The development workflow is described in four make targets, run from the repository root. You build local binaries into target/ with make build, start a local development network with make debug, build a node runtime image with make devimage followed by make release_image, and build a development node image with make devimage, make dev_image_tag and make image. The documentation is explicit that make debug uses config/iserver.yml, and that mainnet deployments need their own configuration and a persistent data directory, which is the sentence that separates a local test chain from a real network. The environment requirements are listed with equal care. The OS must be Ubuntu 22.04 or later, Go 1.27.2 is what CI and the development Docker image use, and the Docker base OS is Ubuntu 26.04 for development and node images. The limitation is stated right after them, and it is the one constraint that shapes everything else, since the IOST node uses the CGO V8 JavaScript engine and currently only supports the x64 architecture. There is no arm64 build path documented here, which rules out an Apple silicon host without emulation and out of most ARM server fleets.

## Sub second blocks, fast finality, and transactions that cost nothing

The performance claims are the platform's pitch, and they are specific enough to be worth quoting precisely rather than paraphrasing loosely. The project states that IOST delivers high throughput with thousands of transactions per second, and that while maintaining that scalability it employs a more decentralised consensus mechanism than DPoS, delegated proof of stake, to balance performance against centralisation. Block time is 0.5 seconds and finality is 0.5 minutes, so a transaction is confirmed in under a minute, and the project argues that this rapid finality is what makes real time applications possible. The third feature is the one that changes how you design an application. Transactions are free. Users stake coins to acquire gas, which removes transaction fees from the user experience entirely. For a consumer dApp that is a significant design lever, because fee mechanics usually force you into metered, awkward flows. The dependency list also shows a serious engineering foundation rather than a demonstration project. The module requires libp2p for peer to peer networking, gRPC and gRPC gateway for the service interfaces, Prometheus client for metrics, Viper and Cobra for configuration and the command line, LevelDB for storage, snappy for compression, secp256k1 libraries for signature handling, and a go-chart library for the built in charts. The repository also carries a metrics/ directory and a proto/ directory for the interface definitions.

## Where the platform stops being the right choice

Two boundaries matter and both are structural. The first is the V8 dependency combined with the x64 only restriction. A JavaScript engine embedded in the chain is a large native dependency that has to be compiled and shipped, the node needs CGO, and the Makefile has per-architecture paths for Linux and Darwin but only for amd64, and the Linux build additionally enables the race detector for tests. Any plan that involves ARM servers, an Apple silicon host, or a managed platform without a custom image is a plan the project does not currently support. The second boundary is that this is one chain's node, not a general purpose blockchain library. There is nothing here you point at your own chain and configure. If your requirement is a smart contract platform with a familiar language, the alternatives differ in kind rather than in details. A chain with a purpose built virtual machine gives you a smaller, more predictable node and a smaller trusted computing base, at the cost of a language your developers may not already know and an execution model you have to learn. A chain built on the Ethereum virtual machine gives you the largest tooling and library ecosystem, and inherits its performance characteristics and its state model. The choice of IOST is defensible when fast finality, free transactions and JavaScript contracts matter more to your product than ecosystem size, and it is hard to defend when the opposite is true.

## Conclusion

Adopt go-iost if you are building a dApp on IOST and want to write contracts in JavaScript with the V8 engine rather than a custom VM, and you are prepared to run a node with CGO enabled on x64. Do not adopt it for a general purpose chain, since the V8 dependency and the x64 only limit narrow where it runs, and do not expect a plug and play developer experience. Before you start, read the environment requirements, plan for a Linux host on Ubuntu 22.04 or later with Go 1.27.2, and decide whether you need the mainnet configuration and a persistent data directory, because the development configuration in config/iserver.yml is for a local network only.

## FAQ

### What is go-iost and what is unusual about it?

It is the official Go implementation of the IOST blockchain, and the unusual part is that the V8 JavaScript engine is integrated directly into the chain, so smart contracts are written in JavaScript. The project presents this as a developer experience benefit, since JavaScript is widely known and V8 is fast.

### What are the environment requirements for building go-iost?

The OS must be Ubuntu 22.04 or later, Go 1.27.2 is what CI and the development Docker image use, and the Docker base OS is Ubuntu 26.04. The node uses the CGO V8 engine and currently only supports the x64 architecture.

### How do I run a local IOST development network?

From the repository root, `make debug` starts a local development network using config/iserver.yml. Mainnet deployments need their own configuration and a persistent data directory. Other targets build local binaries with `make build`, and the image targets are `make devimage && make release_image` and `make devimage && make dev_image_tag && make image`.

### How fast are IOST blocks and what do transactions cost?

The project states a 0.5 second block time and 0.5 minute finality, so transactions confirm in under a minute. Transactions are free, with users staking coins to acquire gas instead of paying per transaction fees, and the chain targets thousands of transactions per second with a consensus mechanism more decentralised than delegated proof of stake.

### What licence does go-iost use?

The project is licensed under LGPL-3.0, and the module path in go.mod is github.com/iost-official/go-iost/v3 with the recent release line at 4.0.0. Because it is LGPL, if you modify and redistribute the node you owe the same licence terms for your modifications, so read the LICENSE file before vendoring it into a commercial distribution.

## Sources

- [iost-official/go-iost on GitHub](https://github.com/iost-official/go-iost)
- [License: LGPL-3.0](https://github.com/iost-official/go-iost/blob/master/LICENSE)
- [Project website](https://developers.iost.io/)
- [README](https://github.com/iost-official/go-iost/blob/master/README.md)
- [Releases](https://github.com/iost-official/go-iost/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/iost-official-go-iost