Explorer (public verification hub)

The AdPriva Explorer at explorer.adpriva.com is a public, read-only place to re-verify a proof and its on-chain anchor. It needs no login and no account.

It replaces “trust our report” with a check anyone can run themselves: take a proof id, confirm it exists, see its verdict, and trace it to the anchored Merkle root.

The rule: a verification lookup, not a feed

The Explorer answers one question: is this proof real, and where is it anchored? It never answers who served it, to whom, or from where.

That rule decides what can appear:

The same boundary applies to the public API endpoints the Explorer is built on (see the API Reference).

What you can do

Look up a proof. Paste a proof id, or open https://explorer.adpriva.com and search. The search box accepts three things, and only these: a proof id, a batch handle, or an anchor transaction hash. You cannot search by publisher, site, visitor or date. There is nothing to enumerate.

For a proof you get:

• its type, status and creation time;
• its validity score and verdict (see Proofs of Engagement);
• once batched, a Merkle inclusion receipt (leaf, sibling path, path indices) so you can recompute the batch root yourself;
• the batch’s Horizen anchor transaction (and, for batches anchored before 2026-09-28, its zkVerify verification).

Follow a batch. Each anchored batch shows its Merkle root, proof count, anchor transaction and a verdict breakdown for the proofs inside it. Batches deliberately mix proofs from different customers, which is why a batch can be published at all.

See the network at a glance. Network-wide counters (proofs sealed and batches anchored in the last 24 hours, share of proofs anchored) and scoring coverage: how many proofs have been scored, the verdict mix, and the current enforcement mode (shadow today, meaning verdicts are recorded but nothing is blocked).

“Recent” lists are not a traffic feed

The Explorer lists the newest anchored batches and the newest scored proofs, so you can watch the network working. Each row is only an opaque id, a type, a timestamp, a status and a verdict. The lists carry no publisher, site or organization dimension, so they cannot be used to follow a customer’s traffic.

Following your own traffic is done in the console, not here. Your own organization’s proofs, with your sites and breakdowns, are in the authenticated console and the authenticated GET /explorer/proofs API (endpoint 6 in the API Reference). The public Explorer never shows them grouped by owner.

Checking a proof without trusting AdPriva

The Explorer shows a status, but the status is not the evidence. The receipt is. To verify independently:

1. Look up the proof and take its leaf, merkle_path, merkle_path_indices and hash_version.
2. Fold the leaf up the path to recompute the root (the API Reference has the exact algorithm for both hash versions).
3. Compare it with the Anchored(merkleRoot) event in the Horizen transaction. The on-chain value is the authority, not our API.

The Explorer makes the same comparison in your browser: it reads the anchor transaction from a public Horizen RPC and shows “ON-CHAIN ROOT MATCHES” when the transaction’s root equals the receipt’s root. If the RPC cannot be reached it shows “chain check unavailable”.

Two honest limits: new batches have no zero-knowledge proof, so a receipt rests on the Merkle path and the anchored root alone (see Legacy: zero-knowledge step), and batches are currently small, so a receipt should not be read as hiding a proof among many others.

Why the Explorer Matters

• Publishers can hand a buyer a proof id instead of a spreadsheet.
• Buyers and auditors can re-check any proof and its verdict themselves.
• Visitors are never exposed: nothing on the Explorer identifies a person, a site or a publisher.