The problem with pixels
Every major ad platform counts conversions when a pixel fires. Pixels are JavaScript — they fire on page load, on refresh, sometimes on redirect. There's no built-in deduplication that works across sessions, devices, or browser restarts. You're trusting a client-side script to tell you the truth.
How HashVex stops it
When a conversion happens, HashVex derives a cryptographic nullifier — a unique fingerprint for that specific user and campaign. The nullifier is stored permanently in Redis and PostgreSQL. Any subsequent attempt to record that same conversion is rejected at the proof level. Not filtered. Rejected. There is no override.
What actually happens under the hood
The nullifier is generated using a Poseidon hash function — the same cryptographic primitive used in zero-knowledge proof systems like Zcash and StarkNet. It takes your user token and campaign ID as inputs and produces a deterministic, one-way output. The same inputs always produce the same nullifier. Different inputs always produce a different nullifier. Once stored, it cannot be re-used.
How it compares
| Method | Deduplication | Cross-session | Tamper-proof |
|---|---|---|---|
| Google Ads pixel | Partial | No | No |
| Meta pixel | Partial | No | No |
| Server-side GTM | Partial | No | No |
| HashVex ZK Proof | Complete | Yes | Yes |
Clean data.
Better decisions.
When your conversion count is accurate, every optimization decision downstream improves. Bid strategies, budget allocation, creative testing — all of it depends on a number you can trust. HashVex gives you that number.