probablynothing.works

There are four user personas referenced in our project:

Publishers - Web 3 community managers who can choose to show ads to their communities as a source of revenue.

Advertisers - These users have messages they want to share with website visitors, and can pay for distribution of the message.

Website visitors - Users whom the ads will be shown.

Protocol operator - Provides the infrastructure to facility the advertising between the publishers and the advertisers.

The ability to bring in revenue via advertising is an important way for traditional web communities to generate revenue. However, Web 2 advertisers and Ad Exchanges have been reluctant to on-board crypto projects. At the same time, centralized Ad Exchanges are prone to "demonetization", where the Ad Exchange refuse to montize publishers for various reasons, sometimes in a transparent manner.

Permissionless-ads protocol lays out the basic foundations for permissionless ad serving infrastructure. For this hack, we implemented the following:

Ad Inventory as a NFT: Similar to a Supply Side Platforms, allowing Publishers to publish their advertising inventory and receive payment for the ads they serve Advertising Campaign as an NFT: Similar to a Demand Side Platforms, allows Advertisers to purchase advertising to the communities they wish to reach Web3 Ad Exchange Connector: Connecting between on-chain orders and Web 2 Ad Server Payment Service: Perodically pay out to the Publisher (Ad Inventory) NFT based on the amount of ads they've served Future functionalities include:

Moderation Tools: Allows Publishers and Advertisers to opt-in to different types and kinds of advertising they wish to receive and pay for Ad Formats: Standardized type and formats of advertising that suppliers can offer and advertisers can purchase Bidding & Auctions: Different methods that advertisers and publishers can reach agreement on pricing of the ads and price discovery Reporting: For advertisers and publishers to estimate the value of their NFT and optimize their spend / revenue

Our project has 5 components:

adUnit smart contract: This creates an "adUnit" as an NFT. An Ad Unit is where advertising can be displayed and where the economic value from the advertising will accrue.

An adUnit has an owner, and is implemented as a Hilbert Curve to optimize display space, and contains information about the kinds of ad that can be shown on it. E.g., the size (200x200 pixels, 800x200 piexles) and type (banner, video) of advertising that can be shown on the ad unit.

The adUnit is typically associated with a web property such as a website.

While this implementation associates the adUnit with a specific website, it can be abstracte to represent a collection of advertising types and locations that someone can operate, e.g., an advertising agency in charge of optimizing advertising revenue associated with multiple collections and properties.

Implementing the adUnit as an NFT allows the economics value accrued to collections and properties to become tradable and liquid.

campaign smart contract This creates an "campaign" as an NFT. A campaign is where advertisers will pay money to reach their desired audience.

A campaign require the following inputs:

Budget: how much the advertiser wants to spend for this campaign CPC: Cost per Click, how much the advertiser will pay for a single click, or "interaction" from the viewer Image: the creative to be shwon to the end user. This can be abstracted to represent a video, sound, or some other media type Landing Page: Where the viewer of the ad will be directed to if they click on the ad Size: how big the advertising will be. This can be abstracted to represent how much "inventory" the advertising will take up from the publisher. E.g., their website or just the top banner. An advertiser will also need to deposit their budget into the value. In this implementation, we have not required the deposite to be any particular token. But publishers can require that the advertiser pay using any set of tokens, such as USDC.

Ad Server - Google AdManager We leverage the capabilities of the Google AdManager Advertising Server to control for how advertising are displayed and other parameters. This functionality can be moved on-chain at a later date.

We also want to demostrate that it's possible to bring Web 2 advertisers directly into Web 3, allowing Web 2 advertisers to buy ads using the tools they already know to reach new audiences and formats.

dApp front-end - Firebase This is an reference implementation of the kinds of ads that can be displayed and how the economic value and be accounted for to NFT holders.

The problem is how to fairly distribute advertising space and revenue to NFT holders in a fair way. We want to avoid cases where single NFT holders can "hold up" other NFT holders from receiving advertising revenue by setting a high minimal bid amount.

In this implementation, via a Hilbert Curve, any set of contiguous NFT holders can support showing advertisements, without regard for their minting order. This implemention also ensures a certain level of "density" to optimize revenue generation for each NFT holder.

Protocol operator - Cloud Function We use cloud functions to observe on-chain events and make API calls to the ad server to insert "orders". Advertisers can start, pause, and stop their campaigns via smart contracts onchain and the cloud function will sync the state to the offchain ad server.

This also acts as a bridge between traditional ad exchanges and on-chain ad serving, allowing Web 2 advertisers (and their budgets) to be spend on-chain.