Verify without trusting us

The verification chain, in three steps

The only trust anchor is the Ed25519 public key published at https://omegaengine.ai/.well-known/jwks.json (a standard JWKS, RFC 7517) — and you can pin that at issuance so even the domain does not have to be trusted later.

Try it now — one command, zero keys

This command fetches a deterministic sample attestation from the live API (GET /api/verify/sample) and verifies its EdDSA signature and content hash locally, on your machine. No signup, no key, nothing to configure:

# Works today. No account, no API key, no secret.
npx -y @omegaengine/verify@latest sample --api https://omegaengine.ai

# ✓ VERIFIED — issued by https://omegaengine.ai (key vGgd...)
# Exit codes: 0 verified · 1 not verified · 2 usage error

The sample envelope embeds its own demo public key so the smoke test is fully deterministic; real attestations verify against the production JWKS at /.well-known/jwks.json.

Step 1 — fetch the log head (STH)

The Signed Tree Head is the log's current commitment: its size and Merkle root, signed with the same Ed25519 key. Monitors poll it to detect split-views; verifiers anchor proofs to it. Public, no auth:

curl -s https://omegaengine.ai/api/transparency/sth

{
  "ok": true,
  "sth": {
    "kind": "omega-attestation-sth",
    "version": "1",
    "logId": "omega-attestation-transparency.v1",
    "treeSize": <number of logged attestations>,
    "rootHash": "<RFC 6962 Merkle root, hex>",
    "timestamp": "<ISO 8601>",
    "signatureV2": "<EdDSA JWS over the root — verify against /.well-known/jwks.json>"
  }
}

signatureV2 is an EdDSA JWS over the root hash. Verify it with any JOSE library against the published JWKS — if it checks out, the log operator has cryptographically committed to exactly this tree.

Step 2 — prove an attestation is in the log

Given an attestation id (64 hex characters — the SHA-256 of the canonical body, printed on the attestation itself), fetch its RFC 6962 inclusion proof:

# {id} = the attestationId — 64 hex chars, sha256 of the canonical body
curl -s https://omegaengine.ai/api/transparency/proof/{id}

{
  "ok": true,
  "leaf": "<the attestationId>",
  "leafIndex": <position in the log>,
  "treeSize": <log size at proof time>,
  "auditPath": ["<sibling hash>", "..."],
  "sth": { "...": "the signed tree head this proof anchors to" }
}

Fold the auditPathhashes up from the leaf (standard RFC 6962 Merkle-tree math — any CT library implements it) and you must land exactly on the STH's rootHash. If you do, the attestation was publicly logged and cannot be quietly retracted or rewritten without breaking every later consistency proof.

Step 3 — fetch the attestation and re-verify it yourself

The public verify endpoint returns the full stored artifact for any attestation id, plus the checks our servers ran on it:

curl -s https://omegaengine.ai/api/verify/{id}

{
  "ok": true,
  "id": "<attestationId>",
  "verified": true,              // ← server-verified convenience — do NOT stop here
  "checks": { "attestation": {...}, "ledger": {...} },
  "attestation": { "...": "the full signed artifact, incl. signatureV2" },
  "ledger": { "...": "Merkle proof ledger (when present)" },
  "inclusion": { "...": "transparency-log inclusion proof (when logged)" },
  "storedAt": "<ISO 8601>"
}

• Honest labeling: the `verified` flag and `checks` object are SERVER-VERIFIED — computed on our infrastructure. Convenient, but on their own they still require trusting us.
• The trustless part is everything else in the response: the endpoint hands you the complete attestation (including signatureV2), the proof ledger, and the inclusion proof — precisely so you can re-run every check offline against the published JWKS and take nobody's word for it.
• Because the id is content-addressed, you also verify integrity for free: recompute SHA-256 over the canonical body and it must equal the id you asked for.

Go fully offline — pin the trust anchor

The live JWKS URL trusts the omegaengine.ai domain. For verification that survives domain loss, registrar hijack, or a hosting compromise — or simply for air-gapped review — snapshot the key set once and verify against your pinned copy forever after:

# 1. Pin the key set (at issuance, or right now)
curl -s https://omegaengine.ai/.well-known/jwks.json > omegaengine-jwks-pinned.json

# 2. From then on, verification needs NO network and NO trust in the domain:
npx -y @omegaengine/verify@latest attestation.json \
  --jwks="data:application/json;base64,$(base64 < omegaengine-jwks-pinned.json)"

// Fully offline with the library — zero dependencies, Node built-in crypto only
import { verifyAttestation } from "@omegaengine/verify";
import { readFileSync } from "fs";

const att = JSON.parse(readFileSync("attestation.json", "utf8"));
const jwks = JSON.parse(readFileSync("omegaengine-jwks-pinned.json", "utf8"));

const result = verifyAttestation(att, jwks); // no network — your pin is the trust anchor

After the pin, verification needs no network at all. If the live JWKS ever diverges from your pin, that is either a legitimate key rotation (your pinned kid should still appear in the retired set) or something to investigate — dated JWKS snapshots are committed to the repository as an audit trail.

Do not take the log's word for it either — monitor it

A transparency log is only as honest as its watchers. Both monitoring primitives are public:

# Mirror the raw leaves (attestation ids), page by page
curl -s "https://omegaengine.ai/api/transparency/entries?start=0&limit=100"

# Prove the log at size N is an append-only prefix of the log at size M
# (i.e. nothing was rewritten between the two heads you observed)
curl -s "https://omegaengine.ai/api/transparency/consistency?first=<N>&second=<M>"

• Mirror the leaves with /api/transparency/entries and you hold an independent copy — equivocation (showing different logs to different parties) becomes detectable.
• The consistency proof (/api/transparency/consistency) proves append-only history between any two tree sizes you have observed: the earlier tree must be a prefix of the later one.
• Each STH you record is a signed commitment. Two contradictory signed STHs for the same tree size are cryptographic evidence of misbehavior — publishable, and not deniable.

What is trustless — and what is not

We would rather under-claim than blur this line. Exactly three things are independently verifiable with no trust in OmegaEngine; everything else is a convenience that still rests on our servers:

If a document or salesperson ever presents a server-verified surface as independent proof, hold us to this page.

Verify one in the browser

Everything above also has a no-terminal path: paste an attestation id into the verification page and it renders the same artifact, checks, and inclusion proof.

The verifier is published as @omegaengine/verify (Apache-2.0, zero runtime dependencies) — audit its source before you run it; that is the point.