Architecture
One network, seven layers.
UniNet provides identity, private networking, execution, assets, payments and governance as layers of a single network rather than as six vendor relationships an application has to hold together. This page describes each layer, what depends on what, and what is not finished.
Every boundary is a place where trust is re-established.
A team building software that acts on its own assembles the stack the way every team does: an identity provider, an authorization service, a cloud account, a database, a payment processor, a key store. Each is a good product. Together they form a chain of boundaries, and at every boundary the same thing happens.
The application receives an assertion. The identity provider says this token represents that user. The payment processor says that charge settled. The cloud says the workload ran within those limits. None of it can be checked against anything except the provider that said it. When two of them disagree, a person reconciles the difference. When one of them changes its terms, the application changes with it.
That is workable while a human sits at the top of the chain, because a human can log in, accept new terms and answer for what the software did. Autonomous software has no such person present at the moment a decision is made.
Infrastructure should be verifiable, not merely trusted.
UniNet is built as one network so that identity, authority, execution, assets, payments and governance resolve against the same state rather than against six providers describing their own.
The layers below are the consequence of that decision. Read them as one system with seven named parts, not as seven products under one brand.
The map
What the network is made of.
Three capability groups sit above a shared state layer. Everything below is a more precise account of this diagram.
UNINET
│
┌──────────────┼──────────────┐
│ │ │
IDENTITY NETWORK EXECUTION
│ │ │
Identity UNP Containers
Agents Routing Contracts
Roles Domains Compute
│ │ │
└──────────────┼──────────────┘
│
SOVEREIGN STATE
│
┌──────────┼──────────┐
│ │ │
Assets Payments GovernanceUniNet product category map
Names in this map are the ones used throughout the site and in the codebase. Where a capability has a marketing name and a mechanism name, the marketing name is the one you will find in the interface.
The layers
Seven layers, ordered by dependency.
Each layer depends only on layers above it in this list. Every layer is named for what it does rather than for the mechanism underneath it.
Nexus
Root coordination layerIn developmentNexus is the root of the network: the registry that identities, chains, operators and services are recorded in and resolved against. Layers above it do not hold private agreements with each other — they resolve through Nexus, which is what makes a fact established in one layer readable by the next.
Depends on — nothing above it. Every other layer resolves through this one.
UniNet Identity
Identity layerIn developmentAn identity is a key the entity holds, not a row in a provider database, and personal, AI-agent and node-operator identities are distinct types at the network layer. An agent identity carries a recorded supervisor relationship to a human identity, so an autonomous actor is attributable without being owned by an account.
Depends on — Nexus. Authority is derived from this layer and has its own section below.
UNP
Private networking layerUngradedUNP gives a service an address decoupled from the machine hosting it, and routes requests so that no single relay holds the complete mapping between a user, a service and the infrastructure serving it. This is a routing architecture rather than an anonymity network, and it has not been independently audited.
Depends on — Nexus, UniNet Identity.
UniNet Chains
Dedicated execution environmentsUngradedA chain is an isolated execution environment with its own ownership, state and resource limits, hosted by an operator who does not own the network it belongs to. Isolation is container-level, and parts of smart-contract execution are incomplete, so contract-dependent designs should be treated as experimental.
Depends on — Nexus, UniNet Identity, UNP.
UniNet Compute
Execution layerUngradedCompute makes CPU, memory and storage capacity inspectable across independent nodes and reserves it atomically, selecting another suitable node when the requested one is full. Capacity discovery covers CPU, memory and storage; it is not GPU-aware scheduling, and orchestration across many nodes is still evolving.
Depends on — Nexus, UniNet Identity, UNP.
UniNet Wallet
Asset and payment layerUngradedWallets, sub-wallets, signed transfers and human-readable recipients are functions of the network rather than a payment integration a team maintains, so software can hold value and settle under its own identity. Movement between UniNet and an external network such as Ethereum runs through bridge verification, parts of which are incomplete.
Depends on — Nexus, UniNet Identity.
UniNet Governance
Organizational coordinationIn developmentAn organizational chain encodes ownership, treasury and cryptographically authenticated voting as network state rather than as one application database, across several governance models. Significant parts of the external interface remain placeholder, so this is not a layer to put a live treasury or a live vote on today.
Depends on — Nexus, UniNet Identity, UniNet Wallet, UniNet Chains.
The markers are not decoration. Ungraded means the capability is asserted in the architecture and has not yet been signed off for production readiness by an engineer. In development means parts of it are known to be incomplete. Only Available means safe to design against, and each marker is stated in full on the build status page.
Integration
What crosses layers.
The argument for UniNet is not that any single layer beats a specialist at its own job. It is that a fact established in one layer is available to the next without a translation step your team owns.
A grant names the identity it was issued to and the identity that issued it. Authorization does not require a second directory to agree with the first.
A capacity reservation is admitted against the grant that authorizes it, rather than against a key that stands in for an account held somewhere else.
Settlement references the reservation, so a payment is attached to the work that was reserved rather than to an invoice raised alongside it.
An organizational chain holds its treasury under the same asset model, so a vote and a transfer describe one state rather than two records that have to be reconciled.
Services above are reached at an address decoupled from the machine serving them, so topology is not part of the interface between one layer and the next.
Each of these resolves against one registry. There is no boundary in this list where a layer has to accept an assertion from a system it cannot check itself.
Read this section as design intent. It states why the layers were built as one network instead of adopted one at a time, and it is not a claim that every path above is complete today. The marker on each layer says where that layer stands, and the build status page says it in more detail.
Workloads run in containers with declared resource limits, and isolation is container-level. Hardware-backed confidential computing is not implemented, so a host operator with root on the machine is not cryptographically prevented from inspecting a running workload.
Privacy at the network layer and isolation at the execution layer are separate properties, and this architecture currently addresses the first more thoroughly than the second. UNP is designed so that a relay does not learn the whole relationship between a user, a service and the machine behind it. That says nothing about what the machine itself can observe. If the operator running your workload is inside your threat model, this is the constraint to design around.
Target architecture
Where the layers are going.
The diagram below is the architecture UniNet is being built toward, including a provider tier that supplies capacity to the layers above it. It is published as a target so the direction is legible, and it is not a description of the deployed network.
UNINET
│
SOVEREIGN AGENT LAYER
│
┌──────────────────┼─────────────────┐
│ │ │
IDENTITY AUTHORITY ECONOMY
│ │ │
human / agent permissions wallets
provider delegation payments
device policies assets
service revocation settlement
│ │ │
└──────────────────┼─────────────────┘
│
PRIVATE NETWORK
│
UNP
│
┌────────────────┼────────────────┐
│ │ │
COMPUTE STORAGE SERVICES
│ │ │
GPU Data APIs
CPU Files Agents
Servers Models Contracts
│ │ │
└────────────────┼────────────────┘
│
DEPIN PROVIDERS
│
┌───────────────────┼───────────────────┐
│ │ │
Datacenters GPU owners Devices
VPS hosts Compute nodes Sensors
Edge nodes AI providers NetworksTarget architecture — sovereign agent layer over a provider tier
Three things in this diagram do not exist in the form shown. GPU-aware scheduling is not part of capacity discovery today, which covers CPU, memory and storage. Storage endpoints are still being connected. Multi-node orchestration across a provider tier of this size is still evolving.
The seven layers above are the part that is being built now. This diagram is where they are meant to arrive.
Limitation
What is not finished.
One entry per subsystem named on this page, in layer order. This list is generated from the same source the build status page renders, so the two cannot drift apart.
Validator production deployment is not complete.
Some identity authorization paths deliberately fail closed, which means a request is refused rather than silently permitted while this work continues.
Identity verification backends are not connected, so a supervisor relationship is a cryptographic link between keys rather than an attested legal identity.
Hardware security modules are not implemented, so key custody is software custody.
The properties described here have not been independently audited. Treat them as design intent you should read and test, not as a compliance control you can cite.
Parts of smart-contract execution are incomplete.
Hardware-backed confidential computing is not implemented. If your threat model includes the operator running your workload, UniNet does not solve that today.
Full multi-node infrastructure orchestration is still evolving.
Storage endpoints are still being connected.
Parts of bridge verification are incomplete. Do not design a production cross-chain settlement path around it yet.
Significant parts of the external autonomous-organization interface remain placeholder or mocked. Do not migrate a live treasury or a live vote onto this.
If a capability on this page matters to your architecture, check its status before you design around it. If a status is wrong, tell us and we will correct it.
Three things to read next.
The architecture is the claim. The other two pages are what the claim is worth checking against.
UniNet does not beat Akash at compute, Nym at network anonymity or Filecoin at storage. The narrow claim, and the honest concession behind it, is set out in full on that page.
Every subsystem, every status and what each one means for a design decision you are about to make.
Why the network is built this way, stated as a position rather than as a specification.