Assets and payments

Value as a function of the network

UniNet treats an account as a property of an identity rather than a record held inside a payment provider. A wallet is a balance controlled by a key the holder already has. A transfer is a statement signed by that key and recorded by the network. No merchant account sits in that path, no third party issues the credential that makes the payment possible, and no company has to stand behind the payer as the entity of record.

That distinction is mostly academic while the payer is a person with a bank. It stops being academic the moment the payer is software. Identity gives an agent something to be; assets and payments give it something to hold.

The four primitives

| Primitive | What it is | Why it is shaped this way | | --- | --- | --- | | Wallet | A balance bound to an identity | The account and the actor are the same object, so a payment carries the identity of who made it rather than which credential was used | | Sub-wallet | A subordinate, scoped balance under the same identity | Isolates a budget without creating a second identity, a second key to guard, or a second reconciliation problem | | Signed transfer | A transfer authorized by the holder's signature | The authorization and the record are one artifact, not an approval in one system and a ledger line in another | | Human-readable recipient | A name that resolves to a recipient identity | Addressing is a naming problem; copying opaque strings between systems is where value goes to the wrong place |

The sub-wallet is the unit an autonomous component is normally given. Rather than handing an agent authority over the balance that also runs payroll, the holder opens a sub-wallet, funds it to a ceiling, and delegates authority over that sub-wallet alone.

Identity
   │
   ├── wallet          balance held by the identity
   │
   └── sub-wallet      scoped balance
          │
          └── delegation   what may be spent, on what, until when

The unit of account

UNE is the unit in which reserved resources are metered. A reservation names a quantity and a duration; both the reservation and its settlement are denominated in UNE. Everything on this page treats UNE strictly as that accounting unit.

| Reserved | Metered as | | --- | --- | | Compute | Allocated CPU held for the reserved period | | Memory | Allocated memory held for the reserved period | | Storage | Capacity held over time |

Reservation happens before the work. Capacity is claimed atomically against a node, as described in execution, and the amount it will settle for is known at the point it is made. Settlement refers back to the reservation, so metering is a property of something both sides agreed to in advance rather than a number the provider reads off a meter afterwards and asks the consumer to accept.

When the wallet belongs to an agent

| | Company account | Agent identity | | --- | --- | --- | | Payer of record | The company, with the agent acting on an issued credential | The agent | | What constrains spend | An issuing process, a budget alert, an invoice read later | A delegation evaluated at the moment the transfer is authorized | | Withdrawing the ability to spend | Rotate the credential, redeploy whatever holds it | Revoke the delegation; everything derived from it goes with it | | The record | A line in a provider's billing system | The signed transfer itself |

The consequence people notice first is that settlement happens without a human approval step. The approval did not disappear; it moved earlier. A human approves scope once, when the delegation is issued — a ceiling, the services or counterparties it covers, an expiry — and the network evaluates that scope every time the agent signs.

The alternative most systems run today is unbounded authority plus a human in the loop: the credential can do anything the account can do, and the only limit is that somebody is supposed to be watching. Bounded authority with no human in the loop is the more reviewable of the two, because the bound is written down and machine-checked rather than reconstructed after the fact from a spending history. That property belongs to delegated authority, not to the wallet; the wallet is what makes it economically meaningful.

How it composes

identity ──▶ delegation ──▶ sub-wallet
                                │
          reservation (CPU, memory, storage, duration)
                                │
                          work executed
                                │
                  signed transfer ──▶ provider identity
                                │
                          recorded state

The provider on the right is an identity as well, carrying its own reliability record at network level. The counterparty being paid and the counterparty whose delivery history is on record are the same entity, which is what makes selection and settlement two views of one relationship rather than two databases to reconcile.

An organization's treasury is this same primitive held by an organization instead of an individual. That is covered in governance.

Assets that originate on another chain

A bridge is a separate mechanism from the settlement path above. Value that originates outside UniNet has to be verified as it crosses, and verifying an external chain's state is a different problem from authorizing a transfer inside this one. Read them as two designs, not one continuous rail: everything described on this page is settlement internal to the network.