Request for Feedback - Web3 Ad Targeting Marketplace

[Nukeme3]

Good day to you all,

I’ve been toying around with a dApp concept for a Web3 Ad Targeting service and would like to get some external feedback to see if:

1. There is a functional capability, or if my understanding of interoperability is way off
2. There is an interest in the community to bring targeted ads to Web3
3. Any immediately noticeable roadblocks or alternatives to explore.

I would hope that getting a few other eyes on it might save me from going down the wrong path, potentially wasting my time.

The tl;dr is effectively to create an automated marketplace for targeted ads. Users grant permission for data collection (or revoke consent), Publishers host targeted web elements, campaign approval is based on staking (with slashing risk if approving harmful, dangerous, or illegal campaigns), Advertisers create an ad campaign with DSA/DMA compliance, and fund a service pool to reward Users, Publishers, and Stakers.

All transactions would be conducted in DOT, with a percentage of the transaction value being burned.

Specific details can be found across the documents Here

A few caveats:

1. I’m not a software developer. Although I have a technical background, I aim to utilize this idea as a learning project with a long-term goal of potentially building something useful.
2. Currently, this is still in a very early concept and is mostly just me putting ideas down on paper. Forgive my use of AI tools as I’m just working on rough outlines and ‘vibing out’ the basic structure.
3. I’m limited on time at present, so this would be a tertiary (or quatinary) side project, for funsies. No guarantees of completion are being made (and thus no plans to request treasury funding at this time).

I don’t have a full pitch at the moment; however, the annual expenditure on targeted advertisements is approaching $1 trillion, and upcoming changes to user-privacy regulations (DSA/DMA) put pressure on gatekeeper legacy enterprises to support alternative solutions and services. I believe a privacy-by-default solution based on core Web3 principles, empowering end-users’ agency over their online activities, is a step in the right direction, ethically.

Functionally, I believe something like this could also prove to be a viable system, resulting in DOT distribution and onboarding to end-users, incentivising Web3-integrated usage, providing a revenue stream to the treasury, and a new mechanism for token burn.

I’m open to hearing any questions, comments, concerns, or complaints.

[DotDotApe]

Maybe @alice_und_bob should start a public brainstorming session around use-cases and what to build at the Polkadot 2.0 Party

[Nukeme3]

Reviving this because I finally started putting something together as a starting point for my own learning and understanding. My experimenting with a pallet_revive ad exchange can be found Here with a chrome extension preconfigured with live Paseo contacts if anyone is willing to test.

This represents a very rudimentary concept of an ad exchange which connects advertisers, publishers, and users where targeted advertisements are delivered to users with attention compensation hosted by publishers and based on second-price auction for ad slots. User/publisher attestation is not enforced, no KYB, zk circuit for user commit for ad relevance is not implemented, along with many limitations and opportunities for improvement. But you can create a small ‘ad’ campaign, vote on other campaigns for quality, include a small inline sdk on a webpage, and receive PAS for viewing campaigns.

This was influenced by basic attention token and some early conversations during parachain slot auctions regarding content monetization models of creator content. I could envision a future where DOT is earned by electively sharing a minimal amount of information about oneself, such as being a relevant match with a targeted advertising campaign while keeping the knowledge of exactly why you are relevant to that campaign under your own control.

Content moderation is through simple majority voting with a minimum quorum with conviction voting and locked tokens with a losing-side slash mechanic which awards 10% of the losing side to the winners. Campaign owners are slashed 10% of escrowed amount of their campaign is terminated via this governance.

I’m open to any thoughts or feedback.

Fair to say use at your own risk, don’t use any real accounts. Some minimal content safety filtering of the .js/phishing websites and keywords is included, but you know how the Internet is.

You will need to provide your own IPFS pinning API for testing. Anyone have experience or could point me where I might be able to learn about pinning such as through Crust network XCM calls on paseo?

[lilymendzdev]

Hi, maybe a live session showing how it works would help a lot

[Nukeme3]

I commissioned my good buddy Michael Bay to whip me up an action-packed demo video

[christ]

Nice idea utilising the extension to pay directly into wallets - reminiscent of Brave Rewards.

Have you considered how you will protect against ad fraud?

[Nukeme3]

Thanks for the feedback. The idea was certainly inspired by Basic Attention Token along with some early conversations about content monetization strategies with some of the team from SubSocial.

Ad fraud is certainly a point I’m taking into consideration, but I will need to experiment to find a solution that works. Currently, the demo is self-reporting without requiring verification of actual claims.

Users build hash chains with a nonce, per campaign, locally on their machine. They will co-sign with a publisher to commit a valid two-party attestation of a real impression.

I have a zk pre-compile stub to verify second price auction batches in the future. There might be an opportunity to pipe a confirmation of visibility, but this is an area I’ll have to explore in more detail. Alternatively, running a lightweight visibility verification or claim validation within a TEE (Acurast or Phala if they’re still around). Although that adds complexity and defeats the ‘minimal user data leaves the device’ goal. Not to mention keeping the real cost-per-impression low enough to be feasible.

It might not eliminate fraudulent impressions entirely, but it may be possible to raise red flags for advertisers to blacklist publishers per campaign. There’s also a planned on chain global blacklist. Advertisers will also be able to whitelist select publishers.

There’s likely a benefit in acceptable levels of commitment for different users, as well. It would be useful to confirm that end users are at least human. So a PoP integration in the future, if it becomes a quick lookup. Publishers make sense to have a higher level of commitment, so possibly an on-chain identity or a registration deposit. Low enough bar to be accessible while hurting if someone is trying to game the system. Advertisers should be tied to real world businesses via KYB. Looks like KILT is gone, but I’m optimistic that oracle void will be filled in the future.

I feel a combination of self-moderation tools and social filtering might improve the anti-fraud capabilities. But that’s more gut feeling than actual engineering. Maybe I’m just naive.

I’m currently working on a redesigned build that incorporates many deferred features. I’ll share updates as I have them.

[christ]

I suppose ad fraud is a future problem to solve if you get people to pay for ad placement. But I can guarantee you will get botted if there is money to be made.

lightweight visibility verification

What would this consist of? Headless browsers are effectively the same as a user.

a PoP integration in the future, if it becomes a quick lookup

Yes, the mythical PoP - I would love this too. The Deloitte / KILT combo sounded promising a couple of years ago but it only ever onboarded a few thousand people. PoP needs huge scale and therefore incentives to get people to use it in the first place.

My company, Prosopo, operate a bot mitigation product with native Polkadot capabilities. We originally planned to have the captcha providers run independently and store results in ink! smart contracts. However, the latency / unreliability associated with parachain nodes made it infeasible. I still think some kind of shared reputation/scoring system associated with accounts might work but we’re focused elsewhere for now.

That said, you can still directly integrate Polkadot accounts with our captcha process. In web3 mode a Polkadot account is required to sign the challenge solution and verified by the captcha providers. In theory, the results could go on-chain and be shared amongst applications but, at the moment, the captcha providers act as oracles, returning a verified verdict.

The code is mostly open source but we obfuscate the detector code. You can run a self-hosted version with a considerable amount of effort. Please give me a shout if you’re interested in trialling it in your extension.

[Nukeme3]

But I can guarantee you will get botted if there is money to be made.

No doubt. Luckily I’m not making any promises I can’t guarantee this little system will work, but it’s fun seeing the intent come together and I’m learning a few things. I’m making that a success in my book.

What would this consist of? Headless browsers are effectively the same as a user.

I’m open to suggestions I’d definitely be interested in checking out your w web3 captcha, even just for some learning

Yes, the mythical PoP - I would love this too. The Deloitte / KILT combo sounded promising a couple of years ago but it only ever onboarded a few thousand people. PoP needs huge scale and therefore incentives to get people to use it in the first place.

Yeah. I was very sad to see KILT go. Not too surprised with the way things have progressed. I get the feeling that Parity is aiming to launch their in-house products all at once in some grand fashion. PoP would be a glue to the product portfolio. But the silence is deafening.

[Nukeme3]

Dropping a small update while I’m here and have a moment. It has been broad-stroke development so far, but now the focus changes to finer adjustments, optimizations, and general polish. Then, trying to break it (more than I already do).

Currently, in the process of stripping functions away from an overly complex extension and setting up an actual Web App at datum.javcon.io The user-side interface will ideally be minimal and intuitively mirror familiar systems (like, share, report, etc.) and be intentional throw-away accounts.

Some key points:

Targeted advertisements without the tracking. The extension passively categorizes content on the user’s device, builds an interest profile used to weight ad campaign price auctions, records impressions in a claim hash, submits to publisher relay so users pay minimal or no gas, optional zk circuit removes the user’s address from the claim submission to enhance privacy and validity of impressions.

4 Primary Roles

• Publishers - register on-chain to host and deliver ads to users running the extension, taking a configurable take-rate which gets snapshot at the time of campaign creation. Automatic reputation scoring and user reporting all happens on-chain to highlight good/bad behavior. Publishers run a lightweight SDK on their website which handshakes with the user extension and serves relevant ad campaigns based on a second price auction. Publishers can accept any campaign, or selectively whitelist only from approved advertisers.
• Advertisers - create ad campaigns, deposit DOT into an escrow vault, and set the CPM and various limits to control the campaign spend. They can additionally sidecar an ERC-20 token (governance, utility, or memecoin) to disperse tokens to end users as part of the advertisement. They can target specific publishers or allow their ad to be open to any publisher willing to run their creative. They can set the settlement to require a zkProof of settlement claims to strengthen validity of real engagement.
• Governance - Primary role is campaign moderation. Conviction-weighted votes are used to support/terminate campaigns. A terminated campaign receives a 10% slash to the remaining escrow budget as a reward to the Nay voters, in addition to a 10% slash from any locked support votes. But the opposite is true, that a campaign that completes successfully gets a 10% slash from Nay voters rewarded to the Aye supporters.
• Users - browse the web as normal. The extension builds an interest profile locally used to weight relevant advertisement bids. Each impression receives a reward from the advertiser. Users can elect to submit their claims themselves (paying gas) or relay to the publishers’ on-chain registered relay endpoint so the only gas Users pay is to withdraw.

Users are compensated in DOT for their attention without sharing any more information than “I saw this ad.” Retaining privacy and only electing when to engage with ad campaigns.

Advertisers and Publishers use an extensible tag-based context taxonomy so context can follow traditional standards, adopt regional or industry content, or morph into niche subculture lingo as so happens on the internet. Individual communities could advertise and monetize unique products and services within their spaces without selling their souls to Uncle Zuckerberg.

I will also work to abstract and generalize the lower-level protocol design in order to allow more extensible application implementations.

Some areas for improvement:

Native pallet_revive Assets enabled through ERC-20 sidecar to enable advertisement-coupled airdrops. Get project tokens into the hands of users while simultaneously raising awareness.

Different claim triggers. Currently, I have only CPM for view impressions. Plan to add Cost-per-Click (CPC), Cost-per-Action (CPA), etc., to reward users for their engagement.

High-level trust assertion per campaign upon claim submission to validate extension/sdk integrity hash within a TEE (exploring Accurast).

Again, open to any feedback. Both positive and negative.