Linera protocol: the crate stack, the local test network, and what the build leaves out

linera-base sits at the floor of the dependency graph

Linera is described as decentralized blockchain infrastructure for highly scalable, secure, low-latency Web3 applications, and this is the main repository for it, written in Rust under Apache-2.0. The way to read the tree is the ordering the README gives from low to high levels in the dependency graph. At the bottom sits linera-base, which holds the base definitions including cryptography, so everything above it assumes those types exist. Next comes linera-version, a library that manages version information in binaries and services, which is the piece that stops a running node and a talking client from disagreeing about what they are. Above that, linera-views maps complex data structures onto a key-value store, with the procedural macros in linera-views-derive. That ordering is the contract: if you add a crate, this is the list you slot it into.

Storage abstractions sit on top of linera-chain

Two crates carry the protocol and split along the same seam. linera-execution holds the persistent data and the corresponding logic for the runtime and execution of Linera applications. linera-chain holds persistent data and the corresponding logic for chains of blocks, certificates and cross-chain messaging. Above that, linera-storage defines the storage abstractions for the protocol on top of linera-chain, which is exactly the seam where a backend would be swapped. Above storage, linera-core is the core protocol, including client and server logic and node synchronization. linera-rpc defines the data type for RPC messages and tracks the corresponding data schemas. The word currently carries weight in that description, because the message set is scoped to the client, proxy, chain and chain interactions the project has implemented rather than to a general network protocol.

The quickstart assumes a compiled linera binary already on PATH

Nothing in the quickstart installs a toolchain. INSTALL.md holds the software requirements for developing in the repository, and the quickstart begins after you have built the binaries yourself. Five lines get you to a local test network with a number of microchains owned by the default wallet.

export PATH="$PWD/target/debug:$PATH"
source /dev/stdin <<<"$(linera net helper 2>/dev/null)"
linera_spawn \
linera net up --with-faucet --faucet-port 8080
FAUCET_URL=http://localhost:8080

The helper function linera_spawn is not a step you can skip. It is fetched through linera net helper and sourced into your shell, and running the network through it also defines LINERA_TMP_DIR, which is the directory every later path is built from. The faucet is given its own port and its URL is captured in a shell variable, because the wallet commands take it as a flag rather than discovering it.

Wallet, keystore and RocksDB paths all come from environment variables

Where a client keeps its state is decided entirely by three exported variables, and the quickstart sets them before creating anything.

export LINERA_APPLICATION_LOGS=true
export LINERA_WALLET="$LINERA_TMP_DIR/wallet.json"
export LINERA_KEYSTORE="$LINERA_TMP_DIR/keystore.json"
export LINERA_STORAGE="rocksdb:$LINERA_TMP_DIR/client.db"
linera wallet init --faucet $FAUCET_URL
linera wallet show

The storage value is not a plain path. It carries a rocksdb: prefix, so the backend is chosen in the string itself rather than in a config file. LINERA_APPLICATION_LOGS is a separate switch that turns on logging for user applications, which is a different stream from protocol logging. Once the wallet exists, request-chain hands back two values per call, and the quickstart splits them into a chain id and an account id, so a script that works with one microchain has to cope with the wallet tracking several.

The Makefile ships public demo infrastructure as its default

The Makefile is written for demos, and its defaults point at a shared bucket. NETWORK_NAME defaults to testnet-conway, PUBLIC_GCS_BUCKET is gs://demos.linera.net and PUBLIC_URL_MAP is demos-linera-net, and both GCS_BUCKET and URL_MAP are declared with ?= so a private deployment overrides them. DEMO_PATH is then built from the bucket and a network type that the Makefile extracts by searching the network name for testnet or devnet. Two consequences follow for a reader. The default target is help, so a bare make prints a usage box listing targets such as build-linera, check-deps, setup and check-gcloud-auth and changes nothing. And WALLET_DIR is created with mktemp -d, so every invocation gets a fresh wallet directory unless you export WALLET_DIR yourself.

cargo test skips linera-bridge because the contracts need solc

Cargo.toml defines a workspace of more than thirty members and then a shorter default-members list, and the difference between the two is commented in the file. linera-bridge is commented out of the defaults because cargo test requires solc, that crate is run separately in CI, and clippy covers it through a --workspace pass instead. The practical effect is that a green cargo test at the repository root says nothing about the bridge, and a contributor who assumes otherwise will ship a change that never compiled a contract. The workspace also reaches outside the Rust tree, listing web/@linera/client as a member. Around the workspace sit the usual development scaffolding: default.nix and flake.nix for a Nix shell, clippy.toml, .taplo.toml for formatting TOML, and a .devcontainer for a containerised editor.

SDK 0.15.23 on 2026-09-11, and a last push on 2026-09-18

The project is not archived and the last push landed on 2026-09-18, so Linera is actively maintained. Release tags tell a consistent story: Linera SDK v0.15.23 and v0.15.22 both shipped on 2026-09-11, and v0.15.21 on 2026-08-14. The version numbers sit in a 0.15 line rather than a 1.0, which is a signal about how the SDK surface is expected to move. The layer an application developer touches is linera-sdk, a library for writing Linera applications in Rust for the Wasm virtual machine, with its procedural macros in linera-sdk-derive, and linera-client, which is used by the command line client, by the node service inside linera-service, and by the web client in the separate linera-web repository. Licence is Apache-2.0.

The examples directory is a pnpm workspace beside the Rust crates

The examples tree is wider than a blockchain repository usually admits to, and it is not only Rust. Alongside the Rust crates sit package.json, pnpm-lock.yaml and pnpm-workspace.yaml, plus a playwright.config.ts, which means browser driven tests run across the sample applications. The applications themselves include counter and counter-no-graphql side by side, so the naming suggests the query layer is optional in the sample set, and there are separate trees for call-evm-counter, bridge-demo and ethereum-tracker for the Ethereum-facing work. Others are ordinary application shapes: amm, agent, crowd-funding, gen-nft, matching-engine, fungible, native-fungible, non-fungible and hex-game, plus a how-to directory for the smaller walkthroughs. Each example carries its own Cargo.toml, and the pnpm workspace is how the JavaScript side is stitched together.

Editorial conclusion

Linera suits an application team that intends to write its contracts in Rust against the Wasm SDK and is comfortable owning a Rust toolchain, a RocksDB client store and a fenced wallet. It does not suit anyone looking for a hosted chain with a support contract, or anyone who needs the workspace root cargo test to cover the bridge, because linera-bridge is excluded from the default members on purpose. Before writing a line of contract code, run linera net up, then confirm that the sdk version you pin against the published Linera SDK tags still matches the commit you have checked out.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes