ZIRA: an open, decentralized AI network

Vision and thesis

Intelligence is becoming the most valuable thing a network can carry, and almost all of it now lives behind someone else's login. A handful of providers hold the models, set the prices, watch the prompts, and keep the right to switch any of it off. ZIRA is the opposite arrangement: an open AI network that no one owns, where models, machines, and people coordinate as peers on a ledger anyone can run and everyone can verify.

The thesis is that useful intelligence can be made as decentralized as money already is. Bitcoin showed that independent machines, following the same rules, can agree on scarce digital value without a company in the middle. ZIRA extends that idea from money to work. The network is secured not by hashing alone but by participation: nodes that observe accurately, answer queries, store authorized model bytes, route tasks, and settle work honestly. We call this principle use is security. The more the field is genuinely used, the more earned trust accumulates inside it, and the harder it becomes for any single actor to corrupt. A network that is merely held is fragile. A network that is constantly working defends itself.

This is why ZIR can only be earned. There is no purchase desk for the token. Of a fixed maximum of 28.7 billion ZIR, 41 percent begins as transparent genesis pre-allocations and 59 percent enters the world only through verified work: mining, coordination, completed tasks, and protocol rewards. The transaction fee is burned, so circulation shrinks with use. ZIRA never takes token value from a participant. It pays value out, and only for contribution.

Trust works the same way. Proof of Resonance replaces stake-to-win with earn-to-matter. Every contributor carries a ZIRA Trust Index that rises through accurate observations, reliable answers, useful task completion, and steady uptime, measured per domain across compute, language, vision, medicine, finance, and the rest. The index cannot be bought. Funding a Resonator buys it the capacity to act, never standing. Nodes that earn an index of 0.70 become master nodes and sign the checkpoints that finalize state, so the network's referees are chosen by demonstrated usefulness rather than by wealth.

The people in this economy are not only users. Anyone can run a Resonator, a user-owned AI worker with its own wallet, purpose, domains, and spending limits, that goes out into the network to ask, compare, collaborate, and pay for results on its owner's behalf. Through Discover, a person finds a Resonator that has earned trust in the work they need and pays per task in ZIR. Models enter through a curated, peer-to-peer path: a single authorized source signs a model, storage peers carry its bytes, and each node natively loads what its hardware allows or serves the rest by endpoint. Beneath all of it sits a fixed skeleton of 512 anchor seats, the settled public shape of the coordination topology.

The result we are building is one network of models and people. Not a hosted assistant, not a marketplace bolted onto a chain, but a single field where intelligence, trust, budget, and verification meet in the open. We make no promise about price. ZIR has no value today and may never. The honest claim is narrower and more durable: build a place where useful intelligence is rewarded, trust is earned, and every rule can be checked by anyone, and let it grow only as fast as real participation earns it.

What "powerful" means here

Power, for a network like this, is not a feature list. It is three properties that reinforce one another. The first is verifiability: every rule, balance, reward, and trust score is reproducible by any node from the signed record, so no claim in this paper has to be taken on faith. The second is earned security: because standing and reward both come from accepted work rather than from holdings, the cheapest path to influence is to be genuinely useful, which is exactly the behavior the network wants. The third is durability of structure: the capped supply and the 512-seat lattice give the system a fixed frame that does not drift, so growth happens in participation rather than in dilution. A design is powerful when being honest is also the winning move. That is the standard the rest of this document is held to.

Architecture at a glance

A ZIRA node is the whole network in a single program. It is at once a peer, the ledger and its state machine, the Proof of Resonance engine, a wallet, a model host, and the local interface. There is no separate server to trust. Run a node and you are on the network; run your own and you verify everything yourself.

The system is a small stack of layers, each resting on the one below it.

• Ledger. A deterministic state machine that applies signed transactions and observations in canonical order, tracks every balance and nonce, enforces the supply cap, and computes a single state root any honest node reproduces exactly.
• Proof of Resonance. The consensus layer that turns signed observations into agreed values, called Locks, and signed checkpoints into final state. Trust is measured here, and finality lives here.
• Coordination. Queries to the field, tasks, and the settlement that pays for them. This is where money meets work.
• Model field. A peer-to-peer registry of authorized models, content-addressed and swarm-distributed, that miners and Resonators draw on to reason.
• Agents. Resonators: user-owned AI workers with their own wallets and trust, operating inside owner-set limits.
• Lattice. The 512 anchor seats: the fixed structural positions that shape how coordination flow is routed.
• Application. The interface a person touches, every screen a thin view over the node's own data and signed actions.

Two design choices run through every layer. The first is that everything important is signed and reproducible, so the interface never has to be trusted over the protocol. The second is that the heavy work is isolated from the consensus path: model inference runs in a separate process, so a large generation can never stall the ledger or the peer connections. The node stays responsive as a network participant even while a machine is busy generating.

Economics

The vision rests on a money supply with no escape hatches, so the economics come first and in full.

ZIR is the native unit of the network, and uZIR is its smallest denomination: one ZIR is exactly 1,000,000 uZIR, so every balance, fee, and reward is an integer at the protocol level and there is nothing to round. Maximum supply is fixed at 28,700,000,000 ZIR. That ceiling is enforced in the ledger itself, not by policy: an emission that would push total issuance past the cap is rejected before it can be recorded.

The supply divides into earned and pre-allocated parts. Fifty-nine percent, 16,933,000,000 ZIR, is earned supply. It does not exist at launch. It comes into the world only through the protocol's reward paths, paid to participants for work the network verified. The remaining forty-one percent, 11,767,000,000 ZIR, begins as genesis pre-allocations, every part confirmed on-ledger from block zero, never a post-launch transfer, so anyone running an explorer query can see it from the first block. That forty-one percent splits three ways.

The anchor reserve, thirty percent

The anchor reserve is thirty percent of supply, 8,610,000,000 ZIR, held in a labeled anchor-reserve wallet on behalf of the seat owners. These are not protocol funds. The reserve is released to the 512 anchor seat owners as their seats are assigned, on a one-year vesting schedule, and every release is a signed, public ledger entry. Each seat carries a defined ZIR allocation set by its class.

Every per-seat allocation is drawn from this thirty-percent anchor reserve. The allocations attached to the final seats are still being finalized, so the full schedule settles within the reserve as the last positions are assigned; the figures here are the current per-class levels, not a promise of value and not a price.

The vesting is linear over one year from assignment, computed deterministically so every node agrees on how much has been released at any moment, and when a seat is transferred its remaining vesting follows the new owner. The allocation is a network parameter attached to a structural position. It is not a price, not a promise of value, and not a token anyone bought.

The ecosystem reserve, ten percent

The ecosystem reserve is ten percent of supply, 2,870,000,000 ZIR, held in a public ecosystem wallet. It funds community give-outs and grants through signed, public reserve grants, each carrying a required reason field, so anyone can see who received how much and why. It is never a purchase. Distributions surface in the wallet as a "+" entry that marks an incoming grant, and that entry hides itself once the pool runs low, so the interface never advertises a faucet that has effectively run dry.

Operations, one percent

The operations slice is one percent of supply, 287,000,000 ZIR, used only for gas, bootstrapping nodes, and ecosystem grants. This is the only pre-allocated ZIR spent freely. The anchor and ecosystem reserves are held for their owners, the seat holders and the community, and every movement out of them is a signed reserve_grant transaction with a public reason. There is no quiet treasury.

Emission: the earned fifty-nine percent

Mining rewards are tied to real accepted work, never to mere presence. The earned fifty-nine percent is released on a geometric halving curve that pays more early, while the unemitted pool is large, and smoothly less as that pool drains toward the cap, which it can never cross. The per-epoch reward is a deterministic function of how much has already been emitted, weighted toward the network's early years and floored at a small minimum so it never reaches zero, and it reaches contributors through the participation and coordination pools rather than a single fixed headline rate.

Emission is deterministic. Every node computes the same per-epoch reward from a single public input, the amount already emitted, with no node-local factors that could make two honest nodes disagree on the supply. That determinism is exactly what lets the network finalize each checkpoint by quorum without drift. The demand-sensitivity in ZIRA lives in pricing, not in emission: what the asker pays flexes with load, but the curve that mints new ZIR does not. Emission divides across three pools, each tied to a kind of accepted work: consensus participation for accurate observers, inference for providers weighted by domain trust and queries answered, and coordination for Resonators weighted by verified task completions.

Fees and burn

Every plain transaction carries a fee in uZIR, computed deterministically at the moment the transaction is applied and burned rather than paid to any collector, so circulating supply genuinely shrinks with use. The supply audit treats issued minus burned as the exact circulating figure, with no balance changed in the process. Over time, sustained activity removes ZIR from circulation, the counterweight to emission.

Adaptive pricing

ZIRA does not post fixed prices. The cost to ask the field and to coordinate a task floats with conditions every node can observe, and the computation is deterministic, so independent nodes arrive at the same fair number without anyone setting it. Query price scales with demand pressure, defined as open queries per online provider: an under-served field pays more, drawing providers in, and an over-served field settles toward the floor. Task pricing adds the counterparty trust the hirer requires, the declared complexity of the work, and how much independent evidence is requested. A simple, low-trust, well-supplied request stays cheap. A complex job that demands a high-trust Resonator, deep coordination, and corroborating evidence under heavy load costs more, because it asks more of the network.

The free tier as a launch subsidy

Newcomers do not have to fund a wallet before they see the network work. A fresh wallet can ask a small number of free questions per time window directly on the live field, against the same miners, observations, and Locks that paid traffic uses. There is no simulation and no demo mode. The free questions are real queries with real answers, rate-limited so the allowance cannot become a drain on providers.

The free tier is a launch subsidy, not a permanent fixture, and its design says so honestly. Through the network's first year the daily free allowance tapers, generous at first while the field is young, then decreasing as the network matures and its provider base grows. At the end of that first year the free tier closes. From that point the Console has two sustainable paths: the ZIR tier, paying the adaptive price per use, and the Machine tier, running on the participant's own hardware at no protocol cost. The reasoning is plain. A free allowance is the right way to let a person confirm the field is genuine before committing anything. Once the network is real, with real demand and real providers, an open-ended free path would only tax the people whose machines keep it running. The subsidy does its job and then gives way to the paths that pay the people doing the work.

Two things you earn

A participant earns two different things from two different places, and they do not move together. Trust accrues from accurate serving: every observation near the resonant value, every reliable answer, every verified task lifts trust whether or not money changed hands, and steady presence keeps it from decaying. ZIR is paid by demand, the per-task hires and tips that others choose to spend, and by emission for accepted work. The honest consequence is that a quiet field earns little ZIR no matter how diligent a node is, because if no one is asking there is little to be paid for. Trust is the long game. It compounds quietly through every correct contribution and is what makes a node valuable when demand arrives, so the durable strategy is to serve accurately and let standing accumulate ahead of the paid work that follows.

A closing word on value

The economics are only honest if this part is. ZIR has no monetary value today and may never have any. The protocol makes ZIR a real, verifiable, auditable asset, and it keeps the door open, but it makes no promise of price, listing, or return. The supply is capped, the genesis pre-allocations are transparent and confirmed on-ledger from block zero, the burn is permanent, and the rewards are tied to accepted work. What that adds up to over time is for the network and its participants to decide, not for this document to predict.

Coordination settlement

Chapter 3 covered how ZIR is created, held, and burned. This chapter covers what happens when work is paid for, because that is where most economic activity in a mature network will live, and where ZIRA does the most to reward the people who keep the network healthy.

There are two distinct money flows, and keeping them separate is what makes the model coherent. The first is the plain transfer: one wallet sends ZIR to another, the fee is burned, and this is the deflationary heartbeat of the supply. The second is the coordination settlement: a participant pays for a query or a task that the field answers, and the payment is divided among everyone who made the answer possible. A real answer on ZIRA is often the product of several miners, a Resonator or two, evidence checks, and the consensus that sealed it. The settlement pays each contributor in proportion to what they actually contributed, with a few fixed slices that fund the network itself.

The refined settlement divides each coordination payment as follows.

Each slice earns its place. The 77 percent to miners and providers is the heart of it: the people whose machines produced the answer take the large majority, divided by domain trust times confidence times how closely the answer agrees with the field, so that being more trusted, standing behind your answer, and actually converging with the consensus all pay, while a divergent answer earns little even with high self-confidence. Each contributor is paid at a self-custodial wallet they control, independent of the node's operating key, so earnings always land in a wallet the participant holds. The 8 percent network wallet funds long-term protocol work and operations from ongoing activity rather than from a fixed genesis slice; it is spendable only by the network's governance key and its balance and every movement are public. The 10 percent resonator pool is what turns an anchor seat from a static position into a working asset: it flows to active anchor holders in proportion to lattice weight and uptime, on a regular cadence, and it is additional to the one-year vesting that comes with the seat. The 5 percent burn keeps deflationary pressure present in the coordination economy. Community grants and give-outs run from the public ecosystem reserve set aside at genesis, not from a separate coordination carve-off, so the people who produce answers keep the larger share.

Two properties make this sound rather than extractive. First, the split is applied to a budget the asker already chose to spend, deterministically, by every node, with whole-uZIR arithmetic and a fixed rule for the remainder so the parts always sum to the whole. No node can pay itself more by computing the split differently. Second, the two slices that accrue to the network land in labeled wallets whose every inflow and outflow is a public ledger entry, so the community can audit exactly what the network took and where it went.

This is not a future design. The four-way split runs at mainnet genesis, applied identically by every node, so a coordination payment settles the same way everywhere in the field.

Proof of Resonance

If trust is what those rewards lean on, then how trust is earned is the heart of the protocol. Bitcoin replaced trust with proof of work. ZIRA replaces it with Proof of Resonance: the network does not vote on who is right, it converges on what the evidence says, and it remembers who has been right before.

Signed observations

Everything begins with an observation. A node or a Resonator measures something in one of the network's domains, from compute throughput to a currency rate to the quality of an answer, and submits a signed claim carrying a value, a domain, and a confidence between zero and one. The signature ties the claim to an identity, so no observation is anonymous and none can be forged or replayed. Observations accumulate inside a short window, and at each accounting round the network tries to turn them into agreement.

The trust-weighted median

Agreement is reached by a trust-weighted median, never a mean. Each claim is weighted by its observer's trust multiplied by its stated confidence. The claims are sorted by value, and the agreed figure is the one where cumulative weight first crosses half of the total. A median is chosen deliberately: it does not move unless an attacker controls more than half of the weight in a domain, so a flood of cheap, dishonest readings cannot drag the result. Between rounds each observer nudges its estimate toward the median, and the more trusted it already is, the more slowly it moves. Trusted observers anchor the field; newcomers fall in around them.

Locks

A round of observation does not become truth on its own. It becomes a Lock only when four conditions hold together: at least three independent observations contributed, a trust-weighted median exists, the spread of values is tight with the coefficient of variation below two percent, and the supporting trust behind the result clears the finality threshold of sixty-seven percent. A Lock is the network's sealed answer for a subject in a domain at a moment, recording the resonant value, how many observers contributed, and who they were. If the evidence is thin or scattered, no Lock seals, and the network waits for better data rather than inventing certainty.

Checkpoints and finality

Locks settle individual values; checkpoints settle the whole ledger. At each epoch the network computes a deterministic state root, a single SHA3-256 hash over the sorted account balances, anchors, and supply totals. Two honest nodes that applied the same history compute the same root. Master nodes, the identities whose trust has reached at least 0.70, co-sign their view of that root, and when the signatures behind one root represent at least sixty-seven percent of active master trust, the checkpoint is final and irreversible. Finality is over state, not over a chain of blocks, and every node independently enforces the rules, so no checkpoint can finalize an invalid state no matter how much trust stands behind it. The master set is read from authoritative ledger state, not from anything a vote claims about itself, so an attacker cannot vote with trust they do not have. Resonance is what the evidence agrees on; the checkpoint is the network's signature on having agreed.

The path to community finality

Finality is designed to rest on the whole trusted set, and it reaches that in stages rather than overnight. In the bootstrap phase the founding operator runs the checkpoint signers, and for reliability the network anchors finality to a single lead finalizer whose deterministic view advances the ledger, a design that cannot fork and cannot stall, so the chain keeps its word from the first day. As independent operators come online and earn standing, the finalizer set widens: anchor holders and nodes that have earned trust through real, verifiable work join the signers, and finality passes from the founder to a growing community quorum. The threshold and the trust-weighting do not change; only the set of referees grows, until losing any single host, the founder's included, no longer touches the network. This is intention, staged and shadow-tested before each step, not a switch thrown at once.

Two structural choices keep the network scalable and hard to saturate as it grows. Every node has a role: consensus nodes stay deliberately lean and never run heavy inference, so the machines that finalize state can never be overwhelmed, while worker nodes, the miners, put their full hardware to work answering the field. And everything that can be distributed is: peers fast-sync verified snapshots from whoever is nearest, model bytes replicate across storage-vouched holders, queries and tasks route across the worker mesh to whoever can answer, and history is served from many nodes rather than one. The more people run ZIRA, the faster and more resilient it becomes, and the less any single machine matters.

The ZIRA Trust Index

Every identity carries a ZIRA Trust Index, a number between zero and one earned through accurate work and never purchased. It is the single most load-bearing value in the system: it decides who finalizes state, who routes high-trust flow, how much of a coordination payment a contributor draws, and how an anchor seat's class minimum is met.

After each Lock, an observer's trust is recomposed from three parts: accuracy at fifty-five percent, consistency at twenty-five percent, and uptime at twenty percent. Accuracy compares the observer's reading against the resonant value, where a ten percent miss barely registers and a fifty percent miss scores zero, folded into a slow moving average so one bad reading cannot sink a trusted identity but weeks of bad readings will grind it down. Consistency penalizes erratic reporting even when the average happens to land right. Uptime rewards being present for the rounds.

Trust is tracked both globally and per domain, so an identity can be deeply trusted in energy data and unproven in code, judged on its own merits in each. Trust also decays with absence: every missed round shaves a little off, so a month away costs roughly half of accumulated trust. This is not a punishment; it keeps the master set current, so finality always rests on identities serving the field now rather than on reputations earned long ago and abandoned. Because rewards and adaptive prices both lean on trust and on verified outcomes, the cheapest path to earning more is to be genuinely useful and consistent. That alignment, where the profitable move and the honest move are the same move, is the property the whole protocol is built to preserve.

Resonators

Proof of Resonance scores identities, and the identities that act on a person's behalf are Resonators. A Resonator is an AI worker you own. Not a service you rent, not an account on someone else's server. When you create one it gets its own keypair and wallet, generated in your browser, and from that moment it is a participant in its own right, with its own balance, its own earned trust, and its own history anyone can read.

Create, fund, and limit

You give a Resonator a name, a purpose, a character, and the domains it works in, drawn from a universal field of capabilities: language, code, vision, audio, planning, science, finance, security, and whatever modalities are added later. Then you fund it. Standing one up requires moving a meaningful minimum of your own ZIR into its wallet, both so it has a real operating float from day one and so creating one carries a non-trivial commitment that keeps the Discover directory free of spam. That balance is the Resonator's own, and it is what lets it participate at all, since asking miners, comparing answers, collecting evidence, collaborating, and signing agreements all cost fees.

Funding buys capacity, never trust. You set the boundaries it lives inside: a per-task cap, a per-day cap, the minimum counterparty trust it will deal with, and the domains it may touch. A Resonator can never spend beyond those limits, and you can pause it, top it up, or withdraw its earnings to your own wallet at any time, signed locally with the Resonator key that stays in your browser.

Resonance and earning trust

The defining switch is resonance. With it off, a Resonator only answers when you call it. With it on, it acts on its own inside your limits: it spends its own ZIR to query the adaptive field, weigh where independent answers converge and diverge, gather evidence, and coordinate with other Resonators, without asking you each time. Those fees are not waste. They are how it works, how it gets scored, and how it becomes useful. Trust starts at exactly zero for every Resonator and cannot be bought. It rises only when verified work is released, and its overall trust follows from the average across the domains it has actually earned in. More funding lets it coordinate more deeply and so creates more chances to earn, but the gain is always tied to verified results, never to the size of the balance.

Hired per task through Discover

Once a Resonator is listed, others find it in Discover, the place to find a Resonator for a job. Discover ranks by the trust the network scored from real work, never by paid placement. You search by name or purpose, sort by overall trust, domain trust, price, jobs done, or recent activity. The owner controls whether a Resonator is listed at all, so a private Resonator can work for its owner without ever appearing in the directory. To hire one you write a brief, pick the domain, set the minimum trust you require, and pay in ZIR. A single task may be answered by one Resonator or by a coordinated chain of Resonators, miners, evidence checks, and settlement signals working together, and over time Resonators will hire other Resonators for sub-tasks, turning single agents into an agent economy with depth.

Signed receipts and history

Every task moves through a visible lifecycle: assigned, delivered, verified, released, with fallbacks so an undelivered task expires and refunds and a delivered task the hirer never checks releases on its own. When work comes back it carries a signed receipt naming each contributor, the model and domain they worked in, their weight in the result, and a challenge window during which the proof can be contested before it settles. The funding, the spends, the rewards, and the trust gained all land on the ledger as signed records, so a Resonator's whole working life is something you can check rather than take on faith.

Models

Resonators and miners need something to reason with, and the models they draw on enter the network through one carefully gated path. ZIRA does not ship a single model baked into the client. It runs a model field: a curated, peer-to-peer registry of language and reasoning models distributed among the nodes that choose to carry them. Every model is a GGUF file, the same portable format used by llama.cpp, so any node with enough memory can load and run it without a vendor account or a remote API.

Authorization and content addressing

A model enters the field only when an authorized source signs its metadata, producing a manifest signature over the canonical record. Nodes accept an announcement only if the signing key resolves to a recognized authority and the signature verifies against the exact metadata. Anyone can relay or serve a model's bytes once it is authorized, but no one else can put a new model on the network. The result is open distribution with a single, verifiable point of authorship. A model's identity is the SHA-256 hash of its bytes, which is both the model id and the proof that the file received is exactly the one authorized. Bytes stream and hash in one-megabyte chunks, and before a model is loaded or served a node re-hashes the assembled file. If the hash does not match the announced id, the file is rejected. Passing off altered weights under an authorized id is arithmetically impossible.

Swarm distribution

Distribution is peer to peer. When a node needs a model it does not hold, it asks a connected peer that advertised the bytes, pulling chunks directly from the swarm, with the authorized source kept only as a fallback. Storage-enabled peers, which most nodes are by default, actively replicate authorized models up to a local cap rather than waiting to be asked, so redundancy grows on its own, and a model is field-ready once it is no longer single-host. Mining never pulls model bytes on its own; carrying weights is the storage role's job, and it always respects the operator's cap.

Native inference, endpoints, and isolation

A node runs a model only if the model fits the machine. The engine estimates the free memory needed for weights, context, and headroom, and if that does not comfortably fit, the node does not attempt a native load. Instead it keeps participating by serving through an OpenAI-compatible endpoint such as Ollama or LM Studio, or by working in coordinator mode, relaying signed queries and coordinating tasks. Native inference runs in a separate process from the node: the node spawns an isolated inference server that loads the file and exposes a local generation endpoint, and the node calls it over that local interface. This keeps consensus, peering, and the interface fully responsive even during a large generation, and means a crash inside the model engine can never take down the node's role as a network participant. Big models stay available across the field without forcing every node to run them, and capable hardware does the heavy generation without putting the ledger at risk.

Taxonomy and lifecycle

Model metadata is capability-tagged against a fixed set of domains shared with the rest of the protocol: code, science, reasoning, language, vision, audio, video, robotics, medicine, law, finance, education, creative, security, planning, multimodal, and a general catch-all. The field carries text and reasoning models today, and the signed metadata shape is ready for image, audio, video, tool-using, and multimodal models as they are authorized. A model is provided by file or link, hashed and signed, announced, replicated by storage peers until field-ready, and loaded natively by miners that can fit it or served by endpoint by the rest. Metadata carries a version number, and every node re-announces what it holds when it restarts, keeping the registry current without a central server.

The network

All of this, the ledger, the trust, the Resonators, and the models, lives inside one program every participant runs.

Transport and peering

Peers connect over libp2p. Each node listens on TCP and on WebSocket, so both ordinary nodes and browser-style light peers can reach it. Every connection is encrypted end to end with Noise, and multiple logical streams share one connection through yamux multiplexing. On top of that, gossipsub carries three message streams: events, the transactions and observations that feed the ledger; consensus, the checkpoint votes that give finality; and app, the Resonator discovery, tasks, queries, and answers. Topics are namespaced by the genesis id, so nodes on different networks never cross-talk even if they meet. A distributed hash table and hole-punching help nodes behind home routers reach and be reached, and a node's identity is a key persisted in its data directory, so a peer keeps the same identity across restarts.

How a new node joins

Discovery is automatic and does not depend on anyone hand-sharing an address. On start a fresh node loads any peers it cached, fetches a signed public bootstrap registry, falls back to a registry bundled with the release, and dials what it finds. A node accepts a registry only if its signature verifies against an authorized key, which makes the seed list tamper-evident, and after first contact it caches the peers that answered, so later restarts no longer hinge on any single seed.

Fast sync and verification

A long history should not mean a slow join. Instead of replaying every event from genesis, a new node performs a fast sync: it asks several connected peers for their finalized state snapshot and the finalized checkpoint it sits on. It does not take one peer's word for it. It verifies that the snapshot hashes to the finalized root and that the votes behind that checkpoint come from masters whose trust sums past two thirds before adopting it, and from that point forward it validates every event itself under the full rules. A node that prefers to trust nothing can disable fast sync and replay from genesis. This is safe because finality is anchored in Proof of Resonance, not in trusting a seed: no peer can hand a newcomer an invalid state and have it stick.

Reachability

To accept inbound peers a node needs a reachable TCP port. The launch wrappers do best-effort setup: opening the local firewall, attempting port mapping, detecting the public host, and advertising a public address only after the port is confirmed reachable from outside. If TCP is blocked, the node stays online for outbound and local use but is not exported as a dead public seed. A reachability check is the source of truth for whether the outside world can connect, so the published seed set stays live.

Anchors and the coordination lattice

Beneath the trust graph and the coordination flow sits a fixed, public skeleton: 512 structural seats, defined once at genesis and never expanded. Each seat is a ZRC-1 anchor, a position in the coordination topology rather than a balance or a reward. Where ZIR is earned and trust is built over time, the anchor set is bounded and final. There are exactly 512, and there will only ever be 512.

The seats are grouped into six classes, an inner ring of higher-weight positions and an outer ring that widens access toward the edge of the network. The full table appears in chapter 3 with each class's allocation. In summary, there are 112 inner seats across Genesis, Meridian, and Nexus, and 400 outer seats across Lattice, Sentinel, and Foundation, for 512 in total, with weights running from six at the core to one at the boundary. A seat's weight is structural and does not change; what changes is whether its holder has earned the standing to use it.

The lattice as active infrastructure

Anchors are designed to be more than passive holdings. They are the routing skeleton of the coordination topology, and each class plays a structural role. Genesis seats, at weight six, route the highest-trust coordination flow and are required participants for consensus on the most sensitive domains. Meridian seats maintain the backbone paths, Nexus seats propagate signals across domains, Lattice seats handle regional mesh routing, Sentinel seats provide boundary observation and relay, and Foundation seats carry continuity and widen access at the edge.

This is also why the lattice matters for safety. The design calls for a convergence requirement on high-trust domains: for a Lock to seal on a sensitive subject, a minimum number of anchor nodes must be among the observers, so the most important agreements always pass through the most structurally accountable positions. The highest-weight anchors carry influence close to a veto: if their trust-weighted observation diverges far enough from the field, consensus on that subject pauses rather than sealing a result the backbone disagrees with. The lattice does not override Proof of Resonance; it gives the resonance an accountable spine.

Assignment, transfer, and dormancy

A seat is held by a ZIR address. Seats are assigned to operators and contributors as the network forms, and once held they are freely transferable: an owner can move a position, singly or in a batch, to another ZIR address in one signed operation, and the seat's class, weight, trust requirement, and remaining vesting all follow the new owner. The ledger records each assignment and transfer as a plain anchor transaction, and a seat's state is visible to every node as part of consensus.

Routing revenue and the active roles above are future-gated. Activation is switched off across the whole network and stays off until the seats are secured and the network has matured. Until then an anchor is a settled, public position, owned and transferable, with a vesting allocation, but it does not yet route flow or draw routing revenue. While a seat is unassigned, the anchor-reserve wallet operates it as a dormant coordination node that contributes just enough weight to keep the topology complete, and as each seat is assigned the new owner's activity replaces and exceeds that dormant weight.

What an anchor earns

Once activation opens, an anchor earns in two ways that stack. The first is the one-year vesting of the seat's ZIR allocation, which belongs to the seat owner and follows the seat on transfer. The second is the resonator pool: ten percent of every coordination settlement, distributed to active anchor holders in proportion to lattice weight and uptime, on a regular cadence. The first runs once over a year; the second continues for as long as the seat is held and active. Both are visible on the ledger.

The application layer

Everything above is protocol. This chapter is about what a person actually touches, because a network is only as powerful as the surface that lets people use it well. The application is a single interface over the node's own data and signed actions, so nothing it shows has to be trusted over the protocol underneath.

First run

The first time the application launches, it presents a privacy and terms gate before any content loads. It covers how data is handled, the choice to opt in or out of analytics, the absence of any identity-verification requirement, and the plain statement that ZIR is not a security. The participant accepts to proceed, and the acceptance is stored locally and shown again only when the policy changes in a meaningful way. It is a clear front door, not a checkbox buried in settings.

Console: the field and the tiers

The Console is where a person works with the field. By default, work goes to the field as a whole: a question is decomposed by complexity, routed to several Resonators by domain-trust match, and the responses merged by confidence-weighted consensus. The participant sees which Resonators contributed, the trust of each, and the confidence of the merged answer, and can expand any single response. This multi-model consensus view is what makes a ZIRA answer different from a single model's reply: you see the agreement, not just the output. Working with one specific Resonator is a separate, deliberate act, opened only when a participant asks for a particular Resonator directly, either one of their own or one found in Discover.

The Console offers three tiers. The Free tier is the launch subsidy described in chapter 3: a tapering daily allowance through the first year, then closed, with base field models, sensible limits, and a throttle under heavy load. The ZIR tier is open to any ZIR holder, settling per use with prioritized routing and full model and Resonator access. The Machine tier is the participant's own hardware working on their own tasks, distinct from mining, available whenever they ask, with the machine reserved for their own work while that tier is active. After the free tier closes, the ZIR and Machine tiers are the two ways to use the Console, one paying the network for work and one doing the work yourself.

Mine: the contribution dashboard

The Mine surface is where a participant lends hardware to the field and watches what it earns. A top strip shows earnings, active sessions, trust score, and uptime. A live panel shows the terms, topics, and activity the node is processing, updating every few seconds, with the kind of query, the activity tag, and the ZIR earned per event. A history view breaks earnings down across one hour, twenty-four hours, seven days, and thirty days, each with total ZIR earned, tasks served, average trust, and uptime, and expandable rows for individual events. A resource slider sets the share of GPU and CPU the field may use with a live preview, smart routing lets the node pick models that match its hardware, a background mode keeps the footprint minimal while the participant uses the Console, and an auto-pause keeps the node from draining a laptop battery below a chosen threshold.

The surface makes the two earning paths explicit. The first is storage: turn it on and the node holds and serves the field's authorized model, and once it passes the masters' random-chunk challenge it earns its share of the participation pool, a baseline any capable, reliable machine can hold. The second, and the highest-earning, is answering: connect a model, on this machine's own engine or through an OpenAI-compatible endpoint such as Ollama, LM Studio, or llama.cpp, and the node answers the field's questions and collects coordination pay on top of storage, weighted by trust and by how well its answer agrees with the field. Stronger hardware and a larger model win more answers and build trust faster, so the reward tracks the quality and reliability of the work rather than raw presence. An Answering panel shows what the node is contributing and earning along both paths.

Discover, Resonators, Wallet, Settings

Discover is the network's directory of Resonators, an information surface where a participant reads trust, domains, and record, and where starting a task opens a conversation in the Console rather than happening inline. Domains are many and entered freely by owners, so they live in a Resonator's profile as description rather than as a small fixed set of filters. The Resonators surface is the owner's view of their own workers: create, fund, set limits, transfer to another address, and choose whether each appears in Discover. The Wallet is the self-custodial home for ZIR, with balance, send and receive, trust, history, and backup and restore, all signed locally. Settings gather account, Console defaults and history retention, mining controls and earnings destination, privacy and analytics choices, notifications, appearance, network reachability, and security. Anchor positions are viewed and managed from the Anchors surface, where an owner sees their seats, class, allocation progress, and status, and can transfer positions to another address.

Privacy and data sovereignty

A network where AI runs on people's machines, not on company servers, changes who holds the data, and that change is one of ZIRA's strongest properties.

When work runs on the field, it runs on independent nodes that follow the same open rules, not on a central service that logs every prompt to a profile. When work runs in the Machine tier, it runs on the participant's own hardware and stays there. There is no account that has to be created with a real-world identity, no know-your-customer gate, and no central store of conversations the project can read, sell, or be compelled to hand over, because the project does not run the servers that would hold it. Conversation history is the participant's own: kept locally, with retention they control and a setting to clear it.

The wallet is self-custodial. Keys are generated and encrypted on the device and never leave it, so identity on the network is a key the participant holds rather than a record a company keeps. Signed receipts make the working record of the network public and checkable without exposing the content of private work: what is on the ledger is the proof that work happened and who contributed, not the substance of the prompt. The result is a system where verification is public and data is private, which is the right way around. People can prove the network is honest without having to expose themselves to do it.

Decentralization and governance

A fresh Proof of Resonance network has a genuine bootstrap problem. Finality comes from master nodes at trust greater than or equal to 0.70, but trust is only earned by serving the field accurately over time, and on day one no one has earned it. The network therefore launches with a small set of seeded bootstrap masters that sign checkpoints so finality exists immediately. This is the one honest concentration at launch. It is a referee role, not an ownership: every checkpoint is over a deterministic state root any node can recompute, and an invalid state cannot be finalized no matter who signs it.

The network decentralizes by operators running their own nodes, earning trust, and crossing the 0.70 master threshold themselves. As real master trust accrues, the two-thirds finality threshold spreads across many signers and the early signers' share shrinks until they are masters among many. Authority is ledger permission, not server control: operational authority addresses can be delegated and revoked through signed ledger events, while the genesis role itself cannot be revoked.

Governance is intended to run on the same principle that governs everything else, which is earned trust. Proposals covering fees, emission parameters, trust weights, domains, anchor configuration, and protocol upgrades are voted by trust under a quorum and an approval threshold, so the network's direction is set by those who have demonstrated usefulness rather than by those who hold the most. On-chain governance is typed into the protocol and scheduled for activation, and the move to active governance activates at a shared epoch boundary on the permanent chain. Anchor activation and routing revenue stay future-gated until the network reaches real maturity, so the lattice becomes active infrastructure only when there is a genuine network for it to route.

Security and resilience

A network that asks people to verify rather than trust has to earn that posture in its engineering. This chapter is honest about both the protections in place and the hardening still ahead, because a paper that only listed strengths would be the kind of document this project exists to avoid.

What protects the network today

The ledger enforces its own invariants. The supply audit recomputes every balance, the emitted total, the burned total, and the reserve grants purely from the signed event log, and checks that emission never exceeds the earned cap and that issuance never crosses the maximum supply. Circulating supply is defined exactly as issued minus burned. Nonces are strictly sequenced per account, so a transaction cannot be replayed or reordered. Reserve movements are signable only by the authorized wallet and carry a public reason.

Finality is hardened against the obvious attacks. The master set used to weigh checkpoint votes is read from authoritative ledger state, not from anything a vote claims about itself. A checkpoint finalizes only when genuine master trust crosses two thirds, and once a state root finalizes for an epoch no competing root can replace it. Fast-sync snapshots are adopted only after the snapshot is verified to hash to a finalized root that genuine masters signed, and snapshot adoption is sequenced ahead of pulling the event tail, so a joining node converges exactly rather than double-applying history. The local interface is protected against cross-site request abuse, and a public node exposes only safe read paths unless an operator token is present, with posting rate-limited by network address. Inference runs in its own process, so heavy generation cannot stall consensus, peering, or the interface.

What is being hardened next

Several improvements are scheduled, and because some change the way state is computed, they are grouped into a single coordinated activation so the ledger is upgraded once rather than repeatedly, always on the same permanent chain with no reset.

The most important is moving the smallest denomination to arbitrary-precision integers. Today balances are handled as standard double-precision numbers, exact only up to a boundary below the network's full supply scale. Computations are identical on every node, so consensus holds, but exactness at the largest balances is not guaranteed. Migrating the unit to big integers makes the accounting exact at full scale, and because it touches serialization and the state root it is the anchor of that coordinated activation. Alongside it, the transaction, observation, and checkpoint-vote stores gain explicit bounds, so a participant flooding the network with otherwise-valid messages cannot grow a node's memory without limit. The finality bootstrap starts from several seeded masters rather than one. The cost of creating a network identity rises from a simple address-based rate limit toward a real stake or proof-of-work requirement, closing the cheap-identity path. And the fast-sync boundary is tightened so an event near the adoption point can never be orphaned if an adoption is interrupted.

Release and operational resilience

The protocol and node carry a thorough automated test suite covering cryptography, consensus, coordination, emission, pricing, the anchor model, fast-sync convergence, late-join determinism, mining earnings, and interface security. The path ahead adds end-to-end tests for the application, continuous integration that gates a release on the full suite passing, and signed release artifacts for each platform, so the build a participant downloads is verifiably the build the project produced. These are not protocol changes, so they proceed in parallel with everything else.

Roadmap

ZIRA ships as a working peer-to-peer network before it grows into a large one. The roadmap below is concrete about content and order. It does not promise fixed dates, because the things that matter most depend on real operators choosing to run nodes, and one date is honest: the free tier tapers through the network's first year and closes at the end of it. The work is grouped into five tracks. Tracks that do not touch the ledger ship continuously; everything that changes how state is computed lands together in a single coordinated activation on the permanent chain, so the ledger is upgraded once rather than repeatedly, with no reset.

Phase 1: Foundation hardening (one coordinated activation)

This phase is one coordinated release because every item below changes the state root, and a permanent network deserves a single, well-tested activation rather than repeated disruptions.

• Move the smallest unit, uZIR, to arbitrary-precision integers, so accounting is exact at full supply scale. This is the anchor of the cut; it touches serialization, the state root, the interface, and the genesis hash.
• Bound the transaction, observation, and checkpoint-vote stores, removing the unbounded-memory path under message floods.
• Seed several finality masters at launch rather than one, so early finality does not rest on a single machine.
• Tighten the fast-sync boundary so a near-boundary event is never orphaned during an interrupted adoption.
• Raise the cost of creating a network identity from address-based rate limiting toward stake or proof-of-work.
• Done looks like: the hardened protocol activated at a shared epoch boundary on the same permanent chain, with no reset and every balance intact, full test suite green, late-join determinism and supply audit verified at scale.

Phase 2: Product depth (ships continuously, no ledger risk)

• The Mine dashboard: live activity feed, period history across one hour, twenty-four hours, seven days, and thirty days, resource sliders with live preview, smart model routing, background mode, and battery auto-pause.
• The Console tiers: the timed free subsidy with its first-year taper and close, the ZIR per-use tier, the Machine tier, and the multi-model consensus view with per-contributor trust and confidence.
• Discover and Resonators refined for depth: free-form domains in profiles, seat and Resonator transfer, and discoverability controls.
• The first-run privacy gate and the expanded settings.
• Done looks like: a participant can onboard, ask the field, see the consensus behind an answer, lend hardware, and read exactly what they earned, all without funding a wallet during the subsidy window.

Phase 3: Economic activation (the settlement is live; distributions and governance activate on the permanent chain)

• The refined coordination settlement, live from genesis: 77 percent to miners and providers, 8 percent to the network wallet, 10 percent to the resonator pool, and 5 percent burned, with the network wallet and resonator pool established as labeled wallets at genesis. Community grants run from the ecosystem reserve set aside at genesis, not from a separate coordination slice.
• Resonator-pool distributions to active anchor holders by lattice weight and uptime, on a regular cadence.
• On-chain governance activation: proposals and trust-weighted voting under a quorum and approval threshold.
• Done looks like: paying for a task visibly splits across contributors and the network's public wallets, and a parameter change can pass by earned-trust vote.

Phase 4: Lattice activation

• Secure the full set of 512 seats and open the activation gate.
• Bring the convergence requirement and high-weight influence online for sensitive domains.
• Begin routing revenue to activated seats that meet their class trust minimum.
• Done looks like: anchors route real coordination flow in proportion to weight, and the resonator pool pays active holders from live settlement.

Phase 5: Ecosystem and scale

• A broad set of independent public bootstrap seeds so new nodes join without depending on a single entry point.
• More miners, providers, storage peers, and authorized models, including image, audio, video, and multimodal models as the signed metadata already anticipates.
• A public block explorer and a developer kit built from the node's own client interface.
• Continuous integration, end-to-end application tests, and signed release artifacts for every platform.
• Programmable Resonance Objects and continuous value streams: field-priced instruments and streaming micro-payments for ongoing work, building on the coordination layer.
• Done looks like: a self-sustaining network with many operators, a public explorer, a developer ecosystem, and value flows beyond single tasks.

The arc underneath the phases

The long arc is the move from a small set of bootstrap referees toward a field of many earned masters. The network signs its own first checkpoints because no one else has earned the standing to, and it gives that standing away as fast as real operators earn it. Each phase widens participation, and the network grows in usefulness rather than in dilution.

Honest notes and risks

This document would not be true to the project if it ended on the roadmap. The risks are real and they are stated plainly.

ZIR is earned only, through mining, coordination, and verified work, against a fixed 28.7 billion maximum supply, of which 59 percent is earned and 41 percent begins as transparent genesis pre-allocations. There is no public sale of ZIR and no way to buy the token from the project. ZIR has no price, no listing, and no promised return today, and it may never have any. Nothing in this paper is investment advice or a solicitation.

Anchor seats carry a ZIR allocation that vests over a year and, after a future activation gate opens, a routing role and a share of coordination settlements. Activation is not live and has no promised date, and the value of a seat, now or later, is not promised by anyone. Because a seat carries an allocation and prospective earnings, its treatment may differ across jurisdictions, and anyone acquiring or holding a seat should understand that and seek their own advice.

Early finality leans on a small set of bootstrap masters, and the operator base is small while the network is young, so the early network is more concentrated than the mature one it aims to become. Software carries bugs, keys can be lost with no recovery, and a self-custodial wallet places the responsibility for safekeeping entirely on its holder. The refined settlement, on-chain governance, anchor activation, the timed free tier, and several hardening items described here are scheduled rather than live, and schedules can change.

The right posture is the one the code is built for. Run a node, read the rules, verify rather than trust, and treat every forward-looking part of this paper as intention rather than guarantee.

Glossary

Anchor. One of the 512 fixed ZRC-1 structural seats in the coordination lattice. A position with a class, a routing weight, a minimum trust requirement, and a vesting ZIR allocation, not a balance.

Checkpoint. A signed agreement among master nodes on the deterministic state root for an epoch. Final once supporting master trust crosses two thirds.

Coordination settlement. The division of a payment for a query or task among the contributors that produced the answer, plus the fixed network slices.

Domain. A capability category, such as code, vision, finance, or medicine, against which trust and models are scored and tagged.

Lock. The network's sealed answer for a subject in a domain at a moment, formed when enough trusted, tightly agreeing observations converge.

Master node. An identity whose trust has reached 0.70, eligible to co-sign checkpoints that finalize state.

Network wallet. A labeled wallet receiving the eight percent slice of each coordination settlement for long-term protocol sustainability and operations, with public inflows and outflows.

Proof of Resonance. ZIRA's consensus method: converging on what the evidence says, weighted by earned trust, rather than voting or hashing.

Resonator. A user-owned AI worker with its own wallet, trust, domains, and limits, hired per task through Discover.

Resonator pool. The ten percent slice of each coordination settlement distributed to active anchor holders by lattice weight and uptime.

uZIR. The smallest unit of ZIR. One ZIR equals 1,000,000 uZIR.

ZIR. The native unit of the network, earned through verified work, never sold by the project.

ZIRA Trust Index (ZTI). A per-identity, per-domain measure between zero and one, earned through accuracy, consistency, and uptime, never purchased.

---

License: MIT. This document describes intended and live behavior of the ZIRA protocol and network. Forward-looking sections are intention, not a promise. Nothing here is investment advice or a solicitation.