Paceproof

PaceProof

[CI] [npm] [PyPI] [License: MIT]

PaceProof verifies Ed25519-signed compute-attestation records from any provider and tells you exactly which ones are real.

[PaceProof init and report: scaffolding an example attestation directory, then generating a verified/unverified compute report]

A record with a missing, malformed, or tampered signature never gets folded into a "verified" total; it's counted and reported separately, every time, in both human-readable and --json output.

PaceProof does not sign or generate attestations. It is a neutral, read-only ingest/verify/report/dashboard layer over records that are already signed somewhere else. Point it at a directory, file, or URL of signed records and it tells you, verifiably, what compute was actually run, by whom, and whether every record's signature checks out.

Install

paceproof-cli is published to both npm and PyPI:

npm install -g paceproof-cli# orpip install paceproof-cli

Both commands install a paceproof binary. paceproof-cli is also available as an alias on both registries if you need to disambiguate from another tool on your PATH.

To build from source instead (useful if you're contributing, or want the exact repo state rather than a published release):

TypeScript (npm package, includes the MCP server):

git clone https://github.com/RudrenduPaul/PaceProof.gitcd PaceProof/packages/cli-tsnpm installnpm run buildnode dist/bin.js --help

Python (PyPI package, independent reimplementation):

git clone https://github.com/RudrenduPaul/PaceProof.gitcd PaceProof/packages/cli-pypip install -e .paceproof --help

Both the published npm install -g paceproof-cli and pip install paceproof-cli commands above were run fresh in a clean environment as part of writing this README, and the quickstart output below is real output from those installs, not fabricated.

Table of Contents

• Features
• Quickstart
• CLI command reference
• Library API reference
• How verification works
• Comparison
• What PaceProof is, and why it exists
• FAQ
• Contributing
• License

Quickstart

paceproof initpaceproof report ./paceproof-example

paceproof init generates a fresh Ed25519 example keypair and 7 example attestation records: 3 validly signed, and 4 intentionally broken (a tampered payload, a wrong-key signature, a malformed signature, and a missing signature) so verify/report have real failure modes to demonstrate, not just a happy path.

Real output from an actual run against the published npm package:

$ paceproof report ./paceproof-example
PaceProof report -- source: ./paceproof-examplegenerated at: 2026-08-04T02:54:30.898Z
== VERIFIED ==  records: 3  compute total: 144.50 gpu_hours
== UNVERIFIED (never counted in verified totals above) ==  records: 4  compute total: 1009 gpu_hours  reasons:    - rec-004: signature does not match record contents    - rec-005: signature does not match record contents    - rec-006: signature must decode to 64 bytes, got 4    - rec-007: schema validation failed: (root) must have required property 'signature'
== BY PROVIDER ==  acme-cloud: verified=132 gpu_hours (2 records); unverified_count=0  beta-compute: verified=12.50 gpu_hours (1 records); unverified_count=0  gamma-hpc: verified=(none); unverified_count=2  delta-cloud: verified=(none); unverified_count=2
== BY WORKLOAD TYPE ==  training: verified=128 gpu_hours (1 records); unverified_count=1  inference: verified=12.50 gpu_hours (1 records); unverified_count=1  idle: verified=4 gpu_hours (1 records); unverified_count=1  unknown: verified=(none); unverified_count=1

verify exits non-zero when any record fails (real exit code from an actual run: 1, with 4 unverified records present):

$ paceproof verify ./paceproof-exampleVerified: 3Unverified: 4  FAIL rec-004: signature does not match record contents  FAIL rec-005: signature does not match record contents  FAIL rec-006: signature must decode to 64 bytes, got 4  FAIL rec-007: schema validation failed: (root) must have required property 'signature'$ echo $?1

[PaceProof verify: signature verification against a fresh example directory, then the same check with --json for structured output]

Render a dashboard from the same data:

paceproof dashboard ./paceproof-example --out dashboard.html

[PaceProof ingest and dashboard: normalizing records to canonical JSONL with ingest --out, then rendering a self-contained HTML dashboard]

Both the TypeScript and Python builds were run against paceproof-example for this README, and both produced the same verified/unverified counts and totals shown above.

Features

• Pluggable data-source adapters. ingest normalizes arbitrary input into the canonical schema through a documented Adapter interface (TypeScript interface, Python ABC). The shipped jsonl adapter reads newline-delimited JSON already in canonical form; a provider-specific adapter (e.g. for ComputeLedger's native export) implements the same interface without touching the aggregator, report renderer, or CLI wiring.
• Ed25519 verification with strict verified/unverified separation. Every record is checked for schema validity and signature validity. A record that fails either check is never silently merged into a verified total: verified and unverified counts and compute totals are computed from disjoint sets and shown side by side in every report.
• Two independent, parity-tested implementations. The TypeScript package (npm) and the Python package (PyPI) are separate, real implementations, not a wrapper around one or the other. Both produce byte-identical report --json output for the same input; a CI job runs the TypeScript CLI's output against the Python CLI's output on a shared fixture in both directions and fails the build on any divergence.
• Self-contained static HTML dashboard. paceproof dashboard renders a single HTML file with inline CSS and no JavaScript: no CDN fonts, no external scripts, no remote requests of any kind. Currently ships one clean light theme; there's no dark-mode toggle yet.
• MCP server for agent invocation. paceproof mcp starts a Model Context Protocol server exposing verify, ingest, and report as callable tools, so an orchestrating agent can call PaceProof programmatically instead of shelling out to a human-facing CLI. The tool handlers are thin wrappers around the same aggregator/report functions the CLI itself calls, with no separate reimplementation for the MCP path.
• Security-hardened by design, not by afterthought. Aggregation buckets are built with Object.create(null) so an attacker-controlled provider or compute_unit field like "__proto__" can't pollute Object.prototype. The one network call PaceProof ever makes (ingest <url>) is bounded by a 30-second timeout and a 50 MiB response cap, enforced against the actual streamed byte count rather than trusting a Content-Length header. Every schema field carries an explicit maximum length so oversized input can't be used to exhaust memory before validation runs.

CLI command reference

Every table below is copied from the actual --help output of the published paceproof-cli npm package (v0.1.0).

paceproof init [path]

Scaffold an example directory with a sample keypair and validly/invalidly signed example records.

paceproof verify <path>

Verify Ed25519 signatures on every record found at <path>.

paceproof ingest <path-or-url>

Run a named adapter over the input and emit normalized canonical-schema records as JSONL.

paceproof report <path>

Ingest and verify records at <path>, then aggregate into a summary report.

paceproof dashboard <path>

Render a single self-contained static HTML dashboard from a report.

paceproof mcp

Start an MCP server exposing verify, ingest, and report as callable tools. TypeScript package only for now: running paceproof mcp from the Python package prints a message pointing to the npm package and exits non-zero.

Every command supports real non-zero exit codes on failure or verification failure, and --help on every subcommand.

Library API reference

The npm package also exports its internals directly (main/types in package.json point at real library code, not just the CLI entry point), for anyone building a custom adapter or embedding verification logic in another tool instead of shelling out to the CLI. This surface is TypeScript-only; the Python package exposes paceproof as a CLI only, with no documented import API.

import { getAdapter, verifyRecords, summarize } from 'paceproof-cli';import type { Adapter } from 'paceproof-cli';
const records = await getAdapter('jsonl').read('./paceproof-example/records.jsonl');const outcomes = verifyRecords(records);const report = summarize(outcomes);

There's no separately generated API doc site (no TypeDoc build in CI yet) -- the table above is the reference until one exists. Every signature was grepped directly from packages/cli-ts/src/ on 2026-08-03, not reconstructed from memory.

How verification works

Every attestation record is a JSON object validated against a single canonical JSON Schema (schema/attestation-record.schema.json), the same file, byte-for-byte, that both the TypeScript and Python packages ship and validate against. A record needs record_id, issued_at, provider, hardware, workload_type, compute_amount, compute_unit, issuer_public_key, and signature; every string field has an explicit maximum length so malformed or oversized input fails fast instead of being parsed first and bounded later.

The signature field is an Ed25519 signature over the canonical JSON encoding of every other field: object keys sorted lexicographically, UTF-8 encoding, no insignificant whitespace, numbers rendered without a leading + or unnecessary trailing zeros. Both implementations produce byte-identical canonical JSON for the same record, so a signature verified by one implementation verifies under the other.

A record is "verified" only if it passes both checks: schema-valid and signature-valid. Anything else (a missing signature, a signature that decodes to the wrong byte length, a signature that doesn't match the payload, a signature made with the wrong key) is "unverified." These two sets are always disjoint in the aggregator's code, not just in the way a report happens to render them: verified and unverified compute totals are accumulated into separate structures, and there is no code path that adds an unverified record's compute_amount into a verified total. A reporting tool that quietly conflates "claimed" and "proven" numbers launders unverifiable claims into something that looks verified, which defeats the point of an audit trail.

Comparison

Star counts and descriptions below were checked live against each project's GitHub API listing and README on 2026-08-03; none is invented or reused from memory.

Broader searches for a directly comparable "ingest signed compute-attestation records from multiple providers, verify Ed25519 signatures, keep verified and unverified totals separate" tool turned up nothing else matching that specific combination as of 2026-08-03. The closest adjacent category is generic hardware remote-attestation verification (e.g. veraison/services, 47 stars, TPM/SEV-SNP/SGX/TDX evidence): a different attestation domain (hardware boot/runtime state, not compute-usage records) with no compute-attestation schema, no adapter model, and no compute-hours reporting.

What PaceProof is, and why it exists

Compute usage claims from AI labs, cloud providers, and infrastructure operators are getting harder to independently verify as the volume of compute-related discourse grows. The real "Pacing the Frontier" open letter, signed in July 2026 by over a thousand employees across OpenAI, Anthropic, Google DeepMind, and Meta asking for verifiable tools to pace frontier AI development, is one example of that industry conversation, cited here only as motivating context. PaceProof is not affiliated with it, was not built in response to any request from its signatories, and makes no claim of endorsement or partnership.

To be direct about the one thing this README needs to be unambiguous about: there is no real "Verified Slowdown" treaty, and no such treaty exists today. That phrase comes from a speculative forecasting scenario at ai-2027.com, not from any actual international agreement, law, or regulatory body. PaceProof does not implement, enforce, or certify compliance with any treaty, law, or regulation, because no such treaty, law, or regulation applicable to this tool exists.

What PaceProof actually is: a neutral, cryptographically-verifiable reporting layer over compute-attestation data you already have. If you (or a provider you work with) already produce signed attestation records, whether through ComputeLedger, a custom signing pipeline, or anything else that emits Ed25519-signed records, PaceProof tells you which of those records actually hold up cryptographically and totals up only the ones that do, split cleanly from the ones that don't. That's useful today for internal audit trails and cross-provider usage transparency. It is not, and does not claim to be, compliance software for a regulation that doesn't exist.

FAQ

What is PaceProof, and what makes it different from a generic cost-monitoring tool? PaceProof is a read-only CLI and MCP server that verifies Ed25519 signatures on compute-attestation records and reports totals with verified and unverified numbers kept strictly separate, never merged. Cost-visibility tools like SkyPilot or OpenCost report what a billing system says was used; PaceProof reports what a cryptographic signature actually proves, and flags everything else as unverified rather than silently counting it.

Does PaceProof provide legal or regulatory compliance? No. There is no real "Verified Slowdown" treaty or comparable regulation for PaceProof to comply with, and PaceProof makes no compliance claim of any kind. It verifies Ed25519 signatures on records you give it and reports the results. Treat its output as a cryptographic verification report, not a legal or regulatory certification.

Does PaceProof sign or generate attestation records? No. PaceProof is read-only: it ingests, verifies, and reports on records that are already signed elsewhere. If you need to generate signed compute-attestation records, that's a separate concern; see ComputeLedger, a sibling project by the same author, for the signing side.

How is PaceProof different from ComputeLedger? They're complementary, not competing, and built by the same author. ComputeLedger signs and hash-chains compute usage receipts; PaceProof ingests and verifies records that are already signed, from ComputeLedger or any other Ed25519-signing source. If you need to produce signed records, use ComputeLedger. If you need to independently verify records you already have, use PaceProof.

What happens to a record with a bad signature? Does it just get dropped? No. A record that fails schema validation or signature verification is never dropped or silently excluded. It's counted in unverified_count, its compute amount is totaled separately in unverified_compute_total_by_unit, and the specific reason it failed (tampered payload, wrong key, malformed signature, missing field) is reported alongside it. Nothing about a failed record disappears from the output.

Can I add support for a provider whose export format isn't JSONL? Yes, that's what the adapter interface is for. Implement the Adapter interface (TypeScript) or the Adapter ABC (Python): a name and a read(input) method that returns records already normalized to the canonical schema. You don't need to touch the aggregator, the report renderer, or existing CLI wiring beyond registering the new adapter's name.

Does paceproof ingest <url> make arbitrary network calls? Only the one you explicitly ask for. Every other command operates on local files. ingest <url> is the single opt-in network call in the whole tool, and it's bounded: a 30-second timeout and a 50 MiB response cap enforced against the real streamed byte count, not just a Content-Length header the remote server could lie about.

Does PaceProof work on Windows, macOS, and Linux? The npm package requires Node.js 18 or newer and has no OS-specific code, so it runs anywhere Node runs, including Windows, macOS, and Linux. The Python package requires Python 3.10 or newer and is listed as OS Independent on PyPI. Both are pure userland tools with no native compiled dependencies.

Why are there two implementations instead of one CLI with bindings? So each package is a real, independent thing you can install from its native registry (npm or PyPI) without pulling in a runtime for the other language. A shared JSON Schema file and a cross-language parity test suite (run in both directions in CI) keep their report --json output identical, so which implementation you pick doesn't change what you get.

Is the MCP server available in the Python package? Not currently. paceproof mcp is TypeScript-only for now: running it from the Python package prints a message pointing you to the npm package and exits non-zero. Every other command (init, verify, ingest, report, dashboard) is a full, independent Python implementation.

What license is PaceProof under, and can I use it commercially? MIT. You can use, modify, and redistribute PaceProof commercially with no royalty and no requirement to open-source your own code, subject only to keeping the copyright notice and license text per the MIT license terms.

Contributing

CI (.github/workflows/ci.yml) runs three jobs on every push and PR to main: TypeScript lint + typecheck + test, Python lint (ruff) + typecheck (mypy --strict) + test (pytest) across Python 3.10 and 3.13, and a cross-language parity job that builds the TypeScript CLI, installs the Python CLI, and runs each side's parity test against the other's CLI as a subprocess.

To run everything locally:

# TypeScriptcd packages/cli-tsnpm installnpm run lintnpm run typechecknpm test        # 60 tests, Vitest
# Pythoncd packages/cli-pypip install -e ".[dev]"ruff check src testsmypy srcpytest -q       # 52 tests

If you change the schema, update schema/attestation-record.schema.json at the repo root and its copies under packages/cli-ts/schema/ and packages/cli-py/src/paceproof_cli/schema/, and update both implementations' validation logic. A parity test in each package's suite checks its local schema copy against the root file and fails CI if they drift.

See ARCHITECTURE.md for the full repo layout, the canonical JSON rules the signature is computed over, and how the adapter interface and MCP server fit together.

License

MIT. See LICENSE.