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.
| Boundary | Implementation / evidence | Meaning |
|---|---|---|
| Website / CVC | Existing original v0 / Vercel application | Public same-origin HTTPS interface |
| Bounded execution service | Gamma fixed-work lane and signed results | Real profiles; initial processes under one administration |
| Historical ledger API | Preserved computenet-mainnet-1 history | Read-only eight-block accounting, not active native consensus |
| Truth Stack / native candidate | Recovered components and isolated tests | General proof and independent-security claims remain scoped |
Practical procedure
- 1Identify which component actually produced the data.
- 2Inspect the source/runtime/policy commitment for execution evidence.
- 3Verify the historical ledger separately from public receipts.
- 4Do not infer production integration from a frontend diagram or a simulated topology.
Browser → HTTPS gateway → bounded execution / signed evidence
↘ historical read API → protected 8-block ledger
Isolated native consensus / settlement: not activated
Separate historical dashboard: demonstration onlyLimits 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.
| Boundary | Implementation / evidence | Meaning |
|---|---|---|
| Eligibility | Unique nonempty registered useful computation | Empty or duplicate work adds no canonical credit |
| Ordering | Greatest fully validated accumulated expected resource work | Receipt count, identity count and recycled payments add no weight |
| Confirmations | Probabilistic / reorganisable | No unconditional finality depth or maximum reorganisation |
| Admission | Ordinary keys can supply valid eligible work | Independent honest resources and propagation assumptions remain necessary |
Practical procedure
- 1Independently validate the bootstrap and every record.
- 2Reject malformed work, unknown policy versions and duplicate semantic work.
- 3Compare fully validated resource weight; withhold confirmation on ambiguous equal-work forks.
- 4Recover validated current history; never administratively reset finalized accounting to a stale balance.
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.
| Boundary | Implementation / evidence | Meaning |
|---|---|---|
| Identity / package | Recovered ZIP 1 and ZIP 2 tooling | Identifies code, inputs and runtime declarations |
| Execution / replay | Registered Node profiles | Real bounded hashing and exact integer arithmetic |
| Signed evidence | Ed25519 / known policy | Authenticates an execution attestation |
| General proofs | ZK / zkVM / hardware attestation | Research—not qualified guarantees in today’s public service |
Practical procedure
- 1Choose a supported profile and explicitly public input.
- 2Execute fixed source under the qualified runtime boundary.
- 3Compare outputs across separate replay processes.
- 4Verify the signed artifact and recompute the supported result.
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.
| Boundary | Implementation / evidence | Meaning |
|---|---|---|
| Software identity | Frozen archive + starter manifest | Verify exact digests before running |
| Execution environment | Non-root disposable Linux container | Read-only root, zero capabilities, private state, no host ports |
| Node initialization | Synthetic public bootstrap / own fresh keys | Never imports a wallet, production history or founder credentials |
| Acceptance report | Locally signed public JSON | Records actual rehearsal results, not independent administration |
Practical procedure
- 1Open Join ComputeNet and review the requirements.
- 2Download and verify the qualification starter using the displayed pinned digest.
- 3Run its explicit qualification-only command in a fresh private directory.
- 4Inspect the acceptance report and retain your local private keys; no automatic upload occurs.
# 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.
| Boundary | Implementation / evidence | Meaning |
|---|---|---|
| Eligibility | Unique nonempty registered useful computation | Empty or duplicate work adds no canonical credit |
| Ordering | Greatest fully validated accumulated expected resource work | Receipt count, identity count and recycled payments add no weight |
| Confirmations | Probabilistic / reorganisable | No unconditional finality depth or maximum reorganisation |
| Admission | Ordinary keys can supply valid eligible work | Independent honest resources and propagation assumptions remain necessary |
Practical procedure
- 1Independently validate the bootstrap and every record.
- 2Reject malformed work, unknown policy versions and duplicate semantic work.
- 3Compare fully validated resource weight; withhold confirmation on ambiguous equal-work forks.
- 4Recover validated current history; never administratively reset finalized accounting to a stale balance.
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.
| Boundary | Implementation / evidence | Meaning |
|---|---|---|
| assignment | workload_id, package_id, request_id, policy_id | Binds the result to the exact registered job context |
| policy | Known digest and initial signing keys | Compare to an independently retained pin, never trust embedded keys alone |
| evidence[] | Unique Ed25519 execution attestations | Check signatures, successful return code, runtime and stdout digest |
| output_commitment / receipt_id | Canonical commitments | Detect altered execution metadata and receipt contents |
Practical procedure
- 1Retain the complete result JSON, not just a receipt identifier.
- 2Check the known policy, assignment and unique signatures.
- 3Compare the signed stdout digest with the actual returned result.
- 4Recompute the original public input separately; preserve the evidence.
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.
| Boundary | Implementation / evidence | Meaning |
|---|---|---|
| Browser boundary | Same-origin HTTPS / fixed upstream routes | No caller-selected upstream or server-side wallet signing |
| Evidence boundary | Pinned policy / canonical commitments / Ed25519 | Reject altered, duplicate, unknown or mismatched attestations |
| Execution boundary | Fixed source, bounded input/runtime, non-root isolation | No arbitrary uploaded program or privileged host command |
| Economic boundary | Production activation remains gated | A receipt cannot authorize issuance, payments or governance |
Practical procedure
- 1Verify software/policy provenance through an independently trusted channel.
- 2Keep private identities local with restricted permissions.
- 3Retain authentic evidence and classify the scope of each successful check.
- 4Stop on source/state/runtime mismatches; never replace a failed check with a simulated success.
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.
| Boundary | Implementation / evidence | Meaning |
|---|---|---|
| Gateway observation | Actual health/policy response + browser timestamp | Availability of that request only |
| Workload observation | Actual job ID and signed result | No fabricated throughput or global daily total |
| Configured host metadata | Known Seed/Gamma records | Not independently measured online operators |
| Independent resource evidence | Consenting hosts / own keys / WAN traces | Not yet supplied by local identities or containers |
Practical procedure
- 1Record source, timestamp, scope and actual response.
- 2Separate configured addresses from measured reachability.
- 3Retain errors and missing measurements as unavailable.
- 4For outside qualification, measure resource throughput, propagation, recovery and actual costs.
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.
| Boundary | Implementation / evidence | Meaning |
|---|---|---|
| Historical records | 8 blocks / height 7 | Original genesis and transfers preserved |
| Historical test issuance | 350 COMPUTE | Seven 50-COMPUTE issuance events; no new issuance here |
| Reconciled migrated balance | 342 COMPUTE | Historical transfers of 5, 2 and 1 remain accounted for |
| Declared schedule | 21-million cap; 50 initial subsidy / 210,000 halving interval | Future issuance eligibility/cadence needs explicit ratification |
Practical procedure
- 1Separate issuance ordinals from a future zero-issuance ordering record.
- 2Check authorized customer funding and exact quoted recipients/fees.
- 3Reject duplicate obligations, replay and unauthorized debits.
- 4Independently reconcile balances and supply; production payments remain disabled.
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.