From 22101a3c0d787b8a4e3e7603e3af0b0327a4c518 Mon Sep 17 00:00:00 2001 From: Veselina Yaneva <64790881+Vesi5@users.noreply.github.com> Date: Mon, 22 May 2023 13:32:18 +0300 Subject: [PATCH 1/5] Update README.md Update of Values --- README.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 56c69e2..bc794e7 100644 --- a/README.md +++ b/README.md @@ -80,13 +80,12 @@ The platform is built on top of [Ambire Wallet](https://www.ambire.com) and uses ### Values -* **Transparency:** full reporting transparency for publishers and advertisers; they both receive the same reports -* **No intermediaries:** connect publishers and advertisers as directly as possible, therefore maximizing results and revenues; this also implies minimized fees and no commissions -* **Privacy:** ensure the user's data stays private by never collecting it -* **No custody of funds:** users have full control over their own funds; you can withdraw any amount at any point, no thresholds -* **Censorship resistance:** we empower a free and self-governed ad market with no centralised restrictions on what can and can't be advertised -* **Ease of use:** modern adtech is complicated. We aim to make it as easy as possible to interact with AdEx -* **Flexibility:** wide variety of use cases, including but not limited to: display advertising, affiliate networks, and even content micropayments +* **Transparency** Transparency is ensured through a decentralized ledger that records ad transactions, enabling a verifiable trail of information and minimizing fraud. +* **Low fees** We only ask for a 7% network fee, which is necessary to operate the platform on the blockchain. Compared to other DSPs with 15-20% fees, our platform significantly reduces costs by over 50%. In addition, the fee for advertisers, who use the ADX token to launch a campaign is only 4%. +* **No custody of funds:** Users have complete control over their funds, allowing them to withdraw any amount at any time without any minimum threshold requirements. +* **Ease of use:** Navigating modern ad tech can be complex, but AdEx simplifies the process with its user-friendly interface, ensuring effortless interaction with the platform. +* **Top-tier support.** We are committed to providing our advertisers with a smooth and hassle-free experience. Our dedicated team is available to assist with product inquiries, targeting strategy guidance, and campaign setup to ensure a seamless user experience. +* **Expanding the Web3 user base** We enable advertisers to extend their reach to an untapped segment of potential crypto users, paving the way for new business prospects and opportunities for growth and expansion and reaching the next billion users. ### Terminology From 875f269106a3a2f2387f2766e0914a61c9ea53a8 Mon Sep 17 00:00:00 2001 From: Veselina Yaneva <64790881+Vesi5@users.noreply.github.com> Date: Mon, 22 May 2023 16:24:58 +0300 Subject: [PATCH 2/5] Update README.md --- README.md | 75 +++++++++++++++++++++++++++---------------------------- 1 file changed, 37 insertions(+), 38 deletions(-) diff --git a/README.md b/README.md index bc794e7..76e1548 100644 --- a/README.md +++ b/README.md @@ -90,58 +90,64 @@ The platform is built on top of [Ambire Wallet](https://www.ambire.com) and uses ### Terminology +#### Platform +We use “platform” to refer to the AdEx DSP + #### Supply side -Throughout these documents, "supply side", "publisher" or "publishers" all refer to entities who sell ad inventory. +Throughout these documents, "supply side", "SSP", "publisher" or "publishers" all refer to entities who sell ad inventory. #### Demand side -Throughout these documents, "demand side", "advertiser", "advertisers" or "buyers" all refer to entities who buy ad inventory. +Throughout these documents, "demand side", "DSP", "advertiser", "advertisers" or "buyers" all refer to entities who buy ad inventory. -#### Users +#### Programmatic -When we refer to "users", we mean end users: not of AdEx itself, but of the publishers. In other words, the users who see the ads, but might not even be aware of AdEx's existence. +Programmatic advertising is the automated buying and selling of digital ad inventory, using real-time bidding and data-driven targeting, to deliver the right ad to the right audience at the right time. -
+#### Demand-side platform (DSP) +A DSP (Demand-side Platform) is a technology platform that allows advertisers to buy and manage digital ad inventory programmatically. -#### Events +#### Supply-side platform (SSP) +An SSP (Supply-Side Platform) is a technology platform that enables publishers to sell and manage their digital ad inventory programmatically. -Events, in the context of the AdView or the off-chain event aggregation, mean anything that a user does in regard to a digital ad - for example, click, impression, closing of the web page, etc. Events are usually broadcast as signed messages. +#### Direct publishers +Direct publishers are websites that have a direct connection to AdEx’s DSP, bypassing the need for a DSP or ad exchange platform. -#### Custom events +#### Users -Custom events usually refer to events that are publisher-defined. For example, if you're a publisher with an e-commerce website, you might choose to send an event for product purchases. +When we refer to "users", we mean end users: not of AdEx itself, but of the publishers. In other words, the users who see the ads, but might not even be aware of AdEx's existence. -A potential use case is using AdEx for affiliate networks, where publishers get a share of the revenue on every purchase of a product. +#### Events +Events, in the context of the AdView or the off-chain event aggregation, mean anything that a user does in regard to a digital ad - for example, click, impression, closing of the web page, etc. Events are usually broadcast as signed messages. #### Campaigns -Ad campaigns are traditionally defined as "coordinated series of linked advertisements with a single idea or theme". In AdEx, they further represent a intent to spend a certain budget towards spreading those advertisements: essentially, a big piece of ad demand. - -Campaigns are created with a total budget (e.g. 5000 USDC) and a specification of the desired result: e.g. purchase as many impressions as possible for this ad, with a maximum allowed price per impression and targeting information. +Ad campaigns are conventionally defined as a “coordinated series of linked advertisements with a single idea or theme”. In AdEx, they signify an intention to allocate a specific budget towards promoting those advertisements, essentially representing a substantial portion of ad demand. Because campaigns represent a financial commitment on a smart contract, they can also be seen as smart, automated insertion orders. -Because campaigns represent a financial commitment on a smart contract, they can be also be seen as smart, automated insertion orders. +#### Layer 2 -The cryptocurrencies that can be used for a campaign depend on what [Core](#core) is used and what it supports: e.g. the Ethereum implementation supports all ERC20 tokens, but it can also be deployed on any EVM network. +Layer 2 refers to blockchain scaling solutions, which allow financial transactions or other state transitions to happen very fast, off the blockchain, while still being enforceable or eventually being committed to the underlying blockchain. Ideally, Layer 2 solutions allow throughput levels seen in centralized systems, while still being as trustless and censorship-resistant as blockchains. In AdEx, we use a scaling primitive, called OUTPACE, which allows for multiple campaigns to run on the same payment channel, thus allowing for lower transaction fees. -In the AdEx protocol, each campaign uses a payment channel powered by a technology we call **OUTPACE**. Multiple campaigns can run on the same payment channel, as payment channels are created between **validators** (more on this later). +#### Validators +Validators in the AdEx ecosystem are responsible for verifying and validating transactions on the blockchain, ensuring the security and transparency of the network. More about validators can be found here. -#### Layer 2 +#### Observers +The observers are delegated to collect events in relation to a certain campaign. All validators of a campaign are, by definition, observers of all events related to it. -Layer 2 refers to blockchain scaling solutions, which allow financial transactions or other state transitions to happen very fast, off the blockchain, while still being enforceable or eventually being committed to the underlying blockchain. -Ideally, layer 2 solutions allow throughput levels seen in centralized systems, while still being as trustless and censorship-resistant as blockchains. +### Layer 2 -In AdEx, we use two scaling primitives that we defined: **OCEAN** and **OUTPACE**. +#### OUTPACE -#### Offchain unidirectional trust-less payment channel (OUTPACE) +In the AdEx protocol, each campaign uses a payment channel powered by a technology we call OUTPACE. Multiple campaigns can run on the same payment channel, as payment channels are created between validators. **OUTPACE** stands for **O**ffchain **u**nidirectional **t**rustless **pa**yment **c**hann**e**l An **OUTPACE** channel is defined on-chain with a validator set and a token address. Any amount of funds of that token can be deposited into the channel at any time. The validators observe off-chain events, and the leading validator (validators[0]) would propose the new state of the channel, and the rest of the validators check and confirm those new states. -If a state is signed by a supermajority (>=2/3) of validators, it can be used to enforce a result on-chain and withdraw funds from the channel. +If a state is signed by a supermajority (>=2/2) of validators, in the case of campaigns in which direct publishers participate, it can be used to enforce a result on-chain and withdraw funds from the channel. ##### State transition rules @@ -149,7 +155,7 @@ The state transition function enforces a few simple rules for each next state: ( Because of these rules, an OUTPACE channel does not need sequences or challenge periods. -The initially delegated validators sign every new state, and a state signed by a supermajority (>=2/3) of validators is considered +The initially delegated validators sign every new state, and a state signed by a supermajority (>=2/2) of validators is considered. @@ -194,13 +200,13 @@ To prevent confusion with the normal terms "supply-side platform" (SSP) and "dem The entire flow is as follows: -1. The advertiser (demand side) starts a [campaign](#campaigns) with a total budget and certain parameters (ad units, targeting, min/max price per impression/click/etc.); this translates to opening an [OUTPACE channel](#ocean-based-unidirectional-trust-less-payment-channel-outpace); at this point the advertiser delegates two validators: one that represents them (advertiser-side [validator](#validator-stack)), and one that represents publishers (publisher-side [validator](#validator-stack)). +1. The advertiser (demand side) starts a [campaign](#campaigns) with a total budget and certain parameters (ad units, targeting, min/max price per impression/click/etc.); this translates to opening an [OUTPACE channel](#ocean-based-unidirectional-trust-less-payment-channel-outpace); at this point the advertiser delegates two validators: one that represents them (advertiser-side [validator](#validator-stack)), and one that represents the publishers (publisher-side [validator](#validator-stack)). With SSPs, only one validator can be used (advertiser-side) and plug the SSPs directly into it as well. The trust assumptions are the same because the SSPs themselves act like a publisher-side validator. 2. Validator(s) have to accept that they're nominated for this channel (and prove that they're available) by broadcasting a signed message to the other validator(s). -3. Publishers will query their own validator(s) for available demand (active channels) every time someone opens their website/app; the query will happen on the client side (in the browser/app), much like header bidding; the [AdEx AdView](#adview) will select one of those bids and relay that selection to the validators. +3. Direct publishers will query their own validator(s) for available demand (active channels) every time someone opens their website/app; the query will happen on the client side (in the browser/app), much like header bidding; In the case of connection to a direct publisher, the [AdEx AdView](#adview) will select one of those bids and relay that selection to the validators; with SSPs this is done by the oRTB. 4. The AdView will generate events (impressions, clicks, page closed, etc.) and send them to the validators. 5. The events will be reflected by the validators, creating a new state; each valid impression event is turned into a micropayment to a publisher; publishers will be immediately able to use that state to withdraw their earnings. -6. Should the publisher decide to withdraw their earnings, they can withdraw from any number of channels at once. -7. As long as the state keeps advancing, publishers have a constant guarantee of their revenue; should the state stop advancing properly, publishers can immediately stop serving ads (see [campaign health](#campaign-health) and [Campaign health vs refusal to sign](#campaign-health-vs-refusal-to-sign)). +6. Should the direct publisher decide to withdraw their earnings, they can withdraw from any number of channels at once. +7. As long as the state keeps advancing, direct publishers and SSPs have a constant guarantee of their revenue; should the state stop advancing properly, publishers can immediately stop serving ads (see [campaign health](#campaign-health) and [Campaign health vs refusal to sign](#campaign-health-vs-refusal-to-sign)). The benefits of this approach are: @@ -211,7 +217,7 @@ The benefits of this approach are: * Allows off-chain negotiations: advertisers can bid for impressions in real time; * All data other than payments information is kept off-chain. -Each campaign has a duration, normally in the range of 2-12 weeks. An OUTPACE channel should have 2-3 times as long of a duration, in order to allow extra time for publishers to withdraw their revenue. +Each campaign has a duration, normally in the range of 2-12 weeks. An OUTPACE channel should have 2-3 times as long of a duration, in order to allow extra time for direct publishers to withdraw their revenue. ### Closing a campaign @@ -227,7 +233,7 @@ While it is possible for a publisher-side validator to refuse to approve the sta The campaign health is a publisher-specific concept that indicates whether the advertiser is properly paying out after impression events. -Each publisher, with the help of the publisher-side validator, tracks the health status of each campaign they've ever interacted with. If a certain (configurable) threshold of non-paid impression events is reached, the campaign will be marked unhealthy, and the publisher will no longer pick it until the paid amount increases sufficiently. +Each direct publisher, with the help of the publisher-side validator, tracks the health status of each campaign they've ever interacted with. If a certain (configurable) threshold of non-paid impression events is reached, the campaign will be marked unhealthy, and the publisher will no longer pick it until the paid amount increases sufficiently. The campaign health should not be confused with OUTPACE state sanity: even if a campaign is unhealthy, the publisher-side validator will continue signing new states as long as they're valid: because of the unidirectional flow, valid states can only mean more revenue for publishers. @@ -249,7 +255,7 @@ For example: Running the validator stack requires computational resource, and the way the validator consensus works implies that channel validators have to represent opposite sides (if they don't, the channel should not be used). -This means that in most cases, no matter if you're a publisher or an advertiser, you'd end up using a validator ran by someone else. +This means that in most cases, no matter if you're a publisher or an advertiser, you'd end up using a validator run by someone else. Third-party validators may require fees to participate in your channel (campaign). With OUTPACE, there's a convenient way of doing that, by just including an entry in the balances tree. Furthermore, the fees can be ongoing (e.g. per 1k events, or per minute), taking advantage of the micropayments capability of OUTPACE. @@ -326,7 +332,7 @@ For more information on how the payment channels work, see [OUTPACE](https://git The market is a RESTful service maintained and hosted by AdEx Network OÜ. -The primary role of the market is to facilitate demand/supply discovery and trading. It keeps record of all campaigns that are currently valid, and allows publishers/advertisers to query that list in order to find what they need. +The primary role of the market is to facilitate demand/supply discovery and trading between advertisers and direct publishers. It keeps record of all campaigns that are currently available, and allows direct publishers/advertisers to query that list in order to find what they need. The market needs to track all on-chain OUTPACE channels and needs to constantly monitor their liveness (>=2/3 validators online and producing new states) and state. @@ -371,13 +377,6 @@ For the JSON blob specification, see [`campaignSpec.md`](https://github.com/AdEx -#### Paying by impression (CPM) or by click (CPC) - -It's possible to pay for advertising in any way by configuring a campaign goal - e.g. by impression, by click, or even by number of user registrations (CPA). - -However, the default option is always impressions as we believe that this creates the best incentives. Paying by click implies more risk and unpredictability, since the publishers will be pushing impressions out without prior knowledge of how much a certain ad will convert. - -Ultimately, the raw resource the publisher provides is impressions, and the conversion rate of the ad depends mostly on the advertiser. #### Analytical reports From 1130de8b158342217614a2090b4a026ba8fbba03 Mon Sep 17 00:00:00 2001 From: Veselina Yaneva <64790881+Vesi5@users.noreply.github.com> Date: Tue, 23 May 2023 12:10:12 +0300 Subject: [PATCH 3/5] Update README.md --- README.md | 36 ++++++++---------------------------- 1 file changed, 8 insertions(+), 28 deletions(-) diff --git a/README.md b/README.md index 76e1548..214b199 100644 --- a/README.md +++ b/README.md @@ -399,7 +399,8 @@ In order to maintain compatibility with the existing AdEx infrastructure (the Pl ### AdView -The primary implementation is [`adex-adview-manager`](https://github.com/AdExNetwork/adex-adview-manager), which is designed for the web. +The primary implementation is [`adex-adview-manager`](https://github.com/AdExNetwork/adex-adview-manager), which is designed for the web. It utilizes first-hand data obtained from publishers, ensuring the utmost accuracy by deriving data directly from the source. By harnessing the insights from the AdView, we can compare the reported performance from SSPs, make conclusions about its accuracy and optimize advertiser’s campaigns, leading to improved audience targeting and enhanced results. The AdView serves as a fraud-protection tool implemented to guarantee that our advertisers are billed solely for authentic and verifiable results, reinforcing the integrity of our payment system. + It's important to note that the AdView is entirely browser-agnostic. It can run as a library (alongside React or any other modern framework) or in an `