Forem: Rounak Banik

Tutorial: Digital Signatures & NFT Whitelists

Rounak Banik — Fri, 11 Feb 2022 11:17:12 +0000

A Note on Terminology

A previous version of this article used the term whitelist instead of allowlist. Although they refer to the same thing, we have decided to update this article to use the latter in the interest of being more inclusive.

Introduction

Creating NFT allowlists has been, by far, the most requested topic in our developer community. Therefore, in this article, we will cover the following topics:

Implementing allowlists on-chain and their cost implications
Implementing allowlists off-chain using digital signatures

By the end of this tutorial, you should have an extremely good idea as to how to go about implementing allowlists in a secure and cost-efficient way, and in the process preventing unpleasant scenarios like gas wars.

Disclaimer

This article assumes that you have an intermediate knowledge of Solidity, Hardhat, and OpenZeppelin Contracts. If some of these terms sound alien to you, we strongly suggest you start here instead.

We also wanted to point out that not every NFT project requires an allowlist. We recommend you think about implementing one only if you have an active and vibrant community, and your projected demand for your NFTs far exceeds supply. For 99.9% of the projects out there, this simply isn’t true. Therefore, trying to implement allowlists will not only result in wastage of resources that could be spent elsewhere but could also backfire by repelling the few backers that your project has should you not be able to fill all slots.

Implementing Allowlists On-Chain

On-chain allowlists are secure and fairly easy to implement. We will be using the NFT Collectible Contract from a previous tutorial as our base.

These are the following additions that we need to make to our contract.

A global mapping variable isAllowlistAddress that keeps track of all the addresses that have been allowlisted.
A function allowlistAddress that is callable only by the contract’s owner and that can add one or more addresses to isAllowlistAddress mapping.
A preSale function that is very similar to the mintNfts function except that it only allows allowlisted addresses to mint at a pre-sale price.

We can define the mapping variable as follows:

mapping(address => bool) public isAllowlistAddress;

Next, let’s write a allowlisting function that allows the contract’s owner to add a list of addresses to the aforementioned mapping.

// Allowlist addresses
function allowlistAddresses(address[] calldata wAddresses) public onlyOwner {
    for (uint i = 0; i < wAddresses.length; i++) {
        isAllowlistAddress[wAddresses[i]] = true;
    }
}

Finally, let’s write a preSale function that allows only allowlisted addresses to mint.

// Presale mints
function preSale(uint _count) public payable {
    uint totalMinted = _tokenIds.current();
    uint preSalePrice = 0.005 ether;
    uint preSaleMaxMint = 2;

    require(totalMinted.add(_count) <= MAX_SUPPLY, 
            "Not enough NFTs left!");
    require(_count >0 && _count <= preSaleMaxMint, 
            "Cannot mint specified number of NFTs.");
    require(msg.value >= preSalePrice.mul(_count), 
            "Not enough ether to purchase NFTs.");
    require(isAllowlistAddress[msg.sender], 
            "Address is not allowlisted");
    for (uint i = 0; i < _count; i++) {
        _mintSingleNFT();
    }

    isAllowlistAddress[msg.sender] = false;
}

Notice that this function is very similar to the mintNfts function that we already have in our contract. We use a different price and mint limit for presale. We also place an additional check to ensure only allowlisted addresses can mint. Finally, we remove the address from the allowlist to ensure that the wallet does not mint more than once.

Your final contract should look something like this:

//SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/utils/math/SafeMath.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Enumerable.sol";

contract NFTCollectible is ERC721Enumerable, Ownable {
    using SafeMath for uint256;
    using Counters for Counters.Counter;

    Counters.Counter private _tokenIds;

    mapping(address => bool) public isAllowlistAddress;

    uint public constant MAX_SUPPLY = 100;
    uint public constant PRICE = 0.01 ether;
    uint public constant MAX_PER_MINT = 5;

    string public baseTokenURI;

    constructor(string memory baseURI) ERC721("NFT Collectible", "NFTC") {
        setBaseURI(baseURI);
    }

    // Allowlist addresses
    function allowlistAddresses(address[] calldata wAddresses) public onlyOwner {
        for (uint i = 0; i < wAddresses.length; i++) {
            isAllowlistAddress[wAddresses[i]] = true;
        }
    }

    function reserveNFTs() public onlyOwner {
        uint totalMinted = _tokenIds.current();

        require(totalMinted.add(10) < MAX_SUPPLY, "Not enough NFTs left to reserve");

        for (uint i = 0; i < 10; i++) {
            _mintSingleNFT();
        }
    }

    function _baseURI() internal view virtual override returns (string memory) {
        return baseTokenURI;
    }

    function setBaseURI(string memory _baseTokenURI) public onlyOwner {
        baseTokenURI = _baseTokenURI;
    }

    // Presale mints
    function preSale(uint _count) public payable {
        uint totalMinted = _tokenIds.current();
        uint preSalePrice = 0.005 ether;
        uint preSaleMaxMint = 2;

        require(totalMinted.add(_count) <= MAX_SUPPLY, "Not enough NFTs left!");
        require(_count >0 && _count <= preSaleMaxMint, "Cannot mint specified number of NFTs.");
        require(msg.value >= preSalePrice.mul(_count), "Not enough ether to purchase NFTs.");
        require(isAllowlistAddress[msg.sender], "Address is not allowlisted");

        for (uint i = 0; i < _count; i++) {
            _mintSingleNFT();
        }

        isAllowlistAddress[msg.sender] = false;        
    }

    function mintNFTs(uint _count) public payable {
        uint totalMinted = _tokenIds.current();

        require(totalMinted.add(_count) <= MAX_SUPPLY, "Not enough NFTs left!");
        require(_count >0 && _count <= MAX_PER_MINT, "Cannot mint specified number of NFTs.");
        require(msg.value >= PRICE.mul(_count), "Not enough ether to purchase NFTs.");

        for (uint i = 0; i < _count; i++) {
            _mintSingleNFT();
        }
    }

    function _mintSingleNFT() private {
        uint newTokenID = _tokenIds.current();
        _safeMint(msg.sender, newTokenID);
        _tokenIds.increment();
    }

    function tokensOfOwner(address _owner) external view returns (uint[] memory) {

        uint tokenCount = balanceOf(_owner);
        uint[] memory tokensId = new uint256[](tokenCount);

        for (uint i = 0; i < tokenCount; i++) {
            tokensId[i] = tokenOfOwnerByIndex(_owner, i);
        }
        return tokensId;
    }

    function withdraw() public payable onlyOwner {
        uint balance = address(this).balance;
        require(balance > 0, "No ether left to withdraw");

        (bool success, ) = (msg.sender).call{value: balance}("");
        require(success, "Transfer failed.");
    }

}

The problem with on-chain allowlists

The implementation we’ve used so far is secure and does exactly what it needs to do.

However, this implementation is wildly inefficient. The root cause of this is the allowlistAddresses function that can only be called by the contract’s owner. By its very design, this contract expects the owner to populate the mapping with all possible allowlisted addresses.

Depending on the size of your allowlist, this process could prove to be computationally intensive and extremely expensive. You may be able to get away with this if you’re operating on a sidechain like Polygon or Binance Smart chain but on Ethereum, even modest-sized allowlists will set you back by several thousands of dollars.

Fortunately, it is possible to implement allowlists securely off-chain without having to deal with extortionate gas fees. We can achieve this using digital signatures.

Digital Signatures

Digital Signatures and public key cryptography are central to virtually everything that happens on a blockchains like Bitcoin and Ethereum. We won’t be covering how signatures work in this article (we have a series on cryptography coming very soon!). Instead, we will just acquire a black-box understanding of how it works.

As most of you already know, we interact with Ethereum using a wallet which is associated with two keys: a public key (or wallet address) and a private key.

Using cryptography, it is possible for a person to prove that s/he holds the private key of a particular wallet address without revealing the key itself. It should be obvious why this is very important. If we couldn’t initiate transactions using our private key without revealing said key, the system would break down completely as there would be no way to authenticate yourself securely and trustlessly.

Digital cryptographic signatures allow us to accomplish the following:

The signer is able to sign a message using a private key and broadcast the signed message.
It is impossible to recover the private key by simply looking at the message and/or the public key.
It is however possible to verify that the signer holds the correct private key using the public key (or wallet address).

If this sounds a little magical, it’s because it is. The feats possible by public key cryptography are nothing short of miraculous. However, as stated earlier, we will cover this in detail in a future series.

With this basic understanding of how digital signatures work, we can now propose the following system of implementing allowlists.

Create a centralized server and database that holds all the addresses that are allowlisted.
When a wallet tries to initiate a mint on your website, send the wallet address to your server.
The server checks if the address has been allowlisted and if it has, it signs the wallet address with a private key that is known only to the project’s creator.
The server returns the signed message to the frontend client (or website) and this in turn, is sent to the smart contract.
The contract’s mint function verifies that the message sent was indeed signed by the wallet controlled by the owner. If the verification succeeds, minting is allowed.
The signed message is stored in a mapping to prevent it from being used more than once or by multiple wallets.

(We will not be implementing a real server or using a real database in this article. If this is something that you’ve never done before, taking a look at Express and Mongo tutorials would be a good place to start.)

Signing Messages

In your Hardhat project, create a new file called allowlist.js in the scripts folder.

We will be using the ethers library to sign our messages. Let’s allowlist Hardhat’s default accounts 1 to 5 for this example.

const ethers = require('ethers');
const main = async () => {
    const allowlistedAddresses = [
        '0x70997970c51812dc3a010c7d01b50e0d17dc79c8',
        '0x3c44cdddb6a900fa2b585dd299e03d12fa4293bc',
        '0x90f79bf6eb2c4f870365e785982e1f101e93b906',
        '0x15d34aaf54267db7d7c367839aaf71a00a2c6a65',
        '0x9965507d1a55bcc2695c58ba16fb37d819b0a4dc',
    ];
}

const runMain = async () => {
    try {
        await main(); 
        process.exit(0);
    }
    catch (error) {
        console.log(error);
        process.exit(1);
    }
};

runMain();

These are the only addresses that will be allowed to mint in the presale. Let’s use Account 0 as the owner’s wallet.

const owner = '0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266';

const privateKey = '0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80';

const signer = new ethers.Wallet(privateKey);
console.log(signer.address)

Run this script by running node scripts/allowlist.js in the terminal. If all goes well, the wallet address printed to the console should be the same as that assigned to owner.

Let’s now sign a simple message and see how that works.

let message = 'Hello World!'

let signature = await signer.signMessage(message)
console.log(signature);

Running this script will output a signed message 0xdd4...61c.

In our case, we will not be signing a message written in English. Instead, we will be signing the hash of a allowlisted wallet address (which is nothing but a hash itself). Ethers documentation recommends that we convert binary hash data into an array before signing it.

Let’s sign the hash of the first allowlisted address from above. Replace the code snippet above with the following.

// Get first allowlisted address
let message = allowlistedAddresses[0];

// Compute hash of the address
let messageHash = ethers.utils.id(message);
console.log("Message Hash: ", messageHash);

// Sign the hashed address
let messageBytes = ethers.utils.arrayify(messageHash);
let signature = await signer.signMessage(messageBytes);
console.log("Signature: ", signature);

Running this snippet will output 0xee...c1b as signature.

Therefore, when a wallet issues a request to the server, you server will need to do two things:

Check if the wallet is a part of allowlistedAddresses
If yes, sign the hashed wallet address with the supplied private key and return the signature and the hashed wallet address.

Verifying Signatures

Verifying signatures is extremely simple using OpenZeppelin’s ECDSA library.

Let’s start with our base NFTCollectible.sol contract again. As a first step, we will write a recoverSigner function that will take the hashed allowlisted wallet address and the signature as arguments and output the address of the signer.

function recoverSigner(bytes32 hash, bytes memory signature) public pure returns (address) {
    bytes32 messageDigest = keccak256(
        abi.encodePacked(
            "\x19Ethereum Signed Message:\n32", 
            hash
        )
    );
    return ECDSA.recover(messageDigest, signature);
}

Let’s open up a new Terminal and spin up a local instance of Ethereum using the following command:

npx hardhat node

Next, let’s write code in allowlist.js that compiles and deploys the contract to our local blockchain and calls the recoverSigner function.

const nftContractFactory = await hre.ethers.getContractFactory('NFTCollectible');
const nftContract = await nftContractFactory.deploy(
    "ipfs://your-cide-code"
);

await nftContract.deployed();

console.log("Contract deployed by: ", signer.address);
recover = await nftContract.recoverSigner(messageHash, signature);
console.log("Message was signed by: ", recover.toString());

Let’s run this script using:

npx hardhat run scripts/allowlist.js --network localhost

If all goes well, you should see your console telling you that the message was signed by the same wallet that deployed the contract.

Amazing work! We now have all the pieces we need to implement our preSale function and by extension, allowlisting.

Let’s define a mapping that will track if a particular signature has already been used to mint.

mapping(bytes => bool) public signatureUsed;

Finally, let’s write our preSale function.

function preSale(uint _count, bytes32 hash, bytes memory signature) public payable {
    uint totalMinted = _tokenIds.current();
    uint preSalePrice = 0.005 ether;
    uint preSaleMaxMint = 2;

    require(totalMinted.add(_count) <= MAX_SUPPLY, 
            "Not enough NFTs left!");
    require(_count >0 && _count <= preSaleMaxMint, 
            "Cannot mint specified number of NFTs.");
    require(msg.value >= preSalePrice.mul(_count), 
           "Not enough ether to purchase NFTs.");
    require(recoverSigner(hash, signature) == owner(), 
            "Address is not allowlisted");
    require(!signatureUsed[signature], 
            "Signature has already been used.");

    for (uint i = 0; i < _count; i++) {
        _mintSingleNFT();
    }
    signatureUsed[signature] = true;
}

Congratulations! You have successfully implemented an allowlisting mechanism that works off-chain but is just as secure as its on-chain counterpart.

Here is the final contract.

//SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/utils/math/SafeMath.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Enumerable.sol";

contract NFTCollectible is ERC721Enumerable, Ownable {
    using SafeMath for uint256;
    using Counters for Counters.Counter;

    Counters.Counter private _tokenIds;

    mapping(bytes => bool) public signatureUsed;

    uint public constant MAX_SUPPLY = 100;
    uint public constant PRICE = 0.01 ether;
    uint public constant MAX_PER_MINT = 5;

    string public baseTokenURI;

    constructor(string memory baseURI) ERC721("NFT Collectible", "NFTC") {
        setBaseURI(baseURI);
    }

    function reserveNFTs() public onlyOwner {
        uint totalMinted = _tokenIds.current();

        require(totalMinted.add(10) < MAX_SUPPLY, "Not enough NFTs left to reserve");

        for (uint i = 0; i < 10; i++) {
            _mintSingleNFT();
        }
    }

    function _baseURI() internal view virtual override returns (string memory) {
        return baseTokenURI;
    }

    function setBaseURI(string memory _baseTokenURI) public onlyOwner {
        baseTokenURI = _baseTokenURI;
    }

    function recoverSigner(bytes32 hash, bytes memory signature) public pure returns (address) {
        bytes32 messageDigest = keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", hash));
        return ECDSA.recover(messageDigest, signature);
    }

    function mintNFTs(uint _count) public payable {
        uint totalMinted = _tokenIds.current();

        require(totalMinted.add(_count) <= MAX_SUPPLY, "Not enough NFTs left!");
        require(_count >0 && _count <= MAX_PER_MINT, "Cannot mint specified number of NFTs.");
        require(msg.value >= PRICE.mul(_count), "Not enough ether to purchase NFTs.");

        for (uint i = 0; i < _count; i++) {
            _mintSingleNFT();
        }
    }

    function preSale(uint _count, bytes32 hash, bytes memory signature) public payable {
        uint totalMinted = _tokenIds.current();
        uint preSalePrice = 0.005 ether;
        uint preSaleMaxMint = 2;

        require(totalMinted.add(_count) <= MAX_SUPPLY, "Not enough NFTs left!");
        require(_count >0 && _count <= preSaleMaxMint, "Cannot mint specified number of NFTs.");
        require(msg.value >= preSalePrice.mul(_count), "Not enough ether to purchase NFTs.");
        require(recoverSigner(hash, signature) == owner(), "Address is not allowlisted");
        require(!signatureUsed[signature], "Signature has already been used.");

        for (uint i = 0; i < _count; i++) {
            _mintSingleNFT();
        }

        signatureUsed[signature] = true;
    }

    function _mintSingleNFT() private {
        uint newTokenID = _tokenIds.current();
        _safeMint(msg.sender, newTokenID);
        _tokenIds.increment();
    }

    function tokensOfOwner(address _owner) external view returns (uint[] memory) {

        uint tokenCount = balanceOf(_owner);
        uint[] memory tokensId = new uint256[](tokenCount);

        for (uint i = 0; i < tokenCount; i++) {
            tokensId[i] = tokenOfOwnerByIndex(_owner, i);
        }
        return tokensId;
    }

    function withdraw() public payable onlyOwner {
        uint balance = address(this).balance;
        require(balance > 0, "No ether left to withdraw");

        (bool success, ) = (msg.sender).call{value: balance}("");
        require(success, "Transfer failed.");
    }

}

To summarize once again, this is how pre-sale minting would work:

A buyer visits your website, connects wallet, specifies the number of NFTs s/he wants to mint, and clicks on the Mint NFT button.
This initiates a request to your centralized server which checks if the address has been allowlisted. If yes, it sends back the hashed wallet address and the signature. If no, it returns an error.
Your website takes the aforementioned values and initiates a transaction to your smart contract on behalf of the user.
In the smart contract, the preSale function verifies that the signature was indeed signed by you and allows minting to take place.

Conclusion

This is by far the most technical article we’ve published so far. If you’ve understood major portions of what’s going on, then congratulations! You are well on your way to becoming an expert Solidity developer.

If you find yourself struggling, don’t worry about it. It may be a little hard to digest this in one go. We would suggest you complement this article with alternate resources and tutorials on the topic.

We should also mention that digital signatures aren’t the only way to achieve off-chain allowlists. It is possible to use Merkle trees to arrive at the same result. We will be releasing an article on that sometime in the future.

If you have any questions or are stuck, reach out to us on our Discord.

If you don’t have questions, come say hi to us on our Discord anyway! Also, if you liked our content, we would be super grateful if you tweet about us, follow us(@ScrappyNFTs and @Rounak_Banik), and invite your circle to our Discord. Thank you for your support!

About Scrappy Squirrels

Scrappy Squirrels is a collection of 10,000+ randomly generated NFTs. Scrappy Squirrels are meant for buyers, creators, and developers who are completely new to the NFT ecosystem.

The community is built around learning about the NFT revolution, exploring its current use cases, discovering new applications, and finding members to collaborate on exciting projects with.

Join our community here: https://discord.gg/8UqJXTX7Kd

Deploying a Dapp to Mainnet

Rounak Banik — Fri, 14 Jan 2022 16:16:48 +0000

Introduction

2021 saw a major boom in web3 education and developer content. There a plethora of excellent tutorials available online that teach you everything you need to get started in web3, from building simple Hello World contracts to creating full-fledged decentralized exchanges and NFT marketplaces.

However, almost every tutorial (including the ones published by us) show you how to launch apps on testnets with fake money. There is extremely little coverage on how to launch on a mainnet, and the considerations and challenges involved with the process.

This article, therefore, is on one of the most-requested topics on our Discord: how to develop and deploy a smart contract in the real world with real money.

Disclaimer

We make the assumption that you are already familiar with developing smart contracts on EVM-compatible chains using tools like Solidity, Ethers, and Hardhat. If some of these terms sound alien to you, we strongly suggest going through this article first.

Step 1: Developing Contract on Testnet

The first step remains the same as with every other tutorial. You develop and test your contract on a testnet of the blockchain (or sidechain) that you wish to launch on. For example, you would use Rinkeby or Ropsten if your network of choice was Ethereum and Mumbai if you preferred Polygon.

Most testnets do a very good job of mimicking their corresponding mainnet and also provide free fake tokens to work with through faucets.

You can reasonably expect your contract’s behaviour on a testnet to be almost identical to that on the mainnet.

Step 2: Auditing and Optimizing Contract

Deploying a contract on a testnet costs the same amount of gas as deploying to a mainnet (note that I’m referring to gas units and not gas price).

Checking how much gas contract deployment consumes should give you a good early indication of how expensive deployment is going to be. In some cases, it may be possible to significantly reduce gas consumption (for example, using an ERC-1155 implementation in place of ERC-721 for an NFT dapp).

Do take the time out to evaluate your choices and ensure that reduction of gas consumption does not come at the expense of security.

Once you’re satisfied with the final version of the contract, you should get it audited.

There are excellent services like solidity.finance that will audit your contract for a fee. Do note that the fee may be steep for a lot of projects. But if your dapp is going to be handling assets of other people worth millions of dollars, then I believe that an audit is mandatory and definitely worth the price.

On the other hand, if your project is of a significantly smaller scale (for example, a generative NFT project), then a professional audit may be overkill. In such cases, just ensure that the contract has been tested and walked through by at least two smart contract developers.

Step 3: Estimating Cost of Deployment

Once you’re satisfied with the way your dapp behaves and are convinced that there are no glaring security loopholes, you can proceed to computing the total cost of deployment.

As mentioned earlier, the amount of gas consumed across testnets and the mainnet is the same. To arrive at an estimate of deployment cost on a mainnet, all you need to do is multiply gas consumed with the gas price.

Typically, deployments on Ethereum cost thousands of dollars whereas deployment to sidechains like Polygon and Binance can be done in under five dollars.

We have a detailed tutorial on how to estimate costs and consider your chain options here.

Step 4: Acquiring tokens

This step may seem way too obvious to warrant an entire section but we have seen a few of our community members trip up in this step, especially when working with sidechains.

Remember that you need to acquire a particular token in the chain that you’re working with. This means you need ETH on the Ethereum Mainnet, MATIC on the Polygon network, and BNB on the Binance Smart Chain.

The easiest way to acquire these tokens on their respective chains is by using a ramp service like Moonpay that allows you to purchase crypto using just a credit card.

However, these services don’t work in all countries (India, for example). In such cases, you will unfortunately have to deal with steps like buying on centralized exchanges, KYCs, and withdrawal to Metamask.

During withdrawal, make sure that your tokens are being transferred to the correct network. By default, most exchanges will send your MATIC and BNB to the Ethereum network. They are useless there and bridging them to the correct network is complicated and expensive. Make sure you only use exchanges that have a direct ramp to the network you want to use.

We will be releasing an article on the options you have while purchasing MATIC, BNB, FTM, and other sidechain cryptocurrencies soon.

Step 5: Configuring Hardhat and Alchemy

It is now time for deployment!

In order to deploy to a particular chain, we will need an RPC URL. We’ve already discussed how to acquire this using Alchemy for the Rinkeby and Polygon Mumbai testnets.

For the corresponding mainnets, the process is identical: create an Alchemy app, set the network to the chain of your choice, and copy the HTTP RPC URL. Below is an app created for the Ethereum mainnet.

Do note that Alchemy, at the time of writing, does not provide RPC URLs for every chain that you could potentially want to work with.

For chains not supported by Alchemy (for example, Fantom Opera), you can use the public RPC URLs available. For instance, https://rpc.ftm.tools/ for Fantom.

We now have everything to configure hardhat.config.js. Add the mainnet network of your choice to module.exports.

module.exports = {  
    solidity: "0.8.4",  
    networks: {    
        rinkeby: {      
            url: RINKEBY_RPC_URL,      
            accounts: [`0x${PRIVATE_KEY}`],   
        },
        mainnet: {      
            url: ETHEREUM_RPC_URL,      
            accounts: [`0x${PRIVATE_KEY}`],   
        },
        polygon: {      
            url: POLYGON_RPC_URL,      
            accounts: [`0x${PRIVATE_KEY}`],   
        },          
    }
};

As is good practice, we have defined our RPC URLs and our wallet’s private key in a .env file that will not be committed to our git repository.

Now, running

npx hardhat run scripts/deploy.js --network mainnet

Will deploy your contract to the Ethereum mainnet. Similarly, running

npx hardhat run scripts/deploy.js --network polygon

Will deploy your contract to the Polygon mainnet.

Setting Gas Price

Do note that if you deploy your contract using our deploy.js script from the previous tutorials, ethers will automatically set a gas price and deploy using that price.

In testnets and sidechains like Polygon and Binance, this may not really be an issue. However, lower gas fees could result in savings worth thousands of dollars on Ethereum. Which is why it is prudent to set a gas price yourself.

This is very easy to with ethers. In deploy.js, add an argument to the deploy() method to set a gas price as follows:

const factory = await hre.ethers.getContractFactory('MyContract');    
const contract = await factory.deploy(arg1, 
                                      arg2, 
                                      {gasPrice:50000000000});    
await contract.deployed();

As you can probably deduce, we have deployed this contract by setting a gas fee of 50 Gwei.

(Optional) Deploying using Metamask & Remix

When you deploy using hardhat, it automatically drains your wallet of the funds that it needs to perform the request. In other words, there is no confirmation step in between. You issue a command to run the deployment script and boom! your funds are gone and your contract is deployed.

If this is somewhat anxiety-inducing to you, you can consider using Remix as a viable alternative. Remix is world class IDE for developing and deploying contracts on Ethereum and EVM-based chains.

Remix allows you to deploy your contracts using Metamask. By doing so, it places an important confirmation step in between where you can evaluate and approve the total amount you’re spending, and modify gas fees using Metamask’s interface.

You also have the option of getting popup notifications from Metamask as and when your transaction is complete.

We will be doing a tutorial on Remix very soon. There are plenty of great tutorials online that use Remix by default though so you shouldn’t find it too hard to learn.

Conclusion

We hope this article has given you a good idea on the things you need to consider before you take the big step of launching your dapp to a mainnet and have real people use real money on it.

If you have any questions, please feel free to drop them on the #suggestions-and-qna channel of our Discord.

About Scrappy Squirrels

Scrappy Squirrels is a collection of 10,000+ randomly generated NFTs. Scrappy Squirrels are meant for buyers, creators, and developers who are completely new to the NFT ecosystem.

The community is built around learning about the NFT revolution, exploring its current use cases, discovering new applications, and finding members to collaborate on exciting projects with.

Join our community here: https://discord.gg/8UqJXTX7Kd

Building an Ethereum Gas Tracker

Rounak Banik — Tue, 14 Dec 2021 15:07:00 +0000

Introduction

The London Hard Fork in August 2021 brought about one of the biggest upgrades that the Ethereum network has ever witnessed. The fork implemented EIP-1559; a gas pricing mechanism that is touted to be superior to the blind auction model. It also introduced fundamental changes in the monetary policy of Ether (ETH), making it a deflationary currency at least in the short term.

In this tutorial, we will build a gas tracker that tracks the two new components of gas fees in EIP-1559 as well as other statistics (such as block volume) for the latest 20 blocks. By doing so, we will achieve two important goals:

A deeper understanding of how EIP-1559 works under the hood and what improvements it brings to the table.
A fully functional gas tracker app that retrieves the latest block volumes and gas fees, broken down by base and priority fee.

In order to do this, we will use Alchemy, the Alchemy web3.js library, Node, and React. Don't worry if some of these words sound alien to you, we will cover them in detail!

This tutorial does assume that you have a basic understanding of how gas and gas prices work on Ethereum though. A preliminary understanding of EIP-1559 is also helpful but not required. In case you need a primer, I strongly suggest going through this excellent article on Alchemy's blog.

A Quick Recap of EIP-1559

EIP-1559 brought about the following changes in the gas pricing mechanism of Ethereum.

The blind auction gas fee has now been replaced by two component fees: a base free and a priority fee (or miner's tip).
The base fee is determined automatically by the network. It can increases up to 12.5% if the previous block was full and decrease by up to 12.5% if the previous block was empty.
The miner's tip is determined by the user and can be tuned based on the urgency of the transaction.
The base fee is burned by the network to prevent miners from artificially flooding blocks. Miners, however, get to pocket the tip.

Apart from improving gas pricing, EIP-1559 also proposed an improvement to better equip the network in handling sudden spikes in traffic. As you may know, transactions in Ethereum are grouped into blocks. Prior to the fork, a block could hold only 15 million gas worth of transactions regardless of the volume of traffic.

With the upgrade, the upper limit of block size has been doubled to 30 million gas. This has been done so that periods of increased demand can be handled better. The expectation, however, is that the base fee will adjust in such a way that block volumes (or gas used by a block) averages at around 50% or 15 million gas.

You will be able to see how all of this works in real time with the gas tracker that we build. We will be building this project in two parts: in the first part, we will write a node script that will track transaction fee history in real time. In the second part, we will create a React app leveraging this script to build our final tracker.

Part 1: The Transaction Fee History script

In this section, we will write a script (in node) that will allow us to get the gas fee history of the latest 20 blocks on the Ethereum network.

Step 0: Install node and npm

Make sure you have node and npm installed on your local computer (at least v14 or higher). You can download it here

Step 1: Create an Alchemy account

In order to get the latest gas fee history of blocks, we will have to connect to and communicate with the Ethereum network. Alchemy is a blockchain developer platform that allows us to do this without having to spin up our own nodes.

You can create an Alchemy account for free here.

Step 2: Create an Alchemy App (and API key)

Create an app on the Alchemy dashboard. Set the chain to Ethereum and the network to Mainnet.

Next, visit your app's page and click on View Key. This will open a popup with the HTTP and Websocket URLs of your app. For this tutorial, we will be using the websocket URL.

Step 3: Create node project and install dependencies

We are now in a good position to start writing our node script. Let's create an empty repository and install dependencies. For this script, we will be requiring the Alchemy web3.js library.

On your Terminal (or Command Prompt), run the following commands:

> mkdir gas-tracker-script && cd gas-tracker-script
> npm init -y
> npm install --save @alch/alchemy-web3
> touch main.js

This should create a repository named gas-tracker-script that holds all the files and dependencies we need. Open this repo in you favorite code editor. We will be writing all our code in the main.js file.

Step 4: Create a web3 client instance using Alchemy

Creating a client instance with Alchemy web3 is incredibly simple.

In the main.js file, add the following lines of code:

const { createAlchemyWeb3 } = require("@alch/alchemy-web3");

// Using WebSockets
const web3 = createAlchemyWeb3(
    "wss://eth-mainnet.alchemyapi.io/v2/<--API KEY-->",
);

Make sure to replace the placeholder above with the websocket URL of your app.

Step 5: Get fee history of the last 20 blocks

We want to get the gas fees history of the last 10 blocks. Data we're interested in includes the base fee, range of priority fees, block volume, and block number.

Fortunately for us, Alchemy has a very convenient eth_feeHistory that returns all the aforementioned data automatically.

All we need to specify is the newest block we want data for, the total number of blocks to look at, and the percentile ranges for priority fees.

We are interested in the latest 20 blocks and the 25th, 50th, and 75th percentile of priority fees.

web3.eth.getFeeHistory(20, "latest", [25, 50, 75]).then(console.log)

Running this script (using node main.js) should fetch you the data you're looking for. Here is some data I received after requesting for 5 blocks worth of data.

Step 6: Format output

The output we received in step 5 is correct but is not very readable. The fees are expressed in hexadecimals and the data structure makes it difficult to figure out which data corresponds to which block.

Let's write a small function that transforms the raw data into a list of dictionaries where each dictionary will contain data on a particular block. The function also converts all hexadecimal gas values denominated in wei to decimals denominated in Gwei.

const formatOutput = (data, numBlocks) => {

    let blocks = []
    for (let i = 0; i < numBlocks; i++) {
        blocks.push({
            blockNumber: Number(data.oldestBlock) + i,
            reward: data.reward[i].map(r => Math.round(Number(r) / 10 ** 9)),
            baseFeePerGas: Math.round(Number(data.baseFeePerGas[i]) / 10 ** 9),
            gasUsedRatio: data.gasUsedRatio[i],
        })
    }
    return blocks;
}

Finally, let's use this function is callback of feeHistory.

const numBlocks = 5;

web3.eth.getFeeHistory(numBlocks, "latest", [25, 50, 75]).then((data) => {
    const blocks = formatOutput(data, numBlocks);
    console.log(blocks);
});

Running this version of the script should yield output in the following format:

Step 7: Subscribe to latest block headers

A new block gets added to the Ethereum blockchain approximately every 15 seconds. Therefore, we would ideally want to subscribe to the event of blocks being added and update our transaction history such that it always shows data for the latest 20 blocks.

Let's nest the getFeeHistory functionality within a subscription event callback.

let subscription = web3.eth.subscribe('newBlockHeaders');

subscription.on("data", () => {
    web3.eth.getFeeHistory(numBlocks, "latest", [25, 50, 75]).then((data) => {
        const blocks = formatOutput(data, numBlocks);
        console.log(blocks);
    });
});

Running the main.js script now will output the freshest batch of data every 15 seconds or so. If you've come this far, congratulations! You now have a fully functional gas tracker.

Part 2: The Gas Tracker React App

In the previous section, we wrote a script that retrieved the fee history of the last 20 blocks every time a new block was added to the Ethereum mainnet.

In this section, we will build a small React app that transports this data from our terminal to the browser. In addition to fee transaction history, we will also display the average gas fees and block volumes over the last 20 blocks.

Step 1: Initialize React project and install dependencies

Run the following commands:

> npx create-react-app gas-tracker-frontend
> cd gas-tracker-frontend

This should create a sample React project. Apart from the react dependencies, we will also need to install the Alchemy web3 library from the previous section.

> npm install --save @alch/alchemy-web3

Step 2: Populate the App.js file

All our logic will reside in the App.js file. Copy the following contents into the aforementioned file.

import './App.css';
import { useEffect, useState } from 'react';
import { createAlchemyWeb3 } from '@alch/alchemy-web3';

const NUM_BLOCKS = 20;

function App() {

  const [blockHistory, setBlockHistory] = useState(null);
  const [avgGas, setAvgGas] = useState(null);
  const [avgBlockVolume, setAvgBlockVolume] = useState(null);

  const formatOutput = (data) => {

    let avgGasFee = 0;
    let avgFill = 0;
    let blocks = [];

    for (let i = 0; i < NUM_BLOCKS; i++) {

      avgGasFee = avgGasFee + Number(data.reward[i][1]) + Number(data.baseFeePerGas[i])
      avgFill = avgFill + Math.round(data.gasUsedRatio[i] * 100);

      blocks.push({
        blockNumber: Number(data.oldestBlock) + i,
        reward: data.reward[i].map(r => Math.round(Number(r) / 10 ** 9)),
        baseFeePerGas: Math.round(Number(data.baseFeePerGas[i]) / 10 ** 9),
        gasUsedRatio: Math.round(data.gasUsedRatio[i] * 100),
      })
    }

    avgGasFee = avgGasFee / NUM_BLOCKS;
    avgGasFee = Math.round(avgGasFee / 10 ** 9)

    avgFill = avgFill / NUM_BLOCKS;
    return [blocks, avgGasFee, avgFill];
  }

  useEffect(() => {

    const web3 = createAlchemyWeb3(
      "wss://eth-mainnet.alchemyapi.io/v2/<--API KEY-->",
    );

    let subscription = web3.eth.subscribe('newBlockHeaders');

    subscription.on('data', () => {
      web3.eth.getFeeHistory(NUM_BLOCKS, "latest", [25, 50, 75]).then((feeHistory) => {
        const [blocks, avgGasFee, avgFill] = formatOutput(feeHistory, NUM_BLOCKS);
        setBlockHistory(blocks);
        setAvgGas(avgGasFee);
        setAvgBlockVolume(avgFill);
      });
    });

    return () => {
      web3.eth.clearSubscriptions();
    }
  }, [])


  return (
    <div className='main-container'>
      <h1>EIP-1559 Gas Tracker</h1>
      {!blockHistory && <p>Data is loading...</p>}
      {avgGas && avgBlockVolume && <h3>
        <span className='gas'>{avgGas} Gwei</span> | <span className='vol'>{avgBlockVolume}% Volume</span>
      </h3>}
      {blockHistory && <table>
        <thead>
          <tr>
            <th>Block Number</th>
            <th>Base Fee</th>
            <th>Reward (25%)</th>
            <th>Reward (50%)</th>
            <th>Reward (75%)</th>
            <th>Gas Used</th>
          </tr>
        </thead>
        <tbody>
          {blockHistory.map(block => {
            return (
              <tr key={block.blockNumber}>
                <td>{block.blockNumber}</td>
                <td>{block.baseFeePerGas}</td>
                <td>{block.reward[0]}</td>
                <td>{block.reward[1]}</td>
                <td>{block.reward[2]}</td>
                <td>{block.gasUsedRatio}%</td>
              </tr>
            )
          })}
        </tbody>
      </table>}
    </div>
  );
}

export default App;

Since this isn't a React course, we are not doing to dive deep into the React-specific bits. But you should be able to observe that all that we're doing is retrieving fee history like we did in our script and outputting it in the form of an HTML table.

The only additional logic we employ is computing average gas price and average block volumes over 20 blocks which is a trivial task to perform.

(Optional) Step 3: Add some styles

You can add some basic styles in the App.css file as follows:

.main-container {
    text-align: center;
}

table {
    border-collapse: collapse;
    margin: 20px auto;
    box-shadow: 0 8px 16px 0 rgba(0,0,0,0.2);
}

thead {
    background: linear-gradient(267.45deg,#05d5ff -34.23%,#53f 99.39%);
    color: white;
    padding: 10px;
}

th {
    font-size: 18px;
    padding: 15px;

}

tbody > tr {
    border-top: 1px solid #ccc; 
    border-bottom: 1px solid #ccc;
    margin: 0px;
    padding: 15px;
}

td {
    padding: 6px;
}

.gas {
    color: #4299E1;
}

.vol {
    color: #4C51BF;
}

Step 4: Deploy app to localhost

We're all done. Watch your app in all its glory by running:

npm start

This is what the app should look like:

Congratulations! You've built a fully functional gas tracker app.

Analysis

Let's take a step back and analyze the data above. Here are a few things we can observe which are a direct result of the EIP-1559 implementation.

The base fee does not fluctuate wildly from block to block. In fact, the maximum it increases or decreases is by 12.5%.
The priority fee, in most cases, is a small percentage of the total fee.
Block volumes tend to fluctuate but the average block volumes hover around 50%.

The data does seem to suggest that gas fees in this model is much more predictable. Since everyone pays the same base fee and the priority fee, in most cases, is a small percentage of total fee, most transactions don't end up overpaying for gas. Therefore, this small sample of data suggests that EIP-1559 has succeeded in what it set out to achieve: more predictable gas prices, and less overpayment in gas.

Conclusion

We've covered a lot of ground in this article. By building an EIP-1559 gas tracker from scratch, I hope you were able to grasp and appreciate the improvement it brings to transacting on Ethereum.

I also hope that you've gotten a decent grasp on how to use Alchemy, its APIs, and the web3.js library. We've barely scratched the surface with respect to its capabilities and offerings. I strongly suggest you dig more into their documentation if and when you set out to build your next great dapp.

Until next time!

Building a web3 frontend with React

Rounak Banik — Sun, 28 Nov 2021 10:46:46 +0000

Introduction

In a previous tutorial, we covered how to create and deploy an NFT collectible smart contract from scratch. We also explored how to verify our contract on etherscan and enable yourself as well as your users to call functions directly from the contract’s etherscan page.

However, most serious projects tend to deploy their own websites and allow users to mint directly from the website.

This is exactly what we will be covering in this tutorial. More specifically, this tutorial will show you how to:

Let users connect their Metamask wallet to your website
Allow users to call a contract function, make a payment, and mint an NFT from your collection.

By the end of this tutorial, you’ll have a fully functioning web3 frontend built with React. You will have also gained the foundational knowledge required to build any general-purpose web3 frontend (beyond an NFT minter).

Prerequisites

This tutorial assumes you have already developed and deployed your smart contract to the Rinkeby test network. If you haven’t, we strongly suggest you go through this tutorial. In order to follow along with this tutorial, you will need the following:

The ABI file for your smart contract (which is available in the artifacts folder of your smart contract project).
The address of your smart contract.

We also assume that you have experience working with React and Javascript. If not, we strongly suggest you go through the official tutorial on React’s website first.

Setting up the project

Let’s start off by creating a React project using create-react-app. Open your terminal and run the following command:



npx create-react-app nft-collectible-frontend

The installation process will take anywhere between 2–10 minutes. Once its done, check that everything is working by running the following:



cd nft-collectible-frontend
npm start

If all goes well, you should see your browser open a new tab at localhost://3000 with the following screen. Pretty standard React stuff.

Let’s do a little cleanup now.

Go to public/index.html and change the title and meta description of your website. This step is optional.

Next, go to the src folder and delete the App.test.js, logo.svg, and setupTests.js files. We will not be needing these files for this tutorial.

Go to the App.js file and replace its contents with the following boilerplate.



import './App.css';

function App() {
    return (
        <h1>Hello World</h1>
    );
}

export default App;

Remove all the contents of App.css as well. Do not, however, delete this file. In a later section, we will provide you with some basic styling that should be good enough for this demo project.

If you go back to localhost, you should see a screen that says Hello World. We now have a basic react project set up and good to go.

Getting contract ABI and address

For our React frontend to be able to connect and communicate with our smart contract, it needs the contract’s ABI and address.

ABI (or Application Binary Interface) is a JSON file that is automatically generated during contract compilation. The blockchain we deploy to stores our smart contract in the form of bytecode. In order to invoke functions on it, pass the correct parameters, and parse return values using a high-level language, we need to specify details about the functions and the contract (such as name, arguments, types, etc.) to our frontend. This is exactly what the ABI file does. In order to learn more about the ABI, we suggest you go through this excellent post.

To find your ABI file, go to your hardhat project and navigate to artifacts/contracts/NFTCollectible.sol/NFTCollectible.json.

We need to now copy the JSON file to our React project. Create a new folder called contracts in the src folder and paste the NFTCollectible.json file.

You should already have the address of your deployed smart contract. (If you don’t just deploy it to Rinkeby again, and get the latest address and ABI file).

Our contract address from the previous tutorial is 0x355638a4eCcb777794257f22f50c289d4189F245. We will be using this contract in this tutorial too.

Let us now import the contract ABI and define the contract address in the App.js file.

Setting up boilerplate HTML, CSS, and JS

Our website is going to be incredibly simple. All it will have is a heading and a Connect Wallet button. Once the wallet is connected, the Connect Wallet button will be replaced by a Mint NFT button.

We’re not going to bother with creating separate component files. Instead, we will write all our HTML and logic in App.js and all our CSS in App.css

Copy the contents of the following Github gist into your App.js file.



import { useEffect } from 'react';
import './App.css';
import contract from './contracts/NFTCollectible.json';

const contractAddress = "0x355638a4eCcb777794257f22f50c289d4189F245";
const abi = contract.abi;

function App() {

  const checkWalletIsConnected = () => { }

  const connectWalletHandler = () => { }

  const mintNftHandler = () => { }

  const connectWalletButton = () => {
    return (
      <button onClick={connectWalletHandler} className='cta-button connect-wallet-button'>
        Connect Wallet
      </button>
    )
  }

  const mintNftButton = () => {
    return (
      <button onClick={mintNftHandler} className='cta-button mint-nft-button'>
        Mint NFT
      </button>
    )
  }

  useEffect(() => {
    checkWalletIsConnected();
  }, [])

  return (
    <div className='main-app'>
      <h1>Scrappy Squirrels Tutorial</h1>
      <div>
        {connectWalletButton()}
      </div>
    </div>
  )
}

export default App;

(Remember to set the correct contract address on line 5)

Notice that we have defined a few functions for you which do not do a lot at the moment. We will be explaining their purpose and populating them with logic as we proceed with this tutorial.

We have a small amount of CSS for you to use too. Copy the following into your App.css file.



.main-app {
    text-align: center;
    margin: 100px;
}

.cta-button {
    padding: 15px;
    border: none;
    border-radius: 12px;
    min-width: 250px;
    color: white;
    font-size: 18px;
    cursor: pointer;
}

.connect-wallet-button {
    background: rgb(32, 129, 226);
}

.mint-nft-button {
    background: orange;
}

Your website should now look like this:

Feel free to customize the look of the website by adding more styles and static elements (images, header, footer, social media links, etc.).

We’ve put together most of the foundational blocks of the project. We are now in a good position to tackle one of the first major objectives of this tutorial: allowing a user to connect their wallet to our website.

Connecting Metamask Wallet

For a user to call functions from our contract, they need to be able to connect their wallet to our website. The wallet will enable the user to pay gas and the sale price in order to mint an NFT from our collection.

In this tutorial, we will be working exclusively with the Metamask wallet and its suite of APIs. Off-the-shelf solutions like Moralis and web3modal exist that allow you to add support for multiple wallets with very few lines of code. But for this project, we will focus on implementing connect wallet functionality from scratch. We will cover solutions like Moralis in a later tutorial.

We assume you already have the Metamask wallet extension installed in your browser. If you do, Metamask injects an ethereum object into your browser’s global window object. We will be accessing window.ethereum to perform the bulk of our functionality.

Checking if Metamask Wallet Exists

A user cannot mint NFTs on our website unless they have a Metamask wallet. Let’s populate the checkWalletIsConnected function within the App component that checks if the Metamask wallet exists.

Note that we have also defined the useEffect hook that checks Metamask’s existence when the App component loads.

Open the console on your app’s localhost page. If you have Metamask installed, you should see a message that says Wallet exists! We’re ready to go!

Connecting Metamask Programmatically

Just because we have the Metamask extension installed doesn’t mean that Metamask will automatically connect to every website we visit. We need to prompt Metamask to ask the user to do so.

This is where the Connect Wallet functionality comes in. It is the web3 equivalent of a login button. It allows the user to connect and send contract function call requests through the website frontend.

Metamask makes this process remarkably simple with the window.ethereum.request method.

Let’s first define a variable in App() with the useState hook that will keep track of the user’s wallet address. (Don’t forget to import useState from React!)



const [currentAccount, setCurrentAccount] = useState(null);

Now, let’s define the connectWalletHandler function.

Let’s briefly go through what this function does.

It checks if you have Metamask installed. If not, the website displays a pop-up asking you to install Metamask.
It requests Metamask for the user’s wallet addresses.
Once the user has consented to connect with the website, it takes the first wallet address that is available and sets it as the value of the currentAccount variable.
If something goes wrong (such as the user refusing to connect), it fails and prints an error message to the console.

At the moment, if you open the Metamask extension on your website, it will tell you that you’re not connected.

It is now time for the moment of truth. Click on the Connect Wallet button on your website. Metamask will prompt you to connect with the website. Once you agree to do so, your extension screen will look like this.

Congratulations! We have successfully connected our wallet to our website.

Once the wallet is connected, we should ideally replace the Connect Wallet button with a Mint NFT button. In the return value of App , let’s replace the render of a Connect Wallet button with a conditional render.



{currentAccount ? mintNftButton() : connectWalletButton()}

Our website should now look like this:

Let’s refresh our page and check our extension. You will see that Metamask tells us that we are still connected to the website but our website still displays a Connect Wallet button.

If you’re familiar with React, it should be obvious why this is happening. After all, we are setting the currentAccount state only within the connectWallet function.

Ideally what should happen is that the website should check if the wallet is connected every time the App component is loaded (i.e every time we refresh).

Let us extend the checkWalletIsConnected function to check for accounts as soon as the website is loaded and set currentAccount if the wallet has already been connected.

(Note that we have marked this function async ). Let’s briefly touch upon what this function does:

It checks if Metamask is installed and outputs result to the console.
It attempts to request Metamask for accounts that are connected.
If Metamask is already connected, it obliges by giving the function a list of accounts. If not, an empty list is returned.
If the list is not empty, the function picks the first account sent over by Metamask and sets it as the current account.

If you now refresh the page, you will see that the website indeed displays the Mint NFT button as it should.

Mint NFTs from the website

Let us now implement the core functionality of our website. When a user clicks on the Mint NFT button, we expect the following to happen:

Metamask prompts the user to pay the NFT’s price + gas.
Once the user accepts, Metamask calls the mintNFT function of our contract on behalf of the user.
It notifies the user about the success/failure of the transaction once it is complete.

To do this, we will require the ethers library from our smart contract project. In your terminal, run the following command:



npm install ethers

Let us import this library in App.js.



import { ethers } from 'ethers';

Finally, let’s populate the mintNftHandler function.

(Don’t forget to mark this function as async)

As usual, let’s touch upon what this function does.

It tries to access the ethereum object injected by Metamask.
If ethereum exists, it sets Metamask as the RPC provider. This means that you will be issuing requests to the miners using your Metamask wallet.
To issue requests, the user will need to sign transactions using their private key. We access signer for this purpose.
We then initiate an ethers Contract instance using the deployed contract’s address, the contract ABI, and the signer.
We can now call functions on our contract through the aforementioned contract object. We call the mintNFT function and ask Metamask to send 0.01 ETH (which is the price we set for our NFT).
We wait for the transaction to be processed and once it’s done, we output the transaction hash to the console.
If anything fails (the wrong function called, wrong parameters passed, < 0.01 ETH sent, user rejected transaction, etc.), an error is printed to the console.

On your website, open your browser’s console so that you are able to view the mining status in real-time.

Now, click on the Mint NFT button. Metamask will prompt you to pay 0.01 ETH + gas. The transaction will take approximately 15–20 seconds to process. Once it’s done, the transaction will be confirmed both by a Metamask popup and the console output.

You can now view the NFT on Opensea too. Navigate to your account on testnets.opensea.io and you should be able to see your latest NFT.

UX Improvements & Conclusion

Congratulations! You now have a fully functioning web3 frontend that users can mint NFTs from.

However, as you may have noticed, the UX of the website leaves a lot to be desired. Here are a few improvements that you should consider doing.

Ensure the user is connected to the right network

Our website assumes that the user is connected to the Rinkeby Network when interacting with our website. This may not always be the case.

Can you implement functionality that gently alerts the user if s/he is not connected to Rinkeby (like OpenSea does)? Also, ensure that the user is not able to see the Mint NFT button when connected to the wrong network.

Show transaction status

Currently, our website prints the transaction status onto the console. In a real project, you cannot really expect your users to open their console while interacting with the website.

Can you implement state which tracks the transaction status and gives feedback to the user in real-time? It should show a loader when the transaction is processing, notify the user if the transaction has failed, and display the transaction hash/Opensea link if the transaction has succeeded.

Prompt Metamask even if funds are non-existent

If you do not have any ETH in your Metamask wallet, clicking on Mint NFT will not prompt Metamask at all. In fact, the user will receive no feedback.

Can you ensure that Metamask is prompted even when the user has insufficient funds? It should ideally be Metamask that informs the user how much ETH is required and how much s/he is short by.

Other Quality of life changes

Here are a few other quality of life changes that you can consider.

Allow users to mint more than 1 NFT at a time.
Add a few sample artworks from your NFT collection.
Add a link to your collection on Opensea.
Add the verified smart contract address so people can double-check what’s really happening behind the scenes.
Add links to your Twitter, IG, and Discord.

Our NFT sandbox project, Rinkeby Squirrels, implements a majority of the UX upgrades mentioned here. Try and mint one here and see if you can notice the difference between it and the website we built.

We will be launching future tutorials showing you how to implement a few of these upgrades. But we really suggest you try doing this yourself. You’ll be one step closer to becoming a web3 frontend master.

If you have any questions or are stuck, reach out to us on our Discord.

Final code repository: https://github.com/rounakbanik/nft-collectible-frontend

About Scrappy Squirrels

Scrappy Squirrels is a collection of 10,000+ randomly generated NFTs. Scrappy Squirrels are meant for buyers, creators, and developers who are completely new to the NFT ecosystem.

The community is built around learning about the NFT revolution, exploring its current use cases, discovering new applications, and finding members to collaborate on exciting projects with.

Join our community here: https://discord.gg/8UqJXTX7Kd

Developing for Polygon and Sidechains

Rounak Banik — Thu, 25 Nov 2021 10:23:26 +0000

Introduction

In our last tutorial, we covered how to develop and deploy an NFT Collectible Smart Contract from scratch. Last week, we published another article showing you how to estimate your costs while operating on the Ethereum mainnet and why it would be a good idea to consider a scalability solution like Polygon.

In this article, we will show you how to deploy your project to the Polygon network and in the process, end up saving potentially thousands of dollars.

Overview of developing on sidechains

If you followed our tutorial on how to create an NFT Collectible Smart Contract, then congratulations! You are already a Polygon developer. You’re also a developer on the Binance Smart Chain, the Fantom Opera Network, and any sidechain or L2 scalability solutions that are EVM compatible.

This tutorial will demonstrate deployment to Polygon but the steps are almost identical for any other Ethereum sidechain and (to an extent) L2 chains like Arbitrum.

Steps

Write a smart contract like you would for the Ethereum mainnet.
Recalibrate payable currency to reflect the chain’s token value.
Add the sidechain network to Metamask and Hardhat configuration file.
Acquire the chain’s token directly or by bridging from the Ethereum mainnet.
Deploy to the sidechain by paying fees using the chain’s token.

Writing a Smart Contract

Note

You can skip this section if you completed our smart contract tutorial.

We have already covered how to develop a smart contract for Ethereum in detail (and I have a feeling I’m mentioning this a little too often). I hope you already have your custom project ready to go. If not, you can clone a starter repository that we created.

Make sure you have Git and run the following commands:

git clone https://github.com/rounakbanik/nft-collectible-contract polygon-nft

cd polygon-nft

npm install

Create a new file called .env and input the following details.

API_URL = "<--Rinkeby RPC URL-->"

PRIVATE_KEY = "<-- Metamask wallet private key -->"

ETHERSCAN_API = ""

POLYGON_URL = ""

You won’t need API_URL for this tutorial so feel free to set this to a blank string (don’t delete it though, the configuration file will break).

You should already know how to get your Metamask wallet’s private key. Let ETHERSCAN_API and POLYGON_URL stay blank for the time being.

Now, go to the hardhat.config.js file and remove line 25 (the one with the defaultNetwork configuration. We won’t be needing this either.)

Finally, run the following command:

npx hardhat run scripts/run.js

If this runs without any errors, congratulations! You are up to speed, and we can finally concentrate on the Polygon aspects of the project.

Recalibrating price

We set the base price of our NFT at 0.01 ETH. In other words, users would have to pay 0.01 ETH for each NFT that they minted (plus gas, of course). We encapsulate this information in line 16 of NFTCollectible.sol in the contracts folder of our project.

Transactions on the Polygon sidechain aren’t conducted in ETH though. The Polygon chain has its own ERC20 token called MATIC. We, therefore, need to set our price in MATIC.

At the time of writing, ETH is touching $5000 whereas MATIC is touching $2. Therefore, if we wanted our NFT to be priced the same (in terms of USD), we would price it at 25 MATIC.

Let’s make a change in our contract to reflect this change.

uint public constant PRICE = 25 ether;

Wait, what? Why does this say 25 ether and not something like 25 matic?

Solidity does not really understand what ETH is. In Solidity, the keyword ether is just a shorthand for 10¹⁸. To Solidity, the line above is the same as this:

uint public constant PRICE = 25000000000000000000;

To put it another way, you can specify payable amounts in Solidity in terms of Wei. On the mainnet, 1 ETH is 10¹⁸ Wei. On Polygon, 10¹⁸ Wei is 1 MATIC. This is a huge difference considering the difference in the price of ETH and MATIC. Always make sure you calibrate your prices correctly if you are moving to a different network!

In this tutorial, we are going to be working with the Polygon Mumbai testnet and I’m going to price the NFT at 0.01 MATIC (for reasons you’ll see soon). So, I’m going to reset the line back to what it originally was.

uint public constant PRICE = 0.01 ether;

Please remember. On Polygon, this is 0.01 MATIC. Not 0.01 ETH.

Add Polygon Network to Metamask and Hardhat

Let’s add the Polygon and Polygon MUMBAI networks to our Metamask wallet. This is really simple to do and Polygon has a short, excellent tutorial on this. Here is a snapshot of my wallet connected to the Mumbai network.

For Hardhat, we will use a custom RPC URL from Alchemy. Go ahead and create an Alchemy account if you haven’t already. Next, create an App by setting the chain to Polygon and the network to Mumbai.

Finally, click on VIEW KEY for your app and get the HTTP URL. Go back to your .env file and fill in the value for POLYGON_URL.

POLYGON_URL = "<---Alchemy Polygon URL -->"

Finally, our hardhat.config.js file should add Mumbai as one of our deployment networks. I have done this already for you in lines 30–33.

Get fake MATIC

Now that we have configured our network on both Metamask and Hardhat, let’s proceed to get some fake MATIC.

Go to https://faucet.polygon.technology/ and request for test tokens for the Mumbai network. Unlike Rinkeby, you shouldn’t face too many issues acquiring these tokens. You will almost always get 1 MATIC almost near instantaneously.

Note about Polygon and sidechain main networks

When you’re ready to deploy to the main Polygon network (or the sidechain of your choice), you will need to acquire real MATIC.

There are two ways to do this:

Buy MATIC on the Ethereum mainnet and bridge it to the Polygon network.
Buy MATIC on a centralized exchange (like Wazirx or Coinbase) and transfer it directly to Metamask.

In the case of sidechains, it is almost always easier and cheaper to do (2).

Deploy to the Polygon Mumbai network

We’re ready to go! Run the following command on your terminal.

npx hardhat run scripts/run.js --network mumbai

We can confirm that our contract was deployed and our NFTs were minted by visiting https://mumbai.polygonscan.com/ and searching for our contract address. As you can see above, our contract was deployed to 0xe4ad3e1d2553eCbe4Ab64cd717564dbD36d520cc.

One of the biggest advantages that Polygon has over other sidechains is that it is supported by OpenSea, the largest NFT marketplace in the world and the defacto platform for secondary sales for almost every popular NFT project.

Visit https://testnets.opensea.io/ and search for your contract address. You will see that your collection has already been uploaded to OpenSea almost magically.

Check out our collection here.

Verifying our contract

As a bonus, let’s verify our contract on Polygonscan so our users are able to mint from Polygonscan directly.

To do this, you will need to sign up for a Polygonscan account. Next, proceed to create an API key.

Go back to the .env file one last time and fill in the value for ETHERSCAN_API.

ETHERSCAN_API = "<--Polygonscan API key-->"

I have kept the name ETHERSCAN_API from the previous tutorial because Polygonscan is powered by Etherscan and we still use the hardhat-etherscan library to verify our contract. Feel free to change the naming if you wish.

Now, run the following command on your Terminal.

npx hardhat verify --network mumbai DEPLOYED_CONTRACT_ADDRESS "ipfs://QmZbWNKJPAjxXuNFSEaksCJVd1M6DaKQViJBYPK2BdpDEP/"

In my case, this was the exact command I ran.

npx hardhat verify --network mumbai 0xe4ad3e1d2553eCbe4Ab64cd717564dbD36d520cc "ipfs://QmZbWNKJPAjxXuNFSEaksCJVd1M6DaKQViJBYPK2BdpDEP/"

You should now see a small green checkmark on your contract’s Polygonscan page. More importantly, your users will be able to read your contract and call functions from it.

Conclusion

Congratulations! You have a good understanding of how to build for Polygon or migrate existing projects into Polygon. The great news, as I’ve stated already, is that this knowledge converts really well to any EVM-compatible network (Binance, Fantom, Arbitrum, Optimism, etc.)

If you have any questions, please feel free to drop them on the #suggestions-and-qna channel of our Discord.

About Scrappy Squirrels

Scrappy Squirrels is a collection of 10,000+ randomly generated NFTs on the Ethereum Blockchain. Scrappy Squirrels are meant for buyers, creators, and developers who are completely new to the NFT ecosystem.

The community is built around learning about the NFT revolution, exploring its current use cases, discovering new applications, and finding members to collaborate on exciting projects with.

Join our community here: https://discord.gg/8UqJXTX7Kd

Writing an NFT Collectible Smart Contract

Rounak Banik — Mon, 22 Nov 2021 11:04:18 +0000

Introduction

In my previous tutorials, we showed you how to use our generative art library to create a collection of avatars, generate compliant NFT metadata, and upload the metadata JSON and media files to IPFS.

However, we haven’t minted any of our avatars as NFTs yet. Therefore, in this tutorial, we will write a smart contract that will allow anyone to mint an NFT from our collection by paying gas and a price that we’ve set for each NFT piece.

Prerequisites

Intermediate knowledge of Javascript. (In case you need a refresher, I’d suggest this YouTube tutorial)
Intermediate knowledge of Solidity and OpenZeppelin Contracts. (I will be releasing tutorials on this very soon! For the time being, I strongly recommend CryptoZombies and Buildspace)
node and npm installed on your local computer
A collection of media files and NFT metadata JSON uploaded to IPFS. (In case you don’t have this, we have created a toy collection for you to experiment with. You can find the media files here and the JSON metadata files here).

While it may be possible for readers who do not satisfy the prerequisites to follow along and even deploy a smart contract, we strongly recommend getting a developer who knows what s/he is doing if you’re serious about your project. Smart contract development and deployment can be incredibly expensive and unforgiving w.r.t security flaws and bugs.

Setting up our local development environment

We will be using Hardhat, an industry-standard ethereum development environment, to develop, deploy, and verify our smart contracts. Create an empty folder for our project and initialize an empty package.json file by running the following command in your Terminal:

mkdir nft-collectible && cd nft-collectible && npm init -y

You should now be inside the nft-collectible folder and have a file named package.json.

Next, let’s install Hardhat. Run the following command:

npm install --save-dev hardhat

We can now create a sample Hardhat project by running the following command and choosing Create a basic sample project.

npx hardhat

Agree to all the defaults (project root, adding a .gitignore, and installing all sample project dependencies).

Let’s check that our sample project has been installed properly. Run the following command:

npx hardhat run scripts/sample-script.js

If all goes well, you should see output that looks something like this:

We now have our hardhat development environment successfully configured. Let us now install the OpenZeppelin contracts package. This will give us access to the ERC721 contracts (the standard for NFTs) as well as a few helper libraries that we will encounter later.

npm install @openzeppelin/contracts

If we want to share our project’s code publicly (on a website like GitHub), we wouldn’t want to share sensitive information like our private key, our Etherscan API key, or our Alchemy URL (don’t worry if some of these words don’t make sense to you yet). Therefore, let us install another library called dotenv.

npm install dotenv

Congratulations! We are now in a good place to start developing our smart contract.

Writing the Smart Contract

In this section, we are going to write a smart contract in Solidity that allows anyone to mint a certain number of NFTs by paying the required amount of ether + gas.

In the contracts folder of your project, create a new file called NFTCollectible.sol.

We will be using Solidity v8.0. Our contract will inherit from OpenZeppelin’s ERC721Enumerable and Ownable contracts. The former has a default implementation of the ERC721 (NFT) standard in addition to a few helper functions that are useful when dealing with NFT collections. The latter allows us to add administrative privileges to certain aspects of our contract.

In addition to the above, we will also use OpenZeppelin’s SafeMath and Counters libraries to safely deal with unsigned integer arithmetic (by preventing overflows) and token IDs respectively.

This is what the skeleton of our contract looks like:

//SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/utils/math/SafeMath.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Enumerable.sol";
contract NFTCollectible is ERC721Enumerable, Ownable {
    using SafeMath for uint256;
    using Counters for Counters.Counter;

    Counters.Counter private _tokenIds;
}

Storage constants and variables

Our contract needs to keep track of certain variables and constants. For this tutorial, we will be defining the following:

Supply: The maximum number of NFTs that can be minted in your collection.
Price: The amount of ether required to buy 1 NFT.
Maximum number of mints per transaction: The upper limit of NFTs that you can mint at once.
Base Token URI: The IPFS URL of the folder containing the JSON metadata.

In this tutorial, we will set 1–3 as constants. In other words, we won’t be able to modify them once the contract has been deployed. We will write a setter function for baseTokenURI that will allow the contract’s owner (or deployer) to change the base URI as and when required.

Right under the _tokenIds declaration, add the following:

uint public constant MAX_SUPPLY = 100;
uint public constant PRICE = 0.01 ether;
uint public constant MAX_PER_MINT = 5;

string public baseTokenURI;

Notice that I’ve used all caps for the constants. Feel free to change the values for the constants based on your project.

Constructor

We will set the baseTokenURI in our constructor call. We will also call the parent constructor and set the name and symbol for our NFT collection.

Our constructor, therefore, looks like this:

constructor(string memory baseURI) ERC721("NFT Collectible", "NFTC") {
     setBaseURI(baseURI);
}

Reserve NFTs function

As the creator of the project, you probably want to reserve a few NFTs of the collection for yourself, your team, and for events like giveaways.

Let’s write a function that allows us to mint a certain number of NFTs (in this case, ten) for free. Since anyone calling this function only has to pay gas, we will obviously mark it as onlyOwner so that only the owner of the contract will be able to call it.

function reserveNFTs() public onlyOwner {
     uint totalMinted = _tokenIds.current();
     require(
        totalMinted.add(10) < MAX_SUPPLY, "Not enough NFTs"
     );
     for (uint i = 0; i < 10; i++) {
          _mintSingleNFT();
     }
}

We check the total number of NFTs minted so far by calling tokenIds.current(). We then check if there are enough NFTs left in the collection for us to reserve. If yes, we proceed to mint 10 NFTs by calling _mintSingleNFT ten times.

It is in the _mintSingleNFT function that the real magic happens. We will look into this a little later.

Setting Base Token URI

Our NFT JSON metadata is available at this IPFS URL: ipfs://QmZbWNKJPAjxXuNFSEaksCJVd1M6DaKQViJBYPK2BdpDEP/

When we set this as the base URI, OpenZeppelin’s implementation automatically deduces the URI for each token. It assumes that token 1’s metadata will be available at ipfs://QmZbWNKJPAjxXuNFSEaksCJVd1M6DaKQViJBYPK2BdpDEP/1, token 2’s metadata will be available at ipfs://QmZbWNKJPAjxXuNFSEaksCJVd1M6DaKQViJBYPK2BdpDEP/2, and so on.

(Please note that there is no .json extension to these files)

However, we need to tell our contract that the baseTokenURI variable that we defined is the base URI that the contract must use. To do this, we override an empty function called _baseURI() and make it return baseTokenURI.

We also write an only owner function that allows us to change the baseTokenURI even after the contract has been deployed.

function _baseURI() internal 
                    view 
                    virtual 
                    override 
                    returns (string memory) {
     return baseTokenURI;
}

function setBaseURI(string memory _baseTokenURI) public onlyOwner {
     baseTokenURI = _baseTokenURI;
}

Mint NFTs function

Let us now turn our attention to the main mint NFTs function. Our users and customers will call this function when they want to purchase and mint NFTs from our collection.

Since they’re sending ether to this function, we have to mark it as payable.

We need to make three checks before we allow the mint to take place:

There are enough NFTs left in the collection for the caller to mint the requested amount.
The caller has requested to mint more than 0 and less than the maximum number of NFTs allowed per transaction.
The caller has sent enough ether to mint the requested number of NFTs.

function mintNFTs(uint _count) public payable {
     uint totalMinted = _tokenIds.current();
     require(
       totalMinted.add(_count) <= MAX_SUPPLY, "Not enough NFTs!"
     );
     require(
       _count > 0 && _count <= MAX_PER_MINT, 
       "Cannot mint specified number of NFTs."
     );
     require(
       msg.value >= PRICE.mul(_count), 
       "Not enough ether to purchase NFTs."
     );
     for (uint i = 0; i < _count; i++) {
            _mintSingleNFT();
     }
}

Mint Single NFT function

Let’s finally take a look at the private _mintSingleNFT() function that’s being called whenever we (or a third party) want to mint an NFT.

function _mintSingleNFT() private {
      uint newTokenID = _tokenIds.current();
      _safeMint(msg.sender, newTokenID);
      _tokenIds.increment();
}

This is what is happening:

We get the current ID that hasn’t been minted yet.
We use the _safeMint() function already defined by OpenZeppelin to assign the NFT ID to the account that called the function.
We increment the token IDs counter by 1.

The token ID is 0 before any mint has taken place.

When this function is called for the first time, newTokenID is 0. Calling safeMint() assigns NFT with ID 0 to the person who called the contract function. The counter is then incremented to 1.

The next time this function is called, _newTokenID has value 1. Calling safeMint() assigns NFT with ID 1 to the person who… I think you get the gist.

Note that we don’t need to explicitly set the metadata for each NFT. Setting the base URI ensures that each NFT gets the correct metadata (stored in IPFS) assigned automatically.

Getting all tokens owned by a particular account

If you plan on giving any sort of utility to your NFT holders, you would want to know which NFTs from your collection each user holds.

Let’s write a simple function that returns all IDs owned by a particular holder. This is made super simple by ERC721Enumerable‘s balanceOf and tokenOfOwnerByIndex functions. The former tells us how many tokens a particular owner holds, and the latter can be used to get all the IDs that an owner owns.

function tokensOfOwner(address _owner) 
         external 
         view 
         returns (uint[] memory) {
     uint tokenCount = balanceOf(_owner);
     uint[] memory tokensId = new uint256[](tokenCount);
     for (uint i = 0; i < tokenCount; i++) {
          tokensId[i] = tokenOfOwnerByIndex(_owner, i);
     }

     return tokensId;
}

Withdraw balance function

All the effort we’ve put in so far would go to waste if we are not able to withdraw the ether that has been sent to the contract.

Let us write a function that allows us to withdraw the contract’s entire balance. This will obviously be marked as onlyOwner.

function withdraw() public payable onlyOwner {
     uint balance = address(this).balance;
     require(balance > 0, "No ether left to withdraw");
     (bool success, ) = (msg.sender).call{value: balance}("");
     require(success, "Transfer failed.");
}

Final Contract

We’re done with the smart contract. This is what it looks like. (By the way, if you haven’t already, delete the Greeter.sol file.)

//SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/utils/math/SafeMath.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Enumerable.sol";

contract NFTCollectible is ERC721Enumerable, Ownable {
    using SafeMath for uint256;
    using Counters for Counters.Counter;

    Counters.Counter private _tokenIds;

    uint public constant MAX_SUPPLY = 100;
    uint public constant PRICE = 0.01 ether;
    uint public constant MAX_PER_MINT = 5;

    string public baseTokenURI;

    constructor(string memory baseURI) ERC721("NFT Collectible", "NFTC") {
        setBaseURI(baseURI);
    }

    function reserveNFTs() public onlyOwner {
        uint totalMinted = _tokenIds.current();

        require(totalMinted.add(10) < MAX_SUPPLY, "Not enough NFTs left to reserve");

        for (uint i = 0; i < 10; i++) {
            _mintSingleNFT();
        }
    }

    function _baseURI() internal view virtual override returns (string memory) {
        return baseTokenURI;
    }

    function setBaseURI(string memory _baseTokenURI) public onlyOwner {
        baseTokenURI = _baseTokenURI;
    }

    function mintNFTs(uint _count) public payable {
        uint totalMinted = _tokenIds.current();

        require(totalMinted.add(_count) <= MAX_SUPPLY, "Not enough NFTs left!");
        require(_count >0 && _count <= MAX_PER_MINT, "Cannot mint specified number of NFTs.");
        require(msg.value >= PRICE.mul(_count), "Not enough ether to purchase NFTs.");

        for (uint i = 0; i < _count; i++) {
            _mintSingleNFT();
        }
    }

    function _mintSingleNFT() private {
        uint newTokenID = _tokenIds.current();
        _safeMint(msg.sender, newTokenID);
        _tokenIds.increment();
    }

    function tokensOfOwner(address _owner) external view returns (uint[] memory) {

        uint tokenCount = balanceOf(_owner);
        uint[] memory tokensId = new uint256[](tokenCount);

        for (uint i = 0; i < tokenCount; i++) {
            tokensId[i] = tokenOfOwnerByIndex(_owner, i);
        }
        return tokensId;
    }

    function withdraw() public payable onlyOwner {
        uint balance = address(this).balance;
        require(balance > 0, "No ether left to withdraw");

        (bool success, ) = (msg.sender).call{value: balance}("");
        require(success, "Transfer failed.");
    }

}

Deploying the contract locally

Let us now make preparations to deploy our contract to the Rinkeby test network by simulating it in a local environment.

In the scripts folder, create a new file called run.js and add the following code:

const { utils } = require("ethers");

async function main() {
    const baseTokenURI = "ipfs://QmZbWNKJPAjxXuNFSEaksCJVd1M6DaKQViJBYPK2BdpDEP/";

    // Get owner/deployer's wallet address
    const [owner] = await hre.ethers.getSigners();

    // Get contract that we want to deploy
    const contractFactory = await hre.ethers.getContractFactory("NFTCollectible");

    // Deploy contract with the correct constructor arguments
    const contract = await contractFactory.deploy(baseTokenURI);

    // Wait for this transaction to be mined
    await contract.deployed();

    // Get contract address
    console.log("Contract deployed to:", contract.address);

    // Reserve NFTs
    let txn = await contract.reserveNFTs();
    await txn.wait();
    console.log("10 NFTs have been reserved");

    // Mint 3 NFTs by sending 0.03 ether
    txn = await contract.mintNFTs(3, { value: utils.parseEther('0.03') });
    await txn.wait()

    // Get all token IDs of the owner
    let tokens = await contract.tokensOfOwner(owner.address)
    console.log("Owner has tokens: ", tokens);

}

main()
    .then(() => process.exit(0))
    .catch((error) => {
        console.error(error);
        process.exit(1);
    });

This is some Javascript code that utilizes the ethers.js library to deploy our contract, and then call functions of the contract once it has been deployed.

Here is the series of what’s going on:

We get the address of the deployer/owner (us)
We get the contract that we want to deploy.
We send a request for the contract to be deployed and wait for a miner to pick this request and add it to the blockchain.
Once mined, we get the contract address.
We then call public functions of our contract. We reserve 10 NFTs, mint 3 NFTs by sending 0.03 ETH to the contract, and check the NFTs owned by us. Note that the first two calls require gas (because they’re writing to the blockchain) whereas the third simply reads from the blockchain.

Let’s give this a run locally.

npx hardhat run scripts/run.js

If all goes well, you should see something like this:

Deploying the contract to Rinkeby

To deploy our contract to Rinkeby, we will need to set up a few things.

First, we will need an RPC URL that will allow us to broadcast our contract creation transaction. We will use Alchemy for this. Create an Alchemy account here and then proceed to create a free app.

Make sure that the network is set to Rinkeby.

Once you’ve created an app, go to your Alchemy dashboard and select your app. This will open a new window with a View Key button on the top right. Click on that and select the HTTP URL.

Acquire some fake Rinkeby ETH from the faucet here. For our use case, 0.5 ETH should be more than enough. Once you’ve acquired this ETH, open your Metamask extension and get the private key for the wallet containing the fake ETH (you can do this by going into Account Details in the 3-dots menu near the top-right).

Do not share your URL and private key publicly.

We will use the dotenv library to store the aforementioned variables as environment variables and will not commit them to our repository.

Create a new file called .env and store your URL and private key in the following format:

API_URL = "<--YOUR ALCHEMY URL HERE-->"
PRIVATE_KEY = "<--YOUR PRIVATE KEY HERE-->"

Now, replace your hardhat.config.js file with the following contents.

require("@nomiclabs/hardhat-waffle");
require('dotenv').config();

const { API_URL, PRIVATE_KEY } = process.env;

// This is a sample Hardhat task. To learn how to create your own go to
// https://hardhat.org/guides/create-task.html
task("accounts", "Prints the list of accounts", async (taskArgs, hre) => {
  const accounts = await hre.ethers.getSigners();

  for (const account of accounts) {
    console.log(account.address);
  }
});

// You need to export an object to set up your config
// Go to https://hardhat.org/config/ to learn more

/**
 * @type import('hardhat/config').HardhatUserConfig
 */
module.exports = {
  solidity: "0.8.4",
  defaultNetwork: "rinkeby",
  networks: {
    rinkeby: {
      url: API_URL,
      accounts: [PRIVATE_KEY]
    }
  },
};

We’re almost there! Run the following command:

npx hardhat run scripts/run.js --network rinkeby

This should give you output very similar to what you got earlier, except that this has been deployed to the real blockchain.

Make a note of the contract address. Ours was 0x355638a4eCcb777794257f22f50c289d4189F245.

You can check this contract out on Etherscan. Go to Etherscan and type in the contract address. You should see something like this.

Viewing our NFTs on OpenSea

Believe it or not, our NFT collection is now already available on OpenSea without us having to upload it explicitly. Go to testnets.opensea.io and search for your contract address.

This is what our collection looks like:

Verifying our contract on Etherscan

We have come a LONG way in this article but there is one final thing we’d like to do before we go.

Let’s verify our contract on etherscan. This will allow your users to see your contract’s code and ensure that there is no funny business going on. More importantly, verifying your code will allow your users to connect their Metamask wallet to etherscan and mint your NFTs from etherscan itself!

Before we can do this, we will need an Etherscan API key. Sign up for a free account here and access your API keys here.

Let’s add this API key to our .env file.

ETHERSCAN_API = "<--YOUR ETHERSCAN API KEY-->"

Hardhat makes it really simple to verify our contract on Etherscan. Let’s install the following package:

npm install @nomiclabs/hardhat-etherscan

Next, make adjustments to hardhat.config.js so it looks like this:

require("@nomiclabs/hardhat-waffle");
require("@nomiclabs/hardhat-etherscan");
require('dotenv').config();

const { API_URL, PRIVATE_KEY, ETHERSCAN_API } = process.env;

// This is a sample Hardhat task. To learn how to create your own go to
// https://hardhat.org/guides/create-task.html
task("accounts", "Prints the list of accounts", async (taskArgs, hre) => {
  const accounts = await hre.ethers.getSigners();

  for (const account of accounts) {
    console.log(account.address);
  }
});

// You need to export an object to set up your config
// Go to https://hardhat.org/config/ to learn more

/**
 * @type import('hardhat/config').HardhatUserConfig
 */
module.exports = {
  solidity: "0.8.4",
  defaultNetwork: "rinkeby",
  networks: {
    rinkeby: {
      url: API_URL,
      accounts: [PRIVATE_KEY]
    }
  },
  etherscan: {
    apiKey: ETHERSCAN_API
  }
};

Now, run the following two commands:

npx hardhat clean

npx hardhat verify --network rinkeby DEPLOYED_CONTRACT_ADDRESS "BASE_TOKEN_URI"

In our case, the second command looked like this:

npx hardhat verify --network rinkeby 0x355638a4eCcb777794257f22f50c289d4189F245 "ipfs://QmZbWNKJPAjxXuNFSEaksCJVd1M6DaKQViJBYPK2BdpDEP/"

Now, if you visit your contract’s Rinkeby Etherscan page, you should see a small green tick next to the Contract tab. More importantly, your users will now be able to connect to web3 using Metamask and call your contract’s functions from Etherscan itself!

Try this out yourself.

Connect the account that you used to deploy the contract and call the withdraw function from etherscan. You should be able to transfer the 0.03 ETH in the contract to your wallet. Also, ask one of your friends to connect their wallet and mint a few NFTs by calling the mintNFTs function.

Conclusion

We now have a deployed smart contract that lets users mint NFTs from our collection. An obvious next step would be to build a web3 app that allows our users to mint NFTs directly from our website. This will be the subject of a future tutorial.

If you’ve reached this far, congratulations! You are on your way to becoming a master Solidity and blockchain developer. We’ve covered some complex concepts in this article and coming this far is truly incredible. We’re proud. :)

We would love to take a look at your collection. Come say hi to us on our Discord. Also, if you liked our content, we would be super grateful if you tweet about us, follow us(@ScrappyNFTs and @Rounak_Banik), and invite your circle to our Discord. Thank you for your support!

Final code repository: https://github.com/rounakbanik/nft-collectible-contract

Scrappy Squirrels

The community is built around learning about the NFT revolution, exploring its current use cases, discovering new applications, and finding members to collaborate on exciting projects with.

Join our community here: https://discord.gg/8UqJXTX7Kd

Working with NFT Metadata, IPFS, and Pinata

Rounak Banik — Thu, 18 Nov 2021 16:50:54 +0000

Disclaimer

This article serves as a sequel to my tutorial on creating generative NFT art. If you haven’t read it, I suggest you do so. I assume your system is already set up (with Python and required packages), and you have used the generative-art-nft library.

Introduction

In the previous tutorial, you learned how to create a generative art collection with custom rarities. If you followed along with your custom artwork (or used my samples), you should now have a collection of PNG images, and a metadata CSV file that contains information on traits for each image.

This is a great first step towards creating an NFT collection but we still have a long way to go. The images that we generated exist on our local systems and are not really accessible to anyone. The metadata we generated is ideal for analyzing on Excel but is not in a format that adheres to standards (and by extension, cannot be used by an NFT marketplace platform like OpenSea).

I will be addressing these issues in this article. More specifically, we will show you how to:

Upload Images to IPFS
Generate compliant JSON NFT metadata
Upload metadata files to IPFS

Don’t worry if some of these words don’t make sense right now. I will be explaining them as and when required.

How NFT Minting Works

To understand why we’re doing what we’re doing, we need to understand how NFT minting works. If you know this already, feel free to skip this section.

Let’s say you want to mint a collection of 10,000 NFTs. What does that really mean?

This means that you’re writing some code (called a smart contract) that tells the blockchain to initialize a table for you. This table stores ownership and metadata information about your NFTs. More specifically, each row of the table consists of the following information:

The Token Identifier (or ID)
The Owner of the Token
The Metadata associated with the token

Here is an example table:

You can see here that the ID is nothing but a unique positive integer that identifies a particular NFT. The Owner column stores the addresses associated with each NFT’s holder. Finally, the Metadata is a column that may contain data of the NFT or about the NFT.

It is possible to store the entire image in the Metadata column of the table. However, storing data on a blockchain is expensive. To give you some context, our collection of 10,000 squirrels occupies a disk space of 600 MB. If we wanted to store 600 MB worth of data on the Ethereum blockchain, it would cost us $1 million dollars.

This is clearly not a great option. Therefore, in most cases, instead of storing data of the NFT, we instead simply store data about the NFT. This data (or metadata) is stored in a format called JSON. If you don’t know what JSON is, don’t worry about it. For our purposes, think of them like Python dictionaries (encapsulated in {}) that you encountered in the previous article to define layers.

This JSON file needs to have information about the NFT such as its name, description, image URL, attributes, etc. In order to make sure that everyone in the ecosystem (including NFT marketplaces like OpenSea) understands what’s in our JSON files, we need to format them in a way that is compliant with the standards. In our case, we will use the standards recommended by OpenSea.

Here is a JSON metadata file for a sample NFT.

my-nft.json

{   
   "description": "Friendly OpenSea Creature",      
   "image": "https://opensea-prod.appspot.com/puffs/3.png",  
   "name": "Dave Starbelly",   
   "attributes": [
       { "trait_type": "Base", "value": "Starfish" },      
       { "trait_type": "Eyes", "value": "Big" },      
       { "trait_type": "Mouth","value": "Surprised" },
   ]
}

Storing metadata in this format on the blockchain is still very expensive. Hence, we add an additional layer of abstraction, and upload this JSON to the cloud as well and simply store a URL pointing to the JSON file.

Therefore, at the end of the data, all you’re storing on the blockchain is https://mywebsite.com/my-nft.json.

To summarize, here is what we need to do:

Upload all our images online and get a URL associated with each image. (This URL will go into our metadata).
Generate a separate JSON file for each image containing metadata in the standard shown above (Image URL, attributes/traits, name, etc.)
Upload all the JSON files to the cloud and get a URL associated with each JSON file.

Uploading Images to IPFS

Uploading images to the internet is pretty simple. We’re sure you must have used a service like Google Drive, GitHub, or AWS to upload folders to the cloud.

While uploading images to such centralized services (AWS, Google Drive, your own server, etc.) would work, it would not be a very good idea.

Why not? For two reasons, mainly.

Centralized Storage tends to be location based

Imagine you upload an image of a dog (called dog.jpeg) to a centralized storage service. Your dog image would then be available by accessing a URL (something like https://mystorage.com/dog.jpeg).

However, it is very easy to swap this image for another. I could upload another image with the same name (dog.jpeg) that replaces the original image.

Now, if I visited the same URL as before (https://mystorage.com/dog.jpeg), I will see a different image. You can see why this is not ideal in NFT world. People spend thousands of dollars on NFTs and they would be pissed if you simply replaced an avatar with extremely rare traits with something else.

Centralized Storage can be taken down

Let’s say you upload an image to a Google Drive or AWS. If you removed the image from these services or the services themselves shut down, the URL pointing to the image would break. Therefore, it is very easy to pull the rug if your images and data exist on a centralized storage service.

For these reasons, almost every serious NFT project uses a service called IPFS (or Interplanetary File System).

IPFS is a peer-to-peer filesharing system that is decentralized, uses content-based addressing, and is secure.

If none of the words above make sense, don’t worry. All you need to know is this:

IPFS used content-based addressing

On the IPFS network, the address (URL) of a file will be dependent on the content of the file. If you change the contents of a file, then the address of the file on the IPFS will also change.

Therefore, on the IPFS network, it is impossible to make one URL point to two different images.

IPFS never goes down

Like most decentralized systems (like blockchains), IPFS never goes down. This means that once you’ve uploaded a file (or image) to IPFS, it will always be available as long as at least one node in the network has the file. This means that you cannot pull the rug at will. Nor is there a threat that the system will be shut down.

We’re not going to go into the nitty-gritties of how IPFS works. If you’re interested, we suggest you give the following two articles a read:

Uploading to IPFS is as easy as uploading to Google Drive, thanks to a service called Pinata.

Go to the Pinata website and create an account. It’s free if you’re uploading up to 1 GB of data.

Once you have signed up, you will be taken to the Pin Manager window. Upload your folder using the interface. Once you’ve uploaded your folder, you will get a CID associated with it. It should look something like this.

This CID was generated based on the contents of the folder. If the contents of the folder change (an image removed, an image swapped with another of the same name, etc.), the CID will also change.

For my folder, the CID is QmRvSoppQ5MKfsT4p5Snheae1DG3Af2NhYXWpKNZBvz2Eo.

Therefore, the IPFS URL for this folder is ipfs://QmRvSoppQ5MKfsT4p5Snheae1DG3Af2NhYXWpKNZBvz2Eo.

This URL will not open in a browser. In order to do that, you can use a HTTP URL of an IPFS gateway. Try visiting this link: https://ipfs.io/ipfs/QmRvSoppQ5MKfsT4p5Snheae1DG3Af2NhYXWpKNZBvz2Eo/00001.png

This will display an image that I named 00001.png and uploaded to my folder.

Congratulations! That is all there is to uploading images on IPFS using Pinata. For the next step, you will need the CID. Keep that handy.

Generate compliant NFT JSON metadata

Since we uploaded our images to IPFS, we now have IPFS URLs for each and every image.

Our next task is to create a JSON file for each image and populate it with data (including the image URL) in a format that is compliant and understandable by platforms like NFT marketplaces.

Fortunately, the generative-art-nft library does all the heavy lifting for you.

Check that the metadata.py file exists in the repository. If not, clone the latest version of the repository and transfer the assets and output folders into the new repo.

Open the metadata.py file in a text editor. Don’t worry if you don’t understand the code here. The only things you need to fill are BASE_NAME, BASE_URL, and BASE_JSON.

In line 17, replace ←Your CID Code → with the CID code of the image folder you uploaded to Pinata.

In line 18, add a base name for your NFTs. This is strictly optional. If you do not add a base name, your NFTs will be named 0, 1, 2, and so on. If you put a base name like “Scrappy Squirrel #”, your NFTs will be named Scrappy Squirrel #0, Scrappy Squirrel #1, etc.

Finally, in line 22, add a description for your collection. Like the base name, this is optional.

Now, open a Terminal in this folder and run the following command.

python metadata.py

The program will ask you the edition to generate metadata for. In our case, it was v2, so that’s what we enter.

It should take less than 15 seconds to generate 10,000+ JSON files. All these files will be conveniently available in a json folder within your edition folder.

That’s it for step 2!

Upload JSON metadata files to IPFS

The third step is probably the simplest. Just like you did with the images, upload your json folder to Pinata.

Conclusion

Congratulations! You now have a very good setup for your NFT metadata. The last and most important step is to write a smart contract that can use this metadata and assign ownership to various holders. That is, however, a topic of a future article. Stay tuned!

If you have any questions or would like us to add additional features to this library, please reach out to us on our Discord server, or drop them in the comments below. We will try to address as many of them as possible.

Until next time!

About Scrappy Squirrels

Scrappy Squirrels is a collection of 10,000+ randomly generated NFTs. Scrappy Squirrels are meant for buyers, creators, and developers who are completely new to the NFT ecosystem.

The community is built around learning about the NFT revolution, exploring its current use cases, discovering new applications, and finding members to collaborate on exciting projects with.

Join our community here: https://discord.gg/8UqJXTX7Kd

Create Generative NFT Art with Rarities

Rounak Banik — Sun, 14 Nov 2021 12:10:22 +0000

Disclaimer

This article was originally published on the Scrappy Squirrels Medium Publication.

Introduction

Marquee NFT projects like Cryptopunks and Bored Ape Yacht Club have generated hundreds of millions of dollars in revenue, and have made several of their owners millionaires.

What the aforementioned projects (and most other successful NFT projects today) have been in common is that they are PFP projects. This means that they usually are a collection of 10,000+ avatars where each avatar is unique and has a set of traits.

In this tutorial, I will show you how to generate a collection like this with custom rarities. I will be using a library created by the Scrappy Squirrels team to accomplish this. At the end of this tutorial, you will have generated your own custom avatar collection with associated metadata.

Pre-requisites

Python and pip installed on your computer

Our library is written in Python so you will need to have this installed on your computer. You will also need pip which will install important packages for us. Go to this website and download the latest version of Python

An artist (preferred but not required)

You will need an artist who knows their way around digital art to create your own custom collection. However, this is not required to follow this tutorial. I will be providing you with test images to play around with.

The Scrappy Squirrels Collection

As part of this tutorial, I will walk you through the process of creating the Scrappy Squirrels NFTs, a real project that my team has launched. This tutorial (and every subsequent one) has been created as part of our roadmap goals to make NFTs and blockchains more accessible to people. Do check out our Discord for more details. (Go on, I will wait :))

The squirrels have been generated using over 90 traits. Here are a few samples.

The Generation Process

The squirrels that you see above were generated by stacking PNG images on top of one another. Although no blue-chip NFT projects describe how they generate their art, we are certain that this is what they do too. Almost every NFT avatar that you see is a set of stacked PNG images (which makes the claims that they are just JPEGs false. Checkmate, NFT critics).

Starting from the top right, if you stack every trait image clockwise, one after the other, you will end up with the image in the center. Here are few things to note:

Each trait image (and the final squirrel avatar) is of exactly the same dimension.
Apart from the background trait (which is the first trait), every other trait image has a transparent background.
The trait images must be stacked in order to get the correct squirrel avatar (i.e clockwise from top-right).
The trait images are drawn in such a way that their positioning makes sense with respect to all other traits.
We can swap any trait with another trait of the same category (for instance, a red shirt for a blue shirt). Therefore, in this case, if we had 10 traits for each category of trait, we could theoretically produce 100 million distinct squirrels.

Therefore, the artist’s job is to create multiple images of various trait categories. You can have as many or as few trait categories as you want. Do keep in mind though that the number of possible combinations increases exponentially with the number of traits categories.

In the Scrappy Squirrels project, we created 8 trait categories.

Each trait category had a varying number of trait images. For instance, we had 11 different shirts to work with.

Now, it’s your turn. You will need to decide on trait categories that you want to work with and generate trait images for each category. Make sure they satisfy the conditions mentioned above (should be of the same dimension, should be correctly positioned, etc). Also, make sure you name the trait images appropriately. What you name your image is what will appear in the metadata file.

Once you are done with this, we are now ready to use the library to generate our collection automatically! If you are not an artist (or do not have access to one), don’t worry! We have some sample images that you can play around with.

NOTE:

At present, the library is only capable of handling PNG images. We will be adding support for other media types soon.

Download repository and install required packages

Our generative art library is available for free on GitHub. Go ahead and clone it.

Once you’ve cloned the repository, open your Terminal or Command Prompt, and run the following command:

pip install Pillow pandas progressbar2

Running this command will install three important Python packages that our library depends on:

Pillow: An image-processing library that will help us stack trait images.
Pandas: A data analysis library that will help us in generating and saving our image metadata.
Progressbar: A library that will tell us about progress and ETA when the image generation takes place.

Add your custom assets

In the generative-art-nft repository that you downloaded, you will see that there is an assets folder. If you have your custom trait artwork available with you, go ahead and replace the contents of this folder with your assets. In our case, our assets folder had 8 subfolders representing categories named appropriately (see above), and each subfolder had trait images of that particular category.

If you do not have custom artwork, leave the default assets folder as is.

Configure the config.py file

This is the last (and perhaps, the most important step) before we can generate our avatar collection. Open the config.py file and fill it up according to the instructions below.

The config file consists of a single Python variable called CONFIG. CONFIG is a Python list (encapsulated by []). It contains a list of trait categories in the order that they need to be stacked. The order here is extremely important. Here is a sample configuration.

CONFIG = [
    {
        'id': 1,
        'name': 'background',
        'directory': 'Background',
        'required': True,
        'rarity_weights': None,
    },
    {
        'id': 2,
        'name': 'body',
        'directory': 'Body',
        'required': True,
        'rarity_weights': 'random'
    },
    {
        'id': 3,
        'name': 'eyes',
        'directory': 'Expressions',
        'required': True,
        'rarity_weights': None
    },
    {
        'id': 4,
        'name': 'head_gear',
        'directory': 'Head Gear',
        'required': False,
        'rarity_weights': None
    },
    {
        'id': 5,
        'name': 'clothes',
        'directory': 'Shirt',
        'required': False,
        'rarity_weights': None
    },
    {
        'id': 6,
        'name': 'held_item',
        'directory': 'Misc',
        'required': True,
        'rarity_weights': None,
    },
    {
        'id': 7,
        'name': 'hands',
        'directory': 'Hands',
        'required': True,
        'rarity_weights': None,
    },
    {
        'id': 8,
        'name': 'wristband',
        'directory': 'Wristband',
        'required': False,
        'rarity_weights': [100, 5, 5, 15, 5, 5, 15, 15, 5, 1]
    },
]

Each trait category is represented as a Python dictionary (encapsulated by {}). All that needs to be done is define these trait category dictionaries in order in the CONFIG list.

A trait category dictionary has 5 keys that it needs. These are id, name, directory, required, and rarity_weights. When creating a new layer (or replacing an existing one), make sure all these keys are defined.

This is how you go about assigning value to each key.

id: The layer number. For instance, if the body is the second trait category (or layer) that needs to be stacked, it will have an id of 2. Please note that layers must still be defined in the correct order.
name: The name of the trait category. This can be anything you choose it to be. It will appear in the metadata.
directory: The name of the folder inside assets that contain images of that particular trait category.
required: If this category is required for every image. Certain trait categories (like background, body, and eyes) must appear in every avatar whereas certain other categories (like headgear, wrist band, or clothes) can be optional. We strongly recommend that you set the first layer’s required value to true.
rarity_weights: This category will determine how common (or rare) your traits are going to be. Check the next section for more details.

Configuring rarity weights

The rarity_weights key can take three values: None, ‘random’, or a Python list. Let’s explore each value one by one.

None

If you set the rarity_weights value to None, each trait will be assigned an equal weight. Therefore, if you have 5 traits, each trait will appear in roughly 20% of the avatars.

In case required is False, it will be equally likely to not get that particular trait at all. In the previous case, if the required property was set to false, then each trait would appear in roughly 16.6% of the avatars. Another 16.6% of avatars would not have that particular trait at all.

‘random’

Setting rarity_weights to ‘random’ (note the parenthesis) would randomly assign weights to each category. We strongly recommend you do not use this feature. Always resort to either equal or custom user-defined rarity.

List

This is probably the most common way of assigning rarity weights.

The first thing to do is to go to your trait category folders and sort the trait images by Name. For instance, sorting the Wristbands folder will yield this for us:

You can see that we have 9 different kinds of wristbands. Now, we need to define a Python list (encapsulated by []) where each number represents a weight assigned to a particular trait in ascending order.

If required is set to True, then the number of weights should be equal to the number of traits for that category. If required is set to False, then the number of weights should be equal to the number of traits plus one.

In our case, if wristbands were required, we would define nine weights in the list and if it wasn’t required, we would define ten weights. In the latter case, the first weight would be the weight associated with not having the wristband at all.

Let’s take a look at the rarity_weights we defined for Wristbands.

[100, 5, 5, 15, 5, 5, 15, 15, 5, 1]

Since wristbands aren’t required, we have set ten weights (nine plus one). The first weight is the weight associated with not having a wristband at all. The second weight is associated with the Cheetah band, the third weight is associated with the Giraffe band, and so on. Note the alphabetical order here.

The higher the weight, the more common a particular trait is. For instance, Cheetah has a weight of 5, and not having a band has a weight of 100. This means that having a Cheetah band is 20 times rarer than not having a band at all.

Generating the collection

Once you’ve configured the config.py file, it is now time to generate your collection. Open up your Terminal (or Command Prompt) and navigate to the generative-art-nft folder (using the cd command).

Now, run the following command:

python nft.py

Running this command will initiate the image generation program. It will first check that the config.py file is valid. Next, it will tell you about the total number of distinct possible combinations.

It will then ask you how many avatars you’d like to create. I suggest creating 20% more than what you want to create so you have plenty left over even after the removal of duplicates. In our case, we chose to create 12,000 avatars although we wanted 10,000. It will then ask you to name the collection, and will then begin the generation process.

It took me approximately 30 minutes to generate 11,957 avatars (after removing duplicates). The images and their related metadata will be available in the output folder.

The images folder will look something like this (note that this is only a sample and not the final squirrels that we generated).

The metadata file is a CSV file that you can import into Excel and analyze (for things like which trait is the rarest, which trait combination is the most common, avatar rarity ranking, etc.)

Conclusion

And there you have it! You have generated your very own avatar collection.

So are we now ready to launch the next big NFT project? Not quite. You will need to upload these images to IPFS, allow your users to mint them into NFTs, and create community and buzz around your project.

Some of these words sounding alien? Don’t worry. We will be launching tutorials on the aforementioned topics very soon. Do join our Discord for the latest updates.

About Scrappy Squirrels

Scrappy Squirrels is a collection of 10,000+ randomly generated NFTs. Scrappy Squirrels are meant for buyers, creators, and developers who are completely new to the NFT ecosystem.

The community is built around learning about the NFT revolution, exploring its current use cases, discovering new applications, and finding members to collaborate on exciting projects with.

Join our community here: https://discord.gg/8UqJXTX7Kd