Oracle Design: How Traffic Events Become On-Chain Payments

PopTrade processes millions of events off-chain but settles payments on-chain. The oracle system is the bridge—and its design determines how trustworthy that bridge is.

The Oracle Problem

Smart contracts can only access on-chain data. They can't call our database to check impression counts. They can't verify fraud scores. They need external data submitted to them.

This creates a trust point: whoever submits the data could lie. The whole trustless system becomes only as trustworthy as the oracle.

Our Oracle Architecture

Data Aggregation

Throughout each settlement period, events accumulate in our database:

• Impressions served (with timestamps, sources, campaigns)
• Fraud scores and filter decisions
• Click and conversion events
• Publisher earnings calculations

At settlement time, we aggregate:

• Total valid impressions per publisher per campaign
• Calculated payouts based on CPM rates
• Platform fees
• Referral commissions (if applicable)

Commitment Hash

Before submitting to the oracle contract, we generate a commitment hash of the underlying data:

hash = keccak256(
  campaign_id,
  settlement_period,
  publisher_payouts[],
  impression_counts[],
  raw_event_merkle_root
)

This hash is included in the oracle submission. Later, anyone can verify that our off-chain data matches the committed hash.

Oracle Submission

The oracle contract receives:

• Settlement identifier
• Payout amounts per recipient
• Commitment hash
• Cryptographic signature from authorized oracle key

The contract verifies the signature, checks that amounts don't exceed escrow balance, and queues the settlement for execution.

Multi-Signature Option

For high-value settlements, we support multi-signature oracle submissions. Multiple independent parties must sign off on the data before settlement executes. This distributes trust across parties.

Verification Process

What you can verify on-chain:

• Total amount paid matches oracle submission
• Recipients match submitted addresses
• Settlement timing matches contract rules
• Commitment hash is recorded immutably

What you can verify off-chain:

• Our published raw data hashes to the commitment
• Individual event counts match aggregates
• Fraud decisions match your configured rules

This creates an audit trail: on-chain payments link to commitment hashes, which link to verifiable off-chain data.

Why Not Everything On-Chain?

We could write every impression on-chain. Why don't we?

Cost: At $0.001 per transaction and 1M daily impressions, that's $1000/day just for recording—more than many campaigns spend.

Speed: Block confirmation takes seconds. Ad serving takes milliseconds. You can't wait for blockchain to serve an ad.

Privacy: Impression data includes IP addresses, user agents, timing. Public blockchain means public data.

The hybrid approach captures blockchain guarantees for money (where trust matters most) while keeping operational data off-chain (where efficiency matters most).

Trust Assumptions

Our oracle design requires trusting:

• PopTrade accurately aggregates event data
• The oracle key isn't compromised
• Commitment hashes aren't pre-computed fraudulently

It doesn't require trusting:

• PopTrade to actually execute payments (contract enforces)
• PopTrade to pay correct amounts (on-chain verification)
• Anyone's word about what happened (audit trail exists)

This is trust-minimized, not trustless. But it's far more verifiable than traditional "trust the platform" systems where you can't audit anything.