One People: community-owned AI infrastructure for a compute commons.

Abstract

One People is a proposal for AI infrastructure that is locally controllable, economically legible, and collectively governable. The system combines a personal AI core called Nexus, a coordination layer led by APEX and specialized control roles, a heterogeneous compute mesh contributed by ordinary operators, and a monetary system in which currency is issued only against verified useful work. Instead of treating AI as a centralized subscription sold from remote datacenters, One People treats AI as a public-interest network: tasks are routed to suitable hardware, rewards are tied to accepted inference and training, and a Commons Fund continuously finances new specialists, public goods, and shared infrastructure.

The architecture rests on several strict invariants. The cooperative model is the near-term economic layer: members share idle compute and de-identified data, and the community shares trained AI experts back. Your data never leaves your device. Utility is anchored in compute through Verified Work Units, benchmark-normalized capacity, and external price comparisons to public cloud markets. A token-based economy is a distant future possibility, not the current model. Governance is neither a corporate roadmap nor a whale-controlled free-for-all: communities propose work, members vote with square-root weighting, AI agents execute approved jobs, and human review remains mandatory at critical boundaries. The result is a system designed to make AI more like energy, broadband, or civic infrastructure: distributed, inspectable, and capable of returning value to the people and institutions that actually provide the substrate.

Introduction: The Problem with Centralized AI

Most AI systems today are economically centralized even when their interfaces feel consumer-friendly. The model weights live in someone else's datacenter, the routing logic is opaque, the governance process is internal, and the revenue model depends on converting access into recurring rents. Users may be allowed to prompt the system, but they do not meaningfully control where computation happens, how outputs are prioritized, how sensitive workloads are isolated, or how value flows back to the people supplying the demand, the data stewardship, or the hardware.

This concentration produces four structural problems. First, it concentrates compute ownership. If meaningful AI capability requires access to hyperscale infrastructure, then the means of production remain locked behind a small number of vendors. Second, it concentrates policy. Decisions about what gets built, what gets throttled, what counts as acceptable risk, and what kinds of communities deserve support are typically made through internal product planning rather than public process. Third, it concentrates data exposure. Users routinely hand prompts, documents, and workflows to systems that are designed to centralize logging, model operations, and telemetry. Fourth, it concentrates failure. When a remote provider changes pricing, policy, access terms, or uptime posture, the downstream user inherits the decision.

There are partial alternatives, but each tends to solve only one slice of the problem. Running a local model can improve privacy, but local-only systems struggle to coordinate collective training, fund public-interest specialists, or monetize spare capacity fairly. Pure token systems can describe a market, but without a hard link to actual useful work they drift into speculative abstractions. Volunteer compute networks may decentralize hardware, but without a strong coordination protocol and a real quality gate they become unreliable for serious workloads. Municipal digital services can be public-minded, but they usually lack a native mechanism for pooling compute, routing work beyond a single institution, or sharing the upside back to residents.

One People starts from the premise that these are not separate failures. The governance problem, the compute problem, the privacy problem, and the economic problem are coupled. A credible alternative to centralized AI has to solve them as a stack. That means a user-facing personal core, a routing and verification layer that can coordinate heterogeneous work, a node substrate that can absorb anything from a laptop to a municipal cluster, and a currency whose monetary policy cannot be rewritten by a small group once adoption begins.

Vision: AI Infrastructure as a Commons

The One People vision is straightforward to state and difficult to implement: AI infrastructure should be held in common. "Common" here does not mean ownerless, vague, or purely symbolic. It means that the core system is designed so that personal users, independent node operators, public institutions, and specialized AI workers all participate through transparent rules rather than through one company's discretionary control. The network is not organized around maximizing engagement or extracting usage data. It is organized around useful work, shared governance, and durable capacity.

In this model, people and AIs do different kinds of work. Humans remain responsible for imagination, normative judgment, and governance. Communities notice which problems matter, propose projects, set priorities, review outcomes, and decide which tradeoffs are legitimate. AI agents handle more of the execution layer. They decompose approved jobs into subtasks, specialize into roles, route work, run training rounds, evaluate intermediate outputs, and carry out repeatable operations at a scale that would otherwise be prohibitively expensive. Hardware owners provide the means of production. Their devices are not decorative endpoints; they are compensated infrastructure participating in a shared economy.

This design produces a different answer to the question "who is AI for?" In centralized systems, the answer tends to be: for whoever can pay the provider, under whatever terms the provider chooses. In One People, the answer is: for the communities that can coordinate demand, contribute capacity, and govern the resulting surplus. The Commons Fund exists precisely because a network should be able to direct part of its issuance toward public goods that are useful but not privately optimizable: health assistants, legal tools, local-language specialists, safety research, accessibility systems, and infrastructure that would rarely win an internal corporate roadmap meeting.

The brand and product architecture support this governance model rather than distracting from it. One People is the parent system. Nexus is the personal AI core, whether it runs on one machine, in a hosted pod, or as a managed service. APEX is the first interface a user encounters, but also the admission layer that turns intent into executable work. Expansas may offer commercial modules, but it does not replace the parent system. That naming discipline matters because commons infrastructure fails when the user cannot tell whether they are entering a public protocol or a closed commercial silo.

Calling this a commons is therefore not rhetorical. It means the monetary rules, the routing invariants, the proof obligations, and the governance flows are part of the architecture itself. A commons is not created by branding; it is created by making extractive overrides difficult and public contribution meaningful.

Architecture Overview: Nexus, APEX, and the DePIN Mesh

One People can be understood as three tightly-coupled planes. The first is the personal plane: Nexus, the user's AI home base. The second is the coordination plane: APEX, the planner engine, Sentinel, Hawk, and the surrounding BrainAI logic that admit, route, monitor, and verify work. The third is the execution plane: a distributed physical network of heterogeneous nodes that actually perform inference and training. Keeping these planes separate makes the system easier to reason about. Binding them together through explicit protocols makes the system economically coherent.

Nexus as the control surface

Nexus is the place where the system becomes personal rather than abstract. It can run locally on a user's own hardware, in a private cloud pod, or as a hosted deployment, but the core idea stays the same: the user interacts with one persistent AI home base rather than with a rotating sequence of disconnected cloud endpoints. APEX is the front door to that system. In practical terms, APEX handles orientation, receives user intent, and routes work into the wider network when the request exceeds local capability, requires specialized models, or benefits from distributed execution.

The coordination plane

The coordination protocol gives the network a formal labor model. Every unit of work is represented as a task message with a stable ID, explicit requirements, and cryptographically bound artifacts. Every task moves through the same lifecycle:

pending -> assigned -> in_progress -> verification -> approved -> completed

That lifecycle is not cosmetic. Phase gates are strict barriers. Phase N+1 may not begin until every subtask in phase N has reached completed with a valid Hawk approval. This prevents a system-wide habit of optimistic parallelism from spilling bad work forward into later stages.

APEX is responsible for job admission and priority calculation. Its base score is intentionally simple:

priority_score = urgency x impact x community_vote_weight

This formula matters because it ties user and Commons work to the same admission surface. A live outage or safety issue can outrank a low-stakes request; a Commons job with overwhelming support can outrank an otherwise similar job with weak mandate. When a task enters high-risk domains such as medical, legal, financial, treasury, or physical safety, APEX must escalate to a human reviewer rather than pretending the protocol is sufficient by itself.

The planner engine performs decomposition and routing. Eligibility is constraint-first: required tier, TEE status, minimum VRAM, latency, load, and artifact availability all have to pass before optimization begins. Among eligible nodes, the planner engine uses a weighted score:

route_score =
0.35 * capability_fit +
0.20 * security_fit +
0.15 * latency_fit +
0.15 * headroom_fit +
0.10 * reliability_fit +
0.05 * cache_fit

The router then selects among the top candidates with a weighted least-loaded policy rather than always choosing the absolute highest-scoring machine. That reduces hotspotting while preserving fit.

Monitoring and verification

Sentinel continuously monitors liveness, drift, and contention. A task is flagged as stalled if meaningful progress or checkpoint activity exceeds twice the expected interval. When the required capability class stays above 85% utilization and queues are backing up, Sentinel may trigger priority re-ranking and preemption of lower-priority checkpoint-safe work. At the phase level, if failed attempts exceed 30% of subtasks, Sentinel halts the phase and escalates. That is the difference between a resilient network and one that quietly degrades into partial failure.

Hawk is the hard quality gate. Low-risk tasks use spot_check, which verifies a random 5% sample and artifact integrity. Medium-risk work such as code generation and model distillation uses full_verify. Critical work such as medical, financial, treasury, security, or robotics tasks uses deep_audit, including adversarial evaluation and human review triggers. No output ships without a signed Hawk attestation bound to exact output hashes.

The DePIN execution mesh

The execution substrate is deliberately heterogeneous. The network does not require a single vendor, a single form factor, or a single accelerator family. Nodes advertise tier, accelerator family, VRAM, TEE capability, uptime, and benchmark profile. BrainAI schedules against that live capability surface. Some work stays local to the user's Nexus. Some moves onto nearby nodes for latency. Some goes to attested or large-memory clusters. The important point is that the same routing and settlement model can span all three without pretending they are equivalent.

Cooperative Economics: The Data Cooperative Model and Distant Token Roadmap

The near-term economic layer of One People is a data cooperative, not a cryptocurrency. Members share idle compute and de-identified data with the cooperative; the cooperative shares trained AI experts back. Your data never leaves your device without explicit consent. Intelligence is cultivated through verified useful work and returned to the community. This is not crypto — it is a cooperative.

A token-based economy is a distant future possibility, not the current model. The cooperative comes first. If a token layer is added in the future, it would be designed with the same principles: no pre-mine, no venture allocation, proof of useful work, and immutable monetary bounds. The technical specification below describes that potential future token model in detail, so that the architecture is complete. But the cooperative model — share compute, get intelligence back — is what we are building today.

Why a token might eventually exist

If a token is eventually introduced, it would serve three functions simultaneously. Users would spend it for compute. Node operators would earn it for providing verified useful work. Holders would use it for Commons governance. These roles would reinforce each other. Spend creates demand for compute. Work creates compensated supply. Governance allocates a portion of issuance toward public goods and shared specialist development. The economic loop would remain internal to the network instead of depending on a separate subsidy model. In the current cooperative model, these functions are fulfilled through cooperative credits and shared intelligence rather than a tradeable token.

Phase 1 settlement path

The recommended launch path is a canonical ERC-20 on Base, not a custom rollup token and not an SPL detour. The reason is practical, not ideological. Daily reward claims, escrow settlement, and epoch minting need low fees, mature verifier tooling, normal wallets, and minimal operational overhead. The contract stack is intentionally small:

Crucially, the token, emission controller, and reward distributor are specified as non-upgradeable. Verifier contracts may change only through timelocked governance. Emission bounds and split constants are immutable. Monetary credibility matters more than upgrade convenience.

Zero-supply launch and bootstrap issuance

The network starts with no OP in existence. That rules out foundation mints, admin mints, vesting mints, and "temporary" pre-mines. But zero supply creates an initialization problem: a percentage-based inflation model cannot emit from zero. The answer is a compute-backed bootstrap phase with fixed constants:

EPOCH_LENGTH = 1 day
BOOTSTRAP_EXIT_SUPPLY = 10,000,000 OP
BOOTSTRAP_VWU_PER_OP = 10,000 VWU
BOOTSTRAP_MAX_EPOCH_EMISSION = 100,000 OP

bootstrap_epoch_emission =
    min(verified_demand_vwu / BOOTSTRAP_VWU_PER_OP,
        BOOTSTRAP_MAX_EPOCH_EMISSION)

The bootstrap phase remains proof-backed. It does not waive useful-work verification; it only replaces the steady-state inflation curve until total supply reaches 10 million OP. After that threshold, the network switches permanently into utilization-driven issuance.

Steady-state monetary policy

Once bootstrap exits, OP issuance becomes annualized inflation on circulating supply with hard bounds expressed in basis points:

MIN_ANNUAL_RATE_BPS = 50      # 0.50%
TARGET_ANNUAL_RATE_BPS = 250  # 2.50%
MAX_ANNUAL_RATE_BPS = 300     # 3.00%

Daily epochs are the chosen cadence because they are responsive enough for real demand shifts, cheap enough to settle on Base, and stable when smoothed with an exponential moving average. Utilization is measured from verified demand divided by normalized active capacity, not from self-reported hardware claims:

utilization_raw_bps =
    min(10,000,
        verified_demand_base_vwu * 10,000 / max(active_capacity_base_vwu, 1))

utilization_ema_bps =
    (prev_utilization_ema_bps * 7 + utilization_raw_bps * 3) / 10

The emission curve is piecewise linear and immutable: 0.50% annualized at or below 30% utilization, 2.50% at 65%, and 3.00% at or above 85%. That curve gives the network a simple economic reflex: overcapacity lowers issuance toward the floor; sustained heat pushes it toward the ceiling. An AI policy model may add only a bounded adjustment of minus 25 to plus 25 basis points. It does not set issuance freely. It nudges a hard-coded curve:

annual_rate_bps = clamp(base_rate_bps + ai_bias_bps, 50, 300)

The feature vector for that bias is public and auditable: utilization EMA, on-chain transfer velocity, node growth, external price ratio versus AWS/GCP/Lambda, and dispute rate. The AI is therefore a bounded policy advisor, not a central bank.

Distribution and claim mechanics

Every epoch mint splits exactly the same way:

node_reward_pool   = 70%
commons_fund_pool = 20%
protocol_dev_pool = 10%

No side pools, discretionary carve-outs, or separate admin emissions are allowed. Node rewards are committed as a Merkle root at epoch close. The claim leaf includes (epochId, operator, amount, workWeight). The recommended claim window is 180 days. Unclaimed rewards roll into the next epoch's Commons Fund allocation rather than silently reverting to a team treasury. That choice is political as much as technical: if value goes unclaimed, it should return to the commons.

Why the currency is compute-backed

The value anchor is not a promise of fiat redemption. It is access to measurable AI work. The network defines reference work curves, translates accepted jobs into Verified Work Units, and compares its effective price surface to public cloud alternatives. As long as the world continues to demand inference and training, a token that directly buys that capacity retains non-speculative utility. The protocol's job is to keep that utility legible by making issuance, capacity, and verification auditable.

The Commons Economy: Governance Model, Proposals, Voting, Rewards, and AI Execution

The Commons Economy is the mechanism that converts social priority into funded work. It is not just a forum and not just a grant program. It is an economic engine in which humans propose useful work, the community votes on what matters, approved work receives cooperative funding, AI agents execute the work on network hardware, and recognition flows back to the different forms of contribution that made the outcome possible.

Proposal flow

Any member can submit a Commons Job proposal. A useful proposal is public, specific, and reviewable. It identifies a problem, defines a target outcome, and gives the network enough information to assess cost, impact, and risk. Examples from the current architecture include multilingual mental-health specialists, privacy-preserving health record systems, climate research datasets, legal document analyzers, and accessibility tools for underserved communities.

Approved proposals are valued from the Commons Fund, which receives 20% of each epoch mint. Valuation considers community vote strength, estimated compute cost, specialist complexity, and impact breadth. In other words, the network is pricing public usefulness rather than clicks.

Voting without linear plutocracy

Commons governance uses square-root weighting rather than simple one-token-one-vote. Voting power is therefore:

voting_power = sqrt(member_stake)

This preserves the idea that stake matters while sharply reducing the governance dominance of very large holders. A holder with 10,000 units of stake has 100 votes. A holder with 1,000,000 units has 1,000 votes: more influence, but not 100 times more. Proposals still need quorum and approval thresholds. The design target is not egalitarian theater, but broad legitimacy.

AI execution inside the Commons

Once approved, Commons work enters the same coordination plane used for operational jobs. Decomposition agents break the work into subtasks. Specialist agents bid on the tasks they are suited for. Training agents coordinate distributed fine-tuning. QA agents validate outputs against explicit acceptance criteria. Hawk and human reviewers close the final gate. This is the architectural expression of the Commons' core division of labor: humans choose the mission, AI agents perform much of the execution, and hardware owners supply the energy and silicon that make execution possible.

The first Commons Job identified in the architecture is appropriately self-referential: privacy-preserving inference on untrusted hardware. The network's first collective act is to solve its own security bottleneck. This is an important strategic choice. Solving secure inference unlocks health, finance, and other regulated workloads, which in turn expands demand, which in turn expands the funding surface for future Commons work.

Reward distribution per job

The Commons specification sketches a per-job reward model that complements, rather than replaces, epoch issuance:

This allocation is notable because it refuses to collapse all contribution into raw compute. Governance, review, and proposal quality are not externalities. They are protocol-relevant work.

Governance principles

The Commons rests on five principles that carry across the rest of the stack: no central authority over the fund, square-root voting to limit whale dominance, proposal and execution transparency, AI autonomy with human oversight, and permissionless participation for proposers, reviewers, and node operators. These principles are not marketing slogans. They are design constraints that explain why emission routing, task verification, and treasury control are all specified as auditable systems rather than internal APIs.

A commons is not defined by who can talk. It is defined by who can allocate labor, who can inspect the rules, and whether the resulting surplus stays public.

Hardware and the Node Network: Tiers, Lifecycle, and Idle Compute Harvesting

One People is intentionally hardware-agnostic. Any device capable of useful AI work can, in principle, participate. The routing layer adapts to what exists rather than requiring operators to buy one approved box. That said, heterogeneous participation still needs a clean normalization model, or the network quickly becomes unfair and unreadable.

Universal capability tiers

The network classifies nodes into four universal tiers based on RAM or VRAM and the class of workloads they can carry:

Tiering is automatic. The node software detects hardware, runs a short benchmark, assigns a tier, and exposes both public and internal capability profiles. The long-term hardware strategy is universal, but the initial contributor module is desktop-only: Linux, macOS, and Windows compile the full node path first, while mobile contribution remains a later Lite-tier extension rather than a Phase 1 assumption.

Security and capacity advertisement

Nodes advertise more than just raw memory. They also expose accelerator family, VRAM, TEE capability, confidentiality support, and uptime posture. The network can therefore route a sensitive health query only to an attested environment, while sending commodity work to any suitable node. TEE families already anticipated include AMD SEV-SNP, Intel TDX, ARM CCA or TrustZone, and NVIDIA Confidential Computing where available.

The expected population is intentionally uneven: roughly 60% Lite and Standard nodes, 30% Pro nodes, and 10% Ultra nodes. That mix mirrors the real world better than an architecture designed only for datacenter-class hardware.

Node lifecycle

The op-node implementation is a thin embedded Rust service inside the Flutter desktop host, not a heavyweight external daemon. On initialization it creates its state directories, restores cached status, loads or generates a session key, scans hardware, and benchmarks the machine. On start it launches six long-lived loops: heartbeat, dispatch receive, execution supervision, proof and result submission, metrics sampling, and reward sync.

The contributor-facing state machine is explicit: Idle, Contributing, Proving, Earning, Suspended, and Updating. Heartbeats run every 15 seconds by default. Reward sync runs every 30 seconds when enabled. Default execution deadlines are short in the current daemon path, and preemption is designed to prefer checkpointing over hard termination. Because the daemon is embedded, host-process exit terminates node execution; the system relies on durable state and reprovisioning rather than on blind restart of half-complete work.

Proof-of-useful-work and normalization

The reward system pays accepted work, not advertised hardware. Hardware tier affects routing eligibility and capacity normalization, but not arbitrary payout favoritism. If a Lite node and an Ultra node execute the same accepted inference lease, they earn the same base work credit for that lease. The faster machine earns more only by completing more verified work over time.

Capacity is normalized through benchmarked base rates:

Lite     =   250 milli-base-VWU / second
Standard = 1,000 milli-base-VWU / second
Pro      = 4,000 milli-base-VWU / second
Ultra    = 16,000 milli-base-VWU / second

Each node's benchmark score is then clamped between 5,000 and 20,000 basis points to prevent benchmark fraud from distorting utilization. Work itself is normalized from reference curves:

inference_vwu =
    (input_tokens * input_token_cost +
     output_tokens * output_token_cost) *
    model_class_multiplier_bps / 10,000

training_vwu =
    accepted_steps * step_cost *
    model_class_multiplier_bps / 10,000

Reward weights may then include secure, uptime, and quality multipliers. Recommended values are 15,000 bps when a verified TEE was required, 10,000 to 12,000 bps for uptime, and 10,000 to 12,500 bps for quality. Those multipliers affect payout distribution, not the emission-rate numerator. That distinction keeps monetary policy tied to base useful work instead of to a bonus surface that could be gamed.

Idle compute harvesting

Idle compute is where consumer hardware becomes economically meaningful at scale. The system is explicitly user-first. A device may offer work only when six hard gates pass together: screen state, recent input inactivity, CPU and GPU load, power status, schedule window, and safety conditions such as thermals and free resources. Recommended defaults are conservative: 120 seconds of inactivity before entry, 15% utilization thresholds, a 60% minimum battery threshold for portable devices, and a minimum five-minute offer window.

The idle predictor uses local-only history, grouped by day of week and 15-minute bucket, and schedules against the 25th percentile of expected remaining idle time rather than the median. This is a deliberately pessimistic forecast. The node undercommits because preemption safety is worth more than short-term throughput. If fewer than seven comparable sessions exist, the cold-start fallback is 10 minutes on plugged-in desktops and 5 minutes on portable devices.

Idle task selection is economic, cache-aware, and conservative. Only explicitly preemptible work qualifies. Assignment score is weighted 40% projected cooperative reward rate, 30% cache locality, 20% duration fit, and 10% resource efficiency. That means a slightly lower-paying job that is already cache-hot and almost guaranteed to finish can outrank a nominally richer job that would spend most of the idle window downloading artifacts.

Training on idle devices is limited to checkpointed LoRA and QLoRA micro-rounds rather than full-model distributed training. Recommended round_steps are 50 to 200, with a default target around 100 and checkpoint intervals of 50 steps. Workers upload only adapter checkpoints, optimizer state, and compressed updates. Compression is equally pragmatic: top-20% sparsification, int8 quantization, and zstd-compressed chunks with Merkle commitments. When the user returns, inference should release accelerator resources within 1.5 seconds and training within 3 seconds after snapshotting adapter state. That timing discipline is what keeps contributor mode compatible with normal ownership of the machine.

Civic Compute: Municipal Deployment and Citizen Dividends

Civic Compute extends the One People architecture from private operators to public-interest institutions. Cities, towns, libraries, school districts, tribal governments, and broadband co-ops can deploy cooperative nodes on public hardware, join the same routing network as private contributors, and flow the resulting value into a community pool. The important point is that civic participation does not create a separate token or a separate routing system. Civic nodes are standard cooperative nodes with additional policy metadata.

Deployment classes and operating model

The civic model defines three deployment classes: access edge sites such as library branches and community centers; municipal hubs such as city IT rooms or school district server rooms; and regional civic clusters for heavier inference, local training rounds, and confidential workloads. A production deployment should include at least one always-on hub, at least two access edge sites, and one payout and governance operator responsible for the community pool ledger and resident communications.

Recommended SLA targets are intentionally concrete: at least 97.0% monthly availability for pilot clusters, 99.0% for non-regulated production workloads, and 99.5% for regulated or confidential attested clusters. Nodes with failed attestation, stale security posture, or repeated proof failures must enter drain mode rather than silently remaining schedulable.

Privacy-preserving resident enrollment

The civic dividend is explicitly designed as a no-surveillance model. Residents enroll in a local community pool voluntarily, prove eligibility with selective-disclosure credentials, and the registry stores only the minimum necessary data: pool identifier, pseudonymous member ID, nullifier, and credential expiry. Accepted issuers may include municipal IDs, library cards, utility accounts, school or community-college enrollment, co-op membership, or another approved local residency attestor.

The pool should not store raw scans of IDs, exact street addresses, prompt history, browsing history, or device telemetry for payout purposes. Anti-duplication is handled through one credential nullifier per person per pool epoch, periodic re-attestation, and fraud review only on duplicate or anomalous claims. The architecture is explicit that prompt content, query count, advertising identifiers, fine-grained location traces, and biometric data are rejected inputs to dividend computation.

Pool accounting and citizen dividends

Community pool revenue combines three sources: user-paid fees attributable to civic nodes, cooperative emission rewards attributable to civic nodes, and optional grants or matching funds. The default split is:

maintenance_reserve   = 10%
local_commons_reserve = 20%
citizen_dividend_pool = 70%

Within the resident dividend pool, the recommended default is a hybrid model: 80% of the dividend is distributed equally and 20% is distributed through a capped participation score. That formula preserves the idea of a civic dividend while still rewarding stewardship and local governance.

equal_pool = citizen_dividend_pool * 0.80
participation_pool = citizen_dividend_pool * 0.20

dividend_i =
    equal_pool / active_members
    +
    participation_pool * participation_score_i / sum(participation_scores)

The participation score is coarse and capped between 0 and 3. A resident can earn one point for verified governance participation, one for approved civic contribution such as review work or facility stewardship, and one for voluntary local compute contribution or approved uptime in a resident-contributed lane. The cap is what stops the dividend from turning into a piecework market dominated by a small cadre of power users.

Routing and local public benefit

Civic routing is a policy layer applied after the network's normal capability and security checks. The priority order is local civic public-service jobs first, local resident workloads second, same-jurisdiction overflow third, and general network jobs fourth. Locality preference flows from same facility cluster to same metro to same municipality or county to same legal jurisdiction, then finally to the general eligible network. These preferences remain subordinate to TEE requirements, data residency rules, latency SLA, fault-domain diversity, and cost ceilings. Civic nodes do not receive extra cooperative credits for identical work; their advantage comes from policy preference and pooled dividend distribution, not from protocol favoritism.

Local and global governance split

Global cooperative governance controls protocol contracts, emission bounds, and security minimums. Local civic governance controls facility placement, reserve use, procurement, and local charter terms within allowed bounds. The recommended local governance body is a seven-seat Civic Compute Council: one municipal or co-op operations seat, one public-institution seat, one privacy and civil-liberties seat, one technical operator seat, and three resident-elected seats. Local pool governance is one verified resident, one vote. This is a deliberate separation from token-weighted global governance because public municipal infrastructure should not be purchasable by outside whales.

Security and Privacy: Local-First Architecture, Open Implementation, and Secure Inference

The security posture of One People begins with architectural minimization. The safest prompt is the one that never needed to leave the user's device. The safest local activity log is the one the protocol never attempts to centralize. The safest monetary policy is the one an operator cannot quietly rewrite. Local-first design, open implementation, and strong verification are therefore treated as one security program rather than three unrelated values.

Local-first by default

Nexus can operate locally, and the node architecture is explicit about what data must remain local. Raw keyboard, mouse, touch, stylus, and controller histories must not be transmitted. Screen contents, screenshots, window titles, unrelated process names, raw calendar content, precise local filenames, device serial numbers, and MAC addresses must not appear in telemetry or settlement surfaces. Even idle scheduling uses local-only predictors; only coarse idle state, likely idle duration, and content hashes for cache summaries are exposed to the network.

The node implementation also splits capability profiles into public and internal forms. BrainAI needs enough information to route work, but not enough to build an unnecessary fingerprint of the operator's device. Diagnostics exports are redacted. Reward claims are replay-protected through a persistent claim journal and on-chain checks. Session keys are separate from wallet keys. These are not glamorous features, but they are how a contributor network remains defensible when operated by ordinary people on ordinary machines.

Open implementation and immutable checks

One People's open-implementation commitment matters because a commons without inspectable code collapses back into trust-me governance. The most important surfaces are specified to be auditable in public: task state transitions, capability advertisements, proof envelopes, claim paths, and the emission controller's bounds. The smart-contract architecture goes further by minimizing mutable power. EmissionController is the only minter. Bootstrap exit is one-way. Verifier replacement is timelocked. Reward splits are immutable. The EVM recomputes cheap invariants directly rather than blindly trusting the zk proof. That combination of open implementation and constrained contract authority is what makes "no central override" a technical statement rather than a cultural aspiration.

Secure inference on untrusted hardware

Secure inference is treated as a first-order protocol objective because the network wants to serve sensitive workloads without collapsing back into centralized hosting. TEE-capable nodes advertise attestation material. Routing constraints can require that a task land only on a node where TEE is both available and attested. For confidential or regulated jobs, proof bundles must bind job_id, lease_id, node_id, model_hash, and the resulting output or checkpoint hash. Depending on sensitivity policy, raw vendor quote references may be enough, or zk execution attestations may be required before final submission.

The epoch proof system adds another layer. At epoch close, the verifier must be able to establish that verified demand came from accepted receipts, active capacity came from attested active nodes, policy inputs came from committed public data, the AI bias stayed inside minus 25 to plus 25 basis points, and the node reward root sums exactly to the minted node reward pool. This is aggregated correctness, not on-chain replay of AI workloads. That distinction is economically important: the network keeps expensive model execution off-chain while still demanding cryptographic evidence for the quantities that affect money.

Human oversight where it actually matters

One People is designed for automation, not for automation theater. The protocol explicitly requires human escalation when acceptance criteria are materially incomplete, when tasks touch medical, legal, financial, or safety-critical domains beyond pre-approved policy, when budget exceeds authorization, or when a phase enters a halted state. Hawk's deep_audit level exists to make sure that "AI autonomy" does not become a euphemism for skipping the part where someone remains accountable.

Roadmap: Phased Rollout

The One People architecture is intentionally phased. Several elements are viable immediately, while others should follow only after earlier layers have proven themselves under real load. The roadmap below synthesizes the current implementation and deployment specs into one sequence.

Phase 1: Foundation and zero-supply launch

The first phase establishes the non-negotiable base: unified One People naming across the product surface, the Nexus control model, the Base settlement contracts, and the desktop contributor skeleton. The cooperative model launches with zero tokens — if a token is introduced in the future, it would launch as a zero-supply ERC-20 with EmissionController as the only minter. The node stack builds hardware scanning, benchmarked tier classification, canonical protocol DTOs, registration, heartbeat, and signed message transport. Success in this phase means the network can register nodes, meter accepted work, and close the first useful-work epochs without any private token allocation.

Phase 2: Execution, proof building, and claims

The second phase turns the contributor network into a functional economic system. External runtime adapters for llama.cpp, ONNX Runtime, and vLLM come online. The execution supervisor handles artifact staging, deadlines, checkpointing, and process-group cleanup. Proof building and attestation bundles mature. Reward receipt ingestion, Merkle proof validation, and Base claim submission complete the flow from useful work to claimable cooperative credits. At the end of this phase, operators should be able to contribute work, receive canonical reward receipts, and claim settlement through a standard wallet path.

Phase 3: Commons activation and the first public goods loop

With issuance and reward flows working, the Commons can move from concept to production. Proposal intake, square-root voting, bounty valuation, and job execution through the APEX/planner/Sentinel/Hawk pipeline become first-class protocol behavior. The obvious first flagship job is secure inference on untrusted hardware because it increases the network's future addressable market while proving the Commons can solve a strategically central problem. Success here is not just "a governance UI shipped." It is a cycle in which public proposals are funded, executed, verified, and fed back into the network's capability surface.

Phase 4: Idle compute and consumer-scale participation

Once the core node path is stable, idle compute harvesting extends participation beyond intentionally-operated desktops and workstations. The idle monitor, capacity governor, checkpoint manager, and earnings indexer unlock the "your hardware earns while you sleep" path without violating the user-first contract. LoRA and QLoRA micro-round training become normal on Standard, Pro, and Ultra nodes during safe windows. Success in this phase means the network can absorb intermittent consumer hardware at scale while preserving responsiveness, proof integrity, and operator trust.

Phase 5: One-city civic pilot

The civic rollout begins with a single municipality or co-op proving the operational, privacy, and payout model in production. Deliverables include one community charter, one privacy-preserving enrollment path, one dividend payout path, one small civic cluster, and one public transparency dashboard. The success criteria are unusually concrete: stable operations for at least one quarter, multiple successful dividend epochs, no major privacy incidents, and measurable evidence that local routing improves latency or public-service reliability.

Phase 6: Municipal toolkit and self-service onboarding

After the first pilot, the goal is reproducibility. Deployment playbooks, governance templates, hardware bills of materials, routing policy templates, wallet and admin interfaces, and modular credential adapters turn Civic Compute from a bespoke partnership into a repeatable public-infrastructure program. The final subphase is self-service onboarding, where towns, libraries, school districts, tribes, and co-ops can create compliant civic pools with limited manual support from One People. At that point civic capacity becomes a normal, scalable part of the network rather than a one-off showcase.

Conclusion

One People proposes that the next durable AI stack will not be defined by model quality alone. It will be defined by who controls the compute, who can inspect the rules, who receives the surplus, and whether the system can serve both private and public needs without collapsing into central management. The architecture presented here is an attempt to make those answers concrete.

Nexus gives the user a local-first center of gravity. APEX and the wider coordination plane turn intention into accountable distributed labor. The node network turns heterogeneous hardware into a useful execution substrate. The cooperative model gives the system an economic layer where members share idle compute and de-identified data, and the community shares trained AI experts back. A token-based economy is a distant future possibility, not the current model. The Commons Economy ensures that public goods can be proposed, funded, and produced in the open. Civic Compute extends the same model to municipalities and co-ops so that AI infrastructure can behave like a local utility rather than a permanent extraction channel.

This does not eliminate complexity. It formalizes it. That is exactly what serious infrastructure should do. If One People succeeds, it will not be because it found a more elegant way to centralize AI. It will be because it made coordination, verification, and public accountability strong enough that centralization stops looking inevitable.