Inspiration

The crypto world is known for scams and rug pulls. It is an unfortunate side effect of having such a booming industry. The biggest issue behind crypto scams is a lack of transparency and accountability. I made this contract so that real-world Twitter identities can be validated in smart contracts. This will hopefully give investors and newcomers to crypto an extra bit of reassurance if their crypto project they are investing in is connected to a real person's Twitter account.

What it does

The final product is a method that allows smart contracts to verify what wallet addresses control what Twitter accounts.

How we built it

We started by running our own Chainlink node on Kovan, and building a simple external adapter that queries an API. Once that was working we focused our attention on creating the external adapter. Luckily most of the code to interact with the Twitter API already existed, we just needed to form it and convert it into a Chainlink friendly output. Once that was done now we just needed to write a simple smart contract to take advantage of this oracle. The smart contract has a verifyUser function that takes in a Twitter handle, and uses msg.sender to create a map from address to a special struct that stores the requestId, Twitter handle, and a bool for whether the user is verified or not. The function sends the oracle the twitter handle, then the Chainlink node grabs the most recent tweet from that Twitter handle. The fulfill function takes the wallet address the node pulled from Twitter, and passes it into the mapping. The requestId in the resulting struct is compared to the requestId of the current request. If they match, then that means that this wallet address does indeed control that Twitter handle. Finally with the proof of concept working we took everything we made and migrated it to Polygon's Mumbai testnet.

Challenges we ran into

We ran into a few challenges along the way.

  1. Setting up the initial Kovan node, and later the Mumbai node took a few days of trial and error.
  2. The Chainlink node could only send 1 variable back, but in order to do the verification properly, it should really send the wallet address it found, as well as the Twitter handle it got the address from.
  3. Figuring out how to do the verification. Originally we just had the fulfill function checking to see if that mapping already existed for that address, which worked but left the contract vulnerable to someone that used one wallet address to make the initial verifyUser call, and would claim they owned a Twitter handle that they did not own. The first call would fail verification, but now that the mapping was set up, they could use a different wallet address to pass in a Twitter handle that they did own. Then they would Tweet their initial wallet address, and the fulfill function would verify that the initial wallet address owned the Twitter handle that it did not own. This security issue was fixed by comparing requestIds and ensuring the verifyUser call and the fullfill function were apart of the same address.
  4. Current ongoing challenge is that our Chainlink Node keeps having an issue with its database erroring out after a few hours of running. We aren't really sure what's going on :(. So at the moment using the smart contract is unreliable, in the meantime, we made a Demo video to showcase how it works! ## Accomplishments that we're proud of We are super excited that we were able to set up Chainlink nodes on both Kovan and Mumbai testnets! Also that we ended with a working product(when the node database is behaving!). The smart contract we made can be queried by whatever web3 dApp or custom smart contracts you want and you can set up Twitter verification with just a few lines of code. Additionally, the framework of the node and external adapter can be built upon to do some really cool things. The external adapter is written in Python, so a user can use whatever Python library they want to, and essentially allow a smart contract to run Python code, but in a decentralized manner(if there are multiple oracles). This allows very powerful machine learning libraries such as TensorFlow, and existing powerful FinTech tools to be easily integrated into dApps. And without even writing much extra code, a hacker code set up a 2FA job, that would allow smart contracts to request 2FA before withdrawing to a new address. The contract would give the user a random string to tweet, and if they tweeted it, then the withdrawal would be approved! ## What we learned We learned so much about working with Chainlink, writing smart contracts, looking at smart contracts critically to find flaws, and just in general the software stacks needed to be a developer! Before this project, we had no experience with Chainlink(except for HODLing it) and very little experience with writing smart contracts. After this project, we feel much more comfortable with diving headfirst into the development of our weird and wild crypto ideas! :) ## What's next for Expanding Chainlink Node Social Media Interaction with ML First, we want to work on the infrastructure of the Node. Figuring out why the database is erroring out, and cleaning up the codebase so that other node operators can use the external adapter, and truly make this into a decentralized verification platform. Once that is done we want to look at expanding the capabilities of this idea. Looking into 2FA within smart contracts, and using Python's machine learning libraries to do computationally expensive ML functions off-chain. One idea for a ML project would be one that can differentiate real users from bots. This would be done by looking at the user's Twitter history and running several variables through a neural network to get an answer. This brings another challenge as to how to make this decentralized since neural network outputs are dependent on what they were trained with, so this could be a good use case to set up an aggregator instead of an oracle.

Built With

Share this project:

Updates