Chain
Execution
Isolated chains and containers with declared resource limits, capacity discovery across CPU, memory and storage, and atomic reservation.
What execution covers
Execution is where a workload actually runs: an isolated chain or container on hardware belonging to an operator the tenant has no contract with. That arrangement only works if two things are settled first. The workload has to be bounded, so it cannot consume the machine it lands on or reach its neighbours. And capacity has to be located and held before the workload is dispatched, so a deployment is not a request to a host that has already given the same cores away.
The unit of work
Two shapes of workload share one isolation model.
| UniNet chain | Container | |
|---|---|---|
| Purpose | a dedicated execution environment with its own ownership and state | a hosted workload |
| Resource limits | declared before it runs | declared before it runs |
| Isolation | container-level | container-level |
| Lifecycle | operations to start, stop and remove | operations to start, stop and remove |
The declaration is the part that carries weight. Limits are stated up front and are the same limits the reservation is made against, so what a tenant may consume is known before placement and what an operator gave up is countable after it. There is no runtime negotiation in which a workload asks for more than it declared.
What the sandbox enforces
On a Linux node with crun or runc installed, every hosted app starts in an OCI sandbox. The Docker image ships crun and uses it when the container runs privileged.
| Boundary | What the app gets |
|---|---|
| Identity | its own user namespace: root inside it is an unprivileged user on the host |
| Files | its own mount namespace: of the host's files it can write only its own work directory, and its /tmp is private to it |
| Processes | its own pid namespace; the app is killed with the node, and after a node crash the next boot sweeps what it left |
| Network | its own network namespace, reached only through its forwarded port, with the outbound access described below |
| Resources | memory, CPU and process-count limits from its allocation, enforced by the kernel's cgroups |
| System calls | a seccomp profile that refuses namespace, mount, kernel-module, tracing and similar calls |
Outbound access is decided each time an app starts. An app its owner started with deny_outbound gets a network namespace with loopback only and no route to any host. So does an app on a chain for which the node's operator has filed firewall rules, unless a rule for that app allows outbound access and none denies it: on such a chain an app no rule names is denied.
Without crun or runc, off Linux included, there is no sandbox. Only the node admin's and operator-trusted owners' apps run there, as plain processes under the node's own operating-system user; anyone else's app is refused, and so is every app of a chain with firewall rules, since a plain process could honor none of them. Each app reports the isolation it actually got, and the report never names a mechanism that was not put in place.
Capacity discovery
Discovery answers one question across independent nodes: what is available, and where. It covers three dimensions.
| Dimension | Discovered |
|---|---|
| CPU | available cores |
| Memory | available memory |
| Storage | available storage |
That list is exhaustive. Capacity discovery is not GPU-aware scheduling: accelerator class is not a dimension the discovery layer reasons about, so a workload that requires a specific GPU cannot be placed by this mechanism. Discovery also returns a set of candidates rather than a single answer, which is what makes the next step possible.
Reservation
Reservation is the commitment point, and it is recorded on chain. A request names the CPU, memory and storage a chain needs on each node that will run it. Each of those nodes checks its own free capacity and sets the amount aside in one step, so the same capacity is never promised twice, then signs a grant that names the chain and the amount. A node that cannot hold it is passed over for the next most reliable candidate. The spawn carries the signed grants, and the chain's record keeps the amount.
request: 1 CPU · 1 GB memory · 1 GB storage, on three nodes
│
▼
candidates ──▶ node A ──▶ holds it, signs a grant ─┐
node B ──▶ full: passed over │
node C ──▶ holds it, signs a grant ─┼──▶ the spawn carries the grants
node D ──▶ holds it, signs a grant ─┘ │
▼
the chain records the amount; A, C and D
hold it as the chain's pool from that block
From the block that records the chain, every node that runs it holds that amount as the chain's pool, and holds it again after a restart. The owner changes the amount with a transaction of their own, which takes a new grant from every node that runs the chain; a node that joins later sets the amount aside before it accepts. A promise nobody used is given back by the node that asked for it, or lapses within minutes, and nothing but the chain's own record releases a pool.
For a caller this changes what a deployment target is. Placement becomes the result of a query evaluated at the moment of dispatch, rather than a hostname written into a configuration file months earlier and hoped to still be correct.
Two limits should be read precisely. The record says what each node signed for: the chain does not measure the hardware behind it. And an app runs on the node it was started on. Coordinating one deployment across the chain's nodes (placement policy, failover between them, rescheduling after loss) is a layer above these primitives, and is not built.
What an operator sells
The distinction that matters on the supply side is that an operator sells capacity, not shell access.
| Arrangement | What the tenant receives | What the operator hands over |
|---|---|---|
| Machine or shell handover | a login on the host | administration of the machine, and an account to police |
| UniNet | a container bounded by its declared limits, for a declared period | the resources that were reserved, and nothing adjacent to them |
The operator keeps administering the machine the way they already do. A tenant's claim is bounded by the reservation and the container's declared limits, which means the end of a period is capacity reclaimed rather than a disagreement to resolve.
The isolation boundary should be read precisely. It is container-level and it is not hardware-backed. The host operator is therefore inside the trust boundary: they can observe what runs on their machine. A workload whose threat model includes the party executing it is not served by this model, and no arrangement of private networking in front of it changes that - routing conceals where a workload runs from everyone except the machine running it.
On the other side of the same transaction, a node operator is a cryptographic identity rather than an address. Delivery history accumulates against that key, so a scheduler can weight candidates by a recorded reliability signal, and that record remains referenceable outside whatever marketplace or scheduler produced it.
How it composes
A reservation is held by an identity, and so is the operator serving it. Both sides of a placement are keys rather than accounts in someone's database, which is what makes a delivery record portable.
Software that reserves capacity on its own behalf does so under delegated authority bounded in scope, spend and duration. An agent permitted to reserve compute is not thereby permitted to reserve without limit, and revoking the delegation cascades to what was derived from it.
Once running, the workload is reachable over UNP at an address not derived from the node that won the reservation - so the fallback described above is invisible to callers, who never held the host address in the first place.