Verifiable Conversions: Why You Can't Audit Your Offerwall Today

Short answer: Most offerwall publishers can't verify their own conversions. They see only the postbacks the network sends, and they have no independent record of what the advertiser reported. A verifiable conversion is a record that both sides hold, with a shared ID, a timestamp, an event and an amount, and whose history can't be changed without detection. Publishing cryptographic commitments to those records on a public blockchain makes them tamper-evident without exposing any user data.

The two-hop problem

Conversion tracking on an offerwall has two hops:

1. Advertiser to network. The advertiser, or its attribution partner, tells the network a conversion happened.
2. Network to publisher. The network tells the publisher through a server-to-server postback.

The publisher sees only the second hop. It can't see what was reported in the first, so it can't know whether everything that happened actually reached it. For a refresher on how postbacks work, read S2S postback explained.

From the publisher's side, three very different situations look identical:

• The user never completed the offer.
• The user completed it, but the advertiser never reported it.
• The advertiser reported it, but the conversion never reached you.

All three show up as "no conversion". Only one of them is the user's fault.

Where conversions get lost

Missing postbacks

A postback can fail for ordinary reasons: a timeout, a server error, a wrong macro, an endpoint that changed. A good system logs every attempt and retries. A weak one tries once and forgets.

Multi-event offers

Modern CPE offers pay on several events: install, registration, level 10, first purchase. Each event is a separate conversion. When one goes missing, the user complains to you, and nobody can tell whether the user stopped or the data did.

Silent edits

When the network can edit records after the fact, a report you downloaded last month and the same report downloaded today can differ, and there's no way to prove which one was right.

No shared identifier

If the network's conversion ID never reaches you, or yours never reaches the network, the two ledgers can't be matched line by line. Reconciliation turns into comparing totals, and totals hide everything.

What a verifiable conversion record looks like

When both sides hold this record, reconciliation stops being an argument. You compare row by row, and the differences tell you exactly where the problem is.

Making records tamper-evident: where blockchain helps

Sharing records is the first step. The second is making sure nobody can change them later. This is where a public blockchain earns its place, and where most "Web3" marketing gets it wrong.

You don't put conversions on-chain. Conversion data can include IP addresses, device details and user identifiers. Writing that to a public ledger would be a privacy disaster and would break data protection law.

What goes on-chain is a commitment:

1. At the end of each period (an hour, a day), the network takes every conversion record from that period.
2. It hashes each record, builds a Merkle tree from the hashes and publishes only the root on a public chain.
3. Each publisher can receive a Merkle proof for its own conversions: a short piece of data proving those records were part of the published root.
4. If anyone later changes, adds or removes a record from that period, the root no longer matches. The edit is visible to everyone, permanently.

It's the same idea behind proof-of-reserves at exchanges and certificate transparency on the web. It costs very little, exposes no personal data, and turns "trust our reports" into "verify our reports".

What commitments don't solve

A commitment proves a record wasn't changed after it was published. It doesn't prove the conversion was real to begin with. That's the oracle problem: the event happens on a phone, and the first party to know is the advertiser. We cover how to handle it in What Is a Decentralized Offerwall?. In short: signed claims, cross-checks between sources, and a dispute window.

What publishers can do today

You don't have to wait for the rest of the industry. Start building your side of the record now:

• Send your own click ID on every click and store it with the user, the offer and the time.
• Log every postback you receive, including the raw query string, before you process it.
• Answer with clear status codes so the network knows when your server failed.
• Export your network's reports regularly and keep the copies. If a past report changes, you have proof.
• Reconcile by ID, not by total. Totals hide missing rows.
• Prefer networks that record reversals as separate entries, so your history stays stable.

What AdswedMedia already does

While most offerwalls still hand publishers a total, AdswedMedia gives them records:

• Your IDs come back untouched. The click and sub IDs you pass are returned on the postback, so every conversion maps to one of your users.
• Every event is its own conversion. Multi-event offers pay each event separately, each with its own record and postback.
• History doesn't change. Conversions aren't edited afterwards. A chargeback is added as a separate entry with its own date.
• Test before you go live. Fire test postbacks from your panel to check your endpoint and macros.
• Full exports. Reports export to Excel with the breakdown by offer, event and date, so you can reconcile row by row.
• Quality numbers in the open. Each offer shows its conversion rate, EPC and chargeback rate across the network.
• Payouts linked to records. Each payout, sent through SwedSwap's non-custodial Affiliate Pay, is tied to the exact conversions it settles.

Records both sides can match are the precondition. Records nobody can change are the next step, and the step that actually earns the word "decentralized".

Key takeaways

• Publishers see only the second hop of conversion tracking, so they can't audit the first.
• A verifiable conversion has shared IDs, timestamps, an event, an amount and a delivery log.
• Never put user data on-chain. Put commitments (hashes, Merkle roots) on-chain.
• Merkle proofs let each publisher verify its own records against a public root.
• Start logging your side of the record today, and reconcile by ID.

Frequently asked questions

How can I verify my offerwall conversions?

Pass your own click ID on every click, log every postback you receive, export the network's reports regularly and reconcile row by row by ID. A network that publishes cryptographic commitments to its records also lets you prove those records weren't changed later.

Why are my offerwall postbacks missing?

Common causes are server timeouts, wrong macros in the postback URL, firewall rules blocking the network's IPs, a changed endpoint, or the advertiser never reporting the event. A network with postback logs and retries makes the cause visible.

Should conversion data be stored on a blockchain?

Not the raw data, because it includes personal information. Store a hash or Merkle root of the records on-chain instead. It proves integrity without exposing users.

What is a Merkle proof in an offerwall?

A Merkle proof is a short piece of data proving that a specific conversion record was included in a set of records whose root hash was published on a blockchain. If the record is changed later, the proof fails.

Does AdswedMedia edit past conversions?

No. Conversions stay as reported. If a conversion is reversed, a separate reversal entry is added with its own date, so your history doesn't change.