SYNXCheck a SYNX run without trusting SYNX.
One Python file. No network, no SYNX install, no key, no account. Copy it onto an air-gapped machine, point it at an exported job, and it tells you whether that run’s sealed proof holds — without asking anything of us.
For runs sealed from 30 September 2026 (chain v2), use the verifier above. The earlier edition on GitHub checks the recorded links and the root only; it stays available for runs sealed before that date.
It refuses the bundled example. On purpose.
The example ships with a valid chain and a signature from a key you have no reason to trust. So it exits 2.
$ python verify_synx.py examples/verified_job.json
job 1f04c660-3d77-47d5-8c82-1850fda030ba
nodes in chain 30
sealed root proof 0582f0117d8a9ec02a0b0d2c14d590eaba32a2d71602b4e88ac4784248a3f88b
recomputed 0582f0117d8a9ec02a0b0d2c14d590eaba32a2d71602b4e88ac4784248a3f88b
origin: UNTRUSTED_KEY
INTEGRITY VERIFIED — this export was NOT ALTERED.
But ORIGIN IS NOT PROVEN. An internally consistent chain can be
fabricated wholesale. Only the signature, checked against a key
you already trust, rules that out.
exit 2The arithmetic already succeeded (what it covers is under “What it does not check” below). What failed is origin, because an internally consistent chain proves nothing about where it came from — anyone can generate a keypair and sign anything with it. Add the deployment’s public key, obtained through a channel you control, and the same command exits 0. The README walks all four steps.
Seven questions, kept separate
Collapsing them is how a verifier ends up overstating what it checked.
Integrityno input needed
Does the chain agree with its sealed root?
SHA-256. The verifier recomputes every node — its content digest and all of its children — up to the root, across all 30 nodes, and compares the result with the sealed root. The root is checked against the deployment's signature with a key you pinned (see Origin). Python standard library only.
Origin
Did it come from the deployment it claims?
Ed25519 signature checked against a public key you obtained out of band. We cannot establish that custody for you, and the tool says so.
Environment
A production run, or a rehearsal?
Pinned beside the key in your copy. The export gets no vote — a sandbox job cannot relabel itself as evidence.
Entitlement
Is this a licensed install?
Reported only, never gating. An unlicensed deployment still seals a valid proof, and an expired licence never invalidates a past one.
Attestation
What did the run actually do?
How many steps ran, how many the quality and fabrication gates flagged, when it sealed, which key submitted it, and a digest of the engine that ran it — signed separately. Editing a flagged count from 5 to 0 breaks the signature.
Revocation
Is the signing key still trustworthy?
A signed revocation list from the licence authority — never from the key it describes — fetched when you choose and checked offline. A list more than 90 days old reports STALE.
Anchor
Was this run backdated?
The deployment signs the set of runs it has sealed, and you publish that somewhere it does not control. The run is then bounded from above: it existed no later than the anchor.
What the sealed hashes commit to
Easy to assume less than is true, so stated plainly.
- What each node wrote, and everything beneath it. A node's hash covers a digest of its actual output — not a label — and the hashes of all of its children, so the sealed root commits to the work of every node.
- That a workflow report belongs to this run. Hand the report to the verifier alongside the export and it recomputes the hash — proof of correspondence, with no content in the export.
- The gate outcomes. Steps recorded, steps flagged, and by which gate — signed, and tamper-evident down to a single edited count.
The export still carries no content — no prompts, no data, no deliverable. You get the commitment without the disclosure, which is what makes an export safe to hand to a third party.
What it does not check
A verification tool that is vague about its limits is worse than no tool, because it produces confidence it has not earned. A passing result does not tell you any of this:
- What the content behind each digest says. The export carries every node's content digest, not the content: the verifier recomputes the chain from those digests to the sealed root, and cannot tell you what the content said.
- That a gate's verdict was the right one to reach. A deterministic gate — grounding, fabrication, constitutional validation — can be re-run on the sealed inputs to confirm its verdict follows from its rule; no tool certifies that the rule is right. A cognitive judge's verdict cannot be reproduced that way, and the measured accuracy rate that would tell you how far to trust it does not exist yet.
- That the deployment is the one you think it is. That rests entirely on how you obtained its key. There is no certificate authority, deliberately.
- That the engine did not lie about itself. A privileged attacker on the host could forge the engine digest; defending against that needs hardware-rooted attestation, which this is not.
- That an anchor was really published beyond the operator's reach. The tool proves a run is named in a signed statement and reports its date; where that statement went is a question about the world, not the file.
- When a run happened, from below. An anchor says no later than; nothing but the chain's own order says no earlier than; and the sealed time itself is the deployment's own signed assertion, not an independent timestamp authority's.
- A run executed by a pipeline SYNX does not run. Its record carries a narrower boundary proof (the admitted request, the executor's identity, the exact bytes returned) and says it does not cover the pipeline's own steps, but there is no node chain to export, so this tool cannot check it today.
If you need any of the above, this is the wrong tool — and we would rather you knew that before you relied on it.
What used to be on this list. A limits section is more useful when it shrinks. These are now checked:
- Who submitted the job — the attestation carries the submitting key's id and label.
- Which build the deployment says ran — the attestation carries a digest of its source tree, which catches drift between the tested build and the running one. It is the engine's own measurement, not hardware attestation, and it is marked unmeasured when it could not be taken.
- Whether the signing key has been revoked — see Revocation above.
- Whether a run was backdated — see Anchor above.
What else is public
The verifier
A single readable file — no build step, no dependencies for the integrity check. Fork it, audit it, embed it in your own tooling.
verify_offline.py →The test suite
The GitHub edition’s 62 tests in six categories, each running the verifier as a real subprocess. Including the one that matters most: a valid production licence attached to a sandbox run still exits 2. (That edition predates chain v2.)
A real exported job
A genuine 30-node execution record, sealed before chain v2: the current verifier reports it as legacy (links and root only). It carries hashes and structure only — no prompts, no data, no deliverable.
verified_job.json →Why we give this away
Calling a vendor’s own /verify endpoint proves less than it appears to. The maths may be sound, but you are trusting their server, running their code, on data they hold. “Trust our endpoint” is the position an audit exists to escape — so it cannot be the position we leave an auditor in.