Operating a node
Running a node
What a UniNet node puts on your hardware: an operator identity, published capacity, isolated containers, and a reliability record scored against the identity.
What a node is, from the machine's point of view
A UniNet node is one process you install on hardware you already administer. It publishes capacity you declare, accepts workloads bounded by that declaration, runs them as containers, and holds an identity that the network scores for reliability. It does not ask for shell access to the box, and it does not take over the host.
That distinction is the point of the design. The usual ask from a network that wants your hardware is broad - an account, an agent with wide privileges, and a workload whose shape you discover after it lands. A node instead gives a tenant a container with declared limits and gives you an operator identity that is a key you hold rather than an account somebody issues to you.
What sits on the machine
YOUR MACHINE - host OS, your root, your remote access, your other tenants
│
│ one process, installed by you
▼
uninet node
│
├──────────► operator identity
│ a keypair you hold; reliability is
│ scored against it, not against a listing
│
├──────────► published capacity
│ cpu · memory · storage
│ allocated shared or dedicated, your choice
│
├──────────► reservations
│ atomic; a request that does not fit here
│ can be placed on another suitable node
│
├──────────► workload containers
│ declared resource limits
│ start · stop · remove, locally
│
└──────────► metering and settlement
delivered capacity, addressed back to
the operator identity that delivered it
The questions operators actually open with
| Question | Answer |
|---|---|
| What runs on my machine? | The UniNet node, a single program, plus the workloads scheduled to it - hosted chains and containerized jobs, each declaring the resources it may consume. |
| Can it be isolated? | Workloads run as containers with resource limits and lifecycle operations. The boundary is the kernel's. You, holding root, are above it rather than outside it. |
| How much of the box does it take? | What you publish, and no more. A reservation is bounded by the capacity declaration it was placed against. |
| Shared or dedicated? | Your decision per machine. It is the lever that sets how much of a box is committed to one tenant. |
| Who measures reliability? | The network records it against your operator identity rather than inside one marketplace's database, so the record travels with the identity. |
| What if a tenant walks away? | A reservation is paid for by the day. A chain whose owner stops paying is frozen at the first unpaid day, and after fourteen your node frees the room. What those days cost stays owed by the chain. |
Isolation, stated precisely
Isolation is container-level. Resource limits bound what a workload consumes; the container boundary bounds what it reaches. Co-tenants are outside each other's boundary. The host operator is not - see the threat model for the full statement of who sits where. This matters to you in a direction operators sometimes miss: a tenant evaluating your hardware is being told plainly that you can observe their workload, and the network makes no claim to the contrary on your behalf.
Everything the host already does stays with the host. The operating system, the patch cadence, the hypervisor, the network operations, and any tenants you already serve are untouched by the UniNet node.
Capacity is published, not surrendered
Capacity enters the network as a declaration: CPU, memory, storage, and whether each pool is allocated shared or dedicated. Consumers query across nodes and reserve atomically, and a reservation that cannot be satisfied on a given node can be placed on another suitable one rather than failing outright. From your side the consequence is simple. Nothing is committed that you did not declare, and the declaration is the contract the reservation is checked against.
Reliability and settlement
Delivery is meant to be scored against the operator identity and paid to it. The scoring holds today: every block carries the signatures that committed the one before it, the chain records from them which validators took part, the same on every node, and your node's score comes from that record. A missed block costs ten times more when you did not declare maintenance on the chain at least an hour ahead. Your node's own key names your identity as its operator and your identity accepts, so the score is yours on every node, and placement skips nodes that score below 9,000 of 10,000 and prefers higher scores.
The payment holds too, and the chain makes it itself. The fees of each block go to the validators that signed it, one share each, and a share nobody earned is burned. A chain that reserves room on your node pays for it by the day, out of its owner's wallet, whether it uses the room or not. A storage tier's price goes to the node the account's storage is assigned to. Each is paid to your operator identity's wallet when one is bound to the node, and otherwise to the node's own wallet. What a node has earned, by kind, is chain state anyone can read. No UNE is created for any of it: what operators earn is what users pay.
Something is at stake as well. A validator needs 1,000 UNE locked behind it, its own or its operator's, and cannot withdraw it while it validates. A validator proven to have voted twice in one round loses half of it, burned, and its seat. Being offline is not slashed: it costs the node its reliability score.
What a delivered unit is worth is a separate and unfinished question. The rates a chain pays are settings of each network, fixed when it starts, and the development network's are placeholders for testing. This documentation publishes no yield figure, no percentage return and no earnings estimate, because UNE on a test network has no price and the parameters are not settled, and a number printed before they are is a number operators would plan against and be wrong about. Understand also what the network is today: capacity discovery is a protocol primitive, not a queue of paying jobs waiting to be claimed. There is no live consumer demand on the network. Publishing capacity does not by itself produce a tenant.
Size a first deployment as a technical pilot on a machine you can spare. If you need contracted revenue from the hardware this quarter, this is not that yet.
Onboarding
There is no self-serve operator portal, and joining is a technical conversation rather than a signup form. That conversation is short and covers what hardware you can commit and for how long, whether the machine can carry the UniNet node alongside what it already runs, what isolation your existing tenants require of you, and whether you want capacity published as shared, dedicated, or both. Deciding that UniNet is not worth your rack this quarter is a legitimate outcome of that call.
Once the machine is ready, it joins a running network without anyone rebuilding it. It
starts from the network file, follows the chain as an observer, and asks to validate by
signing with its own key. It locks 1,000 UNE behind itself, or is bound to an operator
identity that has; the current validators then vote it in, and it takes part eight blocks
later. The repository's scripts/validator-join.sh does the installation on an Ubuntu or
Debian machine. On a Linux desktop with KVM, the desktop installer does the same inside a
virtual machine, given a Linux node binary; its Windows and macOS versions are not finished.
On an Ubuntu (22.04 or newer) or Debian 12 server on x86_64, one line installs a node from the latest signed release and starts it as an observer of the hosted testnet:
curl -fsSL https://uninet.technology/install.sh | sudo bash
The script checks the release against the UniNet release key it pins before it installs
anything, reads the hosted testnet's network file (uninet.technology/network.json), and
ends by printing the node's wallet and the steps to validate. The faucet covers
the fees; the 1,000 UNE stake comes from someone holding UNE, such as the network's
operators. On a cloud that keeps the public address off the machine (AWS, GCP, Azure), pass
it with --ip; --auto-update installs each new signed release by itself, once a day.
To run the node under your own identity, give it with --operator (your identity id, or
@username); the UniNet app's My nodes page shows the whole line with yours filled in:
curl -fsSL https://uninet.technology/install.sh | sudo bash -s -- --operator @you --auto-update
The installer then prints a link to My nodes. There you send the new node the 1 UNE it needs for its fees; once synced it applies to validate and names your identity by itself, and you accept it on the same page and lock the 1,000 UNE stake behind it. No operator token and no copied ids.
How this composes
An operator identity is one of the identity types the network defines, alongside personal and agent identities - see identity. Consumers reaching a service you host do so through addressing that is decoupled from your machine, described under private networking, which is why hosting a service does not require publishing where it physically runs. Spending authority on the consumer side is bounded by delegated authority, which is what makes an automated counterparty something other than an unbounded one. Per-subsystem grades for everything named here are on build status.