Project Name: TronXChange
Project Track: Web3
Team Name: Lutron
Team Member(s): (1) @ageoflutron
HackerEarth Project Link: HackerEarth Submission
Project Goal: TronXChange is a Tron-based Decentralized App that connects publishers and advertisers, promoting a fairer and more widely accessible ad marketplace.
Project Value: The existing infrastructure of ad exchanges is an ineffective solution to connecting publishers and advertisers. The status quo advantages large businesses and incentivizes these businesses to monopolize the industry. A decentralized storage and payment system for connecting publishers and advertisers would directly address problems of transparency, audience privacy, and market monopolies. Advertisers would save on the commissions usually paid to ad exchanges, and small publishers would be able to enter the space without paying astronomical setup fees to exchanges. Both advertisers and publishers would benefit from not having to waste valuable time manually negotiating contracts with multiple exchanges.
Project Info: whitepaper (58.8 KB)
Project Website: TronXChange
Project Test Instructions:
SETUP
- Connect to TronLink and the TRON Nile Testnet.
- Compile AdLibrary.sol in TRONBOX, using compiler 0.8.0+commit.7c2e641
- Deploy AdLibrary in the JavaScript VM environment with a fee limit of 1000000000.
RUN
- Add some advertisements (addAdd()) and ad spaces (addAdSpace). Flow requires at least one ad with a higher price than at least one adspace. See details below.
- Run an ad (runAd()). Note that the bid price must be not lower than the set ad space price, but not higher than the set ad price.
Project Details:
Advertisers store their ad content on InterPlanetary File System (IPFS) or similar decentralized storage technologies. Using the content hash, they then create a smart contract on the TRON blockchain to reference the ad content. These smart contracts will contain the usual metadata, but will also contain information about the type/format/size of content, as well as information about pricing and payment mechanisms.
Publishers create a profile on TronXChange, where they specify requirements for type/format/content of ads that they are willing to host. This information is also hosted on IPFS, and publishers associate this profile information with a smart contract that specifies their own payment mechanisms. When a publisher has ad space, they will post to TronXChange, which matches the post to advertisements based on eligibility requirements specified by the publisher smart contract and the individual ad’s smart contract. A winning advertisement is selected, the advertiser pays the publisher directly via mechanisms described in the respective smart contracts, and the publisher retrieves the content from IPFS via the ad’s hash. Publishers publish the ad alongside their pre-existing content, requiring user interaction (watching a video, scrolling past the ad, clicking, etc) as proof of publishing (proof-of-work) to validate the transaction.
For a small buy-in for each active day (each day where an ad is served), TronXChange maintains a measurement of a publisher’s ad engagement throughout the day. The publisher with highest average ad engagement (proof-of-work per ad served) receives a proportional payout in TRX. This incentivizes publishers to choose ads that are the most engaging and appropriate for their audience, which in turn creates a better user experience and serves as ad quality control. In a ripple effect, advertisers are incentivized to create ads that meet publisher requirements for higher quality and engagement.
Smart Contract links: testnet deployment
Project Milestones:
This project was ideated at the TRON x Princeton Hackathon on 9/23. Great care was taken in understanding the existing ad exchange infrastructure, designing functionality requirements and incentives, and designing server logics for a high-performance and scalable system.
The current status of the project is proof-of-concept smart contracts. Users may test the primary smart contract AdLibrary which provides MVP functionality. Users may expect a basic web UI by mid-October, roughly three weeks after the original whitepaper.
For the purposes of this submission, all ads and ad spaces are eligible to be matched with each other provided the price the advertiser is willing to pay is higher than the minimum price the publisher is willing to accept. In its final form, this system will allow advertisers and publishers to set requirements on the size, layout, and content of ads.