Identity

What an identity is

An identity in UniNet is a key the holder controls and a record in network state that other layers resolve against. There are three first-class types — personal, AI agent and node operator — and they are separate types rather than one record carrying a role attribute. The difference matters because each type roots a different kind of claim, and the network has to be able to tell them apart without asking an application.

The three types

| Type | What it roots | What attaches to it | | --- | --- | --- | | Personal | Original authority. It is not derived from any other identity. | Keys, wallets and sub-wallets, delegations issued, ownership of chains and organizations | | AI agent | Held authority. Every right it has names the identity that issued it, and its record names a supervising personal identity. | Wallet, grants held, service endpoints, workloads owned, interaction history | | Node operator | Infrastructure. It binds an operator to the capacity it advertises and the record of how that capacity was served. | Advertised capacity, hosted services, payment address, reliability history |

Why not one record with a role column

Most systems arrive at the role column honestly. You have a users table, agents show up, and role is one migration instead of a redesign. It works until the network has to reason about the distinction.

A role is an attribute of a table, owned by whichever service last wrote it. Two services can hold two answers, and nothing above them can adjudicate. A type established at the network layer is resolvable by any party that can resolve the identity at all, including a party that has never spoken to your application.

The three differ in structure, not in label. A personal identity is a root of authority. An agent identity is never a root: what it holds was issued to it, and its record names the issuer and the supervisor. That is a different shape — an edge that has to exist — not a flag with a different string in it. An operator identity accumulates delivery history that would be meaningless on either of the others. A single record with a role column has to carry the union of three shapes and enforce, in application code, which fields are legal for which value.

Attribution degrades when they are collapsed. Ask what an agent did and who stands behind it. With three types, both answers are properties of the identity record. With one type and a role column, both answers are a join across application tables, and they are exactly as reliable as the application that wrote them — which is the application you were trying to audit.

Role columns get edited. A type is established at creation and is bound to cryptographic material. Changing what an identity is means creating a different identity, which is the correct amount of friction.

The supervisor relationship

An agent identity is created in relation to a personal identity, and the relation is recorded at the network layer rather than inside whatever system operates the agent.

Concretely, the link is a cryptographic association between keys. The supervising identity signs; the association is recorded in network state; any party that resolves the agent identity can resolve the link and check that signature for itself. That is what lets an autonomous actor be attributable without being a subordinate account of a platform. The agent holds its own key and acts under its own name, and the record says which identity stands behind it.

Read the link precisely, because its strength is also its boundary. It establishes that the key controlling identity A vouched for the key controlling identity B. It carries no claim that A corresponds to a named legal person in a jurisdiction — that is a separate assertion, produced by an attestation layer, and the association does not stand in for one. A design that needs regulated onboarding or jurisdictional proof needs that second thing explicitly.

PERSONAL IDENTITY
      │
      │  supervises ── signed association, recorded at the network layer
      ▼
AGENT IDENTITY
      │
      ├── wallet and sub-wallets
      ├── authority held — each grant naming its issuer
      ├── service endpoints, reachable over UNP
      ├── chains and workloads it owns
      └── interaction history

Identity is what everything else resolves against

This is the concrete part. Every other primitive names an identity rather than a machine, an account, or a key pasted into a configuration:

• Authority. A delegation names an issuer identity and a holder identity. See authority.
• Assets. A wallet is owned by an identity; sub-wallets partition it under the same owner.
• Network. A UNP address resolves to a service registered by an identity, decoupled from the host serving it.
• Execution. A chain or workload records the identity that owns it and the operator identity running it.
• Operators. Reliability history accrues to the operator identity, so it belongs to the operator rather than to one scheduler's database.

The payoff is that withdrawal has somewhere to land. Because everything downstream names an identity, revoking a right at the identity is a single operation whose effect propagates to everything derived from it. Where an agent is a row with a role and a key in a secrets manager, the same intent is a search — across services, for credentials you hope were all recorded.

One property to carry into your threat model: an identity is exactly as strong as control of the key behind it. Where that key lives, and who can reach it, is part of your design rather than a detail the identity layer settles for you.