What Adworth Provides

For Enterprises & Investors

Today, ad platforms self-regulate consent through honor-system toggles — cookie banners, privacy dashboards, IAB Transparency & Consent Frameworks. The platform that benefits from the data is the same platform that polices the consent. Adworth replaces this with cryptographic enforcement at the transaction layer: an advertiser cannot complete a transaction without presenting a valid, signed consent token. Compliance becomes a property of the network, not a policy on a page.

For Developers

Three patent-bearing components work together:

• Cryptographic Consent Token (“The Seal,” CCT) — a 128-bit cryptographically random token bound to a specific advertiser, data scope, and time window via HMAC-SHA256 signature. Issued by adworth-consent-widget (v3.4.0) or adworth-ingestion-api (v1.3.0, via Privacy Cockpit Ed25519 verification). Tokens are stored in the ADWORTH_TOKENS KV namespace and identified by opaque IDs — no PII.
• Privacy Governance Engine (“The Bouncer,” PGE) — runs in adworth-bouncer (v2.3.0). Performs six sequential cryptographic checks on every access request: token existence, revocation status, expiration, advertiser match, scope match, and HMAC signature verification. Honors Global Privacy Control (Sec-GPC: 1) as a valid opt-out under CPRA § 1798.135(d). Applies a Minor Shield block returning MINOR_SHIELD_ACTIVE when minor user status is detected — this block is final and cannot be overridden.
• Invisibility Ledger — append-only, tamper-evident audit trail in the ADWORTH_LEDGER KV namespace. Records consent lifecycle events (CONSENT_ISSUED, CONSENT_REVOKED, CONSENT_EXPIRED) and enforcement events (ACCESS_CHECKED, VIOLATION_DETECTED, RPE_GENERATED, MINOR_SHIELD_ACTIVE). Includes synthetic chaff entries (see Advanced Privacy Protocols) for surveillance resistance. Viewer is read-only by architectural design.

For Enterprises & Investors

The Ad Intelligence Dashboard at adworth.app/dashboard demonstrates the consent-enforcement opportunity. Enter any domain — see what advertisers are targeting users associated with that domain, what data inferences are being made, and which regulations (GDPR, CCPA, DSA) those practices trigger. This is the “before Adworth” view. Without consent infrastructure, this is what every advertised user is exposed to. The dashboard is a live working product, not a mockup — useful for enterprise privacy teams evaluating their exposure and for journalists documenting ad transparency.

For Developers

Pipeline architecture:

• Data source: DataForSEO SERP API (POST /v3/serp/google/organic/live/advanced). Called exclusively from adworth-ads Cloudflare Worker; no direct browser-to-DataForSEO requests. Cost: $0.002 per request. Results cached in ADWORTH_ADS_CACHE KV namespace for 6 hours under ads:{domain} keys.
• PII Advertiser Name Classifier (v5.4.0): two-pass detection pipeline. Pass 1 is a regex pre-filter for Title-Case name bigrams, filtered against a denylist of brand names, place names, and common phrases. Pass 2 sends remaining candidates to Anthropic Claude Haiku as a named-entity-recognition classifier. Detected names are replaced in-place with the [PERSON] token before any downstream use. A non-reversible HMAC-SHA256 audit hash (salted with a server-side secret) is written to ADWORTH_ADS_CACHE under the audit:pii: key prefix with a 90-day TTL. Privacy-fail-safe: if NER is unavailable, all regex candidates are anonymized.
• AI privacy analysis: Anthropic Claude Haiku generates risk scores, regulatory flags, findings, and an Adworth-value summary. Operates only on already-anonymized data — person names have been replaced before this call is made.
• Public endpoint: POST /analyze on adworth-ads.adworthllc.workers.dev. Rate-limited to 10 requests per IP per hour via Cloudflare KV. Strict CORS origin allowlist. Constant-time HMAC-SHA256 API key authentication for authenticated callers.

Full technical disclosure is in Terms of Service Section 2 and Privacy Policy Section 3.

For Enterprises & Investors

This is the user-side proof. A consent token isn't issued by a platform on behalf of a user; it's issued by the user, signed with a private key that never leaves their device. The advertiser receives only a verifiable signature, not the user's identity. Consent becomes user-sovereign, cryptographically enforceable, and revocable in real time. The Cockpit is the canonical implementation of how a user grants the Seal that Section 1 describes.

For Developers

Architecture:

• On-device key generation: Ed25519 keypair (FIPS 186-5 approved) generated in the extension's background service worker via the browser's Web Crypto API (crypto.subtle). Private key stored exclusively in chrome.storage.local as a non-extractable CryptoKey object — never transmitted, never exported.
• Public key registration: Public key uploaded to adworth-ingestion-api and stored in the ADWORTH_PUBLIC_KEYS KV namespace under user:{user_id}:pubkey:{device}. One keypair per device; multi-device by design. Revocation invalidates the device's signing ability but preserves previously verified records.
• Data extraction: A MutationObserver detects ad-platform dashboard updates (Google Ads, Meta Ads) in the user's active browser tab. The extension extracts campaign-level metrics, strips all PII client-side, and signs the sanitized data with the device's private key before transmission. Adworth never receives raw dashboard content.
• Ledger write: As of Ingestion API v1.3.0, upon successful Ed25519 signature verification, a CONSENT_ISSUED event is written to ADWORTH_LEDGER. This event becomes immediately evaluable by the Privacy Governance Engine during subsequent advertiser access requests.

Live Verification Flow

For investors, partners, journalists, and developers who want to verify the cryptographic chain end-to-end, Adworth provides a working demo at adworth.app/demo.html — a simulated advertising-platform dashboard built specifically as a Privacy Cockpit extraction target. The page is intentionally excluded from the sitemap and carries a noindex meta tag; it is reachable by direct URL but not surfaced in search.

The five-step demo flow:

1. Navigate to adworth.app/demo.html in Chrome with the Privacy Cockpit extension installed
2. Open the extension popup and click Sync Dashboard Data
3. The extension extracts the campaign metrics on the page, strips any PII client-side, and signs the sanitized payload with the device’s Ed25519 private key
4. The signed payload is submitted to adworth-ingestion-api, which verifies the signature using the device’s registered public key and writes a CONSENT_ISSUED event to ADWORTH_LEDGER
5. Verify the token landed in the ledger at adworth.app/ledger.html, and optionally evaluate it through the Privacy Governance Engine via the Advertiser Sandbox at adworth.app/advertiser-sandbox.html

Source dashboard data on demo.html is simulated. The cryptographic chain, the Worker fleet, the signature verification, and the ledger write are live. This is the canonical proof-of-flow for any party seeking to verify Adworth’s claims independently — no account required.

For Enterprises & Investors

This service closes the enforcement loop. Revocation isn't a UI state — it's an action that, when persistence is detected, produces a legally formatted deletion request with full regulatory citation, a tamper-evident HMAC signature, and a public verification endpoint. The notice is generated against a versioned regulation rules table (adworth-rules v1.0.0, effective March 5, 2026), so the legal basis of every notice is reproducible, auditable, and version-locked at the moment of generation.

For Developers

RPE architecture:

• Runtime rule evaluation: adworth-rpe fetches legal citations, deadlines, and obligations at runtime from adworth-rules via a Cloudflare Service Binding (RULES_WORKER) — direct worker-to-worker communication, bypasses the public network. Currently supports GDPR-ART17, GDPR-ART7, CCPA-1798105, CCPA-1798120, DSA-ART26, and DSA-ART25. Planned extensions: LGPD, UK GDPR, Virginia VCDPA, Colorado CPA, Connecticut CTDPA.
• Notice contents: Notice ID, target domain, right ID, regulation, rules_version, rules_effective_date, opaque data subject reference, data categories, legal citation text, compliance deadline, HMAC-SHA256 signature of the notice content, SHA-256 content hash for tamper detection. Stored in RPE_DATA KV namespace.
• Public verification: Unauthenticated endpoints for third-party verification of any RPE-generated notice. Verification returns status, target, regulation, rules_version, jurisdiction, deadline, generation timestamp, content hash, HMAC signature, and integrity result. No PII disclosed.

For Enterprises & Investors

These services exist because regulatory compliance is a buyer requirement, not a marketing claim. Each one maps to a specific obligation in a specific regulation and is built to produce evidence on demand — the kind of evidence an enterprise privacy team can hand to outside counsel during a regulatory inquiry without further preparation.

For Developers

Components in this service area:

• Data Subject Request processor (adworth-dsr): GDPR Art. 17 and CCPA § 1798.105 handler. Cross-namespace deletion authority across the consent infrastructure. Records DSR events in ADWORTH_DSR_LOG with verification token TTL of 3600 seconds.
• Audit trail export (adworth-audit-export): Read-only export bundling audit data across ADWORTH_LEDGER, ADWORTH_DSR_LOG, and ADWORTH_CHANGELOG. Fulfills GDPR Art. 15 access requests. User-facing exports exclude synthetic chaff entries. No PII in exports.
• Consent receipt delivery (adworth-consent-receipt): Generates and delivers cryptographically signed consent receipts to users upon token issuance. Receipts written to ADWORTH_RECEIPTS.
• Age gate (adworth-age-gate): COPPA-relevant age certification enforcement at the platform front door, gating Minor Shield eligibility downstream.
• Breach notification (adworth-breach): Logs security events in ADWORTH_BREACH_LOG. Triggers the South Carolina § 39-1-90 notification workflow when threshold conditions are met.
• CCPA Enforcement Gap (adworth-ccpa-gap): Public reference data on enforcement disparities, sourced from reports companies are required to publish under California Civil Code § 1798.185(a)(7). Available at adworth.app/ccpa-gap.
• Retention enforcement (adworth-retention): Daily cron at 03:00 UTC. Purges expired tokens, stale KV entries beyond retention windows, and stale monitor state.

For Enterprises & Investors

Adworth runs entirely on Cloudflare Workers at the network edge — 29 Workers across 41 KV namespaces, no traditional servers, no databases, no separate ops layer. This architecture matters for two reasons: latency (every consent check resolves at the edge, in single-digit milliseconds globally) and cost (a single $5/month Cloudflare Workers Paid plan handles current load with significant headroom). The 29-Worker fleet is deployed exclusively via the Cloudflare Dashboard, never via the Wrangler CLI; every deploy is logged to adworth-deploy-integrity with a tamper-evident record.

For Developers

Authentication

All protected endpoints across the 29-Worker fleet require an X-API-Key header or Bearer token in the HTTP Authorization header. All API key comparisons use constant-time HMAC-SHA256 verification via crypto.subtle to prevent timing-based side-channel attacks. API keys are stored as encrypted Cloudflare environment secrets, never in source code or version control.

Rate limits

Rate-limit policy varies by endpoint surface. Public endpoints (e.g. adworth-ads /analyze: 10 requests per IP per hour) are KV-counter-based. Authenticated endpoints have higher limits per partner contract. Brute-force protection on authentication endpoints is centralized in adworth-auth-guard.

CORS

Strict origin allowlist on every Worker. No wildcard origins, no localhost or 127.0.0.1 origins in production. Unknown origins return null Access-Control headers (no fallback origin disclosure).

Error contract

JSON error responses across the fleet: {success: false, error: "..."} with appropriate HTTP status codes. Unauthenticated requests receive 401 Unauthorized with no data disclosure. Rate-limited requests receive 429. Internal errors return 500 with a generic message; internal details are logged but never leaked in the response body.

Fleet structure

The 29-Worker fleet falls into five architectural patterns: data-handling Workers (own data namespace + _RL partner + ADWORTH_CHANGELOG), stateless verification Workers (_RL namespace only + ADWORTH_CHANGELOG), single-namespace Workers, cross-system reader Workers, and pure stateless Workers (e.g. adworth-well-known with zero KV bindings). One Worker uses a Service Binding (adworth-rpe → adworth-rules). One Worker has a cron trigger (adworth-healthcheck running daily at 06:00 UTC).

Complete Worker-by-Worker disclosure including KV bindings is in Privacy Policy Section 3.