Case Study · IDDAS

IDDAS — proving physical ads actually happened

A cryptographic verification and audit layer for physical advertising — making offline interactions provable, prices reproducible, and revenue splits auditable.

Surfaces per candle

Placement signals

Deterministic outputs

Challenge

Physical advertising — billboards, point-of-sale displays, candles placed in real venues — is a multi-billion-dollar blind spot. Sponsors pay for estimated impressions with no mechanism to independently verify that consumers actually interacted, that reported metrics are authentic, or that revenue was allocated correctly.

The system places a decorative candle with a 4-door, 3-exit geometry (12 interaction surfaces) in venues like salons, libraries, and stadiums. The question: how do you cryptographically prove real people interacted with a physical object — and that nobody fabricated the numbers to steal money?

Approach

We built IDDAS on a single principle — verifiability over trust. Private data (identities, raw interactions) stays off-chain and is protected with salted one-way hashing; the public blockchain stores only 32-byte cryptographic anchors.

Five subsystems work together: an append-only, hash-chained activation ledger; a Merkle sealing mechanism for batch integrity; a Polygon smart contract (AnchorRegistry) that commits Merkle roots on-chain; a deterministic 5-phase CPM pricing engine bound to versioned rulesets; and an 11-variable placement-strength scoring engine with environment-maturity classification.

Every computation is a pure function with EPSILON-corrected rounding and canonical JSON, so identical inputs always produce bit-identical outputs — and PostgreSQL triggers enforce true append-only immutability at the database layer.

Outcome

Any independent party can rebuild a Merkle tree from published events and compare it against the on-chain anchor — a match proves the data is authentic and unmodified.

The result: tamper-proof interaction recording, O(1) on-chain storage for O(n) verifiable events, reproducible economics, and privacy-preserving identity — a blueprint for trustless economic systems wherever offline activity needs digital proof.

“Verifiability over trust — every interaction, price, and allocation must be independently reproducible and cryptographically provable.”
Saad · Author, IDDAS Thesis

By the numbers

The models and splits behind the system, straight from the design.

Revenue allocation

Deterministic 15 / 15 / 70 split across the activation chain.

100%total

Platform70%
Originator15%
Closer15%

Trust multipliers by environment

Score weighting applied per placement environment class.

Institutional

1.25×

Appointment

1.15×

Service

1.05×

Transactional

0.95×

Transitional

0.85×

Placement-strength signal weights

11 behavioral signals over a 30-day window, summing to 1.00.

Opens / exposure

0.22

Outbound rate

0.14

Transitions / open

0.13

Returns / open

0.12

Propagation velocity

0.08

Consistency

0.06

Multi-door explore

0.05

Reliability

0.05

Location quality

0.05

Lineage retention

0.05

Doors / session

0.05

Architecture

How the system fits together, straight from the design docs.

engines

Verification Ledger

Hash chains · Merkle sealing

Pricing Engine

Deterministic 5-phase CPM

Scoring Engine

11-variable strength model

commit

PostgreSQL

Append-only · trigger-enforced immutability

serve

Fastify REST API

Verification, pricing & scoring endpoints

anchor Merkle root

Polygon · AnchorRegistry

Public, immutable on-chain proof

Hash-chained ledger

Event 1: hash(data₁ + genesis) → H₁
Event 2: hash(data₂ + H₁)      → H₂
Event 3: hash(data₃ + H₂)      → H₃
...
Event N: hash(dataN + HN₋₁)    → HN

Modifying any historical event invalidates every hash after it.

The 5-phase pricing pipeline

Phase 1: Static Ruleset Path
  → Load education / mobility / wellness / liveevent ruleset
  → Validate 4×3 geometry invariant
  → Route to PlacementEngine or ParticipationEngine

Phase 2: Venue-Driven Valuation (Database)
  → Resolve exposure baselines (footfall)
  → Resolve attention multipliers (venue-specific)
  → Resolve environment CPM bands (floors / ceilings)

Phase 3: Density & Category Response
  → Resolve expected activation density
  → Apply saturation penalty factor
  → Resolve category response modifiers

Phase 4: Performance Modifier (Sibling Handoff)
  → Look up linked Placement Strength score
  → Resolve performance adjustment from score band

Phase 5: Governance Validation
  → Validate governance version is active
  → Bind governance lineage to output

Lifecycle: interaction → settlement

Day 1:  User A scans candle    → Event 1 (H₁)
Day 5:  User B opens Door 3    → Event 2 (H₂, parent: H₁)
Day 12: User C picks up flyer  → Event 3 (H₃, parent: H₂)
Day 20: User D shares a link   → Event 4 (H₄, parent: H₃)
Day 30: Campaign ends          → Merkle root R from [H₁..H₄]
Day 30: Anchor batch executes  → R → Polygon tx 0x123...
Day 35: Sponsor pays $500      → Revenue tied to seal
Day 35: Settlement executes    → $75(A) + $75(D) + $350(Platform)

Independent verification flow

Step 1: Obtain polygon_tx_hash from the batches table
Step 2: Look up the transaction on Polygonscan
Step 3: Decode the Anchor event → extract merkleRoot
Step 4: Request all events for that batch from the API
Step 5: Independently rebuild the Merkle tree
Step 6: Compare computed root vs. on-chain root
  ✅ Match    → data is authentic and unmodified
  ❌ Mismatch → data has been tampered with

Want results like these?

Tell us what you’re building.

Start a Project

Opening case study

IDDAS

loading assets0%