Piggi - Web3.0 Marketing Stack

Visit piggi.ai for more.

Motivation

The marketing industry is currently dominated by a few large companies that possess a significant level of influence over the market. As the primary means for marketers to reach a mass audience and for publishers to generate revenue, many entities feel compelled to utilize these centralized giants as their ad networks, despite the lack of oversight and accountability. This leaves both Marketers and Publishers susceptible to exploitation and calls for a fundamental change in the current system.

Marketers often encounter challenges in comprehending the true performance of their campaigns when utilizing ad networks, due to lack of transparency in the analytics provided. Inaccurate or unreliable attribution models can further exacerbate these issues, making it difficult to identify areas for improvement and optimize future campaigns. Click farms, bots, and fake websites can skew the metrics and lead to false conclusions, thus making it challenging to justify the return on investment(ROI) and expenditure associated with digital marketing. Moreover, it becomes difficult to achieve a favorable Customer Lifetime Value(LTV) with respect to Revenue Per Acquisition(RPA).

Publishers have different challenges than Marketers, such as not having Trustable analytics, and losing credibility with their audience when the ads they show don't meet user expectations and negatively impact the customer experience because they are not relevant. The ad networks currently being widely used also take away a huge part of income.

We aim to tackle these challenges faced by the marketing industry by developing our own protocols, UAAP, and NERP. By leveraging blockchain technology and a Reputation/Experience-based system, we offer a reliable and trustless solution that benefits all stakeholders. Marketers can trust in the accuracy, immutability and verifiability of the attribution. End-users are protected from spammy or annoying ads. Overall, the protocols offer a promising solution for creating a safer, more trustworthy more transparent advertising ecosystem.

Abstract

This paper describes innovative and cutting-edge protocols that utilize reputation-based and trustless attribution methods, which are expected to completely change the way in which users interact with the Web3 environment, users possess both a unique digital identity and distinct behavior patterns. Traditional metrics, such as click-through rates and conversion rates, are no longer sufficient for understanding how users interact with decentralized projects. Unlike traditional Web 2.0 user acquisition methods, the Protocol is specifically designed to leverage the unique characteristics of the Web3 ecosystem, such as decentralization, security, and scalability.

As the adoption of Web3 technology is growing, the demand for a reliable platform that facilitates the seamless discovery of superior decentralized applications (DApps), web3 games, and decentralized finance (DeFi) projects is becoming increasingly vital. The Protocol addresses this need by providing publishers with a reliable mechanism for identifying and promoting quality projects, while also providing Marketers with a measurable and predictable way to launch targeted campaigns.

We enable an open, peer-to-peer, global marketing infrastructure powered by immutable code controlled attribution. This is achieved using a claim-verify mechanism in which a publisher claims traffic that they drove and the marketer validates the claim. The system is developed with high flexibility allowing conventional, unconventional and futuristic methods of marketing to be implemented. As Web3 expands and end user interactions become on-chain events, some marketing processes could ideally be automated by Smart Contracts. However, in cases where a 100% on-chain system is not feasible, trust in the system and other stakeholders is established through the inbuilt Reputation algorithm.

The Core Tenets

The development of Web 3.0 technologies and protocols was guided by the principle of decentralization. With the introduction of our protocols, we aim to prioritize the user experience and value for stakeholders as a fundamental principle. Furthermore, we endeavor to ensure that all parties involved benefit mutually and foster a sense of community among users.

The Network Stakeholders

Network comprises of 3 major stakeholders

1. Marketers –

Marketers are individuals or entities who wish to promote their products or services to a wider audience. E.g. Web3 Projects, DApp's, DeFi Apps, etc.

2. Publishers –

Publishers are individuals or entities that have a sizable viewership and can assist Marketers in reaching a larger audience. E.g. Communities, DApp's, Web3 Games, DEX/CEX etc.

3. End-Users –

End users are those who are at the receiving end of the campaigns provided by the marketers on the publisher’s channel. Usually, the end users are the publisher’s followers.

Network of Publishers, Marketers & End-Users

These stakeholders play a crucial role in the network as marketers rely on publishers to disseminate their message effectively and publishers rely on Marketers for revenue to sustain their operations. The network is built on the mutual benefit of both stakeholders and the creation of value for them is central to the ecosystem's functioning.

The Protocols

The fundamental purpose of the protocols is to enable a system for marketing that is completely decentralized. To accomplish this we built these protocols:

• UAAP (User Acquisition Attribution Protocol) ensures Service delivery.

• NERP (Network Experience & Reputation Protocol) focuses on the quality of the service.

User Acquisition Attribution Protocol - UAAP

The UAAP, or User Acquisition and Attribution Protocol, is a system that enables Transparent and Verifiable attribution for Marketers and publishers. At its core, a claim-verify mechanism is implemented to manage attribution.

The protocol is composed of smart contracts, including the Publisher Manager Contract, Campaign Manager Contract, Campaign Contract, and Holding Contract, that form the on-chain components of the system. They all have different functions ranging from creating a lead to holding tokens until the claim is verified.

The claimer, who may either be a Publisher or a third-party provider approved by the publisher or a piece of code in a Smart Contract, can claim a user that was generated by the publisher. As soon as they do this a predefined amount of tokens will be taken from Campaign funds and held. The verifier, which may be a Marketer or an approved third-party provider, or a piece of code in a Smart Contract, can then verify the claim. The tokens will be transferred to the publisher if the claim is true. If the claim turns out to be false the tokens shall be reverted back to the marketer. This allows for a secure and efficient process for user attribution. In any case, the claimer and verifier, need to get trustable information to make this work. This information can be gathered in a variety of ways including through the use of standard tracking mechanisms, user providing the information in exchange for incentives, on-chain transaction data, a mix of these, or any other appropriate approach.

Additionally, all the data related to the claims and verifications is stored on-chain, allowing providers to perform analysis and gain valuable insights. The UAAP also enables the discoverable creation and funding of leads.

The Network Experience & Reputation Protocol - NERP

The Network Experience & Reputation Protocol, or NERP, utilizes a decentralized trust system proposed in the study “A blockchain-based trust system for decentralised applications: When trustless needs trust” [1] to manage the reputations of Marketers, Publishers, End Users as well as the Campaigns. Following an interaction, the involved parties are able to give feedback to each other. The feedback may be implicit or explicit. The experience between the two parties is built up from the previous feedbacks between the two. The reputation of a stakeholder is then calculated considering the experience of all other stakeholders with them.

Stakeholders who engage in good practices will have a higher reputation and will be encouraged to stay in the system. In comparison, those who engage in malpractices will have a lower reputation. This leads to the development of a healthy and constantly evolving network. The NERP plays a crucial role in promoting accountability and credibility within the ecosystem, by giving users the ability to make informed decisions based on the reputations of different actors, ultimately leading to a better overall experience for all stakeholders involved.

Providers

With the implementation of the aforementioned protocols as the foundation, a diverse range of functionalities are to be carried out by the providers. These functionalities are designed to enhance the project's overall quality. They can be broadly categorized into two groups:

1. Providers who offer interfaces that simplify the utilization of the protocol i.e by assisting publishers and marketers in claiming and verifying respectively.

2. Providers who leverage the protocol and its associated data to create new applications and functionalities.

The System Flow

Campaign Creation

The marketer creates and funds a new campaign using the Campaign Manager smart contract. This contract manages the creation and bookkeeping of campaigns. A new Smart Contract for that particular campaign is then created. This is called the Campaign contract. This contains all the details like Campaign ID, Campaign name, Reward per User, etc. Whenever a campaign has been created or funded the campaign manager contract logs it on-chain. Providers and Publishers can view this.

Attribution Data Flow

Publishers can then post the leads to their channels where the end users can interact with them. When a user performs an action (Specified by the marketer) the provider layer notifies the Publisher Manager Contract about the attribution i.e User has interacted with a Campaign. The Publisher Manager contract includes a function called ‘claimUser’ which allows a publisher to claim a particular user who has interacted with a specific Campaign. Every claim has a unique ID. When a publisher claims a user, a predefined number of tokens is frozen using the holding contract. The provider layer can then verify if the claim is true or false. The Publisher receives the previously frozen tokens once a claim is verified. In case the claim turns out to be false the tokens are reverted back to the marketer’s fund.

Implementation

The system will be deployed on zkSync, a cutting-edge layer2 zk-Rollup solution for Ethereum. This choice was made due to zkSync's ability to offer lower transaction fees and higher transaction speeds while still maintaining the same high level of security that Ethereum is known for. This makes zkSync an ideal choice for our system's deployment.

Furthermore, zkSync's compatibility with the Ethereum Virtual Machine (EVM) means that developers who are already familiar with the Ethereum ecosystem will be able to start creating on-chain provider interfaces without any additional learning curves. This makes the deployment much smoother and less time-consuming.

zkSync's handling of Account Abstraction is another benefit of choosing to deploy on this platform. Account Abstraction can be a critical component in the setup of managed accounts between providers and stakeholders.

The Smart Contracts

1. Publisher Manager Contract

interface PublisherManager {
   
    function viewCampaignHeldTokens(address _campaign) 
external view returns(uint);

    function claimEndUser(address _userId,address _campaign) 
external;

    function rateMarketer(address _marketer,uint _feedback) 
external;

    function rateCampaign(address _campaign,uint _feedback) 
external;

}

Source Code

The Publisher Manager Contract serves as the gateway for Publishers to interact with the rest of the system. Through the claimEndUser function, Publishers can claim attribution by providing the user and campaign identifier. The viewCampaignHeldTokens function enables Publishers to view their pending, verified tokens for a campaign. Additionally, the rateMarketer function allows Publishers to provide feedback for Marketers, but only after they have successfully claimed and verified attribution for a campaign.

2. Campaign Manager Contract

interface CampaignManager {
    
    function createCampaign(
        string memory _campaignName,
        uint _revenuePerUser )
external returns (address);

    function fundCampaign(address _campaign ) external;

    function verifyClaim(
        address _campaign,
        uint _claimId,
        bool _result,
        uint _feedbackPublisher,
        uint _feedbackUser ) 
external;

}

Source Code

A marketer initiates the creation of a new Campaign Contract by calling the createCampaign function with the relevant campaign details. Once token transfers have been made to the campaignManager, the fundCampaign function is executed to provide funding for the contract. To validate an attribution claim, the verifyClaim function is utilized by specifying the claim identification details, as well as the result and feedback.

3. Campaign Contract

interface Campaign {

    function claimUser(address _publisher,address _user)    
  onlyPublisherManager external;

    function verifyClaim(
        address _verifier,
        uint _requestId,
        bool _result )
  onlyCampaignManager onlyApprovedVerifier external;

}

Source Code

Each Campaign Contract signifies a singular Campaign initiated by a Marketer. To initiate an attribution claim for the campaign, the claimUser function is called. To facilitate the feedback process, only the PublisherManager has the authority to raise claims, requiring Publishers to raise claims through the Manager. The verifyClaim function is employed to verify a previously made claim, and this function is only accessible by the CampaignManager to preserve the proper functioning of the feedback mechanisms and to confirm that only authorized Verifiers can validate the claim.

4. HoldingWallet Contract

interface HoldingWallet {

    function viewHoldings (address _publisher,address _campaign) 
external view returns (uint);
   
    function freezeTokens (address _receiver) external payable;

    function revokeTokens (address _receiver,uint _amount) external;
    
    function freeTokens (address _receiver,uint _amount) external;

}

Source Code

The HoldingWallet is utilized to manage the tokens during the claim and verification process. Keeping the tokens in the wallet requires the Verifier to take appropriate action in response to a claim. The viewHoldings function provides information about the amount of tokens held for a publisher in a specific campaign. If an attribution claim is made, the freezeTokens function is activated by the Campaign Contract, which transfers the tokens to the HoldingWallet and holds them until the claim is verified. If the claim is found to be false, the revokeTokens function is triggered by the Campaign Contract, returning the held tokens back to the Campaign Contract. Conversely, if the claim is deemed true, the freeTokens function is executed by the Campaign Contract, transferring the tokens to the publisher.

5. Experience Contract

interface Experience {

    function enableFeedback(address _from, address _to) 
external onlyManagers;

    function giveFeedback(address _from,address _to,uint _feedback) 
external onlyManagers returns(bool);

    function viewExperience(
        address _from,
        address _to) 
external view returns(uint,bool);
   
}

Source Code

This contract manages the Experience between each entity. The right to update feedback is granted exclusively to the Campaign Manager and the Publisher Manager, who are knowledgeable of all claims and verifications. This ensures that feedback is provided only by involved parties. The enableFeedback function enables an entity to furnish feedback to the other party. The giveFeedback function updates the mutual experience between the two entities by incorporating the new feedback.

6. Reputation Contract

interface Reputation {

  function RepPos(address _entity) external returns (uint);

  function RepNeg(address _entity) external returns (uint);

  function updateReputation(
      bytes calldata positiveRep,
      bytes calldata negativeRep )
external onlyAdmin;

}

Source Code

This Contract stores the positive and negative reputations (RepPos and RepNeg respectively) of every stakeholder. Since the reputation calculation is computationally expensive, it is done off-chain and updated on-chain at regular intervals. The calculation is verifiable since the Experiences used and the algorithm is open to view. Currently, the computation is handled solely by our provider as we are still working towards more efficient algorithms. Eventually, the computation would be handled by other decentralized Oracles.

The User Acquisition & Attribution Protocol(UAAP):

Creating a New Campaign

Marketers create a new campaign by calling the createCampaign (campaignDetails) function in the CampaignManager contract. This emits the campaignCreated(address indexed marketer,address indexed campaign) event, which allows publishers and providers to monitor the contract logs and stay updated on newly created campaigns. Marketers may also add trusted third-party addresses for contract management. To fund a campaign, transfer tokens to the Campaign Manager Contract and use the fundCampaign (campaignAddress) method. This funds the specified campaign and emits the campaignFunded(address indexed campaign,uint indexed amount) event, enabling publishers and providers to track funding information through the contract logs

Raising an Attribution Claim

The provider layer invokes the claimEndUser(address userId, address campaign) function of the PublisherManager Contract to attribute an end user(identified by userId) who has interacted with a campaign(identified by campaign address) to the publisher. This leads to the claimUser(address publisher,address userId) function of the Campaign Contract being invoked. Only the PublisherManager is allowed to make claims to impose accountability. The reward tokens are transferred to the HoldingWallet Contract by calling the freezeTokens(address receiver,uint amount) function of the HoldingWallet Contract. The event NewClaim(address indexed publisher,address indexed user,uint claimId) is emitted every time a claim is made.

Claim Verification

The provider layer monitors the Campaign Contract for claims. After verifying the validity of the claim, the verifier calls the verifyClaim(address campaign, uint claimId, bool result, uint feedbackPublisher, uint feedbackUser) function of the CampaignManager contract. The Campaign Manager after managing the feedback , invokes the function verifyClaim(uint claimId,bool result) of the Campaign Contract. In case the claim is valid, the held reward is transferred to the Publisher by calling the freeTokens(address publisher, uint amount) function of the HoldingWallet Contract. In case of a valid claim, the event SuccessfulClaim(address indexed publisher,address indexed user,uint requestId ) is emitted whereas the event RevokedClaim(address indexed publisher,address indexed user,uint requestId) is emitted for a false claim.

Network Experience & Reputation Protocol(NERP)

The Quality of service depends on the end users (in this case Publishers, Marketers, Providers & End-User). To enable the assessment of each entity’s quality and to evaluate the trust between two parties we use a blockchain-based trust system proposed in the study “A blockchain-based trust system for decentralised applications: When trustless needs trust” [1]

The details of the implementation are provided in the following section.

Evaluation of Trust between Transacting Parties

Sequence Diagram of Decentralized Trust System Incorporation

Each transacting party has Reputation and Experience. Experience is an asymmetric relationship from an entity to another which is built up from previous transactions between the two. Experience is an indicator of trust [2]

After the delivery of ensured service between two entities the trust system enables an entity to give feedback (this is implicit as well as explicit) toward its counterpart, thus establishing and updating the Experience relationship between the two. As a result, the trust system maintains an Experience network among participants, which is publicly recorded on-chain and autonomously updated whenever an entity gives feedback to the other. The reputations of all participants are then calculated based on the Experience network, following the idea of weighted Google PageRank algorithms.

Finally, trust relationship between two entity is calculated as a composition between Experience and Reputation.

Reputation mechanism

The reputation of an entity represents the overall perception of a community regarding the characteristic of the entity such as trustworthiness. In the DApps ecosystem, the reputation of an end-user $U$ (denoted as $Rep(U)$) can be calculated by aggregating $Exp(i,U)$, $∀i$ are users who have already been transacted with $U$. To calculate the reputation of end-users, we utilise the model proposed in [1] which is based on the standard PageRank [3] and the weighted PageRank [4].

Let $N$ be the number of end-users in the DApps ecosystem, an directed graph $G(V,E)$ is constructed in which $V$ is a set of $N$ users, $E⊆{(x,y)|(x,y)∈V2∧x≠y}$ is set of edges representing experience relationship $E(x,y)=Exp(x,y)$. If there is no prior transaction between $(x,y)$; $E(x,y)=0$. To enable the reputation model, $G(V,E)$ is divided into two sub-graphs: positive experience $PG(V,PE)$ in which any edge $PE(x,y)=Exp(x,y)$ satisfying $Exp(x,y)>θ$ and negative experience $NG(V,NE)$ in which any edge $NE(x,y)=Exp(x,y)$ satisfying $Exp(x,y)<θ$, where $θ$ is a predefined threshold. $d$ parameter is a damping factor ($0<d<1$) introduced in standard PageRank [3]. The reputation for each sub-graph is then calculated as follows:

Positive Reputation

$RepPos(U)=(1−d)/N+d(∑∀iRepPos(i)×PE(i,U)/CPos(i))$​

in which $CPos(i)=∑∀jPE(i,j)$ representing the sum of all positive experience values that the end-user $i$ holds (toward other end-users).

Negative Reputation

$RepNeg(U)=(1−d)/N+d(∑∀iRepNeg(i)×1−NE(i,U)/CNeg(i))$in which $CNeg(i)=∑∀j(1−NE(i,j))$ representing the sum of all complements of negative experience values (i.e., $1−NE(i,j)$) that the end-user $i$ holds (toward other end-users).

Overall Reputation

$Rep(U)$ is the aggregation of $RepPos(U)$ and $RepNeg(U)$:$Rep(U)=max(0,RepPos(U)−RepNeg(U))$

The Feedback Loop

The Experience contract calculates and stores the experience between each party based on feedbacks. Since feedbacks must be interaction based, all feedbacks and interactions are routed via the Publisher Manager and Campaign Manager contracts who are solely given access to the Experience contract. When a Publisher initiates a claim for an attribution in a campaign, the Publisher Manager enables the marketer to give feedback towards this Publisher and the User that is being claimed. The User of the claim is allowed to give feedback towards the campaign. When verifying the claim, the marketer can provide feedbacks towards the Publisher and the User. After a claim is verified, the Publisher can provide the feedback for the marketer.

Feedback loop to update Reputation & Experience between parties

• While verifying the claim, the Marketer gives feedback for Publisher and the User based on factors such as the Quality of the user for the Marketer and the validity of claim.

• End-User optionally gives feedback towards the Campaign to determine its quality. Negative feedback by reporting the Ads as in-appropriate, irrelevant, spammy etc.

• Publisher can provide feedback for the Marketer after his claim has been validated.

Constraints And Vulnerabilities

Reputation cold start conundrum

The reputation system in place operates on a slow accumulation of positive experiences and a quicker reduction of reputation in the case of negative interactions. When a party first joins the system, they begin with a base reputation score, but until they establish a credible history of legitimate behavior, it can be difficult to accurately assess their trustworthiness. This presents a challenge for the system, as it lacks a reliable way of verifying the legitimacy of newly joined parties. It takes time for these parties to build a reputation and prove their credibility; until then, their reputation remains uncertain.

Web 3.0 is still a work in progress

Web 3.0 is an emerging technology that is yet to mature and be widely adopted. As a consequence, for attribution in Web 2.0 projects, the system may have to rely on external providers, leading to various potential obstacles, including security, dependability, and responsibility concerns. The reliance on third-party providers for attribution increases the likelihood of subpar user experiences, presenting another challenge for the system.

Off-chain reputation calculation

The cost of maintaining an on-chain reputation system can be prohibitively high, which is why the system will opt to calculate the reputation of all parties involved off-chain using oracles. Even though the reputation data will be available on the chain to all parties, without the ability to verify the calculation process, there may be a lack of trust in the results of the off-chain reputation system, which could further erode its credibility.

False and falsified Claims

The trustworthiness of the protocol depends on its on-chain components, which are implemented as open-source, verifiable, and immutable smart contracts. This ensures that the code is transparent and cannot be altered once deployed, making it secure and trustworthy.

However, the trustworthiness of the protocol can be compromised by the actions of the Claimer and the verifier. The Claimer may attempt to falsely claim that a user has performed a certain action, and the Verifier may attempt to falsify claims, even if the user has indeed performed the described actions.

If the publisher or marketer decides to delegate the claiming or verifying process to a third party, there is a risk that the third party may attribute the user to the wrong publisher. This could result in incorrect information being recorded on the blockchain, which would negatively impact the trustworthiness of the protocol.

Cookies

The providers may turn to cookies for attribution of web2 projects. The use of cookies, which track a user's behavior and store information on their device, can be a significant source of privacy concerns. They may not only intrude on the user's personal space but also raise security issues for the system as cookies can be exploited by malicious actors to steal sensitive information and compromise the security of the system.

The Scope & Future: Increased Adoption and Full Decentralisation

The open-source nature of the protocols presents a unique opportunity for the system to evolve and grow, as it attracts a larger pool of providers. The influx of new providers will bring new perspectives, ideas, and innovations, which will enrich the system with new capabilities, functionalities, and features. The potential for growth and improvement is immense, as the system continues to expand and evolve.

Layer 3

The implementation of Layer 3, an application-specific layer, may be a crucial step toward enhancing the overall user experience and reducing the costs associated with blockchain transactions. The layer is designed to provide faster and more efficient transactions, which will result in a more seamless and enjoyable user experience. Additionally, the lower costs associated with blockchain transactions are bound to make the process more cost-effective for end-users, thus increasing the overall value proposition of the system.

Reputation Calculation

The existing method of calculating reputation, which is currently conducted off-chain, may undergo modification to be executed on the blockchain in the future. This transition would make the reputation calculation process more transparent and secure, as all relevant information will be stored on the decentralized blockchain.

Boosted NERP

The network newcomers often face the obstacle of the cold start problem, making it tough to establish their credibility and assimilate into the system. By boosting the NERP with entity-related off-chain information, the system can more accurately gauge the reputation of new entities, alleviating their struggles. This leads to a frictionless integration for new entities, fostering a welcoming environment that encourages more participation and contributes to the network's advancement.

Provider and Interface Standards

The roles and responsibilities of providers are crucial to the smooth operation of the system. By clearly defining and standardizing these roles and responsibilities, the system can promote a more seamless and efficient operation. As Web3 technology gains wider adoption, providers may become simplified as standard code within a decentralized application, serving as a plugin for attribution purposes. This simplification will further streamline the operation of the system and enhance its overall functionality.

Cross-Chain Interoperability and Privacy

The system may also incorporate cross-chain interoperability, which will allow providers and marketers across different chains to interact with one another. This integration will provide greater flexibility and versatility for all users of the system, and open up new opportunities for growth and development.

Additionally, the implementation of privacy-enhancing technology, such as zkSNARKs, will improve the security and privacy of the system, ensuring the protection of users' information. These updates will create a more secure, private, and interoperable experience for all users, making the system a more attractive and valuable proposition for all users.

References:

[1]Truong, Nguyen, et al. "A blockchain-based trust system for decentralised applications: When trustless needs trust." Future Generation Computer Systems 124 (2021): 68-79.

[2]Truong, Nguyen B., et al. "From personal experience to global reputation for trust evaluation in the social internet of things." GLOBECOM 2017-2017 IEEE Global Communications Conference. IEEE, 2017.

[3]Brin, Sergey, and Lawrence Page. "Reprint of: The anatomy of a large-scale hypertextual web search engine." Computer networks 56.18 (2012): 3825-3833.

[4]Tyagi, Neelam, and Simple Sharma. "Weighted page rank algorithm based on number of visits of links of web page." International Journal of Soft Computing and Engineering (IJSCE) ISSN (2012): 2231-2307.