Verifying Twitter On Your Domain with Chainlink

Oct 22, 2020

Share this article:

Crypto is intimidating. Users face unfriendly hexadecimal addresses, dozens of individual addresses for each and every crypto in your wallet, a constant fear of a typo, and an inability to verify the receiving address before sending. Blockchain domains solve these issues for end-users by substituting an easy to remember name — yourname.crypto — linked to dozens of your cryptocurrencies validated on-chain. However, we wanted more. Today we’re excited to announce another innovation in improved UX for crypto users: On-chain twitter verification for sending crypto payments.

See the Twitter Handle before sending crypto on MEW
See the Twitter Handle before sending crypto on MEW

Now, when you send a payment with Unstoppable you can check the verified Twitter account linked to a domain, giving you much more confidence in the recipient before sending money.


At its core, the Twitter verification system extends Chainlink’s market leading decentralized oracle network to support an entirely new class of use cases — social verification. While oracle networks have initially been applied to DeFi to satisfy its growing demand for price feeds, oracles will play a much more expansive role in other user cases.. Although still in its infancy, we believe that social app verification with on-chain oracles linked to blockchain domains opens up unique and interesting new opportunities for the emerging decentralized web and non-financial use cases of blockchain.

Setting up your domain

  1. Give permission to the Chainlink Network to post verified data to your domain by approving the Twitter verification operator to make changes to your records.
  2. Tweet a verification post.
  3. Pay the oracle to verify tweets using the Twitter verification operator contract on-chain.

Watch this video to setup your domain now:

How it works

The Twitter verification system consists of an External Adapter and External Initiator for Chainlink nodes that supports the validation of user twitter accounts on the Ethereum blockchain using .crypto domains. The goal here is to create bi-directional verification on-chain. Users post verification information linking their domain name to their Twitter account on their Twitter feed. Then the Chainlink Network posts verification information linking a Twitter account to a domain name on the blockchain. The verification signatures can be checked on-chain and the Twitter feed can be checked using Twitter APIs to confirm the bi-directional association and attesting to the link between the blockchain domain and user Twitter handle.

Let’s take a behind the scenes.

Flow for Twitter Verification with Chainlink (download image to view better)
Flow for Twitter Verification with Chainlink (download image to view better)

Approving Twitter Verification Operator

When users give permission to the Chainlink Network to post data to their domain name, what they are actually doing is approving the Twitter verification operator via the .crypto Registry using either of the two functions below:

function approve(address _approved, uint256 _tokenId) external;

function setApprovalForAll(address _operator, bool _approved) external;

Both of these functions come from the ERC-721 Non-fungible Token standard. They let users delegate domain control on an individual domain basis, or for all of that user’s domains.

You can see the contract on-chain here.

Currently, at Unstoppable we use a setApprovalForAll call to make a one-time call to enable the Twitter verification for all domains users own. When making this call, users are not directly permitting the Chainlink Network to make updates on their domain. Instead, they are giving permission to a specific smart contract that has limitations on who and what updates can be made to your domain. This ensures the oracle can only set Twitter verification fields on a domain. The setValidation function has hardcoded limits to only allow the setting of Twitter fields, social.twitter.username and

Once the Twitter verification operator is set up to allow the Chainlink Network to write the needed data to the smart contract, the user can tweet the required validation information — their domain and unique verification code.

Tweeting the Verification Post

Now the user needs to post the validation information to their Twitter account to associate the Twitter handle and their blockchain domain. To do this, the user tweets a standard tweet containing both the domain that they wish to verify and a verification code to allow the lookup of the tweet by the oracle.

Example tweet contains domain name paulbloc8.crytpo and verification code, both the domain name and verification code are required:

Requesting Verification

After the user has pre-configured their domain and successfully sent a tweet, the last step they need to make is a call to the verification contract to request that the oracle validate a tweet. To make this easy, we’ve embedded the flow inside of the LINK token’s ERC-677 standard transferAndCall function. The ERC-677 standard allows tokens to be transferred to contracts that have contract trigger logic. So transferring LINK to the verification contract will then call the onTokenTransfer function as a callback, registering a request (domain and verification code) with the oracle.

The transferAndCall function logic inside the LINK token

The onTokenTransfer function call checks if the domain owner initiated the request, that the verification contract is approved by the domain, and that an appropriate amount of LINK has been sent with the request.

onTokenTransfer call also checks owner and signature
onTokenTransfer call also checks owner and signature

After requesting validation, the Chainlink (oracle) node jumps into action.

Chainlink Oracle Verification

The Chainlink node is listening for request events on-chain. When the user makes a call to the onTokenTransfer an event is emitted. The operator extracts the data from the event, the domain name (NFT tokenID), and the Twitter verification code. Then searches for the tweet using the verification code hashtag. Once it finds the tweet, it compares the tweeted domain with the domain emitted on-chain. If they match, the operator proceeds with verification.

The Chainlink node signs a message attesting to the fact that the Twitter handle and domain are linked. The operator then broadcasts a setValidation call to the verification contract writing the Twitter handle and a signature to the domain’s record fields via the set method. setValidation also lets the oracle claim the LINK payment embedded in the request made in onTokenTransfer.

Resolver Contract Example set Call (link)

The twitter handle has now been associated with the domain name.

Client Lookup

When a user types in a domain name, the wallet can now also check for twitter records, and ensure the signature on the twitter records is from the Chainlink oracle, and that the twitter handle records on the blockchain domain match the verified twitter records. The Unstoppable Domains open source resolution library automatically makes these checks for wallets. So if wallets implement Twitter lookup using the library, it will automatically do these security checks. This all happens on the client-side in the users wallet. Client side validation ensures that the user can always check the validity of the data directly by checking on chain signatures with the oracle network as the trust assumption.

And that’s it!

Limitations & Technical Improvements:

  • This is only as valid as the Oracle Network. We want to increase the number of Chainlink nodes and add more data providers to remove single points of failure and add more redundancy to the process.
  • Extend to require redundancy from multiple data providers in order to update the records field, for a minimum of 2 providers must be in agreement to update a record.
  • Update UX to allow users to reset validation of their twitter.
  • We are trusting the Twitter API, and ChainLink as a 3rd party verifier. Instead, Twitter could verify directly or participate directly in the Chainlink network as a verifier.
  • Twitter is a centralized source of truth; in the future internet we need dTwitter or potentially Twitter can provision user owned identifiers per account.

Future areas of exploration:

  • Permissioning external apps to act as validators, compare to onboarding individual apps to explicitly verify for their app. This can allow user-controlled data later on.
  • Programmatic actions on permitted access linked back to a domain
  • Works not just for Dapps, but for anyone that wants to enable web3 functionality for their application, including large web2 companies

Blockchain domain names are at their core user-owned assets. Blockchain domains are ERC721 NFT tokens that link out to resolver contracts which store data about domains much like TXT, MX, and A records for more traditional domain names. Users can post records to their blockchain domain to attest ownership, much like posting txt records to confirm a .com domain ownership for configuration with DNS providers. This enables bottom-up extensible identification for participating applications and applications enabled by verification networks. We are in the first inning of a very large move in ownership online powered by user owned identifiers, off chain data, and the increasing viability of crypto networks.

Changing the way the world sends crypto

Follow me on twitter: