Advertisement Tracking Interface
Video
Original
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.
Security Considerations
Copyright
Copyright and related rights waived via CC0.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all