Anchor Worker

The AdPriva Anchor Worker is the service that batches cryptographic engagement proofs and anchors Merkle roots to Horizen mainnet — making every engagement permanently verifiable on-chain.

What It Does

At a high level, the Anchor Worker runs a continuous two-stage pipeline every 5 minutes:

1. Batch — Query the database for unprocessed (pending) engagement proofs, group them into a Merkle tree, and compute the Merkle root.
2. Anchor — Recompute the root from the batch’s proof ids, then submit it to the Anchor.sol smart contract on Horizen mainnet, emitting an Anchored event that creates a permanent, public record.

View batches anchored before 2026-09-28 had a step between the two: a Groth16 zk-SNARK was submitted to zkVerify and the root was anchored after zkVerify accepted it. That step was retired on 2026-10-16. See Legacy: zero-knowledge step.

This pipeline runs as a single Node.js worker process on DigitalOcean App Platform, replacing the previous three-Lambda AWS architecture.

Architecture

Go Server
  │
  ▼ INSERT proofs
MySQL (proofs, proof_batches, anchor_jobs tables)
  │
  ▼ Poll every 5 minutes
DO Anchor Worker (Node.js)
  │
  ├─► Batch: Poseidon Merkle tree, root recomputed from the proof ids
  │
  └─► Horizen Mainnet (Anchor.sol)
        └─► anchorBatch(merkleRoot)
        └─► Anchored event emitted (permanent on-chain record)
  │
  ▼ UPDATE anchor_jobs (status='completed', result={txHash})
MySQL

Why a Single Worker?

The previous AWS Lambda approach required three separate services (batch creator, zkVerify submitter, Horizen anchor) connected by SQS queues. This added operational complexity and latency.

The Anchor Worker replaced all three with a single stateful process:

The simplification reduces failure surface area, makes logs centralized, and eliminates SQS propagation delays.

Proof Lifecycle

Every proof follows this path through the Anchor Worker:

1. Engagement event → Go server captures a view or click, creates HMAC-signed proof, inserts row into proofs table with zkverify_status = 'pending'.

2. Batch → Worker queries unbatched proofs from the proofs table, organizes them into a Poseidon Merkle tree, computes the root, and creates a proof_batches row + an anchor_jobs row with job_type = 'zkverify_submit'. The job type keeps its historical name.

3. Skip zkVerify → Worker claims the zkverify_submit job and recomputes the Merkle root from the job’s proof ids. It stops if the result differs from the stored root. With PROOF_BATCHES_SKIP_ZKVERIFY=true, which is on in production, it generates no Groth16 proof and makes no Kurier call: it sets the batch’s zkverify_status to NOT_APPLICABLE and creates an anchor_submit job.

4. On-chain anchoring → Worker claims the anchor_submit job and calls Anchor.sol.anchorBatch(merkleRoot) on Horizen mainnet, with the on-chain note AdPriva Proof Batch (no zkVerify). The contract emits Anchored(merkleRoot) and stores nothing, so an anchor is cheap: 28,784 gas measured on a production batch on 2026-10-16.

5. Status update → Worker marks anchor job as status = 'completed' with the txHash in the result field. Proofs in the batch are marked anchored, and their zkverify_status mirrors the batch: not_applicable for a batch anchored without zkVerify.

Legacy path: zkVerify

The flag is off unless it is exactly true. With it off, step 3 is the zkVerify path that view batches used until 2026-09-28: the worker downloads the circuit artifacts (proof_verification_v2.0.0.wasm, *.zkey) from Cloudflare R2, generates a Groth16 zk-SNARK over the Merkle tree, and submits it to zkVerify through the Kurier API. zkVerify checks it (~25 seconds, ~$0.05/batch) and returns an attestationId, and the worker then creates the anchor_submit job. Proofs in such a batch are marked zkverify_status = 'verified'.

Public Verification

Anyone can verify a proof by:

1. Looking up the proof ID in the AdPriva Explorer.
2. Tracing the Merkle root to the on-chain Anchored event on Horizen mainnet.
3. Recomputing the root from the proof’s own Merkle receipt — GET /public/proofs/{proof_id} returns leaf, leaf_index, merkle_path and merkle_path_indices, which fold back to the anchored root offline. Steps 1 and 2 alone only show that some root was anchored; this step is what shows the proof is in it. See the API Reference for the fold, or use the browser verifier at explorer.adpriva.com/verify/{proof_id}.
4. For a batch anchored before 2026-09-28, cross-referencing the zkVerify attestationId for the legacy zero-knowledge attestation.

A limit worth knowing: batches are currently small, so a receipt is exact but the anonymity set it places a proof in is correspondingly small. Current batch sizes are public via proof_count on GET /public/anchors/recent.

The Anchor contract (Anchor.sol) is deployed on Horizen mainnet (Chain ID: 26514, RPC: https://horizen.calderachain.xyz/http).

Legacy: Zero-Knowledge Proof Details

For view batches anchored before 2026-09-28, AdPriva used Groth16 zk-SNARKs with a custom Circom circuit (proof_verification_v2.0.0):

• Circuit inputs: proof leaf hashes, Merkle path, Merkle root, timestamp
• Output: single bit — proof is valid and belongs to the committed Merkle root
• Proving key: stored in Cloudflare R2 (circuits/v2.0.0/)
• Verification: performed by zkVerify’s on-chain verifier

This means that even the Anchor Worker never sees raw user data — it only processes cryptographic hashes produced by the Go server.

Deployment

The Anchor Worker runs on DigitalOcean App Platform as a background worker (no inbound HTTP). Infrastructure is managed via OpenTofu in the infrastructure/ repository.

Key environment variables:

Deployment is currently manual. The GitHub Actions workflow in AdPriva/proofs (.github/workflows/deploy-anchor-worker.yml) still runs on push to main, but its deploy step does not succeed until its DigitalOcean credentials are renewed. Until then the worker image is built, pushed to the DigitalOcean registry and deployed by hand, as described in the proofs README.