ERC-7580: Advertisement Tracking Interface
Interfaces for advertisement clients tracking user actions and checking proportional rewards.
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
.
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.