Advertisement Tracking Interface

Abstract

This ERC proposes a standard interface for advertisement clients to track user actions in contracts and check corresponding rewards from advertisement protocols. Contracts implementing the interface use events to define a region of interest within a transaction. A Dapp could implement this interface to join an advertisement protocol, which enable projects to fund users for specific actions in a contract. While users could benefit from project funds, dapps would also get proportional rewards once they joined the protocol.

Motivation

Dapps would propsper due to mass adoption and there emerges surging demands for advertisement on chain. Compared with advertisements in web2, web3 has tremendous advantages on delivery and many other fields. We do need a set of standard tracking interfaces to facilitate advertisement related developments, which could create new economic cycles on chain, further boost dapp prosperity and ultimately benefit on chain users.

Tracking interface standard should be designed with essential & universal support for tracking user actions, and minimum restriction, which could leave most innovative space for airdrop (or advertisement) protocol. The general routine would work like this:

projects get a seed id (hash) from promotion side
before the target promotion action starts, project contracts called the interface onTrackStart(id, contract_address, function_hash)
after the target promotion action ends, project contracts called the inferface onTrackEnd(id, contract_address, function_hash)
promotion contract collect the project action info and distribute the rewards back to projects

For example, we have two entities holding their respective contracts: contract A and contract B. Contract A targets on users who did specific key moves(eg. commit specific functions) in contract B and would give bonus/airdrop to these users. Sure B would also get incentives in the meanwhile. To connect all these dots, B needs to identity these users, verify they’re coming for the A’s bonus. Hence, we need a track mechanism to facilitate such business.

Specification

The keywords “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,” “RECOMMENDED,” “MAY,” and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Interfaces

This protocol standardizes how to keep track of inter-dapp operations, which initially offers 2 main methods onTrackStart and onTrackEnd.

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.10;

interface IERCXXX {
    // Events

    /// @dev Emits when track starts.
    /// @param track_id track id
    /// @param contract_address the address of tracking contract
    /// @param function_hash the hash of tracking function with params
    event onTrackStartRecorded(uint256 track_id, address contract_address, bytes32 function_hash);

    /// @dev Emits when track starts.
    /// @param track_id track id
    /// @param contract_address the address of tracking contract
    /// @param function_hash the hash of tracking function with params
    event onTrackEndRecorded(uint256 track_id, address contract_address, bytes32 function_hash);

    // Functions

    /// @dev Track a specified contract function start move.
    /// @param track_id track id
    /// @param contract_address the address of tracking contract
    /// @param function_hash the hash of tracking function with params
    function onTrackStart(uint256 track_id, address contract_address, bytes32 function_hash) external;

    /// @dev Track a specified contract function end move.
    /// @param track_id track id
    /// @param contract_address the address of tracking contract
    /// @param function_hash the hash of tracking function with params
    function onTrackEnd(uint256 track_id, address contract_address, bytes32 function_hash);
}

Rationale

The core mechanism for this proposal is to provide a shared tracking interface for inter-dapp operations, to improve the efficiency and fulfill the required tracking business. We provide two interface functions onTrackStart and onTrackEnd to fill the basic required info and connect the necessary dots. Sure there’re more demands for more functions and it would be updated later.

Backwards Compatibility

No backward compatibility issues are introduced by this standard.