HomeWhitepaper

ComputeNet Whitepaper

Historical whitepaper and current implementation companion

The published V5-named PDF is preserved unchanged; its contents are internally labeled v4 and Open Public Testnet. This web companion distinguishes research proposals from the service actually available on 12 November 2026.

Historical whitepaper PDF
Published filename V5 · internally labeled v4 · historical

Abstract

Compute anywhere. Verify through ComputeNet. ComputeNet is a computational-verification ecosystem. The live public service performs bounded document hashing and exact integer aggregation, returning policy-bound signed execution evidence. Broader decentralized verification and native consensus remain qualification work.

1. Introduction

Reproducible workload identities, execution packages, replay and signed evidence help users inspect computation. They do not by themselves prove arbitrary program correctness, economic security or independent network administration. The current service does not execute arbitrary customer code or AI workloads.

2. Protocol philosophy

The intended protocol is permissionless and ownerless, with equal ordinary participant rights. This is a design objective, not the current deployment state. Seed, Gamma and the initial execution/signing identities share one administration; actual independent consensus participation has not been demonstrated.

3. System architecture

The existing website and CVC reach a server-side HTTPS gateway. Supported jobs run in bounded execution environments; separate verifier processes issue Ed25519 evidence under a pinned policy. Public receipts are separate from the protected eight-block historical ledger. The compound native ordering and settlement adapter is an isolated candidate, not a production writer.

Existing systems and their interfaces

The website is one part of ComputeNet. Execution evidence, historical reads, the isolated native candidate and research systems have distinct deployments and guarantees.

BoundaryImplementation / evidenceMeaning
Website / CVCExisting original v0 / Vercel applicationPublic same-origin HTTPS interface
Bounded execution serviceGamma fixed-work lane and signed resultsReal profiles; initial processes under one administration
Historical ledger APIPreserved computenet-mainnet-1 historyRead-only eight-block accounting, not active native consensus
Truth Stack / native candidateRecovered components and isolated testsGeneral proof and independent-security claims remain scoped

Practical procedure

  1. 1Identify which component actually produced the data.
  2. 2Inspect the source/runtime/policy commitment for execution evidence.
  3. 3Verify the historical ledger separately from public receipts.
  4. 4Do not infer production integration from a frontend diagram or a simulated topology.
Technical reference · scope is explicit
Browser → HTTPS gateway → bounded execution / signed evidence
       ↘ historical read API → protected 8-block ledger

Isolated native consensus / settlement: not activated
Separate historical dashboard: demonstration only

Limits and failure cases

  • Direct-IP HTTP examples are not supported browser production guidance.
  • Private TLS roots and credentials stay server-side.
  • A distinct machine or key does not establish a distinct administrator.

4. Proof of Useful Compute

The frozen compound proposal requires unique eligible useful computation plus fresh complementary native resource work. Empty records, copied receipts, duplicated computation and recycled payments must not manufacture canonical credit. Successful tests do not establish a sufficient security-resource budget. No such ordering or new COMPUTE issuance is active in production.

Native ordering and recovery — isolated candidate

The compound candidate requires useful computation plus fresh complementary resource work. Production consensus remains inactive, with parameters and economic/security commitments unratified.

BoundaryImplementation / evidenceMeaning
EligibilityUnique nonempty registered useful computationEmpty or duplicate work adds no canonical credit
OrderingGreatest fully validated accumulated expected resource workReceipt count, identity count and recycled payments add no weight
ConfirmationsProbabilistic / reorganisableNo unconditional finality depth or maximum reorganisation
AdmissionOrdinary keys can supply valid eligible workIndependent honest resources and propagation assumptions remain necessary

Practical procedure

  1. 1Independently validate the bootstrap and every record.
  2. 2Reject malformed work, unknown policy versions and duplicate semantic work.
  3. 3Compare fully validated resource weight; withhold confirmation on ambiguous equal-work forks.
  4. 4Recover validated current history; never administratively reset finalized accounting to a stale balance.
Technical reference · scope is explicit
Mandatory useful execution + fresh resource proof
  → full independent record validation
  → accumulated expected work comparison
  → probabilistic confirmations

No qualifying useful jobs → stalled head, not empty rewards.

Limits and failure cases

  • A resource-majority adversary can reorganise valid history, including payments.
  • Software tests do not establish economic security or an honest-resource budget.
  • Ratification, actual outside resources and separate production authority are required.

4A. Verification pipeline

For the two live deterministic profiles, users can independently recompute the result and verify policy-bound signatures and commitments. A signature authenticates an attestation by a key, not universal correctness or independent ownership. General ZK/zkVM proofs, arbitrary AI verification and hardware attestation are not qualified public guarantees. Truth Stack research is described separately.

The layered verification pipeline

Different verification mechanisms answer different questions. The implemented public lane makes a narrow result independently checkable; broader proof systems remain research.

BoundaryImplementation / evidenceMeaning
Identity / packageRecovered ZIP 1 and ZIP 2 toolingIdentifies code, inputs and runtime declarations
Execution / replayRegistered Node profilesReal bounded hashing and exact integer arithmetic
Signed evidenceEd25519 / known policyAuthenticates an execution attestation
General proofsZK / zkVM / hardware attestationResearch—not qualified guarantees in today’s public service

Practical procedure

  1. 1Choose a supported profile and explicitly public input.
  2. 2Execute fixed source under the qualified runtime boundary.
  3. 3Compare outputs across separate replay processes.
  4. 4Verify the signed artifact and recompute the supported result.
Technical reference · scope is explicit
Public input
  → registered package
  → bounded execution
  → assignment-bound signatures
  → output and receipt commitments
  → portable result / on-device checks

Limits and failure cases

  • No arbitrary customer program, AI proof or universal correctness claim.
  • A deterministic output can be independently recomputed; administration independence needs separate evidence.
  • No synthetic score is substituted when execution or signature validation fails.

5. Validator network

Two known infrastructure hosts are not two independently administered operators. Four signing keys in the initial execution policy are not four independent validators. Fresh peer reachability, global regions, network-wide latency, uptime and validator throughput are not inferred from configured addresses. Off-mainnet volunteer qualification is available without founder credentials; live consensus joining is inactive.

Install, initialize, qualify

The starter preserves the old simple joining intent while replacing its unpinned installer. It is deliberately off-mainnet and uses newly generated local identities.

BoundaryImplementation / evidenceMeaning
Software identityFrozen archive + starter manifestVerify exact digests before running
Execution environmentNon-root disposable Linux containerRead-only root, zero capabilities, private state, no host ports
Node initializationSynthetic public bootstrap / own fresh keysNever imports a wallet, production history or founder credentials
Acceptance reportLocally signed public JSONRecords actual rehearsal results, not independent administration

Practical procedure

  1. 1Open Join ComputeNet and review the requirements.
  2. 2Download and verify the qualification starter using the displayed pinned digest.
  3. 3Run its explicit qualification-only command in a fresh private directory.
  4. 4Inspect the acceptance report and retain your local private keys; no automatic upload occurs.
Technical reference · scope is explicit
# Open the guided starter at /validator-qualification#join
# It checks source/runtime integrity and preserves prior state.
# No services, host ports, mainnet activation or financial option.

Native CLI reference inside the verified source:
node.py init --bootstrap PUBLIC_SYNTHETIC_BOOTSTRAP
  --sha256 EXACT_BOOTSTRAP_SHA256 --directory NEW_PRIVATE_DIRECTORY

Limits and failure cases

  • Two local nodes remain one administrator; an outside operator must run their own infrastructure and keys.
  • WAN/public exposure requires consenting peers, independently checked public certificates and host-specific qualification.
  • Never reuse production keys or treat installation as reward entitlement.

6. Consensus model

The unactivated compound candidate proposes greatest fully validated accumulated resource work, conditional on qualified useful computation. Confirmations are probabilistic and reversible; there is no guaranteed finality depth or unconditional maximum reorganisation. Resource-majority, propagation and eclipse assumptions must be supported by real independent resource commitments before activation. Insufficient eligible useful jobs means a stalled head, never empty-work credit.

Native ordering and recovery — isolated candidate

The compound candidate requires useful computation plus fresh complementary resource work. Production consensus remains inactive, with parameters and economic/security commitments unratified.

BoundaryImplementation / evidenceMeaning
EligibilityUnique nonempty registered useful computationEmpty or duplicate work adds no canonical credit
OrderingGreatest fully validated accumulated expected resource workReceipt count, identity count and recycled payments add no weight
ConfirmationsProbabilistic / reorganisableNo unconditional finality depth or maximum reorganisation
AdmissionOrdinary keys can supply valid eligible workIndependent honest resources and propagation assumptions remain necessary

Practical procedure

  1. 1Independently validate the bootstrap and every record.
  2. 2Reject malformed work, unknown policy versions and duplicate semantic work.
  3. 3Compare fully validated resource weight; withhold confirmation on ambiguous equal-work forks.
  4. 4Recover validated current history; never administratively reset finalized accounting to a stale balance.
Technical reference · scope is explicit
Mandatory useful execution + fresh resource proof
  → full independent record validation
  → accumulated expected work comparison
  → probabilistic confirmations

No qualifying useful jobs → stalled head, not empty rewards.

Limits and failure cases

  • A resource-majority adversary can reorganise valid history, including payments.
  • Software tests do not establish economic security or an honest-resource budget.
  • Ratification, actual outside resources and separate production authority are required.

7. Compute Receipts

The live service returns a complete signed result JSON with job, assignment, policy, evidence and result commitments. Download it in CVC and check the pinned policy and signatures locally. Recompute the submitted input separately. Signed execution evidence does not establish COMPUTE settlement, ledger finality, legal compliance or independent administration.

Receipt anatomy and verification

The public service returns a real policy-bound execution artifact. Its fields have specific bindings; they are not an arbitrary proof or an independent-operator census.

BoundaryImplementation / evidenceMeaning
assignmentworkload_id, package_id, request_id, policy_idBinds the result to the exact registered job context
policyKnown digest and initial signing keysCompare to an independently retained pin, never trust embedded keys alone
evidence[]Unique Ed25519 execution attestationsCheck signatures, successful return code, runtime and stdout digest
output_commitment / receipt_idCanonical commitmentsDetect altered execution metadata and receipt contents

Practical procedure

  1. 1Retain the complete result JSON, not just a receipt identifier.
  2. 2Check the known policy, assignment and unique signatures.
  3. 3Compare the signed stdout digest with the actual returned result.
  4. 4Recompute the original public input separately; preserve the evidence.
Technical reference · scope is explicit
Trusted legacy policy
sha256:ca5ccb4ac07f505c8cdc69d5368b677bb2b99c4eb3704655d689fa94c30e7f8e
Patched-runtime policy (after qualified cutover)
sha256:1b6ae938262ac0ba88b717cf416035def35f223eb5aed75ca149928fbe7eabcf

GET /api/public-work/jobs/YOUR_ACTUAL_JOB_ID

Receipt agreement ≠ canonical financial finality.

Limits and failure cases

  • Signatures authenticate keys, not independent people.
  • The initial workers share one administration.
  • A local check report is unsigned and does not replace the original receipt.

8. Security model

Isolation, bounded input/runtime limits, HTTPS, source/policy pins and signature validation are real engineering boundaries. Internal tests and AI review are not an independent security audit. Compromised keys, implementation defects and shared administration remain material risks. Do not submit confidential data, credentials or wallet keys to public workloads.

Trust boundaries and practical checks

Security comes from specific controls and explicit assumptions. No website badge, AI review or internal test count is an independent security audit.

BoundaryImplementation / evidenceMeaning
Browser boundarySame-origin HTTPS / fixed upstream routesNo caller-selected upstream or server-side wallet signing
Evidence boundaryPinned policy / canonical commitments / Ed25519Reject altered, duplicate, unknown or mismatched attestations
Execution boundaryFixed source, bounded input/runtime, non-root isolationNo arbitrary uploaded program or privileged host command
Economic boundaryProduction activation remains gatedA receipt cannot authorize issuance, payments or governance

Practical procedure

  1. 1Verify software/policy provenance through an independently trusted channel.
  2. 2Keep private identities local with restricted permissions.
  3. 3Retain authentic evidence and classify the scope of each successful check.
  4. 4Stop on source/state/runtime mismatches; never replace a failed check with a simulated success.
Technical reference · scope is explicit
Read-only source and pinned artifacts
  ├─ HTTPS public API / bounded inputs
  ├─ qualified fixed-source runtime
  ├─ known-policy receipt verification
  └─ separate financial/consensus activation gate

Limits and failure cases

  • Signatures do not prove independent administration or arbitrary computation correctness.
  • Internal tests are scoped evidence; they are not an external audit or economic-security guarantee.
  • No certified SOC/ISO/GDPR service or paid bounty commitment is claimed.

9. Telemetry

CVC reports an actual gateway health observation, client check time and request round-trip when available. This is not worker uptime, consensus health or global peer latency. Aggregate throughput, verification volume, region coverage and independent validator counts are not published as measured production metrics.

Observe without inventing telemetry

A gateway request has a time and round trip. That measurement is useful, but it is not global peer latency, validator uptime or consensus health.

BoundaryImplementation / evidenceMeaning
Gateway observationActual health/policy response + browser timestampAvailability of that request only
Workload observationActual job ID and signed resultNo fabricated throughput or global daily total
Configured host metadataKnown Seed/Gamma recordsNot independently measured online operators
Independent resource evidenceConsenting hosts / own keys / WAN tracesNot yet supplied by local identities or containers

Practical procedure

  1. 1Record source, timestamp, scope and actual response.
  2. 2Separate configured addresses from measured reachability.
  3. 3Retain errors and missing measurements as unavailable.
  4. 4For outside qualification, measure resource throughput, propagation, recovery and actual costs.
Technical reference · scope is explicit
Observation = source + time + actual measurement + limitation
Gateway RTT ≠ validator latency
Signing keys ≠ independently controlled operators
Historical height ≠ advancing production consensus

Limits and failure cases

  • No invented uptime percentage, eight-region map, 47-peer total or confidence score.
  • A resource benchmark is not a guaranteed attacker-cost lower bound.
  • No arbitrary outside-operator count proves founder-independent security.

10. Historical genesis and economics

The protected computenet-mainnet-1 history has eight blocks at height 7, 350 COMPUTE historical test issuance and a reconciled migrated balance of 342 after transfers of 5, 2 and 1. The declared cap is 21,000,000; original subsidy research specifies 50 COMPUTE and halving every 210,000 issuance events. Mining, new issuance, customer payments, transaction fees and rewards are inactive. Neither this page nor a receipt ratifies future economics or authorizes changing balances.

Historical accounting and the original schedule

Historical facts are preserved separately from future incentive policy. A public Compute Receipt is not an issuance authorization.

BoundaryImplementation / evidenceMeaning
Historical records8 blocks / height 7Original genesis and transfers preserved
Historical test issuance350 COMPUTESeven 50-COMPUTE issuance events; no new issuance here
Reconciled migrated balance342 COMPUTEHistorical transfers of 5, 2 and 1 remain accounted for
Declared schedule21-million cap; 50 initial subsidy / 210,000 halving intervalFuture issuance eligibility/cadence needs explicit ratification

Practical procedure

  1. 1Separate issuance ordinals from a future zero-issuance ordering record.
  2. 2Check authorized customer funding and exact quoted recipients/fees.
  3. 3Reject duplicate obligations, replay and unauthorized debits.
  4. 4Independently reconcile balances and supply; production payments remain disabled.
Technical reference · scope is explicit
Original subsidy research (not an activation instruction):
issuance ordinal 0 … 209,999:    50 COMPUTE
issuance ordinal 210,000 … 419,999: 25 COMPUTE
Subsequent halvings remain subject to the declared cap.

Current mining / issuance / rewards / payments: INACTIVE.

Limits and failure cases

  • Initial zero-issuance qualification does not permanently abolish the original schedule.
  • No customer payment, stake transfer or return is offered by the qualification installer.
  • No automated retry/refund or rollback of real balances is authorized by a reorganisation example.

11. Development status

LIVE: bounded document hashing, integer aggregation, signed receipts and their public HTTPS interface. ISOLATED CANDIDATE: compound consensus, receipt-bound settlement, recovery and ordinary operator tooling. NOT ACTIVE: production native consensus, mining, issuance, COMPUTE payments and rewards. NOT DEMONSTRATED: genuine independent operator control, resource security and founder-offline live continuity. The original PDF is a historical research artifact and may contain superseded status descriptions.

12. Long-term vision

A useful-computation network with independent operators and verifiable native accounting remains the intended destination. Broader workloads, economic security and ownerless live operation require additional qualification and explicit protocol/economic and production approvals. They are not offered as current service guarantees.

13. Protocol ethos

Preserve original history and wallet access, publish reproducible technical evidence and make future participation objective rather than founder-privileged. Historical founder-controlled test issuance must be disclosed; intentions of fair participation are not evidence of an already independent launch.

14. Scope and limitations

The live public service is experimental bounded computation verification; it is not an active reward or investment offering. No guaranteed value, returns, mining income, compliance certification or universal correctness proof is promised. No financial or consensus activation is authorized by these web descriptions.

Original V5 PDF SHA-256: 4ac84163bac5dd91efa2144fec70b83fdbbb3f215c161eb8e2ffcbc8c2a4a7c2. Preserved from the published repository revision de788c1f7ad13e7100df2f21a339aa04a5c6dba8; historical descriptions are not current activation evidence.