Documentation

What UniNet is

UniNet is a sovereign infrastructure network for autonomous software. It gives applications, AI agents and organizations an identity they hold the key to, authority that is delegated and withdrawn at the network layer, private addressing, isolated execution, and native assets and payments — as properties of one substrate rather than as six vendor integrations a team wires together and maintains. The premise is narrow and testable: an autonomous actor needs more than a model and an API key, and the things it actually needs are infrastructure, not library code.

What this documentation is not

Before anything else, so you find it here rather than three pages in:

There is no public install path, no SDK reference and no quickstart in these pages. There is no publicly reachable network endpoint to write one against. A command, an endpoint or a config sample published under those conditions would be invented, and invented interface documentation costs more trust than the gap it papers over. When the network is externally reachable and there is a distributable client, a quickstart follows — written against whatever actually answers, and no earlier.

Also absent by choice: benchmarks, capacity figures, named customers and yield numbers. None of them would be measured.

What it is

The concept model. One page per primitive: how it is shaped, why it is shaped that way, and how it composes with the primitives around it. This is the durable half of a system's documentation and the half worth evaluating before you commit. An interface is learned in an afternoon. A model that is wrong about identity or delegation is not fixed by better reference pages — it is fixed by rebuilding, usually after the design has already spread through your application.

Subsystem status is not written into the prose of these pages. It comes from a single table that the site reads, rendered onto each page as a status chip and a limitation block. A page therefore cannot claim more than that table states, and when the table changes, every page changes with it.

The sections

| Section | What is in it | | --- | --- | | Start here | Orientation and scope. This page. | | Concepts | One page per primitive, explaining the model rather than an interface. |

Read the concept pages in this order:

1. Identity — the three first-class identity types, why they are types rather than a role attribute, and what the supervisor relationship between an agent and a human records.
2. Authority — delegation as a property of the network: what a grant carries, how it is issued, and what cascading revocation does that key rotation does not.

Identity comes first because every other primitive resolves against it, and authority second because it is derived from identity and is the primitive most of the interesting designs actually turn on.

Where the rest of the system is described

| Page | | | --- | --- | | Architecture | The seven layers — Nexus, UNP, Identity, Chains, Compute, Wallet, Governance — in dependency order, with the status of each. | | Build status | The single status table. Implemented, in development, not built, and ungraded. The most useful page on this site if you are deciding whether to build on UniNet. | | Where UniNet fits | Against adjacent systems, including the cases where UniNet is the wrong choice. |

How to read a claim on this site

Every capability statement here is meant to be checkable against the status table, and the two are deliberately kept apart: the body of a page describes a model, the chip describes what exists. If you find a page where the prose is ahead of the chip, the prose is the error. That separation is the reason this documentation can be read at face value, and it is worth more than any individual claim inside it.