Hosting on Machines You Do Not Own

Running a workload on hardware owned by a company you have no contract with sounds like a legal problem and is mostly an engineering one. A single cloud provider answers a set of questions implicitly, in the account model and the contract: who this operator is, what they committed to, what happens when they fail, who pays whom, and what they are permitted to see. Spread the same workload across machines owned by parties who share no owner and every one of those answers has to be produced somewhere else.

That is the actual subject of decentralized hosting. Not ideology about cloud concentration — the coordination work that a provider relationship used to absorb, and where it goes when there is no provider relationship.

The problem

A distributed set of hosts gives you redundancy against a single operator's outage. It also gives you a set of counterparties with no shared reputation system, no common billing relationship, no scheduler that can see all of them, and no agreed definition of what "delivered" means. Most projects rebuild that layer themselves: a providers table, a reputation table, a payments table, a permissions table, and a scheduler that trusts its own database.

The result is a marketplace with a database in the middle. The operators are independent; the coordination is not.

The principle

If hosts are independent, the coordination between them has to be network state rather than one company's table. An operator's identity, the capacity they advertise, the reservation you hold against it and the record of what they delivered should be things any participant can reference — including the next marketplace, and including you when you decide to leave.

The architecture

Provider identity. A node operator is a cryptographic identity, not an IP address. Public key, advertised capacity, hosted services, payment address, and a reliability record accumulated against that identity. Because the record attaches to a key rather than to a marketplace account, an operator's history is portable and so is your ability to check it.

Capacity allocation. Scheduling across independent hosts needs two operations that a single provider gives you for free: query CPU, memory and storage across candidate nodes, and reserve atomically so two schedulers cannot both win the same capacity. Where the requested node cannot satisfy the reservation, the request falls back to another suitable node rather than failing the deployment.

Isolated workloads. Each hosted chain or container runs isolated, with its own resource limits and lifecycle operations. The distinction matters to the operator as much as to you: it turns the product from "give a stranger shell access to my machine" into "sell a bounded slice of capacity", which is the only version of this that an operator with other tenants can responsibly offer.

Addressing separated from hosting. UniNet's private networking layer is designed so a service is reachable at an address decoupled from the machine serving it, and so routing splits knowledge across relays rather than concentrating it in one. The intent is that no single relay holds the complete relationship between the client, the service and the physical host.

What the operator can and cannot see

This is the section most decentralized hosting material omits, and it is the one that decides whether the architecture fits your threat model.

Designed not to be visible. The full path from a client to a specific machine running a specific application is split across relays by design, so a single relay is not intended to hold the whole relationship. Infrastructure topology is not published as a side effect of making a service reachable.

Visible to the operator, today. Isolation here is container-level. An operator with root on the host is inside the trust boundary, not outside it. Process state, memory and anything your workload writes to that machine are within reach of the person who owns it. So are the coarse signals that resource accounting produces: how much you are using, when, and in what pattern. Hardware-backed confidential computing is not implemented, so there is no attestation you can hold up to say otherwise.

The practical rule: encryption in transit and at rest is your responsibility to arrange, and a workload whose plaintext must never be observable by the machine's owner does not belong on this substrate yet.

Two claims worth retiring

An earlier version of this post described the blockchain as coordinating parties who do not know each other with no trust required at all. That phrase is doing no work. Coordination between strangers here still rests on assumptions, and they can be named: that key custody in software is adequate for your risk, that container isolation holds against the host, that the operator's advertised capacity is real, and that an implementation nobody has independently audited behaves as described. Naming four assumptions is more useful to an architect than asserting zero.

The same version claimed censorship resistance as a property. The accurate version is narrower. An operator can stop hosting your workload at any time, for any reason. What changes in this model is that no single party's decision removes the service from the network, provided suitable capacity exists elsewhere and your deployment is built to move. That is a property of your architecture as much as of the network.

Pricing follows the same discipline. Capacity that already exists being sold is a different cost structure from capacity being provisioned, but reward economics on UniNet are not finalized and there is no live consumer demand on the network yet. No cost comparison would be defensible at this stage, so none is published here.

Limitation

Hardware-backed confidential computing is not implemented, and if your threat model includes the operator running your workload, UniNet does not solve that today. Hardware security modules are not implemented, so key custody is software custody. Full multi-node infrastructure orchestration is still evolving, which makes large deployments unsupported for now. Storage endpoints are still being connected, so storage-dependent flows are not production paths. Nothing described here has been independently audited. Several of the capabilities above are graded Ungraded on build status: asserted in the design documents, production readiness not signed off by engineering. That page carries the current state of every subsystem and the date a person last reviewed it against the codebase.

What this supports

The parts that are coherent now are the supply-side primitives: an operator identity with a reliability record, capacity that can be discovered and reserved atomically, and workloads that run bounded rather than as shell access. A team building a DePIN network can reference those instead of writing the fifth implementation of a providers table, and spend its own engineering on the thing that is actually differentiated — the scheduler, the workload, the market design.

If you have machines rather than workloads, the operator side is described at run a node. The system view, including how addressing, identity and settlement fit together, is on architecture.