Execution.
Evidence.
Independent checking.
The architecture that turns bounded useful computation into inspectable, portable evidence. Explore the identities, execution packages, replay signatures and assurance boundaries behind a real Compute Receipt.
The public verification lane is live. Native consensus, mining and COMPUTE rewards are inactive. TESTED below means isolated qualification, not production security or independent administration.
Portable result
A signed receipt you can inspect
Policy and commitments
Known trust roots, not embedded-key trust
Execution and replay
Bounded deterministic profiles
Canonical inputs
Registered code, public data, runtime identity
The verification journey
Six layers. One traceable execution.
Explore each boundary. The diagram explains architecture; it is not a simulated live job or a map of independently administered validators.
Canonical workload identity
Recovered ZIP 1 tooling gives a deterministic identity to a declared workload. Code, public inputs and runtime declarations are committed; changing the input changes the workload identity. An identity is not a correctness proof or a meter of physical compute.
- Canonical descriptor and deterministic input representation
- Code / input commitments
- Explicit workload and package identifiers
workload_id → cmp_work_… package_id → cmp_pkg_… These exact values are inspectable in a genuine receipt.
Capability-specific assurance
Know what each layer establishes
The stack is substantial, but its guarantees are specific. Expand a layer to inspect its evidence, implementation scope and remaining trust assumptions.
Workload identityTESTED
Canonical descriptors and reproducible execution packages from recovered ZIP 1 / ZIP 2 components.
What it does not establish
Identity binds declarations. It does not establish economic demand or arbitrary correctness.
Bounded executionLIVE
Real document hashing and exact integer aggregation with registered source, input limits and runtime commitments.
What it does not establish
No arbitrary-code, AI-model, user-command or general WASM hosting in the public lane.
Signed execution evidenceLIVE
Assignment-bound Ed25519 attestations, output digests, pinned policy and portable receipt commitments.
What it does not establish
Separate initial processes share one administration. Signatures authenticate claims by keys.
Native ordering and accountingTESTED
Isolated compound useful-computation plus complementary-resource ordering, receipt-bound settlement and recovery.
What it does not establish
Not production-qualified or activated. Probabilistic confirmations remain exposed to superior valid work.
General proofs and adaptive assuranceRESEARCH
Workload-specific assurance, challenge/replay strategies and potential ZK/zkVM or attestation integration.
What it does not establish
No universal proof of correctness, trusted hardware guarantee or synthetic confidence percentage.
Broader workloads and independent operationPLANNED
Extended workload profiles and genuinely separately administered operators, with measured resources and continuity.
What it does not establish
No independent live consensus, production rewards or universal external-operator availability is claimed.
Try the mathematics yourself
Replay a result. Change an input.
This is a genuine on-device calculation, not a synthetic confidence score. Use the public example inputs, compare commitments and then inspect their real signed execution records.
Independent result laboratory
Actual local computation · no network submission
Try changing one character. A document’s exact UTF-8 bytes change its digest. This is not a signed service execution or a consensus vote.
Check the evidence yourself
The examples use public inputs from genuine 12 November qualification jobs. Compare the exact result with its signed receipt in CVC. Local calculations here do not create a Compute Receipt.
Receipt construction
A chain of bindings you can inspect
The evidence object is useful because its fields have specific relationships. These are inspectable commitments, not decorations or invented trust percentages.
Compute Receipt ├─ network + schema ├─ assignment │ ├─ workload_id + package_id │ ├─ request_id → actual job │ └─ assignment_id → commitment ├─ policy → independently pinned digest ├─ evidence[] │ ├─ validator_id → signing key │ ├─ assignment_id → exact assignment │ └─ execution + Ed25519 signature ├─ output_commitment └─ receipt_id → canonical receipt commitment
Identity and context
The same output from another job is not interchangeable evidence. Assignment, request, package and policy bindings are checked.
Signatures and agreement
Reject unknown or duplicate signers, invalid signatures and conflicting execution digests. Current signing identities still share one administrator.
Durable, portable evidence
A service result can be retained and checked without relying on a decorative dashboard. Policy-level receipt agreement is not financial ledger finality.
Preserved original presentation
The historical Truth Stack dashboard
The original v0 page embedded a separate dashboard. It remains available as a clearly separated demonstration—not authenticated telemetry, a current validator roster or live consensus evidence.
HISTORICAL DEMONSTRATION · SIMULATED METRICS
Eight-validator, region, throughput, reputation and confidence figures inside are illustrative, not current production measurements.
Original demonstration, deliberately separated
Load it on request to explore the historical visual concept. No clipboard, same-origin storage, form or popup permission is granted. Its separate internal source is not included in the v0 export.
Understand the stack.
Inspect the evidence.
Real bounded computation is available today. Ownerless native consensus and broader proof systems remain distinct qualification work.