This article explains how advertiser data moves through the platform, how it is stored and managed, and what security and privacy controls protect it at every stage. It is designed to help technical, legal, and marketing stakeholders understand exactly how hashed identifiers are ingested, processed, and safeguarded so they can assess compliance, risk, and suitability for their campaigns.
1. End-to-End Data Flow & Upload Process
Ingestion Methods
Data enters our platform exclusively as one-way cryptographic hashes (SHA-256). We offer three primary ingestion paths:
- Direct Hash Upload: Clients upload CSV files containing hashed identifiers (emails/device IDs) directly to our encrypted dashboard.
- API Integration: Real-time syncing from client-side CDPs or CRM systems via our secure REST API.
- Web3 Pixel: A lightweight JavaScript library ("Web3 Cookie") that captures and hashes user signals directly in the browser.
Third-Party Involvement
Blockchain-ads operates an end-to-end proprietary stack. While we integrate with Partisia Blockchain for privacy-preserving computation, they act as a protocol layer and do not have access to the underlying data. We do not use third-party data brokers for matching; all matching occurs against our internal Identity Graph.
Matching & Activation
The matching process bridges the gap between Web2 identifiers and Web3 activity:
- Identity Mapping: We use a deterministic matching logic to link hashed device IDs/emails to a Unique Anonymous ID.
- Wallet Linkage: When a user connects a wallet via a partnered publisher or "Web3 Cookie" touchpoint, that wallet address is mapped to the Anonymous ID.
- Real-Time Activation: When an ad request is made, our DSP (Demand-Side Platform) queries the match table. If the user matches a target segment (e.g., "Whales" or "DeFi Users"), the ad is served without the publisher ever seeing the user's wallet address or email.
2. Data Handling, Storage & Management
Storage & Encryption
- Zero-Knowledge Storage: We utilize Zero-Knowledge Proof (ZKP) technology (powered by Partisia) to ensure that even if our database were compromised, the data remains computationally impossible to decipher.
- Transit Security: All data moves through TLS 1.3 tunnels.
- At-Rest Security: Database volumes are encrypted with AES-256, with keys managed in a segregated Hardware Security Module (HSM).
Data Retention Policies
- Standard Expiry: Campaign-specific audience data is purged 30 days after campaign completion.
- Global Opt-Out: We maintain a "Global Suppression List." If a user opts out via any of our partner sites, their hash is purged across our entire ecosystem within 24 hours.
3. Data Security & Extraction Controls
Reverse-Engineering Protections
We confirm that hashed data cannot be extracted or re-identified.
- Salted Hashing: We apply an internal salt to all hashes during the ingestion process, preventing "rainbow table" attacks.
- K-Anonymity: Our reporting dashboard only shows aggregated data. If an audience segment has fewer than a minimum threshold of users (e.g., <100), the data is suppressed to prevent individual identification.
Purpose Limitation
Certification of Use: Blockchain-ads officially certifies that client-provided data is used strictly for the execution of the agreed-upon advertising campaigns. It is never utilized for "lookalike" modeling for other clients, nor is it sold to external enrichment providers.
