# starcoin: a Move blockchain that scales by layering

> starcoin is a Rust implementation of a smart contract blockchain built on the Move language with a table extension feature, and its architecture is expressed as a Cargo workspace with dozens of small crates. The README is short and unusual in one respect: it tells you to compile the dev branch if you want to use it, while the default branch is called dual-verse-dag.

**starcoinorg/starcoin** — Starcoin - A Move smart contract blockchain network that scales by layering

- Repository: https://github.com/starcoinorg/starcoin
- Stars: 1,154 · Forks: 255
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/starcoinorg-starcoin

## Move, with tables as a first-class feature

Starcoin is a smart contract blockchain network that scales by layering, and the repository description calls it a Move smart contract blockchain network that scales by layering.

The technical sentence in the README is the one worth reading closely: net proxima using move with table extension feature. That is a working note rather than polished documentation, but it is the substance of the project. The chain is Move, and the thing that distinguishes it from other Move chains is the table extension, which is a way of storing structured data in a global table rather than only as values inside contract fields.

The rest of the README is short, and it contains a sentence that changes what using the project means. If you want to use it, you should compile the dev branch.

That is a notable thing for a project to tell you, and it interacts with the branching in the repository. The default branch is dual-verse-dag, the build badge points at the master branch, and the instructions point at dev. Three branch names in one project is a sign of an architecture in progress, and a user who needs a reproducible node should pin a tagged release rather than follow a branch tip.

The licence is Apache-2.0, the primary language is Rust, and the repository is not archived, with the last push on 2026-10-15.

## Which binaries ship, and which you build yourself

The binary file description is a table with a column that says whether the binary is included in the release archive, and that column is the most useful thing in the README.

Four of them ship. The starcoin command is the main CLI client and the entry point into the network, used to run a node or to connect to another node as an interactive console, with starcoin --help and a CLI reference for the options. The mpm command is the Move Package Manager, a tool to develop Move projects, described as being to Move projects what Cargo is to Rust or NPM to NodeJS. starcoin_miner is a CPU miner client, and starcoin_db_exporter exports or imports data to and from the database. starcoin_generator generates a genesis file or mock data.

The rest are marked as not in the release archive, and they are the operator tools. The airdrop tool does batch token transfers based on a CSV file. The genesis-nft-miner claims the GenesisNFT for the addresses listed in a file in the contrib-contracts directory. The starcoin-faucet provides a simple faucet web service. The starcoin-indexer creates an index on Elasticsearch for blocks and transactions. The merkle-generator produces merkle data from a detail CSV file of a distribution, for airdrop by merkle tree, and the resource-exporter exports resources.

That split is worth internalising. The release archive is the node and the developer tools, and the rest of the tooling is for people running a network of their own, which is a different job from running a node.

## The Cargo workspace is the architecture

The workspace member list in the Cargo.toml is a map of the system, and it is worth reading as one.

The commons/ directory holds the shared plumbing, and each entry is small: the logger, the metrics, the timeout join handler, the local, ipc and tcp RPC implementations, the API limiter, the accumulator, the forkable jellyfish merkle tree, the time service, the infallible helper, the pipeline timing, the service registry, the serde helpers and the stream task.

Then the domain crates. There is types with a uint module, genesis, the state/ tree with the state tree, statedb, the state store API and the state service, config, storage, consensus with a cryptonight-rs member, the testsuite, txpool with an api and a mock service, the executor with a benchmark, contrib-contracts, flexidag, and the chain/ tree with an api, a data migration, an open block, a mock, a chain notify and a service.

The network side is split into network-p2p with types, the peerset, the derive and core modules, the network package with its own types and api, and network-rpc. Accounts have an api, a service and a provider, and the rpc/ directory holds the api, the schema derive, the middleware, the client and the server.

The virtual machine is the vm/ tree, with types, the vm-runtime, the natives, the stdlib, the compiler and a move-prover crate, and there is a vm/move-package-manager directory behind the mpm command.

The resolution is set to 3 and the members list runs to well over a hundred lines, which tells you this is a full node implementation rather than a library.

## Toolchain, lints and the project conventions

The root files show the conventions of a project that came out of a large organisation's toolchain rather than a hobby.

There is a rust-toolchain.toml and a rustfmt.toml, so the compiler and the formatter are pinned for everyone. There is a clippy.toml, and separately a cargo-toolchain file and a cargo-flags file and a .cargo/ directory, which together mean the build is invoked in a specific way. The .envrc is for direnv, so the toolchain and the environment variables follow you into the directory, and flake.nix with a flake.lock gives a reproducible environment as well.

The continuous integration markers are bors.toml, the GitHub workflows including one named Build and Test, and codecov.yml with the coverage badge. There is a CODE_OF_CONDUCT.md, a CONTRIBUTING.md and a SECURITY.md, so the usual governance documents are all present, and a code_layout.md that explains where things live.

The container side has a docker/ directory and a .dockerignore, and the scripts/ directory holds the build and release helpers. The .gitmodules file means some dependencies are checked out as submodules, which is common when a project needs a specific version of a large dependency.

The directory names outside src/ are also informative. The chain/, node/, sync/, network/ and miner/ directories are the node itself. The account/ tree is the account model. The state/ tree is the state store, which for a chain with a table extension is where the interesting work sits. And the simnet/, stratum/, flexidag/, kube/ and benchmarks/ directories suggest a private test network, a mining stratum, the DAG implementation, a Kubernetes deployment and a benchmark harness.

## Reporting problems, and the split across repositories

The three issue links at the top of the README tell you how the project organises feedback, and the split is not what you would expect.

Bugs go to the starcoin repository, with a template named 01_BUG_REPORT.md. Feature requests go to the same repository with the 02_FEATURE_REQUEST template. Questions, though, go to a different repository entirely, starcoin-cookbook, with a 02_QUESTION template.

The reason is not explained, but the pattern is common in blockchain projects: the repository is the implementation and the cookbook is the documentation, and questions are usually documentation questions. It is a sensible routing, though it means a user looking for the question link has to notice that it points elsewhere.

The repository also carries a SECURITY.md, so there is a defined route for a vulnerability report, and a CODE_OF_CONDUCT.md for conduct issues.

The rest of the documentation is in the docs/ directory and the release artefacts come from the release.toml configuration and the scripts/ directory, with the release archive containing the binaries described in that table.

## The release names say more than the version numbers

The release history is short, and the tag names are the interesting part.

Version 1.13.21 is titled Starcoin v1.13.21, Height-gated block permits, and v1.13.22 is the plain version title, from 2026-08-24. The third tag, halley-secp256k1-sign-03 from 2026-01-22, is not a version at all but a named artefact with its own numbering.

Height-gated block permits tells you something about the chain design: a block carries a permit that is only valid up to a certain height, which is the kind of mechanism a chain uses to bound how far a piece of off-chain work or a signature remains usable. The halley tag suggests a named signing scheme, and the fact that it has its own sequence rather than a version number implies it is released independently of the node.

The dates are informative in the other direction. Two of the three releases are from August 2026, and the last push was on 2026-10-15, so the tree is moving while the version numbers have not obviously advanced. That is consistent with the README's instruction to compile the dev branch, and it is a project where the branches and the tags carry different amounts of meaning.

## Conclusion

Adopt starcoin if you are building on Move and want a network that treats the table extension as a first-class feature rather than an experiment, and if you are prepared to track a development branch rather than a tagged release. Do not adopt it as a general smart contract chain to run, because the documentation is thin on the consensus and the node model, and the releases carry feature names like height-gated block permits that need reading. Before you start, compile the dev branch as the README instructs, read the release notes for the version you intend to run, and look at the binary table to see which of the operator tools are actually shipped in the release archive rather than built from source.

## FAQ

### What is starcoin?

It is a smart contract blockchain network that scales by layering, implemented in Rust with the Move language, and the README describes it as net proxima using move with table extension feature. The distinctive part is the table extension, which is how the chain stores structured data in global tables.

### Which starcoin binaries are included in the release archive?

Four: the starcoin CLI client, the mpm Move Package Manager, starcoin_miner, a CPU miner client, and starcoin_db_exporter for importing and exporting database data, plus starcoin_generator for genesis files or mock data. Tools such as airdrop, the faucet, the indexer and the merkle generator are not in the release archive.

### How is the starcoin codebase organised?

As a large Cargo workspace. The commons/ directory holds shared plumbing such as the logger, metrics, RPC transports and the merkle tree, while the domain crates are genesis, state, storage, consensus, txpool, executor, chain, node, sync, network, account, rpc and the vm/ tree with the runtime, natives, stdlib, compiler and a move prover.

### How do I report a bug or ask a question about starcoin?

Bugs and feature requests go to the issue tracker of the starcoin repository, with the BUG_REPORT and FEATURE_REQUEST templates. Questions go to the separate starcoin-cookbook repository, and the project also ships a SECURITY.md for private vulnerability reports.

### How do I build starcoin?

The README says that if you want to use it you should compile the dev branch, and the default branch is dual-verse-dag. The toolchain is pinned with rust-toolchain.toml and rustfmt.toml, the environment comes from a flake.nix and a .envrc, and the build and test workflow is in the GitHub actions.

## Sources

- [Issues](https://github.com/starcoinorg/starcoin/issues)
- [License: Apache-2.0](https://github.com/starcoinorg/starcoin/blob/dual-verse-dag/LICENSE)
- [README](https://github.com/starcoinorg/starcoin/blob/dual-verse-dag/README.md)
- [Releases](https://github.com/starcoinorg/starcoin/releases)
- [starcoinorg/starcoin on GitHub](https://github.com/starcoinorg/starcoin)

---

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