Build status
What works today, and what does not.
We publish the status of each layer, including the parts that are unfinished.
How to read this page
One file drives every status on this site. This page renders all of it.
UniNet is under active development. Some layers run; some are partially connected; some are specified and not yet built. Identity authorization is deliberately fail-closed: where the verification backend is not connected, the request is refused rather than allowed.
If a capability matters to your architecture, check its status before you design around it. If the status is wrong, tell us and we will correct it.
This page exists because of what it costs you to find a gap late. A limitation you read here costs an afternoon of planning. The same limitation found halfway through an integration costs a quarter. We would rather publish the gap than have you discover it.
Each row states a design decision, not only a shortfall. Fail-closed authorization is a choice: a request that cannot be resolved is refused rather than quietly permitted. Container-level isolation is a boundary we can describe, so we also describe where it ends. A limitation without the decision behind it is not useful to an architect, and this page is written for architects.
Vocabulary
The four status values
Every subsystem below carries exactly one of these. There is no fifth value and no partial credit.
| Status | What it means | What to do with it |
|---|---|---|
| Available | A person has read the subsystem against the running code and signed that it behaves as described. | Design against it. If it behaves differently than the row says, that is a defect on our side and we want to hear about it. |
| In development | The subsystem exists and runs in part. Coverage, interfaces or failure behaviour are still moving. | Read the row before you use it. Prototyping against it is reasonable. Making it load-bearing is not, yet. |
| Not implemented | The subsystem does not exist today. There is no partial path and no flag to enable. | Plan as though it will not be there. If your architecture requires it, tell us early rather than late. |
| Ungraded | Our own design documents assert the capability. No engineer has graded its production readiness. | Read it as unverified. Ask what the subsystem does today before you write a dependency on the description. |
Status is carried by the word, not by colour alone. Every chip prints its value as text — Available, In development, Not implemented, Ungraded — and the marker beside it differs in shape as well as in hue: filled, split, outlined, dashed. The page reads the same in monochrome.
Not implemented is set in neutral grey, never in red. Red would read as broken. These are stages of a build, and a stage that has not started yet is not a fault. Amber is reserved elsewhere on this site for value transfer, so it appears here only on work that is genuinely in flight.
Available
0 subsystemsNo subsystem has been graded Available yet. Available is not a description of ambition. It means an engineer has read the subsystem against the running code and signed that it behaves as this page describes, and nothing has been through that review.
If you are designing against UniNet today, read that literally: there is no row on this page you can treat as settled. Everything below is either in development, not implemented, or asserted in our own documents and not yet graded. Work with the note on the row you care about, and talk to us before you make any of it load-bearing.
It also sets a ceiling on what we are willing to write elsewhere. An empty group here is the reason the rest of this site describes UniNet as protocol primitives under construction rather than a platform you can adopt this quarter.
In development
8 subsystemsThese subsystems exist and run in part. Interfaces, coverage and failure behaviour are still moving, so the row matters more than the heading. Read the one you depend on.
| Subsystem | Status | What that means for you |
|---|---|---|
| External governance / AO interfaces | In development | Parts of the interface are still placeholders. Do not build production governance flows against it. |
| Smart-contract execution | In development | Parts of execution are incomplete. Treat contract-dependent designs as experimental. |
| Validator production deployment | In development | The network is not yet operating as a production validator set. |
| Bridge verification (Ethereum) | In development | Parts of verification are incomplete. Do not move value you cannot afford to have stuck. |
| Storage endpoints | In development | Endpoints are still being connected. Storage-dependent flows are not production paths. |
| Multi-node infrastructure orchestration | In development | Orchestration across many nodes is still evolving. Treat large deployments as unsupported. |
| Identity authorization | In development | Some authorization paths deny by default when they cannot resolve. That is deliberate. It is not a guarantee that every path fails closed. |
| Operator reward economics | In development | Reward parameters are not finalized. No yield figure would be defensible at this stage, so none is published. |
Not implemented
5 subsystemsThese do not exist today. There is no partial path, no flag and no staging environment where they behave differently. If one of them is a requirement rather than a preference — hardware-backed key custody and an independent audit are the two that most often are — say so at the first conversation. It is the fastest way to find out whether UniNet is the wrong choice for you this year.
| Subsystem | Status | What that means for you |
|---|---|---|
| Identity verification backends | Not implemented | Verification backends are not connected. Do not plan flows that require an externally attested human identity today. |
| Hardware security modules | Not implemented | Regulated and public-sector procurement asks for HSM-backed key management. Without it, those deployments are out of scope. |
| Hardware-backed confidential computing | Not implemented | Isolation is container-level. A host operator with root on the machine is inside the trust boundary, not outside it. |
| Devnet faucet | Not implemented | The faucet page is published, but it is not yet connected to a devnet. Requests cannot be served until that connection is wired. |
| Independent security audit | Not implemented | The privacy and isolation properties described on this site have not been through an independent audit. |
Asserted, not yet graded
8 subsystemsOur strategy and architecture documents assert these capabilities. They say nothing about production readiness, and neither will we until an engineer has graded each one against the running code. Publishing any of them as Available without that sign-off is exactly the failure mode we set out to avoid: a claim that outruns the build, made by the people least able to see the gap.
A capability being described elsewhere on this site is not the same as a capability being graded here. Where a page and this table disagree, this table is the one to trust. Ungraded is not a soft yes. Read it as: we have not checked, so you should not assume.
| Subsystem | Status | What that means for you |
|---|---|---|
| Node operator identity and reliability scoring | Ungraded | Provider reliability is recorded at network level rather than inside one marketplace database. |
| Resource discovery and atomic capacity reservation | Ungraded | Query CPU, memory and storage across nodes and reserve atomically, with fallback to another suitable node when the requested one is full. |
| Container and chain isolation | Ungraded | Workloads run isolated, with resource limits and lifecycle operations. Isolation is container-level only. |
| Wallet and signed transfers | Ungraded | Signed transactions, sub-wallets and human-readable recipients are available to build against. |
| Delegated authority and cascading revocation | Ungraded | Rights can be delegated, restricted in scope and revoked, with the revocation cascading to everything derived from it. |
| UNP private addressing and routing | Ungraded | A service is reachable at an address decoupled from the machine hosting it, and routing is designed so no single relay holds the complete relationship. |
| Public network access for external developers | Ungraded | Whether you connect to a hosted network or run your own node. This determines what the quickstart can honestly claim. |
| Distributable client (CLI / SDK) | Ungraded | What you install to build against the network. If only a node binary and RPC exist, the quickstart is written against RPC. |
Before you commit
Tell us which row is blocking you.
If a capability matters to your architecture and it is listed as in development or not implemented, do not design around it yet. Contact us before you commit to it.
The conversation is with an engineer, not a sales team. Bring the subsystem you are worried about and we will tell you what it does today, what it does not, and when we expect that to change. A correction from someone outside the team is worth more to us than a favourable row.