Creating My Own Polygon Domain Service
Everyday when I scroll on twitter, I’m constantly seeing people with a ‘.eth’ at the end of their name.
I looked more into this and became pretty interested in the concept of having a personalized domain assigned to your name. For me personally, I’d rather have a customized name service rather than a ‘.eth’ though. I always thought a cool name would be .ath, because my last name begins with those three letters, and it does resemble the Ethereum name service quite a bit! It would be so cool to see this as a real domain on the blockchain.
Through Buildspace, I created my very own domain service on Polygon and made it a reality.
Obviously, there are a few main things that need to be clarified before hopping into what I built…
Ethereum Name Service
I built my name service on a Polygon network, but both have similar functionality. an ENS is essentially a username in web3. These can be assigned to wallets, websites and much more but just like usernames in pretty much every other platform you know, there can only be one, meaning that once you buy a domain, it’s yours to keep in your wallet.
In my project, I used Polygon L2.
Polygon L2
Polygon is a layer two solution that runs alongside other blockchains such as Ethereum. We use Polygon because of its low fees and fast transactions. If we were to test this app on an Ethereum Mainnet, we would have to spend a lot of money just for transaction fees. (I made a lot of transactions in testing this application). Instead of $ETH, we use $MATIC.
An L2 is a type of scaling solution that has a separate layer when new code is executed. The second layer does inherit decentralization of the network, meaning that if it does somehow malfunction due to an error, all information will be held safely in the first layer.
Ethereum only has one layer however, it does allow other blockchains to be deployed on top of it. This is what we’re doing with Polygon; we’re running this blockchain on top of Ethereum making it an L2.
The .ath Domain service
I essentially built my own ENS, but on the Polygon L2 network that carries .ath as its domain instead of .eth. I used a few different tools:
- Solidity: The programming language that’s utilized in creating smart contracts on the blockchain.
- Alchemy: Allows us to broadcast my transactions so that miners on the testnet can understand them quickly. All of this needs to happen before it can be posted on the blockchain itself.
- React: Our frontend framework that allows us to communicate with our backend smart contract and display it on a web app so people can buy a domain from my service and use it themselves.
- The Polygon Mumbai Testnet: Since I’m testing this app without real money, I’ll be using the Polygon Mumbai Testnet. I wouldn’t want to pay real gas fees in testing domains, so I got free $MATIC from a Polygon Faucet (testing purposes, obviously I cant use this in the real world).
Selling Domains as NFTs
Once we’ve run our smart contract, it would be pretty cool to turn our domains into NFTs on OpenSea. If you think about it, ENS’ are literally NFTs where you can only hold one of them in ur wallet.
Even ENS requires some sort of ownership of an NFT on OpenSea:
ERC721 NFT Standard
I used a library called OpenZeppelin that allows us to integrate the ERC721 standard into our web3 app. A common API for NFTs can be implemented within smart contracts thanks to the ERC721 standard. This standard offers the bare minimum capabilities for tracking and moving NFTs.
In my previous article on a DAO I created, I talked about creating a universal NFT using the ERC-20 standard. We can’t use this because all of our tokens won’t be alike. Example: you can see in the image above how each ENS NFT has a different domain at the bottom.
The ERC-721 standard is used when representing ownership of an NFT when all tokens are unique from one another.
Creating SVG Files
The next step is to actually develop a really cool NFT for the domain service. I used SVG files which are creating images with code.
<svg xmlns="http://www.w3.org/2000/svg" width="270" height="270" fill="none">
<path fill="url(#a)" d="M0 0h270v270H0z"/>
<defs>
<filter id="b" color-interpolation-filters="sRGB" filterUnits="userSpaceOnUse" height="270" width="270">
<feDropShadow dx="0" dy="1" stdDeviation="2" flood-opacity=".225" width="200%" height="200%"/>
</filter>
</defs>
POLYGON-LOGO-ICON-GOES-HERE
<defs>
<linearGradient id="a" x1="0" y1="0" x2="270" y2="270" gradientUnits="userSpaceOnUse">
<stop stop-color="#FF4E50"/>
<stop offset="1" stop-color="#F9D423" stop-opacity=".99"/>
</linearGradient>
</defs>
<text x="50" y="191" font-size="27" fill="#fff" filter="url(#b)" font-family="sans-serif" font-weight="bold">sambhav.ath</text>
</svg>
SVG code is obviously really similar to HTML, which made it quite easy to customize it and make it into what I think looks pretty cool…
Here’s the NFT I made for my domain service:
This whole Dapp is a two part process, a frontend with my React code, and the backend with my Solidity and smart contract code.
In order to connect the two, I used what’s known as an ABI file.
ABI Files
Our web app needs to be able to interact with our smart contract. ABI files make it really easy to do so.
Every solidity application has ABI settings disguised as a .json file. All I had to do is copy the contents of this json into my react folder (two separate project folders were used for each portion of my app). These files are typically 500+ lines of code and it’s constantly updating.
I also needed to input my contract address where I deployed my smart contract, into my react code as well. Every single time I update the contract, I have to do the following steps:
- Deploy the contract again
- We need to update the contract address on our react code.
- We need to update the ABI file on our frontend.
It’s pretty tedious, but without these steps then our frontend will just not work.
Every time we run our deploy.js file to deploy our smart contract, it generates an entirely new contract address for us.
With everything complete, here’s an explanation of our frontend.
This is the main front page where you connect your MetaMask wallet to my app. I just chose a pretty cool rocket ship gif to cover the middle of the screen.
This part of my app is pretty straight forward, but once you connect your wallet, it gets even better:
This page is where you actually get to mint the domain. Under recently minted domains you can see a pencil icon next to one of them. This is a neat feature where you can edit the domain within the application itself, and save it as a new domain!
Obviously you cannot buy a domain that already exists, and this all you really need to do is type in a cool username and press the mint button. Within 5–10 seconds you’ll have an OpenSea link with the NFT in your wallet.
If you’d like to play around with this Dapp yourself or even buy your own .ath domain, check out https://athdomain.vercel.app/
The code can be found here!
There are endless opportunities in the web3 space, and I honestly never thought that usernames as NFTs would be one. I’m so excited to see what’s coming next and stay tuned for further updates and projects!