Deploy an edge verifier template to your own Cloudflare account. The 5-minute setup is a target, not production acceptance. Hybrid verification is conditional on a real ML-DSA-65 implementation and trusted published keys. Missing keys, stub mode or an unsupported scheme must remain unknown, never hybrid success. See endpoint evidence.
The verifier runs in your own Cloudflare account, not on receipts.thehiveryiq.com. Each Cloudflare location keeps its own copy of the public keys (JWKS), refreshed every 5 minutes through Workers KV. Once that copy is warm, checking a signature makes zero outbound calls.
When a location needs a fresh copy of the keys (at most once every 5 minutes), it fetches them from hivemorph in the background using ctx.waitUntil. That means your caller never has to wait for it.
The verifier ships as a Cloudflare Worker. You need a Cloudflare account (free tier works) and Node.js 18+.
Request access at security@thehiveryiq.com. You'll get a private GitHub link within 24 hours.
git clone git@github.com:hiveciv/hive-edge-verifier.git cd hive-edge-verifier npm install
The verifier uses Cloudflare KV to cache the JWKS public keys at each edge POP.
npx wrangler kv:namespace create JWKS_CACHE
Copy the output id and paste it into wrangler.toml under [[kv_namespaces]].
npx wrangler login
npx wrangler deploy
Your verifier is live at https://hive-edge-verifier.<account>.workers.dev
# Health check curl https://hive-edge-verifier.<account>.workers.dev/v1/health # Verify a Hive cert curl -X POST https://hive-edge-verifier.<account>.workers.dev/v1/verify \ -H "Content-Type: application/json" \ -d '{ "cert": { "cert_id": "04364b3e08d54264b06443693ddf504b", "agent_did": "did:hive:agent:edge-verifier-001", "controller_did": "did:hive:controller:thehiveryiq", "ed25519_signature": "fJD7UEYzekkAGCXIMFfhu5Umw...", "mldsa65_signature": "RFNBLVNUVUIt...", ... } }'
This is an implementation design, not evidence of a deployed hybrid verifier. Native Ed25519 and any ML-DSA module require positive and negative signature tests against independently trusted keys. An unpublished key or stub implementation must return unavailable/unknown, not substitute an Ed25519-only pass for hybrid acceptance.
BASE=https://hive-edge-verifier.<account>.workers.dev # Health check, returns { ok, version, edge_pop, ts, runtime } curl "$BASE/v1/health" # Illustrative JWKS request. Require trusted keys; PQ publication is unverified. curl "$BASE/v1/verify/jwks" # Verifier metadata curl "$BASE/.well-known/hive-verifier" # Request hybrid verification. Unknown/stub PQ must not count as success. curl -X POST "$BASE/v1/verify" \ -H "Content-Type: application/json" \ -d '{"cert": {...}, "mode": "hybrid"}' # Ed25519 only (skip ML-DSA-65) curl -X POST "$BASE/v1/verify" \ -H "Content-Type: application/json" \ -d '{"cert": {...}, "mode": "ed25519_only"}'
The verifier runs on its own, fully separate from receipts.thehiveryiq.com on the fast path. Keys are cached right at the Workers edge.
Hybrid policy requires both Ed25519 and ML-DSA-65 to pass against trusted keys over the intended current payload. This page does not establish that the deployed implementation meets that policy. Missing keys or stub mode must fail closed as unknown/unavailable.
The cert body is encoded with RFC 8949 deterministic CBOR before the signature gets checked. That matches the did:hive spec signing domain.
Workers KV caches the keys at each location for 5 minutes. If the cache is empty, it refreshes in the background with ctx.waitUntil, so nothing gets blocked.
You can send the cert body as a JSON object or a CBOR base64 string. It figures out which one from the request headers.
It supports full CORS, has a /.well-known/hive-verifier metadata endpoint, and a /v1/verify/jwks endpoint so callers can find the keys.
ML-DSA-65 key publication and full verification are planned/conditional. Publishing a key alone cannot upgrade a stub into accepted lattice verification. Before enabling hybrid success, pin trust, validate the implementation and run dated positive, tamper and wrong-key acceptance tests bound to the deployed revision. Until then, report unknown/unavailable.
Once /v1/purity/cert/issue ships, the verifier will handle one combined 24-axis bundle that covers Wave-Lattice (6 axes, MAPET) and Loess (18 axes, environmental anchor). You'll be able to send type: "bundle" to POST /v1/verify.
This will check the kem_ct field inside receipt_envelope using FIPS 203 key encapsulation.
This will check the did:hive registry in real time during verification, to see if a key has been revoked, with a cache time you can configure.
Rate limiting for bulk verification jobs, spread across Cloudflare Durable Objects, with separate quotas per DID and per IP.
The repo is available to security partners and enterprises on request. Contact security@thehiveryiq.com with the subject line Edge Verifier Access, and we'll send you the private GitHub link within 24 hours.