Core model
Assets and payments
Wallets, sub-wallets and signed transfers as network functions, and what changes when the account holder is an agent identity rather than a company.
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. Today a sub-wallet is opened on chain and spent from by its holder's own signature, and it pays its own fees; an agent spending from it under a delegation is delegated spending, which the status table grades on its own.
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.
Today the settlement is a daily charge. A chain that reserves CPU, memory and storage on the nodes that run it pays each of them for it by the day, at rates fixed when the network starts, out of its owner's wallet and with no step for anyone to approve: the first block of each day takes the charge and pays the hosts. A day the wallet cannot cover freezes the chain until its owner pays what it owes, and after fourteen unpaid days the reservation ends and the hosts free the room. Transaction fees take the same route to the nodes: each block's fees go to the validators that signed it. No UNE is created for either.
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.
What is not finished
No transfer consults a delegation: delegation covers read, write and execute on the fields of an element, and only a wallet's own key moves its funds. Until this is built, the only bound on what an agent can spend is how much its sub-wallet holds.
Only tests call the proof verifier and the escrow. For bridge messages to go through them, bin/uninet-node would have to call them, and today its relay endpoint only records a message hash in memory, which is lost on restart. There is no Ethereum client, relayer or light client, so no asset can cross. Light-client proofs are always rejected, and Merkle roots are never checked against Ethereum. Do not design a production cross-chain settlement path around it yet.