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.

[Nukeme3]

Another quick update.

I have a demo page running the extension in-page, so no sketchy extension install for testing. Background deamon handles serving available ad campaigns with a visualizer for second price auction selection. There’s also a web-browsing simulator which reads common web-ad content tags and builds a user-interest profile used in auction bid weights (limited in scope for testing).

Interest tags are not currently passed to the auction system correctly, yet, but that’s next on my radar. Edit: scratch that, I’m just dumb and have a few over priced campaigns outbidding all others even at minimal floor price. Bid weights by tag relevance still work, but a heavy campaign open to all publishers can out bid others. In practice, this would mean it would outspend its budget at a faster rate and receive wide reach but poor targeting. Could also put it in the crosshairs of a voting governance to terminate for nuisance rewards.

I’ve also got an eth-rpc compatibility layer built and running on top of smoldot, available to use in the WebApp settings. Select the checkbox to use Pine light client, takes a few seconds to sync, then blow away the fallback rpc address and run entirely through your browser. There’s still some denomination issue to resolve, but all calls I’ve tested have succeeded. That may be useful for others, so I’ll extract it and make it more modular in the near future.

Also. A few pics:

[Nukeme3]

Small update with some more cool stuff.

Ad creatives support common image sizes (banners, skyscrapers, mid-paragraphs, mobile screens, etc) via tag selection with fallback alt text or only-text mode. Should also work for videos. Tag selection is extensible and can change naturally.

It can also render multiple creative slots per page, but gotta see how to balance multiple campaign wins. Slot selection type can add natural competition, but still testing.

Working on close-loop content feedback to ZK circuit to confirm the creative content actually appeared on screen.

Also testing a WordPress plugin for publisher setup.

ERC-20 sidecar confirmed to support any Assethub Native Assets via known pre compile.

Safety gating governance functions for eventual rollout on a network with real value. Initially, all campaigns will be approved by admin function. Later will transition to a trusted collective. Then eventually a wild OpenGov style permissionless vetting process.

I know it’s a bit quiet right now, but if anyone has some experience in digital marketing/advertisement space, or has a website/blog and be willing to help trial the ad slot SDK or browser extension, I’d love to touch base. It’s still in early Paseo testing for validation, but I’d be willing to cover Relay signing costs upon migration to Polkadot/Kusama for any publishers helping with limited alpha testing.

[Nukeme3]

About a month later, chugging away in the dark and trying to make a thing that kinda works.

DATUM Protocol

Significant expansion on the admin structure with a planned council and OpenGov-lite mechanisms for parameter tuning and upgrades. Rough outline is to initially deploy on Asset Hub, prove out the functionality, and then migrate to a native parachain model if demand scale requires. Optimistic, I know, but I think it’s worthwhile planning for the endgame early on.

Three-token earning paths are defined.

1. PAS/DOT end-to-end for advertisers, publishers, users, and governance for all critical paths.
2. ERC-20/Native Precompile sidecar tokens are optionally set by advertisers. If a project wants to distribute their tokens alongside the advertisement view claims, they can seed and onboard users into their ecosystem without users needing to swap anything for a unique token.
3. DATUM tokens will be distributed along with every settled claim batch, in addition to PAS/DOT with a dynamically adjusted emission curve and 100M total supply.

• DATUM will be used for parameter adjustments, core protocol governance, and distribution of protocol fee share distribution. DATUM will be minted via system use and is composed of a DATUM Native Asset and ERC-20 WDATUM for simple EVM interaction and clear path to a native parachain asset.

User claim submissions can be feeless via EIP-712 relay batches, batch signing either handled by the publisher or a third-party relay service provider. Additionally, the advertiser can require their own EIP-712 signature to improve fraud detection for all settled claims. Alternatively, campaigns can be fully open and served by any publisher for pure awareness and settled by no more than a single user signature. Advertisers, publishers, and users each have controls for which level of assurance, privacy, and control in their ad experience they are willing to accept.

Claim submissions are rate-limited via a PoW challenge. Normal claim submission rates face negligible difficulty with a cooldown to optimise for efficient batch claims, while abusers who try to over-claim settlement impressions face an exponential difficulty curve at the contract-level. These values are global across all campaigns and adjustable via parameter governance.

Also experimenting with Bulletin Chain for creative storage, People Chain for identity confirmation, optimistic campaign approvals with challenge-bond commit/reveal for content moderation.

A lot of the design stems from the idea that publishers and users should have control and agency over the advertisements they are exposed to. They should be able to control and filter what content they display or see, and be clearly and fairly compensated for the work they do. Advertisers should be able to control their risk and have the option to be kept in the loop for each settled claim.

The user-facing side ships with a Smoldot ↔ RPC compatibility layer with a centralised RPC fallback for maximum resiliency and user privacy.

There’s still a lot more work to do before any kind of mainnet release, but the current build has the key pillars in place.

Ultimately, DATUM is a passion project of a guy who is upset with the way the internet has turned out. I think the Web3 philosophy is good in principle, but the blockchain space has been commandeered by gamblers and charlatans. I’m wanting to build systems and tools that will support a more user-centric internet that seeks optimization rather than exploitation of maximum extracted value. I’m not looking for payment or any kind of funding, but hopefully I can help move the needle toward a better internet experience for some and hopefully for all.

Based on the recent insight report published by W3F, it seems plausible that the value created by user data is generally sufficient enough to supplement their online activities, given they had access to this value as a steam of revenue. Moreover, even just a small percentage of value capture in key areas like North America or Europe may be enough to sustain an average user’s activities across Web3 services. I intend to experiment with this further.

Once the DATUM Paseo deployment stabilizes, I’ll try to mock up and model different digital services and gather some empirical observations on base costs. Currently, tests of raw cost per 1000-impressions are approximately 10x lower than industry standard while still being profitable for all roles under normal conditions.

I’ll continue to share progress as comes in.