ProofJudge

Settlement receipts for agent work.

Agents are deciding who gets paid. Who verifies the judge?

The four judges · How the proof works · Run it locally · API · Trust boundary

---

Canonical HTTPS demo: proofjudge-demo.proofjudge.workers.dev
The edge route is the stable browser entry. Judgment and signing still execute in the Research EigenCompute deployment, whose app identity remains embedded in every receipt.

AI agents are starting to do paid work, and acceptance is the fragile part. Who judged the result? Was the verdict changed after the fact? Can anyone check it before money moves?

ProofJudge is a verifiable acceptance layer: submitted work is judged against explicit terms and a rubric inside an EigenCompute TEE, and every verdict ships as a signed, tamper-evident DecisionArtifact. A settlement receipt. Anyone can re-verify it against the live judge before payment moves.

The hero moment: edit one byte of a sealed receipt. The score, a hash, anything. Verification fails on the spot: hash mismatch, signature broken, money does not move. The seal is honest crypto, not theater.

The four judges

One proof machine, deployed four times on EigenCompute, each under its own inspectable identity.

	Judge	What it settles	Live console	Identity
{ }	Code	Verifiable review for code bounties and PRs	34.12.29.220:3000	EigenVerify ↗
◎	Research	Claims require sources; sources require verification	35.204.155.165:3000	EigenVerify ↗
⇄	Negotiation	Neutral ground; both parties can verify	34.58.112.209:3000	EigenVerify ↗
▲	Governance	Proposals verified before votes are cast	34.87.56.225:3000	EigenVerify ↗

Open the canonical HTTPS demo or any deployment console and hit Watch the proof. It plays itself: a real case is judged live, sealed, re-verified, then broken in front of you. Touch anything to take the wheel.

Live readiness

Cloud state alone is not treated as proof that a judge works. The public readiness check calls each deployment's health endpoint, variant catalog, and guided demo. Deep verification also creates a real signed receipt and sends it back through /api/verify.

npm run live:check   # bounded public readiness check
npm run live:verify  # judge + sign + verify on all four deployments

Last deep verification: 2026-08-01. All four public judges passed health, demo, live judgment, receipt signing, and verification. The scheduled badge above reruns the bounded readiness check every six hours, opens an incident on failure, and attempts one restart only when EigenCloud reports an exact Exited state.

How the proof works

   terms + rubric + submitted work
                │
                ▼
        ┌──────────────┐    hash inputs        SHA-256
        │  the judge   │    apply rubric       LLM via Eigen AI gateway
        │  (inside a   │    collect evidence   signals + reasoning trace
        │   TEE)       │    seal artifact      record frozen
        └──────────────┘    sign receipt       Ed25519, in the enclave
                │
                ▼
      DecisionArtifact: verdict · score · settlement action
      hashes · judge identity · signature · attestation
                │
                ▼
        POST /api/verify  →  anyone re-checks schema, hashes,
        signature, deployment identity, attestation, timestamp.
        Change any field and verification fails.

The verdict is more than a number. Every receipt carries the evidence matrix (which signals were checked) and the reasoning trace, both signed into the artifact. And the judge is not a yes machine: the seeded docket produces genuine accept, revise, and reject outcomes depending on what the work deserves.

Run it locally

npm install
npm run dev          # http://localhost:3000
npm run check        # build + smoke: "Smoke checks passed for all ProofJudge variants."

Without EigenCompute credentials the judge runs in a clearly labeled deterministic demo mode. Hashing and the tamper-detection loop still work, but the receipt is marked simulated rather than attributed to a published ProofJudge signer.

API

Endpoint	What it does
GET /healthz	Service health
GET /api/variants	Judge metadata for all four variants
GET /api/deployments	Fresh, bounded reachability measurement for all four public judges
GET /api/demo/:variant	Seeded demo inputs
POST /api/judge	Judge a submission, returns a signed DecisionArtifact
POST /api/verify	Re-verify any artifact: schema, hashes, signature, identity, attestation

The trust boundary, stated honestly

Verification proves which deployed evaluator produced which decision record, under which rubric, and that nothing was altered afterward. It does not prove the verdict is objectively correct. ProofJudge makes AI judgment accountable, not infallible.

New deployed receipts use Ed25519 public-key signatures. Verification checks both the signature mathematics and whether the public key is in ProofJudge's published trust registry. The current signer fingerprint is ed25519:b9cccedea909d831a23a55d4cc4676034148b071a00206eacc9ee9567049f07f.

Legacy HMAC and deterministic demo receipts remain readable for continuity. To verify a saved receipt without calling the service:

npm run receipt:verify -- path/to/receipt.json

More

• Agent explainer · Architecture · Architecture diagram
• Demo Day script · Submission packet
• Promo film: docs/social/video/proofjudge-promo-v4.mp4 · Live demo capture: docs/demo-video/proofjudge-live-demo.webm

Proof, not promises. 🧾

Built on EigenCompute. What will you build with TEEs?

---

_{Repository hygiene: .env.example is the only environment file that belongs in the repo. Never commit .env.* deployment files or private preview material.}