Build status
What works today, and what does not.
Every subsystem, including the unfinished ones.
StatusLast reviewed by a person:
Available
22 subsystemsGraded by reading the implementation, its tests and the binary that calls it.
| Subsystem | Status | What that means for you |
|---|---|---|
| Element and token model | Available | The primitive the rest of the system is defined in terms of. Element and token definitions, the module registry and amount handling are settled enough to model against. |
| PBFT consensus | Available | Three-phase PBFT with Ed25519-signed votes, quorums that stay safe at any validator count, view change with prepared certificates, and checkpoints with watermarks. A validator votes only for a block it would apply to its own state. Running it as a production validator set is graded separately. |
| Storage endpoints | Available | State and blocks both persist through an encrypted disk backend, and the storage API serves real inclusion proofs against the node state root. |
| Merkle state proofs | Available | A sparse-trie inclusion proof can be requested over HTTP and verified against a state root you already trust. |
| Smart-contract execution | Available | Contracts run on Wasmtime with every instruction and host call metered: they read and write their own storage, verify Ed25519 signatures and pay out only from their own wallet, never their caller's, users sign their own calls, and code the VM would not run is refused at deploy. Contracts do not call other contracts, and are built without bulk-memory, SIMD and tail-call instructions (for example for wasm32v1-none). |
| Container and chain isolation | Available | Contracts are sandboxed and each chain keeps its own ledger. On a Linux node with crun or runc, which the Docker image ships and uses when run privileged, every hosted app runs in an OCI sandbox with its own user, mount, pid and network namespaces, kernel-enforced memory, CPU and process limits, and only the outbound access its owner and the node operator's firewall rules for its chain allow, applied each time it starts. Without crun or runc, off Linux included, only the node admin's and operator-trusted owners' apps run, as plain processes, a chain with firewall rules runs none, and every app reports the isolation it actually got. |
| .unp domain registry | Available | A .unp name is held for a 12-month term by a signed transaction that costs 50 UNE, and its holder renews it for the same price; when the term ends it stops resolving, and after a 30-day grace period anyone may register it. A name stays with the wallet that paid for it: names are not transferable, and the name's NFT is soul-bound. uninet-cli dns-verify proves who holds a name, and until when, against the validator keys you pin, trusting nothing the answering node says; a registration or renewal is provable from the next block. |
| Wallet and signed transfers | Available | A transfer is signed in the client app with the user's own key, and the chain checks the signature and nonce before any balance moves. A recipient can be named by username instead of an address. Sub-wallets are opened on chain, so every node lists the same ones: each is an address derived from its owner's key, its owner sends from it by signing, and it pays its own fees. |
| Identity authorization | Available | Admins, root holders, per-field grants, parent links and token gates are recorded on the chain beside the identities they name, so every node gives the same verdict, and the reason for it, over the identity API. The chain enforces writes itself: an identity granted a field updates it with a transaction it signs, and nobody else can. A change of roles is a transaction its maker signs. A parent link needs both the child and the parent to agree, and a child inherits what its parent was granted, never what it owns. Read and execute verdicts are for your application to enforce. |
| Delegated authority and cascading revocation | Available | An identity can pass a right on one field of an element to another identity, optionally onward and until an expiry, with a transaction it signs. The delegation is recorded on the chain, so every node sees it, and the delegate acts on it: it updates that field with its own signed transaction and the chain accepts it. Revoking any link, or the delegator losing the right, ends everything passed on from it at once, and a chain of delegations counts for at most eight links. |
| Autonomous organization governance | Available | Organizations, their votes and their treasuries are kept on the chain, so every node holds the same ones and only a transaction a member signs changes them. An organization moves between the six governance types by the whitepaper's thirty transitions, each made only by the act it names: a member vote, a shareholder vote or the sitting authority. A vote's electorate is fixed when it opens, and a vote that passes authorises the one change it was opened for, once. Joining locks a deposit that leaving refunds, so a roll cannot be filled with free identities. Treasury spends, the admission policy, the deposit and acts on elements as the organization's own wallet execute, by the authority for a right it kept or by a passed vote for a right released to the members. An authority of several people decides together: a share register by the shares of its holders, up to the voting threshold its founders agreed, and several representatives by a majority of them. A consortium goes live when all its founders agree to the same split, and every chain spawned gets its own organization. |
| Node operator identity and reliability scoring | Available | Every block carries the signatures that committed the block before it, and the chain records from them which validators took part, the same on every node. A node's reliability score comes from that record: a missed block costs ten times more when its operator did not declare maintenance on the chain at least an hour ahead, and a validator that stops signing is scored down everywhere within a few blocks. A signature that reaches the next leader late still counts; one a faulty leader leaves out counts as a miss until the view changes. The operator is bound from both sides: the node's own key names the operator identity and the identity accepts. Spawning, capacity substitution, replacement nodes and storage replicas skip nodes that score below 9,000 of 10,000 and prefer higher scores, and an idle chain still makes a block every minute, so a quiet network is measured too. |
| Onion routing and cell format | Available | Requests between validators travel over onion circuits: one relay at Standard, two at Private, three at High Security, whichever is stronger of the tier a domain's owner sets on the chain and the one the visitor asks for. One fixed-size cell names the relays with a fresh key for each, and the request and its reply carry one layer per relay in power-of-two size buckets, so no two links carry the same bytes. The request and the reply are padded to those buckets inside their seal as well, so the last step to the host shows a bucket too: 1 KiB at least, and 4 KiB at High Security. At High Security every relay also holds a cell for up to 150 ms each way, and every node sends cover: at random intervals, a request for nothing that travels as a visit does, which no relay can tell from one. Relays publish their records on the chain and rotate their onion keys daily. Any node with 1,000 UNE staked behind it may relay, a validator or not, and the chain keeps the whole list, so a client can check that no relay was left out. A node uses a relay only after the relay proves its key at its address, and a Private or High Security circuit needs relays under different operators, each with a stake behind it, in different networks, or it is refused rather than shortened. A relay that cannot pass a request on says so under its own layer, and the request is retried around it. |
| UNP private addressing and routing | Available | The desktop app finds a site and builds its own circuit of one to three relays, checking the relay list and the site's records against the validators' keys, so the node it connects through carries only sealed cells and never learns which site is visited. The host never learns the visitor's address, no relay sees the domain or the content, and only the last relay knows the host. A domain's owner sets on the chain how many relays its visitors go through, and can have a site hosted hidden: the chain then names a service key and the relays the site is met at, not the node that hosts it, and the host reaches those relays over a circuit of its own. A transaction a user signs through a validator leaves it over a circuit to another validator, which passes it on as its own, so the other validators cannot tell which node it came in through. A site keeps one path for ten minutes, and a request no circuit carried is refused: it goes through the visitor's node only if the visitor turns that on. A page shown in the desktop app may load only UNP addresses, and runs no script at High Security. In a web browser the app builds its circuits the same way, on an address of the site's own, and says there that this is the weaker of the two. |
| Validator production deployment | Available | Validators check the signature on every consensus message, count quorums that stay safe at any validator count, journal what they sign so a restart cannot make them sign twice, keep their message logs bounded with checkpoints, and replace a lost leader by view change. One script stands a network up across VPSes and another reports its finality and failover. On the hosted testnet, five validators on four rented servers and a laptop behind a home router, a transfer is final on every server a median of 75 ms after it arrives (p95 92 ms, 20 samples), and with any one validator stopped the others go on making blocks. Validator keys are as trustworthy as the genesis configuration that lists them. |
| Dynamic chain spawning | Available | Spawning a chain is a signed transaction any identity can submit, naming the validators that run it. The primary chain records every chain, and its validators start it when they apply that block, so a spawn that fails starts nowhere and a validator that was offline starts it when it catches up. The chain runs its own PBFT, keeps its history encrypted and brings a validator that fell behind back up to date. Its owner holds an NFT as proof, changes who runs it (a validator joins only with its own consent), and can freeze and unfreeze it. Its fees, in its own token, go to its validators, and what it reserves on them is charged to its owner by the day: a day left unpaid freezes it. |
| Multi-node infrastructure orchestration | Available | Validators join and leave a running network by a vote on chain. A node applies with its own key, a quorum of the current validators votes it in or votes a validator out, and the change takes effect eight blocks later on every node. Validators find each other through the addresses they publish on chain, and scripts install a validator on a server, join it, or remove it, on a local devnet or a testnet of rented servers; one line from this site installs a node on a server from the latest signed release. A test with five nodes running as real processes runs four validators, a fifth that joins from the network file, one validator switched off and voted out, and an observer that syncs across both changes. On the hosted testnet a laptop behind a home router joined the four servers this way as the fifth validator, reaching them over a private overlay network with no port open at home. |
| Distributable client (CLI / SDK) | Available | A command-line client, and the Rust library it is built on, reach a node over the encrypted UNP tunnel and verify every response signature. They read the chain, check who holds a name and which relays exist against the validators' signatures, and act with a key of their own: make a key, register its identity, and sign transfers, name registrations, stakes and any other transaction a node prepares, showing each transaction before it is signed. The key file is the client application's recovery file, so a key made in the terminal opens in the application. |
| Operator reward economics | Available | Every chain pays the fees of each block to the validators that signed it, one share each, and a share nobody earned is burned. A validator has 1,000 UNE locked behind it, its own or its operator's, and one proven to have voted twice in a round loses half of it and its seat. A storage tier's price goes to the node that stores for the account, and a chain that reserves room on its hosts pays them for it by the day, out of its owner's wallet; an unpaid day freezes the chain. No UNE is created for any of this: what operators earn is what users pay, and each node's earnings, by kind, are chain state anyone can read. |
| Resource discovery and atomic capacity reservation | Available | What a chain reserves is recorded on chain. Every node that will run the chain sets the CPU, memory and storage aside in one step and signs a grant of it; the spawn, or the owner's later change, carries those grants, and each of those nodes holds the amount as the chain's pool from the block that records it, and again after a restart. The owner pays those nodes for it by the day. A node that is full is passed over for the next most reliable one. Apps draw CPU and memory allocations from the pool on the node they run on, as operating-system limits where the host can apply them. Only the node that asked for a hold can give it back, and nothing but the chain's record releases a pool. |
| Devnet faucet | Available | The faucet form on this site asks the hosted testnet's first node for test UNE, for a wallet address or a username, which the node looks up as it does for a transfer. This site signs each request with a secret the node shares, and the node sends the grant from its operator wallet: one grant per wallet and three per visitor in any 24 hours, within a daily cap, without the node running in insecure mode. |
| Public network access for external developers | Available | A node outside the validator set can join a network as an observer. It boots from the network file a validator writes, finds peers through a public swarm kept apart from the validators' own network, syncs every block and checks each against the validators' signatures, and passes on the transactions its users sign. No private traffic reaches that swarm, and the command-line client can pin a node's key to the network file. The hosted testnet publishes its network file at uninet.technology/network.json, and a node that knows only that file syncs to the newest block in seconds. |
In development
2 subsystemsRuns in part. The row matters more than the heading.
| Subsystem | Status | What that means for you |
|---|---|---|
| Bridge verification (Ethereum) | In development | Checking of signed validator attestations (Ed25519, two-thirds quorum, replay window) and lock-and-mint escrow are implemented in the interop crate, and the node runs an operator-only bridge registry with validator rotation and slashing. Nothing yet carries messages or assets between UniNet and Ethereum. |
| Desktop node installer | In development | On Linux with KVM, the desktop app installs a real node. It fetches Flatcar Container Linux and checks it against the SHA-512 its release publishes, then creates a virtual machine whose node joins the network a network file names. It then shows the node's wallet, balance and standing, and has the node apply to validate. A rehearsal with KVM runs the same code without the screens against a four-validator network. The node syncs, is funded, applies, is voted in and signs blocks, and keeps its identity across a shutdown and a new boot. |
Not implemented
7 subsystemsDoes not exist today. If one is a requirement, say so in the first conversation.
| Subsystem | Status | What that means for you |
|---|---|---|
| Configurable governance models and member roles | Not implemented | Organizations defined by configuration rather than by the six types: member roles with a scope and a term, votes weighted by role, which roles may put a question, a ceiling on what a decision may release from the treasury, and voting rules the members amend under the rule in force, with a member's rights on elements derived from membership as delegated authority that ends when membership does. The design the governance page describes. Plan without it for now. |
| Delegated spending under a ceiling | Not implemented | An agent spending from a sub-wallet under a delegation, bounded by a ceiling, the services or counterparties it covers and an expiry, with the bound checked when each transfer is authorized: the design the economy and authority pages describe. Plan without it for now. |
| Zero-knowledge proofs, verifiable secret sharing, threshold signatures | Not implemented | These were implemented, found to be unsound, and removed rather than shipped. Nothing in the system relies on them today, and no design should. |
| Identity verification backends | Not implemented | Nothing in the system checks who a person is, and every identity is recorded as unverified. Do not plan flows that require an externally attested human identity today. |
| Hardware security modules | Not implemented | No key can be held in a hardware security module today. A deployment whose rules require HSM-backed key management is out of scope until one is. |
| Hardware-backed confidential computing | Not implemented | There is no trusted execution environment, enclave or threshold-MPC backend anywhere in the system, and hosted apps run in an OS-level container sandbox on the operator's own kernel. An operator with root on the machine is inside the trust boundary. |
| Independent security audit | Not implemented | The privacy and isolation properties described on this site have not been through an independent audit. All security review so far is the project's own: dependency checks in CI, plus fuzz harnesses that a developer runs by hand. |
Before you commit
Tell us which row is blocking you.
In development or not implemented? Talk to an engineer before you design around it.