PaceProof

paceproof init paceproof report ./paceproof-example

paceproof initgenerates 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) soverify/reporthave 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-example generated 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

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

$ paceproof verify ./paceproof-example Verified: 3 Unverified: 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 dashboard ./paceproof-example --out dashboard.html

Both the TypeScript and Python builds were run againstpaceproof-examplefor this README, and both produced the same verified/unverified counts and totals shown above.

- Pluggable data-source adapters.ingestnormalizes arbitrary input into the canonical schema through a documentedAdapterinterface (TypeScript interface, Python ABC). The shippedjsonladapter 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-identicalreport --jsonoutput 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 dashboardrenders 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 mcpstarts a Model Context Protocol server exposingverify,ingest, andreportas 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 withObject.create(null)so an attacker-controlledproviderorcompute_unitfield like"__proto__"can't polluteObject.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 aContent-Lengthheader. Every schema field carries an explicit maximum length so oversized input can't be used to exhaust memory before validation runs.

Every table below is copied from the actual--helpoutput of the publishedpaceproof-clinpm package (v0.1.0).

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

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

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

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

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

Start an MCP server exposingverify,ingest, andreportas callable tools. TypeScript package only for now: runningpaceproof mcpfrom 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--helpon every subcommand.

The npm package also exports its internals directly (main/typesinpackage.jsonpoint 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 exposespaceproofas 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 frompackages/cli-ts/src/on 2026-08-03, not reconstructed from memory.

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 needsrecord_id,issued_at,provider,hardware,workload_type,compute_amount,compute_unit,issuer_public_key, andsignature; every string field has an explicit maximum length so malformed or oversized input fails fast instead of being parsed first and bounded later.

Thesignaturefield 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-validandsignature-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'scompute_amountinto 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.

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.

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.

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.

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 inunverified_count, its compute amount is totaled separately inunverified_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 theAdapterinterface (TypeScript) or theAdapterABC (Python): anameand aread(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.

Doespaceproof 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 aContent-Lengthheader 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 theirreport --jsonoutput identical, so which implementation you pick doesn't change what you get.

Is the MCP server available in the Python package?Not currently.paceproof mcpis 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.

CI (.github/workflows/ci.yml) runs three jobs on every push and PR tomain: 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.

This is a web browser that enables your coding agent, such as Claude Code, to visit websites on your behalf and assist you in identifying bugs or creating UI test cases.

Create crafted UI components inspired by the best 21st.dev design engineers.

Bring agent evaluations, observability, and synthetic test set generation directly into your IDE for free with Galileo's new MCP server

An MCP server to help AI assistants to answer questions and generate AccelByte Extend SDK code more effectively .

MCP server for AI Diagram Maker — generate beautiful software engineering diagrams directly inside Cursor, Claude Desktop, Claude Code, or any MCP-compatible AI agent

ALAPI MCP Tools,Call hundreds of API interfaces via MCP

AI-powered SVG animation generator that transforms static files into animated SVG components using the Allyson platform

MCP server that gives AI assistants on-demand access to 1,500+ amCharts docs, ~300 code examples, and 1000+ class API references.

APIMatic MCP Server is used to validate OpenAPI specifications using APIMatic. The server processes OpenAPI files and returns validation summaries by leveraging APIMatic’s API.

One shared context layer for AI agents and humans — live API specs, DB schemas, and versioned contracts across repos so every agent and teammate works from the same source of truth.