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.
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:
onTrackStart(id, contract_address, function_hash)onTrackEnd(id, contract_address, function_hash)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.
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.
This protocol standardizes how to keep track of inter-dapp operations, which initially offers 2 main methods onTrackStart and onTrackEnd.
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.
No backward compatibility issues are introduced by this standard.
Copyright and related rights waived via CC0.