Sovereign infrastructure for autonomous software

Infrastructure for Autonomous Software

Identity, authority, private networking, execution, assets, payments and governance are properties of one substrate.

UniNet gives autonomous agents, applications and organizations sovereign identity, private networking, programmable authority, execution and native economic coordination.

Read the architecture What works today

Under active development — see exactly what runs today

Image needed

hero-console

Product UI. The console showing one agent identity: its linked human supervisor, and an active delegation with a spend cap, allowed service class and expiry. Real interface, real values — this is the single highest-value image on the site.

2400 × 1400

An agent identity, its human supervisor, and a live delegation

The shift

AI gave software intelligence. UniNet gives software infrastructure to act independently.

Agents reason, call tools, execute workflows and move money. The layers beneath them still assume a human is present: identity lives in one provider, authorization in another, execution on a third, payment in a fourth. Each one assumes an account holder who can log in, accept terms and be held accountable.

Autonomous software cannot be truly autonomous while everything beneath it remains dependent.

Six accounts, five trust boundaries — or one continuous relationshipA two-column comparison. Left column, Human-mediated: six stacked boxes — Human, Application, Cloud, Database, Payment provider, Identity provider — each one marked account. The link between every pair is cut by a hairline running past the edge of the column, giving five trust boundaries: five separate relationships, each owned and revocable by a different provider, and each assuming a human who can log in, accept terms and be held accountable. Right column, Autonomous: the same capability collapses to three — Agent identity; UniNet; and execution, assets, payments and settlement — strung on one unbroken rail with no handoff between them. The right column describes the model UniNet is built around rather than a claim that every part of it is production-complete; the build status page carries maturity per subsystem.

Requirements

Autonomy requires more than intelligence.

An autonomous system needs eight things it does not get from a model.

Agents need more than modelsAn autonomous agent is assembled from seven inputs, drawn as seven equally sized boxes in a row. The model is one of them — the first box, marked as the part you bring yourself. The other six are infrastructure: identity as keypairs, authority as delegation, memory as durable state, execution as containers, payments as settlement, and network as routing. A bracket spans those six and only those six, labelled UniNet. The model and the bracket drop onto a shared bus and resolve through an equals junction into one terminal node, the autonomous agent. Memory is drawn with a dashed outline because its storage endpoints are still being connected, and multi-node network operation is still evolving.

01Identity

Every actor should have an identity it actually controls. Something the entity holds a key to, not a row in someone’s user table.

02Authority

Permission should be an enforceable property of the system. A rule the network evaluates, not a prompt instruction.

03Execution

An isolated environment with declared resource limits.

04Communication

Reachability that does not publish the machine behind the service.

05Assets

Ownership the network recognizes without a custodian.

06Payment

Settlement between two machines with no human approval step.

07Verification

A record of what happened that either party can verify independently.

08Governance

Rules for multi-party decisions enforced by the network rather than by trust.

The substrate

UniNet provides the substrate.

Three planes over one shared state layer. Identity, network and execution resolve against the same record that holds assets, payments and governance.

UniNet product category mapUniNet resolves into three planes: Identity, containing identity, agents and roles; Network, containing UNP, routing and domains; and Execution, containing containers, contracts and compute. All three planes resolve against a single shared sovereign state layer, which carries assets, payments and governance.

Target architecture: the provider layer

This tier is target state, not deployed state. It describes the supply side UniNet is designed to resolve against once multi-node orchestration and storage endpoints are connected. Read it as the direction of the architecture, not as capacity you can reserve today.

DePIN supply tier — target stateA target-state architecture, not a deployed system. UNP, the private network, fans out into three resource classes: compute, covering GPU, CPU and servers; storage, covering data, files and models; and services, covering APIs, agents and contracts. Those resource classes in turn draw on a tier of DePIN providers — datacenters, GPU owners and edge nodes. Everything drawn with a dashed outline is not built: no provider supply is deployed on the network, storage endpoints are still being connected, and multi-node orchestration is still evolving, so there is no live consumer demand to allocate against. Only UNP and the compute and services resource classes are drawn solid.

Capacity discovery across CPU, memory and storage is a network primitive rather than a marketplace database. GPU-aware scheduling is not part of it. Multi-node orchestration is still evolving, and there is no live consumer demand on the network to allocate against. Check the status of each subsystem before you design a supply path around this diagram.

Pillars

Five properties, one network.

Each pillar is a layer of the same substrate rather than a product you integrate. The marker states how far the implementation has been graded.

Sovereign Identity

Every actor should have an identity it actually controls.

UniNet defines personal, AI-agent and node-operator identities as distinct types. An agent identity carries a supervisor relationship to a human identity, recorded at the network layer. Verification backends are not yet connected.

In development

Identity layer

Programmable Authority

Permission should be an enforceable property of the system.

Rights are delegated with cryptographic signatures, restricted in scope, and revoked with immediate cascade to everything downstream.

Ungraded

Authority model

Private Execution

Your infrastructure should not reveal everything about what it runs.

Private by architecture: UNP separates users, relays and serving machines so no single relay holds the complete mapping between a user, a service and the machine hosting it. This is a design property, not an audited one, and it is not a general-purpose anonymity network.

Ungraded

UNP and routing

Native Economy

Software should be able to own and move value.

Wallets, sub-wallets, signed transfers and human-readable recipients are functions of the network rather than a third-party integration.

Ungraded

Wallet layer

Sovereign Coordination

Organizations should be able to encode their rules into infrastructure.

Organizational chains define ownership, treasury and cryptographically authenticated voting across several governance models. The external governance interface is in development.

In development

Governance layer

The wedge

Agents that consume decentralized infrastructure.

An agent needs compute. It has a budget, not a credit card. It has an identity, not an account. This is the reference implementation we are building, end to end.

Twelve-step reference flow — not yet end to endA reference design, not a working demonstration: this flow does not run end to end today. An autonomous agent buying decentralized compute travels one rail through four phases. Identity: 01 create an agent identity with a linked human supervisor; 02 receive delegated authority bounded by maximum spend, allowed service class, duration and expiry. Discover: 03 search available compute across nodes; 04 evaluate providers on capacity and node reliability score; 05 select a provider against a declared policy rather than a hard-coded address; 06 reserve compute atomically. Execute: 07 send the workload privately over UNP rather than to a published address; 08 execute it in an isolated container with declared resource limits; 09 receive the result back at the agent identity. Settle: 10 verify the transaction against recorded state; 11 pay the provider by signed transfer from the agent wallet; 12 record the interaction as cryptographically recorded state. Steps 03 through 08 are drawn as dashed outlines, and the rail between them is drawn plain rather than accented, because multi-node orchestration and capacity reservation are still evolving.

Create identity

Agent identity with a linked human supervisor.

Receive delegated authority

Max spend, allowed service class, duration, expiry.

Search available compute

Query CPU, memory and storage across nodes.

Evaluate providers

Capacity and node reliability score.

Select a provider

Selection against a declared policy, not a hard-coded address.

Reserve compute

Atomic reservation; another suitable node if full.

Send the workload privately

Reached over UNP, not a published address.

Execute in isolation

Container with declared resource limits.

Receive the result

Returned to the agent identity.

Verify the transaction

State checked against the record.

Pay the provider

Signed transfer from the agent's wallet.

Record the interaction

Cryptographically recorded state.

Image needed

delegation-refused

Product UI, close crop. The moment a transfer exceeding the delegated limit is REFUSED by the network. The refusal is the differentiator — anyone can show a payment succeeding. Show the limit, the attempted amount, and the denial.

1600 × 1200

A transfer over the delegated limit, refused by the network

In this design, no human creates an account, approves an API call or releases the payment. The agent is the economic actor. Each step is designed as a network primitive rather than an integration your team maintains.

This flow does not run end to end today. The status of each step is published on the build status page.

Infrastructure for agents What works today

Mechanisms

How it actually works.

Seven mechanisms, stated at the level an architect can evaluate.

UNP routing, and what each hop can seeA request travels left to right from a user through three relays to a service. Each hop carries a note for what it can see and what it cannot: the user sees a service name but not the machine behind it; relay 1 sees the user but not the service; relay 2 sees neither end, only the next hop; relay 3 sees the service but not the user. No single relay therefore holds the whole mapping between user, service and infrastructure. Below the service, a dashed line marks that the service address is not derived from the machine serving it: the two are bound logically, not by host location. The serving machine is deliberately drawn sighted. Its operator can see what runs there, because hardware-backed confidential compute is not implemented, which the diagram shows as a dashed panel inside the machine labelled not implemented. This is a routing architecture that splits knowledge across relays, not an anonymity guarantee, and the privacy properties have not been independently audited.

UNP

Private addressing and routing. A service receives an address disconnected from its physical machine; relays do not hold the complete user–service–infrastructure mapping.

Containers

Each hosted chain or workload runs isolated, with resource limits and lifecycle operations.

Identity types

Three first-class identities: personal, AI agent, node operator. Agent identities carry a supervisor relationship.

Wallets

Signed transactions, sub-wallets and human-readable recipients at the network layer.

Unit of account

Transfers and resource settlement are denominated in the network’s native unit.

Resource reservation

Available CPU, memory and storage are inspectable across nodes; capacity is reserved atomically, with automatic selection of another suitable node when the requested one is full.

Bridges

Asset and message transfer between UniNet and networks such as Ethereum. Parts of bridge verification are incomplete. Do not design a production asset path around this row yet.

Build status

What works today, and what does not.

We publish the status of each layer, including the parts that are unfinished.

UniNet is under active development. Some layers run; some are partially connected; some are specified and not yet built. Identity authorization is deliberately fail-closed: where the verification backend is not connected, the request is refused rather than allowed.

If a capability matters to your architecture, check its status before you design around it. If the status is wrong, tell us and we will correct it.

Subsystem build statusBuild status across all 21 tracked UniNet subsystems, drawn as a single bar divided in proportion to how many subsystems hold each status. Available: none. In development: 8 — External governance / AO interfaces; Smart-contract execution; Validator production deployment; Bridge verification (Ethereum); Storage endpoints; Multi-node infrastructure orchestration; Identity authorization; Operator reward economics. Ungraded: 8 — Node operator identity and reliability scoring; Resource discovery and atomic capacity reservation; Container and chain isolation; Wallet and signed transfers; Delegated authority and cascading revocation; UNP private addressing and routing; Public network access for external developers; Distributable client (CLI / SDK). Not implemented: 5 — Identity verification backends; Hardware security modules; Hardware-backed confidential computing; Devnet faucet; Independent security audit. No subsystem currently holds Available status, so that span of the bar is empty; the drawing marks the zero rather than showing a sliver. The Not implemented span is drawn as a dashed ghost because it stands for capability that does not exist yet. Last reviewed against the codebase on 2026-08-28.

21 subsystems tracked. Ungraded means the capability is asserted in the architecture but its production readiness has not been signed off by an engineer. Last reviewed against the codebase on 2026-08-28.

See the full build status

Audience

Who this is for.

Three kinds of team, one shared problem: the layer beneath the application assumes a person is holding the account.

Agent infrastructure

You are building autonomous software that needs to authenticate, hold permissions, reach services privately and pay for what it uses.

DePIN and decentralized infrastructure

You are building a compute, storage or network protocol and would rather not implement identity, permissions, routing, payments and governance yourself.

Privacy-sensitive infrastructure

Your application cannot expose its infrastructure topology or its user relationships, including to the operator hosting it.

Infrastructure for agents Where UniNet fits

For operators

Datacenters, VPS providers, GPU owners and node operators host chains and isolated workloads. Capacity is allocated as shared or dedicated, and each operator carries a reliability score.

Run a node

For developers

Talk to a node, not to a stack of providers.

The design intent is one interface. An application or an agent connects to a node, and identity, permissions, private addressing, execution, assets and payments resolve against the same network. The alternative is what most teams run today: six providers, six trust boundaries, and the integration code holding them together.

We are not publishing a quickstart or an install command until one runs to completion on a machine with no prior UniNet state. Public network access for external developers and a distributable client are both ungraded on the build status page. Until they are graded, the architecture is the honest entry point — read it, and if the primitives match what you are building, tell us what breaks.

Read the architecture Talk to an engineer

What works today Where UniNet fits Architecture notes

The UniNet principle

Autonomous software cannot be truly autonomous while everything beneath it remains dependent.

Software should be able to operate independently. That means identity it controls, authority that can be programmed, and infrastructure that can be verified.

Infrastructure for software that operates independently.

Talk to the team Read the manifesto