Every job runs the same five steps.
Only the job type changes per module. Each step below says whether it is live today or planned.
- 01
Commit
LiveHash the inputs: code commit, files, prompt or spec, model id, settings. The commitment is written to the log before anything else happens.
- 02
Lock the seed
Liveseed = H(commit ‖ hash of a future Solana block). Neither the customer nor ByteGuard can re-run until the answer is the one they want.
- 03
Run
LiveToday a hosted model runs the job and its verbatim output is hashed and committed; the verdict follows deterministically from it. Phase 4: a self-hosted deterministic node that gives byte-identical output on any conforming machine.
- 04
Receipt
LiveOne-time hash-based signatures (LMS / LM-OTS, RFC 8554) over every entry, appended to a Merkle log. Hourly signed tree heads exist today. Daily roots anchored on Solana come in Phase 2.
- 05
Spot-check
Planned (Phase 4)The receipt hash picks random tiles; verifiers recheck only those instead of the whole job. A dispute triggers a full bit-exact replay. Needs the deterministic node.
- The inputs were committed before the answer was seen.
- The answer was recorded unchanged.
- The verdict follows from that recorded answer.
- The record is signed and sits in a public, append-only log.
- That the code is safe. An audit can miss things.
- That anyone can re-run the model and get the same bytes. Today's audits use a hosted model; byte-identical replay is Phase 4.
- That the findings are complete. They name the bug and the fix, never exploit steps.
A receipt proves the audit ran as stated. It does not prove the code is safe.
Open any receipt in the app. Nothing is taken on trust from the server: the receipt key is pinned at build time.
Open the verify page →The same twelve checks from a clean checkout. How outsiders get it is not settled yet.
pnpm verify-receipt -- <receipt url> --key-id <id>