Novarithm Protocol A Decentralized Standard Compute Ownership and Reservation Network “Compute is becoming a primitive. Ownership should be as open as the network.” Version: 1.0 Date: February 2026 Website: novarithm.xyz Developed by: Arithm Nova Group Notice (Read First) This paper describes a protocol design and a research direction. It is not an offer to sell securities or a solicitation to buy any asset. Nothing in this document should be interpreted as a promise of profit, yield, appreciation, or financial return. Novarithm involves significant technical, market, and regulatory risks. Participation may be restricted in certain jurisdictions. ⸻ Abstract Artificial intelligence is turning compute into a foundational economic input. Yet access to frontier compute remains concentrated among centralized cloud providers, and most decentralized compute networks struggle to create durable ownership because they implicitly tokenize hardware—an asset class subject to rapid obsolescence. Novarithm proposes a different abstraction: standard compute ownership as a fixed-supply network share, rather than a claim on any specific device generation. The base asset, ComputeBTC, has a maximum supply of 21,000,000 units (8 decimals). Each unit represents a persistent claim on a fraction of the network’s frontier-normalized compute capacity, realized through a reservation-rights mechanism: ComputeBTC is locked, not spent, to produce time-bounded entitlements to compute delivery. The protocol is built to separate financial liquidity from industrial demand through a dual-mode architecture: 1. Asset Mode: ComputeBTC can be transferred and priced in open markets. 2. Utility Mode: developers and enterprises obtain compute services using fiat or stablecoins, without needing to permanently hold volatile inventory; reservation rights can be sourced from a leasing market. For institutions that require compliance and privacy to access on-chain liquidity, Novarithm integrates ILAL (Institutional Liquidity and Access Layer): a session-based, zero-knowledge compliance layer designed for Uniswap v4 Hooks that verifies institutional eligibility without exposing personally identifiable information on-chain.  Novarithm’s thesis is simple: if compute becomes a base-layer commodity, then standardized compute ownership should be as portable, divisible, and credibly scarce as the network itself—while making explicit the inevitable trust assumptions of any protocol that touches the physical world. ⸻ Table of Contents 1. Introduction 2. Design Goals 3. The Asset: ComputeBTC 4. Standard Compute Units (SCU) 5. Dual-Mode Architecture 6. Protocol Mechanics 7. Incentives and Economics 8. Institutional Access and Privacy (ILAL) 9. Security Model 10. Trust Assumptions and Failure Modes 11. Implementation Path 12. Conclusion Appendix A: SCU Methodology (Benchmarking and Updates) Appendix B: Economic Security Parameters Appendix C: Glossary ⸻ 1. Introduction Compute is no longer merely infrastructure; it is a constraint on scientific progress, product iteration, and AI deployment. Today, the market is dominated by centralized intermediaries that control pricing, allocation, and access. This creates three structural problems: • Concentration: a small set of vendors and chip supply chains define “who gets to build.” • Fragile ownership: most actors cannot directly hold “compute” as an asset; they hold equity proxies or short-lived hardware. • Hardware depreciation: when decentralized networks tokenize device capacity, the asset inherits the device’s obsolescence curve. Novarithm aims to define a compute primitive that behaves like a network-native property: divisible, transferable, and resistant to the “yesterday’s hardware” trap. ⸻ 2. Design Goals Novarithm is designed around the following goals: 1. Fixed supply, no dilution The base compute ownership asset must have a programmatically fixed cap. 2. Standardization without pretending the world is simple A compute unit must be defined in a way that minimizes subjective “hardware exchange rates,” while admitting that the frontier changes. 3. Utility without mandatory token inventory Enterprises should be able to consume compute via familiar payment rails; token holding is optional. 4. Verifiable delivery with explicit security bounds Computation verification is not universally deterministic. The protocol must provide: • client-verifiable evidence where possible, and • economically secure verification where not. 5. Thin-waist architecture The protocol’s “core” must remain small and auditable, while integrations (DEX liquidity, compliance layers, payment rails) remain modular and replaceable. 6. Institutional readiness without on-chain identity leakage Provide a path for regulated capital to interact with liquidity and settlement without placing PII on-chain. ⸻ 3. The Asset: ComputeBTC 3.1 Definition and Supply ComputeBTC is the base asset of Novarithm. • Max supply: 21,000,000 • Decimals: 8 • Non-inflationary: supply is permanently capped ComputeBTC is not designed as a “pay-per-job” consumable token. Instead, it functions as a reservation-rights bearer instrument: holders can lock ComputeBTC to obtain time-bounded entitlements to compute delivery. 3.2 What a ComputeBTC Represents ComputeBTC represents a persistent claim on a fraction of network capacity as measured in standardized compute units (SCU) for a given epoch. Let: • S = 21{,}000{,}000 (total ComputeBTC supply) • C_e = total frontier-normalized network capacity (in SCU) available in epoch e Then the per-token entitlement for epoch e is: q_e = \frac{C_e}{S} A holder who locks x ComputeBTC for epoch e can reserve up to: x \cdot q_e \;\;\text{SCU} Important: Novarithm does not guarantee that C_e grows. The definition guarantees proportionality; it does not guarantee trajectory. ⸻ 4. Standard Compute Units (SCU) The protocol’s credibility depends on how SCU is defined. If SCU is “a committee’s exchange rate between H100 and B200,” the system becomes an index with governance risk. Novarithm therefore defines SCU as a unit of work measured by an open benchmark harness, not a static mapping from chip names. 4.1 SCU as Work, Not Hardware An SCU is defined as completion of a standardized workload bundle under fixed constraints (model, precision, context window, batch, and verification artifact). Because compute is not monolithic, Novarithm uses compute classes, each with its own SCU definition: • SCU-I (Inference): standardized inference throughput tasks • SCU-F (Fine-tuning): standardized fine-tuning step tasks • (Optional in future) SCU-T (Training subnet): higher-interconnect, specialized regime Each epoch publishes C_e as a vector by class: C_e = (C_{e,I}, C_{e,F}, ...) Reservations specify the class they consume. 4.2 Measurement and Reproducibility Providers must run a public harness: • deterministic container images • fixed workload seeds • standardized output commitments (hashes) • reproducible measurement procedure This makes SCU measurement auditable and challengeable. The protocol does not require anyone to “believe” a chip label; it requires acceptance of reproducible measurement. 4.3 Updates: The Reality of a Moving Frontier No benchmark suite is eternal. Novarithm treats SCU updates as protocol upgrades, not casual governance. • Fixed cadence: e.g., SCU suite updates at predefined intervals • Time-delayed activation: a timelock between announcement and activation • Forkability: in the extreme case of disagreement, the methodology can fork This is not a weakness to hide; it is a physical-world truth to specify. (Appendix A provides a concrete SCU methodology template.) ⸻ 5. Dual-Mode Architecture Novarithm separates ownership liquidity from compute consumption. 5.1 Asset Mode In Asset Mode: • ComputeBTC is transferable • markets can form liquidity and price discovery • holders may choose to lease reservation rights to users Asset Mode is not a promise of profit. It is a property of transferability. 5.2 Utility Mode In Utility Mode: • users buy compute services using stablecoins or fiat rails (through compliant gateways) • the system acquires reservation rights on their behalf via a leasing market • users receive compute delivery without long-term token inventory Utility Mode exists to serve real workloads: • inference • fine-tuning • real-time AI applications ⸻ 6. Protocol Mechanics 6.1 Compute Reservation Transactions (CRT) A Compute Reservation Transaction (CRT) locks ComputeBTC to mint a time-bounded compute entitlement. A CRT specifies: • owner • locked amount x • epoch range [e_{start}, e_{end}] • compute class (SCU-I, SCU-F, …) • maximum SCU consumption • settlement asset (e.g., stablecoin) • dispute window parameters ComputeBTC is released after the reservation expires or is fully settled. 6.2 Work Receipts and Settlement When a provider completes work, it issues a Work Receipt containing: • CRT reference • SCU delivered • commitment to inputs/outputs (hashes) • execution metadata (time, class, provider id) • provider signature Receipts are batched per epoch into a Merkle root committed on-chain, enabling efficient auditability and pruning. 6.3 Proof of Execution (PoE): Economic Verification General compute verification is hard. Novarithm uses a practical model: • Stake-backed providers • challenge window disputes • replication sampling • slashing for provable fraud or repeated nondelivery This creates economic correctness: cheating becomes irrational under appropriate parameters. ⸻ 7. Incentives and Economics 7.1 Participants • Providers: supply compute, stake, earn fees • Holders: own ComputeBTC, may reserve or lease rights • Users: consume compute, pay fees • Watchers: monitor receipts and disputes, earn bounties • Governance: parameter updates, security budgets, SCU suite upgrades 7.2 Provider Rewards Providers earn fees proportional to SCU delivered, net of penalties. They also stake to participate; stake is slashable for fraud and nondelivery. 7.3 Leasing Market: “No Token Inventory” for Enterprises A leasing vault aggregates ComputeBTC deposits and sells time-bounded reservation rights. • holders earn leasing revenue (market-determined) • enterprises pay stablecoins/fiat via gateways • the protocol mints CRTs from leased ComputeBTC This is the bridge between Asset Mode and Utility Mode. 7.4 Upgrade Incentives (Compute Upgrade Budget) To reduce the “depreciating hardware” trap without making the protocol a centralized hardware buyer, Novarithm uses an upgrade budget to subsidize frontier-class capacity provision. Mechanism (one example): • a portion of fees funds a “frontier capacity auction” • providers bid to deliver SCU at a price and quality tier • the protocol selects lowest-cost, highest-quality capacity • subsidies flow to verified deliveries This shifts the burden of hardware procurement to providers while letting the network preferentially reward frontier efficiency. No mechanism here guarantees network growth; it only shapes incentives. 7.5 NOVA Governance and Incentive Token Novarithm introduces NOVA (max supply: 1,000,000,000) as a governance and coordination token. Proposed allocation: • 40% – ecosystem and node incentives • 25% – core contributors (multi-year vesting) • 20% – community distribution and early contributors • 15% – strategic partnerships and liquidity support NOVA is intended for: • governance votes • parameter tuning (stake requirements, dispute windows) • SCU suite upgrade activation • ecosystem incentives and grants NOVA is not equity in any corporate entity. ⸻ 8. Institutional Access and Privacy: ILAL Institutions face two barriers when interacting with on-chain liquidity: • regulatory compliance (KYC/AML) • privacy (PII exposure) and transaction friction (gas) Novarithm integrates ILAL (Institutional Liquidity and Access Layer) as an optional institutional access rail for Asset Mode liquidity and large-scale settlement flows. 8.1 What ILAL Is ILAL describes itself as “Zero-Knowledge Compliance Infrastructure for Uniswap v4,” enabling institutional access with privacy via ZK-SNARKs.  Its technical architecture is session-based verification integrated with Uniswap v4 Hooks.  8.2 Session-Based Compliance ILAL uses: • one-time proof verification • a session TTL (e.g., 24 hours) • lightweight “session active” checks for subsequent actions ILAL’s documentation claims substantial gas/cost reductions via session caching relative to per-transaction verification.  8.3 Technical Components (as documented) ILAL documents four core components: • Registry: configuration center (trusted issuers, router whitelist, global parameters, emergency pause)  • SessionManager: caches verification state with a session TTL and batch query support  • ComplianceHook: Uniswap v4 access control hook that intercepts operations (e.g., beforeSwap, beforeAddLiquidity, beforeRemoveLiquidity), verifies EIP-712 signed hookData, and checks session status  • PlonkVerifier: on-chain verification of PLONK proofs, validating public inputs such as user, merkle root, and issuer  8.4 Why Uniswap v4 Hooks Matter Uniswap v4 allows a pool to define a “hook contract” that executes custom logic at specific points in a call lifecycle.  This makes “native compliance gates” feasible without wrapping the pool in a separate system. (Hooks introduce new security considerations and attack surface; see Section 9.4.)  ⸻ 9. Security Model Novarithm’s security model targets three properties: 1. Correct settlement: reservation rights cannot be double-allocated 2. Honest delivery: providers cannot profitably claim compute they did not deliver 3. Censorship resistance at the protocol layer: no single operator can unilaterally deny reservations or settlements (subject to trust assumptions) 9.1 Threats • provider fraud (fake receipts, partial execution) • nondelivery (accept job, do nothing) • collusion (provider + watcher) • measurement manipulation (benchmark cheating) • governance capture (SCU suite, parameters) • integration failures (DEX, stablecoin, compliance layer) 9.2 Probabilistic Fraud Detection If each job is replicated with probability p, and a provider cheats on k jobs, the probability of escaping detection is: (1-p)^k The system chooses p and slashing severity so that the expected value of cheating is negative. 9.3 Stake Sizing (Simple Bound) Let: • V = value a provider can extract by cheating on a job • S = slashable stake associated with that job class • p = replication probability A conservative condition for negative expected value is: p \cdot S \;>\; (1-p)\cdot V \quad\Rightarrow\quad S \;>\; \frac{1-p}{p}\,V Large-value jobs require larger stake or higher replication probability. 9.4 Hook Security Considerations (ILAL / DEX Integrations) Hooks can broaden the attack surface at the user-hook interface and require careful access control, validation, and upgrade safety. Security research highlights risks such as permission mismatches, incorrect return values, missing access control, and privileged-role compromise.  For this reason, Novarithm treats DEX/compliance integrations as modular adapters, not core consensus. ⸻ 10. Trust Assumptions and Failure Modes A compute protocol cannot be as closed as a purely mathematical system. Novarithm becomes credible by making its trust assumptions explicit and minimized. 10.1 The Minimal Core The core protocol must remain small and auditable: • ComputeBTC ownership and locking/unlocking • CRT creation and entitlement accounting • receipt commitments and dispute/slashing rules Everything else is replaceable. 10.2 Unavoidable Assumptions 1. Physical delivery exists Providers operate real machines. The protocol can punish fraud; it cannot make physics disappear. 2. SCU methodology evolves Benchmarks update over time. Novarithm’s defense is: • reproducible methodology • slow, time-delayed activation • forkability 3. Economic security is probabilistic Verification uses sampling and incentives. The defense is parameterized safety bounds and optional stronger verification tiers. 10.3 Failure Modes • SCU dispute: methodology perceived as biased • mitigation: transparent harness, timelock, forkability • Verification regime too weak: fraud becomes profitable • mitigation: parameter adjustment, higher stake, increased sampling, tiered verification • External integration failure (DEX/ILAL/stablecoin): • mitigation: thin-waist core; integrations are optional adapters; system degrades rather than dies • Regulatory constraints: • mitigation: ILAL rail for compliant institutional access where appropriate; clear jurisdictional restrictions; do not embed PII on-chain  ⸻ 11. Implementation Path Novarithm is designed to be deployed in phases: 1. Phase 0 – Reference Harness + Testnet SCU benchmark suite, receipt format, basic dispute framework. 2. Phase 1 – Utility Mode MVP Leasing vault, routing layer, provider onboarding with staking. 3. Phase 2 – Asset Mode Liquidity ComputeBTC markets, optional DEX adapters, oracle-free pricing discovery. 4. Phase 3 – Institutional Rails Integrate ILAL for compliant access to liquidity and settlement for eligible participants.  5. Phase 4 – Specialized Subnets High-interconnect subnets for workloads requiring tighter coupling, with explicit trust assumptions and stricter operator sets. ⸻ 12. Conclusion In the previous era, the network learned that money could be made native: divisible, transferable, and not dependent on a central issuer. In the AI era, compute is becoming equally fundamental. But compute lives in the physical world. A protocol cannot erase that fact; it can only confront it honestly. Novarithm proposes: • a fixed-supply compute ownership asset (ComputeBTC) • a reservation-rights mechanism that turns ownership into delivered utility • a benchmark-defined standardized compute unit that minimizes subjective “hardware exchange rates” • an economically secure delivery system with explicit probabilistic bounds • a modular architecture that treats integrations as optional, replaceable rails • a privacy-preserving institutional access path via ILAL and Uniswap v4 Hooks  Compute is power. If compute becomes a primitive, ownership should not be locked behind a handful of gates. Novarithm is a proposal to return that primitive to the network. ⸻ Appendix A: SCU Methodology Template (Benchmarking and Updates) A1. Public Harness • containerized workloads • deterministic seeds and dataset slices • published output commitments • reproducible measurement script A2. Multi-Class Units • SCU-I for inference • SCU-F for fine-tuning • optional SCU-T for specialized training subnet A3. Anti-Cheating Rules • random “canary tasks” injected for replication • validator-run replays of benchmark tasks • penalties for benchmark manipulation A4. Update Rule • fixed cadence • public test period • timelock activation • forkability in irreconcilable disputes ⸻ Appendix B: Economic Security Parameters (Template) • replication probability p by job class • minimum stake S by maximum job value V • challenge window length by class • watcher bounties as fraction of slashed stake • nondelivery penalties (timeouts) ⸻ Appendix C: Glossary • ComputeBTC: fixed-supply compute ownership asset • SCU: standardized compute unit (work-defined, class-based) • CRT: compute reservation transaction (locks ComputeBTC for time-bounded entitlement) • Receipt: signed proof of delivered work (commitments + metadata) • ILAL: institutional liquidity and access layer (ZK compliance + session caching via Uniswap v4 Hooks)  • Hook: Uniswap v4 pool extension contract called at defined lifecycle points  ⸻ References • Uniswap v4 Whitepaper (Hooks, Singleton, Flash Accounting, Native ETH, Custom Accounting).  • Uniswap v4 Docs – Hooks (core hook functions and lifecycle points).  • ILAL – Technical Architecture (Registry, SessionManager, ComplianceHook, PLONK verifier, session TTL, benchmarks).  • ILAL – Overview (ZK compliance infrastructure for Uniswap v4; session caching; privacy claims).  • CertiK – Uniswap v4 Hooks Security Considerations (attack surface, permission mismatch, access control, privileged roles).