Networks that span very different hardware tend to fork their software. There is the server agent and the embedded agent, the full client and the light client, each with its own release cadence, its own bugs and, sooner or later, its own idea of the protocol. Forks are where interoperability breaks.
Tenzro takes a different line: one node source, built for every class of machine. A tier is not a separate program. It is a set of compiled features plus a resource preset. This post explains how that works, what the small build costs, and why small devices are worth including at all.
Tiers are builds plus presets
The network has four tiers of participant: edge nodes on small machines, standard nodes on CPU servers, GPU providers and validators. They come from three release variants of the same source.
| Tier | Machines | Build | Roles it refuses |
|---|---|---|---|
| edge | single-board computers (the Raspberry Pi is the reference device), Jetson-class modules, mini PCs, NAS boxes, gateways | light build, edge profile | ai, compute, tee |
| validator | servers that validate, store and relay | light build, release profile | ai, compute, tee |
| provider | servers that also serve models | standard build plus a GPU backend | none |
The build decides which roles a node can fill. The preset only sizes it. Keeping those two decisions separate is what lets one codebase stretch from a 2 GB board to a multi-GPU server.
The light build: leave the engines out
The standard build compiles in the model engines: the ggml runtime behind llama.cpp, media generation, adapter training and the ONNX runtimes, all behind a single Cargo feature that is on by default. The light build turns it off:
cargo build --release -p tenzro-node --no-default-featuresWhat remains is everything a node needs to take part without running models: hardware identity (including a remote-TPM client for machines with no TPM of their own), payments, the agent surfaces, RPC, MCP and A2A, consensus, storage and block sync.
A light node still answers model calls. A chat, completion, embedding, rerank, transcription or media request for a model some provider serves is forwarded to that provider, exactly as the standard build forwards it. What would run a model locally (loading one, training, hosting experts) is refused with an error naming the light build. Started with a model-running role, the light build exits before it opens any key or file. No silent degradation, no model running badly on the wrong hardware.
Going the other way, the provider build adds a GPU backend at compile time (CUDA, ROCm, Vulkan, Metal, SYCL and others), and a GPU build that finds no usable GPU refuses to start rather than running every layer on the CPU.
Presets: fit the machine you are on
The --tier setting takes auto, edge, validator or provider. auto picks provider for roles that run models, edge on a machine with at most 8 GiB of memory, and validator otherwise.
The edge preset bounds the storage engine to a sixteenth of the node's memory pool, between 32 MiB and 256 MiB, with smaller write buffers, one background compaction job, a paced background write rate of 16 MiB/s and fewer open files. In practice that is 96 MiB of store memory on a 2 GB board, 192 MiB on 4 GB and 256 MiB from 8 GB up. Background tasks are already gated by role, and the light build starts none of the model runtimes.
Disk is bounded by governance rather than presets: every non-archival node keeps the governed history window, prunes to it, compacts past a high-water mark and refuses non-essential data past a higher one. On an SD card or small eMMC, those watermarks are what keep a node inside its disk.
What we measured
We measured the builds against a small private network on an aarch64 server, with the node's memory budget set to emulate 2 GB and 4 GB machines. These are emulated limits on a larger host, not runs on a physical board, and the host was running other work, so CPU and sync figures carry noise of tens of percent.
- Binary size. The light build was 86.8 MB stripped against 132.4 MB for the standard build, 35% smaller. Optimising for size brought it to 62.2 MB.
- Memory. A light node following a chain that makes about one block a second held roughly 130 to 230 MiB of resident memory, idle and under a load of 40 RPC reads a second. That fits beside the operating system on a 2 GB board.
- CPU. Following the chain kept about one core busy on that host. That is block import, not idle overhead, and it is the figure to watch on older boards.
The release process checks every light build against a budget: 100 MB stripped, and 256 MiB idle and 320 MiB loaded resident memory.
Small-board realities
- Processor targets. A build tuned for the Raspberry Pi 5's Cortex-A76 uses instructions a Pi 4's Cortex-A72 lacks; build for the A72 to run on both.
- C library. A binary built against a newer glibc will not run on an older operating system image; build on, or pin to, the target's glibc.
- Storage. Use an SSD where the board takes one. Compaction is paced, but SD cards have low random-write rates.
- Identity. A Pi has no TPM. It keeps its identity key in another machine's TPM and signs through it, rather than falling back to a key file.
- Not yet built: 32-bit ARM and RISC-V. Their dependency trees resolve, but storage, cryptographic native code and the zero-knowledge verifiers have not been checked on those targets.
Why small devices belong in an AI network
It is fair to ask why a network about AI should care about machines that cannot run a large model.
- Orchestration is most of the work. Agents spend most of their steps routing, classifying, retrieving and checking. Those steps fit small hardware, close to where data originates.
- Breadth makes a network resilient. Thousands of inexpensive nodes following the chain, relaying and serving reads are harder to take down or capture than a few large ones.
- Data residency starts at the edge. A device on site can filter and redact before anything leaves the building.
- Energy and placement. A low-power board is the right machine to hold state and wait for events. A GPU is the right machine to run a large model when one is needed.
- One codebase keeps them honest. A small device runs the same consensus, identity and payment code as a validator, so it cannot drift into a dialect of the protocol.
Where Tenzro fits
Built: one node source with light and standard builds, GPU backends selected at compile time, edge, validator and provider presets with automatic selection, governed disk watermarks, remote TPM signing for boards without a TPM, and a release budget check for light builds. Planned: a small-GPU edge profile for Jetson-class modules and a harness-host profile for edge devices that host agent orchestration. Not yet built: 32-bit ARM and RISC-V targets. The network is live in preview; governance decides the steps to testnet and mainnet.
