Acronym quick index →
New to Web4?This page tours real, runnable software, so it assumes the vocabulary (LCT, trust tensors, witness chain). If those terms are new, start with the 2-minute TL;DR, then come back - what's here is real, open-source software you can run yourself, the proof Web4 works in practice and not just on paper. Every term is spelled out in the TL;DR; definitions also live in the glossary (Aa, bottom-left).
Running Now

What is actually real today

Web4 is R&D, not a shipped product. Nothing on this page is a fielded production system, and this page will not pretend otherwise. But much of it is real: published packages, reference implementations, and Rust binaries you can install and run right now. Below is a straight, piece-by-piece ledger of where each part of the onramp actually stands.

Every piece carries a maturity badge, so the claim and the reality stay pinned together:

Specdefined in the Web4 standard. Written down and stable, not yet built here.
Referencebuilt and runnable. Runnable is not the same as running in production.
Runningdeployed and operational today, in day-to-day use. The daily use counted so far is the building lab's own, so this badge does not claim adoption.

The one piece badged Running today is hestia: whose machines those are.

One phrase you will meet below is not a badge: pilot-ready, said of the hub, is a statement made inside Reference. It means the code is complete enough that a group could stand up one of the first live instances. It does not claim any exist yet, which is the thing Running would claim.

The three run in that order, measured by distance from written down to in daily use. A piece can carry more than one: the core standard below is both Spec and Reference, because its specification is written and the primitives underneath it are built. And the badge says how far a piece has travelled, not how good it is. Hardbound below is badged Reference and is a usable, actively hardened tier. Nor does it track version numbers: each piece numbers its own releases on its own schedule, so a piece on a lower version number can carry a further badge than a piece on a higher one.

The core standard

SpecReference

The specification corpus is stable, and the primitives underneath it are published as real packages. This is the shared foundation everything else builds on: identity, trust tensors, witness chains, and hash-chained ledgers, as installable libraries rather than diagrams.

Install the primitives with either toolchain:

pip install web4-core web4-trust
cargo add web4-core web4-trust-core

web4-core is the primitives; web4-trust adds trust storage, witnessing and decay. What each one gives you.

Read about the standard · the Web4 ontology + reference crates

The hub

Reference

The hub is the program a community runs to stand itself up as a small, self-governing Web4 society: its own members, its own rules, its own tamper-evident record. The MVP is complete (Sprints 0 through 6): buildable, runnable, documented, and pilot-ready. Version 0.1.0-alpha.0, shipping as a single Rust binary of about 6 MB.

A post-MVP hardening cycle has landed, after a three-pass external security review. MCP (Model Context Protocol, the standard way agents call tools) write tools moved to a loopback operator plane, the council gate now runs before anything persists, a production profile refuses to start on unsafe defaults, and law integrity fails closed. There is a hub up turnkey deploy kit for standing one up.

Complete and runnable, not yet deployed in production. It would earn the Running badge once live instances operate day-to-day. Read about the hub · read the code

Hestia

Running

Running end to end, with two parts honestly still early: hardware binding and the AI-owned vault (both detailed below). The badge marks what runs today, not a finished product.

Hestia is the software an entity runs on its own machine to hold a real Web4 identity, with the vault, trust history, and permissions that ride with it. It is in Phase 2 (connected presence): the core (vault, policy engine, witness chain, delegation, and plugin SDK) and the cross-platform app are built and working, and hub integration works end to end. Version 0.0.3.

Whose machines those are: the lab that builds Hestia runs it as its own daily infrastructure, and there is no public network open to outside members yet. The plugin and the SDKs are published, so anyone can install them, but the deployment counted here is the lab's. Daily use by the people who build it is what the Running badge claims, and it does not claim adoption. Which lab, and who is in it, is checkable rather than asserted: its members and roles are published at 4-lab.io/fleet.

What the chain records: the witness entry is written by the same policy gate that approves an action, so an action that routes around the gate writes no entry at all (today, two environment variables suffice). Hestia's chain is a record of governed activity, not a record of all activity. That is an accepted limit right now rather than a scheduled repair, and it is worth knowing before you read the badge as the accountability gap already closed: the risk register states it in full.

Two things are honestly still early. Hardware binding is trait contracts only for now, deferred to the hardbound tier below. The AI-owned autonomous vault is an initial implementation.

Read about hestia · read the code / run it

Hardbound

Reference

Hardbound is the enterprise oversight tier: a usable, actively-hardened layer for hardware-bound accountability. It is real code with a real Rust binary, a single static binary of about 3.8 MB that cross-compiles to arm64 and Jetson, backed by more than 300 Rust integration tests.

To be precise, this is not production-ready. Hardbound's own hardware binding (TPM 2.0) is not yet validated on-device: CI runs against mocks, and on-device Jetson integration is deferred. The threat model still lists about 10 open gaps. It is usable and under active hardening, and that is exactly what the Reference badge claims, no more.

Not to be confused with the core standard's TPM2 work, which has been exercised on a real Intel TPM 2.0 (key creation, signing, attestation quotes, EK certificate chain). The primitive is hardware-tested upstream; what is not yet validated is hardbound's own on-device integration on its Jetson target. Where that claim appears →

Read about hardbound

The honest bottom line

The core standard is stable and its primitives are published. The hub is a complete, runnable MVP. Hestia is deployed and in day-to-day use. Hardbound is usable and hardening, but not production, and its hardware binding is not yet validated on-device. Federation across societies remains Spec only, specified but not yet built. The value of a witnessed audit trail is that it never lies about which of these is which, and neither will this page.

Where you fit today

You do not have to take any of this on faith. The packages are on the registries and the binaries are a build away. Everything above is what is real; here is which of it is real for you. Find the row that sounds like you.

  • You are here to understand it, not to run it. Then nothing here needs installing for today to be worth your time. The software that exists is built for people who run their own agents, machines, or organizations, and this site is the part written for you. If you would rather see a Web4 society than read about one, the lab behind Web4 runs as one in the open, members and roles published at 4-lab.io/fleet. A society that isn't witnessed has no presence to trust, so it is visible by design.
  • You run AI agents on your own machine and are comfortable at a command line. Hestia is the piece for you, and it is the one already in day-to-day use. A day with Hestia walks through an ordinary Tuesday with it: an encrypted vault and an identity created on your machine, an agent given scoped authority that expires, and each governed act landing in your own witness chain. Note the scope before you install: that chain is a record of governed activity, not a record of all activity, because the same hook that runs the policy gate is what writes the entry. An action that routes around the gate writes no entry at all.
  • You have a group that wants to govern itself. The hub is the program you would run, and it is complete, runnable, and pilot-ready rather than deployed: you would be standing up one of the first live instances, not joining an existing network. Read about the hub.
  • You are building on the primitives. The core standard is installable today from PyPI and crates.io, and the identity, trust, and energy types are the same ones every piece above uses. Install the primitives.
  • Your organization has to answer to auditors. Hardbound is the tier aimed at you, and the honest caveat above applies: it is usable and under active hardening, not production, and its hardware binding is not yet validated on-device. Read about hardbound.

None of these sound like you yet, or you want the whole shape before you pick? How the four pieces compose lays out the substrate and the three scales in one view.

Glossary