TeaLink

Inspiration

Chainlink brings the power of real world data to trusted peer-to-peer transactions. The team at TeaLink saw this as an opportunity to leverage unique data sources in a betting environment, while maintaining the guarantee of accurate bet results without the need for a third party.

What it does

TeaLink provides a platform for users to create peer-to-peer bets based on potential future headlines.

Users can post a bet to the on-chain marketplace indicating the choice of key-words that they expect to show up in future headlines, a timeframe for those words to appear, the number of articles they expect to be written with those headlines, and optionally the sources where they expect those headlines to appear!

The marketplace allows other users to view bet parameters and the requested buy-in amount and accept any open bet on the marketplace. The user's Ethereum buy-in is stored on-chain and the winner of the bet is delegated the total pool of buy-ins. Each bet also comes with a service fee (in ETH) which is used to fund Chainlink services used in TeaLink.

TeaLink employs Chainlink Oracles and Chainlink Keepers to guarantee the correct bet outcomes. ChainLink Oracles are used to check for articles that satisfy a bet published within the bet's active period. A Chainlink Keeper is used to maintain the bet marketplace, removing any bets that have not been accepted, and closing any bets that have expired - checking who won the bet, and paying out the winners.

How we built it

TeaLink was developed using the HardHat framework. The main contract for the bet marketplace (BetGame.sol) is used to create, accept, check and close Bet structs created within it. Bets are mapped to the addresses of creators and acceptors to ensure accurate funding and payouts.

Each Bet has a unique API URL which is used to query the NewsAPI and return the number of articles including the Bet's keywords within the timeframe of the bet from the specified sources. This request to NewsAPI is done via a Chainlink Oracle using the GET --> uint job.

The API URL of a bet is used to check whether or not the bet has been won. The bet is checked by the Orcale when a user has manually called the checkBet() function or automatically when the bet has expired. A Chainlink Keeper is used to check all of the open bets in the marketplace and: 1. Remove a Bet that has not been accepted by its Accept deadline. 2. Check any accepted bet that has finished since the last keeper upkeep for its winner by using the API call.

TeaLink's contract converts a portion of the bet creator's eth funds into Link in order to fund the Chainlink Oracle and Keeper by utilizing UniSwap's V2 router. The contract is then able to use the KeeperRegistry that is in charge of maintaining the Bet Marketplace.

The user interface is built in TypeScript and is hosted using Netlify. It also features a chatroom which would be great as users can communicate to find acceptors for their bets. This feature will eventually lead to a sense of community around the application.

Challenges we ran into

TeaLink aims to be a fully self-sufficient dApp by utilizing service fees from created and accepted bets to fund the Chainlink services used. The team had to think creatively about how we could leverage Chainlink keepers to maintain the marketplace, while still allowing user's to cash-out if they know a bet was won, or didn't want to wait for the expiry date to check. We integrated a manual bet check option which allows a user to use their own Metamask balance to query the Oracle and receive a bet result (and their winning payout if won!).

We also had to think critically about how the bet behaves within TeaLink before it is accepted, once it is accepted, and after it has expired. Maintaining an accurate log of Active and Accepted bets is a very important process for the accuracy of the marketplace.

We explored using several different news api's before settling on NewApi. We are restricted to the free tiers of these APIs and so we had to be conservative with our daily api calls when testing.

Lastly, we had to come up with solutions for self-sufficient funding of the Keeper. The team wanted to allow users to only need ETH to interact with our dApp, which meant we needed to come up with a solution for converting ETH to LINK, and ultimately funding our Keeper.

Accomplishments that we're proud of

We were able to leverage both Chainlink Oracles and Chainlink Keepers in a unique way to build a marketplace-style betting platform. Through this process we learned so much about the value of Chainlink's technologies in creating powerful smart contracts which can be the engines for dApps. We were able to creatively use Chainlink jobs to get information from a unique data source, and provide an awesome usecase for bringing real-world data on-chain.

The team was able to build a successful user interface which interacts with our contract...

What we learned

The TeaLink team entered the hackathon with little knowledge of full stack dApp development, but we were able to learn the entire process of building a dApp from start to finish. Beginning with solidity and contract structure, all the way to using Hardhat and Moralis for our front end. We learned a lot about Chainlink services and saw first hand how they solved fundamental challenges in developing hybrid smart contracts. We also honed on our project managing skills in order to set project goals and ensure progress was made throughout development.

What's next for TeaLink

We have already identified several next steps for our project. We would like to provide users with a profile page where the bets they have created, bets they have accepted and closed bets they have been apart of. In addition, we would like for closed bets to display exact articles that the API returns in order to be transparent about bet outcomes.

Adding different bet types would also be a good next step. Betting on certain keywords not occuring in headlines or collections of keywords (["Kanye, "Married"] OR "Kanye", "Wedding"]) would provide users with more options. Additionally, we would like to branch out from NewsApi and use many different apis relating to different real-world events. Examples would be weather apis or sports apis leading to a larger variety of bets.

Like with many successful dApps, building community is essential to its success. We would like to create platforms for bet discussion using communication tools such as Telegram and Discord as well as the building out the on site chatroom.

Eventually, we would like this application to be hosted on the mainnet and would build in a developer fee which would take portions of bets and send to an address the developer team would own.