DEV Community: Jarrod Watts

zkEVMs and the Race to Scale Ethereum

Jarrod Watts — Tue, 21 Feb 2023 01:04:58 +0000

In the past week, the race to launch an EVM-compatible ZK rollup has been heating up:

Polygon announced the launch date for their zkEVM mainnet
zkSync launched their zkEVM mainnet (just two days later!)

Why's this happening? WTF is a zkEVM? How do I use one?

Let's dive into it.

Wait, what's wrong with Ethereum?

Ethereum Mainnet is able to process roughly 15 transactions per second. We all know what this means; huge gas prices and long finality times, leading to a grim user experience.

Depending on how deep down the rabbit hole you are at this point, you may already be familiar with solutions to address this; sidechains, layer 2s, rollups... all that good stuff.

These were all built because Ethereum is currently too popular for what it is capable of handling. Despite this, the Ethereum Foundation has agreed they are not going to sacrifice security/decentralization to improve scalability.

This balance between decentralization, security, and scalability is known as the scalability trilemma. The long-term vision of Ethereum is to achieve all three of these qualities.

Why should we improve scalability?

Scalability refers to how well Ethereum can handle the demand for transactions to be processed. If more transactions can be processed faster, two things happen:

Gas prices go down
Finality (how fast your transactions are finalized) gets faster

So, if we're not going to sacrifice decentralization, how do we make Ethereum more scalable? There are multiple different solutions that are either already being used today, in the research/testing phase, or recently shipped to mainnet 😉.

Let's explore some of the existing solutions first, why they have problems of their own, and then dive into ZK EVMs as the potential "final boss" of scaling solutions.

What's been built to address this so far?

Most solutions built to address the scalability of Ethereum usually come with some kind of sacrifice in the other two qualities in the scalability trilemma.

"it scales better... buuuuuut <insert downside here>", is usually how it goes*.*

Let's take a closer look at each of them.

Sidechains

A sidechain is a completely separate blockchain from Ethereum, with different histories, roadmaps, and even consensus algorithms.

In order for a side-chain to actually be a side-chain, it is required to have a two-way bridge connecting it with Ethereum Mainnet, where data can be transferred between the two chains.

Polygon's PoS (proof-of-stake) is the most popular example of a sidechain.

Polygon PoS boasts a ~10,000x lower gas fee per transaction, and ~450x increase in transactions per second than Ethereum. Polygon PoS is awesome. Some of the biggest brands in the world have chosen Polygon as their partner; Adidas, Meta, Stripe, Reddit, and more.

However, sidechains sacrifice some measure of decentralization or security to achieve this higher throughput.

You can dive deeper into the risk assessment of scaling solutions on sites such as L2BEAT. For example, if we take a look at Polygon PoS, we can see this:

In addition, despite these sacrifices, Polygon PoS has had struggles with scalability several times in the past.

For example, in 2022, a play-to-earn game called Sunflower Farmers sent gas prices skyrocketing after the game took up over 40% of the network's gas fees.

// Detect dark theme var iframe = document.getElementById('tweet-1478613172487602179-536'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1478613172487602179&theme=dark" }

More recently, transactions were failing from users' wallets due to incorrect gas estimations, as a result of the high demand on Polygon PoS.

// Detect dark theme var iframe = document.getElementById('tweet-1626195644573425665-847'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1626195644573425665&theme=dark" }

Rollups

Rollups are different from sidechains in the sense that they're not "separate" from Ethereum. Instead, they publish transaction results onto Ethereum mainnet; allowing them to derive the full benefits of Ethereum's security in the process.

Rollups work by allowing operators to bundle multiple off-chain transactions together outside the main EVM, and then submit them all together to Ethereum; achieving 10 to 100 times improvements in terms of scalability.

On a technical level, these batches are submitted to a "rollup" smart contract that is stored on Ethereum mainnet; which keeps track of the rollup's state.

There are two kinds of rollups that exist today:

Optimistic rollups
Zero Knowledge (ZK) Rollups

A bridge allows you to transfer funds or data between Ethereum mainnet and a rollup.

Optimistic Rollups

Optimistic rollups such as Optimism and Arbitrum One are called "optimistic" because they assume the transactions that they roll up are valid by default.

They don't post any proof that the transactions are valid to Ethereum. Instead, transactions are "innocent until proven guilty", which includes a fraud-proving scheme that enables the detection of invalid transactions.

A "challenge period" is available for parties to contest the results of a rollup transaction by submitting a fraud-proof that can see whether or not a fraudulent transaction took place in that rollup.

If one is detected, the transactions are re-executed and the state of the rollup is updated. The party who submits the fraudulent transactions incur a penalty, creating an incentive mechanism within the ecosystem.

Okay, this sounds great. What's the downside?

Because of this challenge period, (usually around 7 days), you must wait until the challenge period is over before you can perform this withdrawal to Ethereum mainnet over the bridge.

There's also some level of reliance that at least one honest person is checking for fraudulent transactions to challenge the state of the rollup.

ZK Rollups

Alright, we're almost at the juicy part.

ZK rollups, unlike optimistic rollups, do post validity proofs to prove the correctness of the changes they post to Ethereum mainnet.

These validity proofs are "zero-knowledge proofs"; meaning the details of the statement that the rollup provides can be proven as true, without revealing the actual contents of that statement, using either zk-SNARKs or zk-STARKs.

Learn more about how validity proofs work in zk-rollups.

This removes the requirement for a challenge period, as the transactions are provably true as soon as the rollup contract verifies the validity proof. This means you can withdraw funds from ZK rollups to Ethereum mainnet without waiting!

Awesome, but what's the catch?

Unlike the other solutions we've talked about so far, ZK Rollups are not compatible with the EVM. This means you can't just point your Solidity contract at a ZK Rollup and ship it, which you can do with all of the other solutions we've described.

Whereas, with other solutions, you can simply change the URL of your deployment script and deploy the exact same code to Ethereum, Polygon PoS, Optimism, Arbitrum, etc.

That's the catch. You cannot do this with ZK Rollups... Until now!

Enter, zkEVMs.

What is a zkEVM?

The main reason ZK rollups are not utilized is that they have not been EVM-compatible in the past, making it extremely difficult to actually build anything on them.

If I've done a good job explaining things so far, the name "zkEVM" is hopefully self-explanatory to you... A zkEVM is a zero-knowledge rollup, that is EVM compatible.

zkEVMs enable all the benefits of a ZK Rollup, with the same developer experience of building on any other EVM chain like Polygon or Ethereum. Combining the best of both worlds, and potentially providing an answer to the scalability trilemma.

This technology unlocks all existing web3 dapps to simply change their deployment scripts to a different RPC URL and ship directly to the zkEVM, exactly the same way they do now.

zkEVMs handle the batching of transaction execution and post cryptographic proof that the result of those transactions is correct to Ethereum mainnet, all while maintaining EVM compatibility.

This means that every smart contract on Ethereum or Polygon PoS can now also be deployed to a zkEVM. Drastically improving the scalability of the smart contracts and the dapps that use them.

"In the medium to long term, ZK rollups will win out in all use cases as ZK-SNARK technology improves." - Vitalik Buterin

How do I build on a ZK EVM?

With all of the hype and releases of ZK EVMs, how do you actually build on one?

At thirdweb (where I currently work), we just shipped support for any EVM chain, including all the zkEVMs such as Polygon zkEVM, zkSync, Scroll and more.

Consider checking out the below guide I helped review by my awesome colleague and friend @Avneesh Agarwal, which shows you how to:

Add a ZK EVM network to your wallet
Bridge funds from Ethereum to the ZK Rollup
Deploy your Solidity smart contract to a ZK EVM

How to Deploy a smart contract to Polygon zkEVM Testnet

Learn how to create and deploy a smart contract to the Polygon zkEVM testnet. Write a smart contract in solidity and deploy using thirdweb.

blog.thirdweb.com

Or check out this 3-minute video to shipping an NFT collection on Polygon's zkEVM:

// Detect dark theme var iframe = document.getElementById('tweet-1627520959854022656-129'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1627520959854022656&theme=dark" }

Wrapping Up

That's it! I've tried my best to condense the past few weeks of reading about Ethereum scaling solutions into a 5 minute read for you :)

What do you think? Are zkEVMs the holy grail for scaling Ethereum? Or are we just getting started? Let me know!

If you enjoyed this article, there'll be many more just like it coming soon. Consider following me to get notified when those are released!

How Account Abstraction Will Change Web3 UX Forever

Jarrod Watts — Tue, 24 Jan 2023 01:09:16 +0000

In this post, we'll explore the issues with UX in the current web3 landscape, and dive deeper into how a proposal known as account abstraction provides a potential solution to several of the biggest problems we have today.

The reality is, a poor UX is a significant drawback to building your application in a decentralized manner. While there are many solutions actively being worked on to address the issues, account abstraction is arguably the most promising.

It's an exciting paradigm that will allow anybody to interact with dapps; not just web3 enthusiasts, and is coming to reality with the latest Ethereum Improvement Proposal EIP-4337.

Let's dive into it!

Ethereum Accounts & Transactions Recap

Let's get through the boring stuff first. To understand account abstraction, we first need to understand what an account actually is when talking about Ethereum.

What Are Ethereum Accounts?

Ethereum has two different types of "accounts":

Contract Accounts
Externally Owned Accounts (EOAs)

You can think of a contract account as code (smart contracts) living on the blockchain that defines how the account behaves, and think of EOAs as a person (although a person could have many EOAs).

You probably are already familiar with EOAs. Your MetaMask wallet is an EOA. EOAs are made up of a cryptographic pair of keys: public and private keys that control account activities.

Contract accounts, however, don't have a private key. They're smart contracts that are controlled by the logic of the code within them; they're not controlled by a user.

The key takeaway here is that code defines what contract accounts do, and users control what EOAs do. This matters because smart contracts have the capability to do anything you can write in code, whereas EOAs can basically just sign transactions.

What Are Ethereum Transactions?

Alright, so that's accounts. What about transactions?

Every time you want to write information to the blockchain, such as transfer tokens, or mint an NFT, a transaction needs to occur. Transactions need to be signed by an EOA, and an EOA also has to pay the associated gas fees.

A transaction is initiated by an EOA, and can be sent to either:

Another EOA, for example, an EOA transferring ETH to another EOA.
A contract account, for example, minting an NFT from a drop.

How Web3 Works Today: EOAs & A Poor UX

Performing actions on the blockchain today is typically slow and tedious. Every time you want to write new information to the blockchain, you sign a transaction from your EOA to do so.

Once you're familiar with the process, this becomes the standard experience.

For new users, however, it's a nightmare.

The process of starting from scratch and interacting with a web3 application for the very first time is enough to put anyone off from entering the space, and that's just the beginning.

Here's a step-by-step experience that a new user goes through to perform their first action on a decentralized application from a fresh EOA:

This experience is brutal for any new user, tech-savvy or not. But it doesn't stop there, the initial setup is just the beginning of the user's concerns when using EOAs.

EOAs Are Extremely Risky

You're likely already familiar with somebody you know losing access to their EOA by either accidentally sharing or losing access to their private key. Some examples:

The level of responsibility you have with traditional EOAs is dangerously high.

There's even a saying for it: "not your keys, not your crypto"; referring to the fact that if somebody else ever has your private key at any point (such as a centralized exchange), they have the power to control your funds; this point has been proven countless times in the past.

The harsh reality is that private keys are easy to lose and impossible to recover.

EOAs Have Limited Capabilities

As we touched on earlier, EOAs are very limited in their capabilities.

From your EOA, you're usually performing one of two typical actions:

Submitting a transaction to transfer tokens to another EOA
Submitting a transaction that executes a function on a contract account

Whoever has the private key can sign messages and initiate any transactions the EOA can handle. Knowing the private key of an EOA gives you the power to perform everything that an EOA is capable of. It's all or nothing.

EOAs Will Never Enable Mainstream Adoption

In the real world, losing your credit card doesn't mean you are completely doomed.

There are rules in place that allow you to do things like set payment limits, stop transactions, detect fraud, change funds to a new account, only allow funds to be transferred under certain conditions, etc.

In web3, if you make one mistake, your entire account is compromised and unrecoverable. EOAs even compared to centralized stores of currency is... 💩.

We've dunked on EOAs enough, let's finally discuss the solution.

What Is Account Abstraction?

Account abstraction is the proposal to allow users to use smart contract wallets instead of EOAs. This completely removes any need for users to use EOAs in order to perform transactions.

But why? What do contract accounts do that EOAs can't?

Smart contracts are infinitely more flexible in their capabilities than EOAs. Each smart contract can define different rules and configurations within its code.

Some examples of use cases can be seen below:

Use Case	EOAs	Contract Accounts
Permission controls	Private key grants full access to everything.	Define a list of tiered permission levels. e.g. Require 3 out of 5 signers to approve a transaction.
Batch transactions	Each individual action requires a separate signature.	Capable of batching transactions together; e.g. approving a token transfer and transferring a token in the same operation.
Account Recovery	Loss or exposure of private key means full loss of control over the wallet.	There is no private key. You can write any arbitrary logic in code that allows you to recover the funds in the wallet.
Transaction limits	Any transaction your wallet signs is what occurs. You cannot restrict anything.	Write any logic to control how funds can be transferred. E.g. a function to halt transactions to other addresses while you recover your account.

These are just a few of the capabilities that contract accounts offer over traditional EOAs. The key thing is; contract accounts are code.

This means a*nything* you can write in code is therefore possible in a contract account.

History of Account Abstraction Proposals

Okay, this sounds great. Why aren't we already doing this today? Before we answer that, let's quickly give a brief overview of the history of account abstraction proposals dating back to 2016, and explore why EIP-4337 is different.

2016: EIP-86 - Proposal allowing users to create "account contracts" that perform any desired signature/nonce checks instead of using the mechanism that is currently hard-coded into transaction processing.

2020: EIP-2938 - Proposal to create a new transaction with type AA_TX_TYPE. Transactions of this type are referred to as “AA transactions”.

2020: EIP-3074 - Proposal allowing users to delegate control of their EOA to a smart contract. Would allow any EOA to act like a smart contract wallet without deploying a contract.

None of these proposals have been merged into Ethereum. They are all currently in the "stagnant" category; meaning they have been inactive for a period of 6 months or greater.

Part of the reason for these proposals not being merged is that they require consensus-layer protocol changes to the Ethereum network.

Until 2021, when EIP-4337 was proposed; account abstraction on Ethereum without a consensus layer change required!

EIP-4337: Account Abstraction Using Alt Mempool

EIP-4337 introduces a *"*pseudo-transaction" object called a UserOperation; a structure that describes a transaction to be sent on behalf of a user.

User Operations go into an "alt mempool"; which is essentially a waiting room for storing information on unconfirmed transactions.

Nodes on the Ethereum network can choose to act as a "bundler". Bundlers pick up user operations from the mempool, and package multiple user operations into a single transaction known as a "bundle transaction".

Once they create a bundle transaction, they send it to a global "singleton" smart contract known as the "EntryPoint". There is only one EntryPoint smart contract on the entire blockchain. The bundler calls a function on the EntryPoint smart contract called handleOps.

This function receives the bundle transaction, and calls a special function on each account: validateUserOp. Each smart contract wallet must implement this function.

validateUserOp should verify the operation’s signature, and pay the fee if the account considers the operation valid, before continuing to execute the operation.

Each smart contract wallet also must implement a second function: expected to be called "execute" to actually perform the operation that is sent in by the EntryPoint contract.

A simplified flow of this can be seen below:

Why Does This Matter?

Contract accounts are the next evolution of wallets required to provide a much-needed improvement to the UX of web3.

The possibilities are really endless for what this change enables:

Creating wallets for your users under the hood when they sign up for your app
Session keys for web3 games (allow any X transaction for Y amount of time without the need for signatures on each transaction)
Team wallets to use decentralized applications with tiered permissions

A grandma could be collecting NFTs and not even know what the blockchain is. Account abstraction enables everybody to use web3; not just tech enthusiasts.

Wrapping Up

In this post, we've outlined:

The fundamental concepts of accounts and transactions on Ethereum.
How EOAs fall short in terms of web3 user experience.
What account abstraction does to solve it and how it works under the hood.

Account abstraction is a game changer for web3 and bringing decentralized applications to a mainstream audience.

The power to use smart contracts as your wallet brings endless possibilities and EIP-4337 is the latest proposal of account abstraction that doesn't require a consensus-layer change.

Thanks For Reading!

I appreciate you making it this far! 🙏

If you enjoyed this content, consider following me for more!

How to ACTUALLY Become a Web3 Developer in 2023

Jarrod Watts — Fri, 06 Jan 2023 06:13:43 +0000

This is an opinionated guide to becoming a web3 developer in 2023.

I'll outline the exact steps that I personally took to land a role as a developer relations engineer at thirdweb; a suite of developer tools for building in web3.

Unlike other roadmaps, I'm not going to give you 300 things to learn and get you stuck in tutorial hell. This is an actionable, sequence of technologies for you to learn, including the exact resources I found most helpful throughout my journey.

Let's dive into it! Below is a preview of each layer of the stack we'll be covering.

Important Disclaimer (READ THIS)

Consuming resources alone will never teach you how to become a developer.

Every dev has to constantly fight their own battles on the journey to understanding how to code, and put together the pieces of the gigantic puzzle along the way.

As soon as you know how to START building, exit the roadmap and go at it alone. Just try to build something. It's going to suck. And that's the point!

Come back to the resources to fill in the gaps in your knowledge as you get stuck; learn what tools are available for you to use that solve your problems with the resources in this guide.

Every project you make will be better than the last, and you'll soon be embarrassed by your old code.

DO NOT just consume these resources, they are only there to help point you in the right direction in a logical order as you actually build your own projects.

It's not going to be easy, but it is worth it. Buckle up and let's get started!

The Roadmap

We're going to cover a lot of topics in this roadmap, and I'll provide you with resources that I personally used to develop my understanding at each step of the way. Here's a quick preview of some of the tools we'll cover:

The Fundamentals: HTML & CSS

Every website consists of three things:

HTML: Structure of elements on the page

CSS: Style of elements on the page

JavaScript: Interactivity of elements on the page

Any application you build, no matter what technology you use, is eventually transformed into these three languages and served to a user on a web page.

Hence it's an important foundational piece of knowledge to understand the very basics of HTML and CSS first before diving into any "programming" (adding interactivity or logic to your application).

HTML & CSS

CS50 is Harvard's introductory course to computer science. It's an outstanding resource taught by the best lecturers in the world. I have taken multiple of their free online courses including their previous years' CS50 course and cannot recommend it enough.

Below is lecture number nine (starting at index 0) of the course that focuses on HTML, CSS and JavaScript. It teaches you the fundamentals of how web pages work and introduces how the three languages work together to create interactive websites.

Even if you already know HTML and CSS, you'll be surprised at how much you learn from these lectures by going back to basics and gaining a deeper understanding of the fundamentals.

JavaScript

Picking up the basics of HTML and CSS is significantly easier than learning JavaScript; which is a behemoth in comparison; but also a lot more fun!

First, you need to learn the absolute basics of programming before diving deeper into JavaScript itself. This includes concepts key to any programming language; variables, functions, loops, and data structures.

A relatively concise resource that will teach you these basic fundamentals is the below video, "JavaScript Tutorial For Beginners".

The video above is just an example of beginner-friendly content to understand the basics of JavaScript. There are plenty of others out there and I encourage you to learn as much as you need before advancing further into this roadmap.

Here are some more great interactive resources that you can use to learn as a beginner:

Optional (For Now): Computer Science Fundamentals

JavaScript is beginner-friendly and abstracts away many complexities of programming; it's designed so that you can hit the ground running quickly.

If you are willing to spend significantly more time learning the fundamentals of computer science, consider watching the full playlist of lectures for CS50 2022; which is ~20 hours total.

My personal opinion is that it's better to come back to these fundamentals later and start building something as soon as possible.

I personally didn't learn these computer science fundamentals in detail until 1-2 years into working as a professional software engineer (which might sound crazy, I know). Again, these are my personal opinions and others will disagree with this.

Advanced JavaScript

Here's where the learning curve reached a steep point for me.

The resources I'm about to share may feel overwhelming at first; it took me several re-watches and many, many pages of notes to start to understand these concepts.

How JavaScript Really Works

The below video goes deep into the nuances of JavaScript and how the magic of the language works under the hood! 🧙

Topics like scope, closures, and prototypical inheritance are funnily enough the topics I've been asked about several times in job interviews over the past few years.

This is another CS50 lecture from 2018, and is still one of my personal favourite resources for learning JavaScript to this day!

Asynchronous JavaScript

The subsequent lecture in this playlist is also quite complex but covers incredibly important topics for understanding JavaScript at a deeper level. You'll be introduced to some of the more modern features of JavaScript introduced in ES6 such as callbacks, promises, and asynchronous functions.

(Optional) Paid Course: "ES6 for Everyone!" by Wes Bos

An additional resource I recommend (if you can afford it) is the "ES6 for Everyone!" course by Wes Bos. It's an excellent interactive course that teaches you a variety of super helpful syntactic sugar that are part of the later releases of ECMAScript.

It's not essential, but Wes is a great teacher and the course is a fun way to learn the more efficient ways of doing things in JavaScript.

This course is very beginner friendly and will help you write more modern Javascript.

(VERY Optional) Paid Course: Master the Coding Interview

As you're on your journey and are building your projects, some code you write is not going to be as efficient as it could be.

A paid course that taught me a tremendous amount about writing better code is the "Master the Coding Interview: Big Tech (FAANG) Interviews" course by Andrei Neagoie.

The title of the course is a bit clickbaity, but it teaches you almost everything there is to learn about data structures and algorithms; with 30 interactive questions for you to go through; all in JavaScript!

For me, this was extremely hard and took me many months to get through; which is why I put the "very optional" tag on this course. It's an amazing resource that I recommend you take at some point on your journey, but if you're a beginner it's likely going to be too hard for you.

React - Building User Interfaces

If you've started building your project by this point, you've probably realised that it is difficult to build an application by writing HTML, CSS, and JS alone.

Developers have come up with many different libraries and frameworks to address these issues over the past decade; jQuery, Angular, Svelte, Vue... the list goes on!

One library has come out on top; React, which is:

The most used frontend JS framework of 2022.
The framework that most developers "want" to use in 2022.
The most in-demand frontend framework for landing a job (too lazy to get a source for this stat, so... "probably" 😄).

React uses a syntax called JSX to combine writing your UI structure and design with your "interactivity" in the same location:

A great resource to understand the "why" of React is this CS50W lecture on user interfaces:

Get Started with Next.js

Next.js documentation is absolutely brilliant. Lee Robinson and his team of DX engineers have written fantastic, interactive documentation to help you learn Next.js and quiz your knowledge along the way.

For this reason, I recommend running through the interactive documentation first; and then diving into creating your first Next.js application with their CLI.

TypeScript

Another hot take on this article 🌶️: Start using TypeScript ASAP! JavaScript is a great language for beginners, but this is a double-edged sword. Part of the reason it's good for beginners is that it gives you a lot of freedom to write 💩 code and it doesn't complain about it!

TypeScript can be a real pain in the 🍑 at first, but once it clicks, you'll never want to go back. More and more developers and developer tools are defaulting to TypeScript and for good reason; type safety makes your code significantly less likely to have bugs!

My suggestion: turn strict mode off at the beginning. Use the any type whenever you get completely stuck and don't know what to do. These are bad practices in reality, but will help you onboard to TypeScript without wanting to break your keyboard.

As you write more and more code with TypeScript and pick up more tricks, you'll feel comfortable enabling strict mode and using the any type more sparingly; until you eventually have complete type safety in your codebase and look at JavaScript in disgust!

Styling

There are a number of options for you to build out more beautiful applications that are ultimately just different ways of abstracting CSS so that it's ... well basically CSS but easier.

The general consensus going into 2023 is that Tailwind CSS is the gold standard for adding styles to your application. I personally like to use a tool called Material UI that comes with pre-built components; however, most people don't agree with me on this.

A great video weighing up the different options available and their pros and cons is "The Best of CSS" by Theo:

Short answer: If you don't already know and love a UI library, pick Tailwind CSS.

Blockchain Fundamentals

If you don't already have knowledge of what a blockchain or smart contract is, a helpful resource for beginners is Patrick Collins' blockchain course.

I suggest you watch the first 2 hours of the 32-hour course which introduces the core concepts of blockchain, smart contracts and web3. You can pick and choose the other areas of the course that interest you as you wish!

Understanding the Web3 Stack

An introductory video I recommend watching is "Defining the Web3 Stack", by @Nader Dabit; which outlines the equivalent web3 tech stack compared to a traditional "web2" application.

As an updated graphic to Nader's talk in 2021, I have provided my thoughts on the tech stack of a web3 application below:

There are a lot of moving pieces to consider when building a web3 application. There are a plethora of tools available to help you build different aspects of your decentralized application, and it's up to you to learn what you like best.

Of course, I'll provide my recommendations here that I have come to after experimenting with a number of these tools in the past year.

Building a full stack web3 app "the hard way"

Arguably the best resource I consumed when I was entering the web3 space was @Nader Dabit's "Full Stack NFT Marketplace" video tutorial. You'll learn how to build almost every aspect of a full-stack web3 application at a rapid pace, including:

NFT Collection smart contract
NFT marketplace smart contract
Smart contract development environment and testing
IPFS file uploads and downloads
Frontend technologies & Next.js to build a web3 application
RPC nodes and IPFS Gateways

This might feel like quite the jump from the previous step, and you might not understand everything in this video immediately, and that's okay!

This resource taught me a tremendous amount about how the pieces of the web3 stack fit together and teach you how to build an epic project with modern technologies.

Extending Nader's Project

Something that really made me understand what was happening was adding more functionality to Nader's NFT marketplace project; specifically, adding a function to get an individual listing's information on the marketplace smart contract.

Adding this capability to the project might sound easy, but it tests to see if you really understand how the project is functioning; and is a great step to add on top of the build itself.

Why is this "the hard way"?

This resource introduces you to what I'd argue is a low-level abstraction of building a full-stack web3 app; it shows you every step of the process which is super important to understand.

However, I'd argue that the purpose of the video isn't to build a "production-ready" application in 2023. I say this because there are a large number of tools that have been released since mid-2021 (the time this video was made), that has abstracted away the complexity of building full-stack web3 applications significantly.

Let's quickly cover a few other core concepts and then dive into the more modern tools available to build web3 apps with.

RPC Nodes

To communicate to and from the blockchain, you need to use a node. Unless you want to run your own Node, you need to use a service provider such as Alchemy, Coinbase, or Moralis, (or thirdweb as we'll explain in the next section) to do so.

Below is a great resource outlining what an RPC Node is and why it's required to build web3 applications.

alchemy.com

Interesting Project: Lava Network

A project I am excited to see in 2023 is Lava Network; which offers a decentralized alternative to the RPC Nodes. Check it out if you are interested!

Decentralized Storage Solutions

Not all information needs to be stored on the blockchain. Storing data on the blockchain itself costs gas fees and has a significant storage limit; for this reason, a common pattern is to store your information "off-chain" and store the URL of that data on the blockchain instead.

Storage solutions exist that aren't stored "on-chain" but are still not controlled by a centralized service such as AWS or Google Cloud. The two prominent decentalized storage solutions solutions in 2023 are:

IPFS
Arweave

IPFS

Below is a concise summary of what IPFS is, how it works, and how you can integrate it into your applications using thirdweb (we'll talk more about this next).

To access data stored on IPFS on most browsers such as Google Chrome, you'll need to use an IPFS Gateway. There are a couple of options available for you here:

Public gateway (available for everyone, not very reliable)
Private gateways - using services such as Pinata or nft.storage for faster speed and higher availability, (again, or just use thirdweb as we discuss next).

Arweave

Another excellent video by Nader Dabit is available for you to understand Arweave and other aspects of the Arweave ecosystem such as Smartweave and Warp.

I should mention a lot of these technologies such as Arweave have grant programs if you are building with them; if you're looking for some funding this might be interesting to you.

thirdweb

Full disclosure: I work on the thirdweb team!

I used Nader's NFT marketplace video as a starting point for a freelancing project I was working on as I began to increase my skills in web3 development. I came to the realisation that building smart contracts is HARD!

I didn't have the confidence at this point to write a fully-featured, gas-optimized, bug-free marketplace smart contract for my clients' requirements; so I started to ask myself: "someone must have done this and open-sourced it somewhere RIGHT!?"

Well, turns out I was right!

I stumbled upon thirdweb shortly after it was released and discovered they had open-source smart contracts for NFT collections, marketplaces, and more.

I basically planned to just copy-paste their solidity smart contracts into my existing project and carry on my way 😂! Here's proof (don't tell Furqan):

But as I explored the product more, I discovered they had an SDK! I didn't have to use ethers anymore! They also have tools to connect users' wallets, and manage my IPFS storage for me! I didn't even need my smart contract code in my project anymore as they had a dashboard I could deploy it with.

I was able to remove SO MUCH of the code I wrote for my marketplace project and replace them with thirdweb tools that I ended up falling in love with the product; and applied for my current position at thirdweb a few months after completing my freelance work!

So, while I do get paid to advocate thirdweb's products, I do it from my heart, not from my ... wallet? 🥲 I was really out here using their tools before I joined the team.

Learning thirdweb

I've spent a lot of time refining the Getting Started flow of the thirdweb documentation to get you up and running from building a smart contract to building a front-end Next.js application in no time! So, my recommendation is to start there!

Alternatively, there is a getting started video that covers the same content:

Once you get the power of thirdweb's stack, you won't want to go back! 🤠 Since I joined, we have shipped even more features that make the web3 building process simpler:

Free IPFS gateway and IPFS rendering components in the SDK.
Free RPC included directly in the SDK (which can be overridden).
IPFS upload and downloads in React hooks with Storage.
React hooks for everything you can imagine on the frontend; for both user wallets and interacting with smart contracts.
Full Solidity SDK called "ContractKit" which is similar to OpenZeppelin.
An Explore page; for you to deploy the most popular smart contract standards.
Much more!

Deploy a smart contract with thirdweb and connect to it in your Next.js application and I promise you'll never want to go back to your old stack.

Other Web3 Frontend Libraries

So that I'm not completely biased, I'll also recommend you some of the other modern libraries available for you to build more robust frontends for your web3 apps.

wagmi

wagmi is a library of React Hooks for building EVM frontends. Much like the thirdweb React SDK, it has hooks for pretty much everything you can imagine and is significantly better than using ethers or web3.js alone.

The documentation is a great starting point for you to understand how to use it in your Next.js/React apps.

Rainbow Kit

RainbowKit is an excellent library for adding connect wallet capabilities into your application and supporting a variety of different connection options for your users.

Their documentation is concise and includes helpful short videos to get you up and running quickly.

Indexing Solutions

Some web3 applications require information that isn't directly available from any smart contract; such as what NFTs a wallet owns, or how many times an NFT has been transferred.

When it comes to indexing solutions, you can use The Graph; a decentralized solution, and again use Nader's resources to learn how to get started:

You might prefer to use SDKs or API endpoints to get your indexed information, and there are a number of popular solutions you can use, each with helpful resources and videos on their documentation:

These tools have similar capabilities with various pros and cons, you can use their documentation to explore which tool is right for you.

Smart Contracts

This might seem crazy that the smart contracts section is all the way down here. 🤯

The reason I placed smart contracts after learning the full frontend tech stack is that you are often going to be building on top of smart contracts that other people have deployed already; such as Lens Protocol, or deploying gas-optimized, audited smart contracts that suit your needs such as those available on thirdweb Explore.

To land a job in web3 you don't need to be an expert in writing your own smart contracts. At thirdweb, we have a team that is dedicated to writing Solidity smart contracts and building out our Solidity SDK; the rest of our engineers understand the Solidity code; but aren't actively writing smart contracts on a daily basis.

This might be a hot take 🌶️🥵 but you should learn the details of building smart contracts after learning how to actually build stuff people interact with; which usually means you need some kind of frontend application skills.

Some people will disagree with that; as almost everything in web3 depends on the foundational layer of decentralized applications; which is smart contracts. I'm not saying it's correct, this is just the path that I personally took to learn web3.

There are many resources you can use to learn Solidity itself, such as:

CryptoZombies (interactive course)
Literally, just read the Solidity documentation 🥸

Object Oriented Programming

OOP. more like oof, am I right? 😑

Solidity is an object-oriented programming language to build your own smart contracts. If you know OOP principles you are already most of the way there to be able to write basic Solidity.

Usually, you don't see JavaScript used for object-oriented programming; other languages like Java, C#, or Python are better suited for this style of writing code.

To get the basics of OOP down, I recommend you consume as many resources as you need to to get the basic principles down. Below is an introduction to OOP in JavaScript that will help you get the core concepts:

OOP In Solidity

Once you know what OOP is, I recommend you return back to Patrick's video at this timestamp (chapter 3), to see how inheritance and overrides work in Solidity:

youtube.com

Using OSS Smart Contracts

Usually, you'll want to build some variety of ERC standards such as ERC20 fungible tokens, ERC721 NFTs, or marketplaces, with a twist that makes your project unique.

Now that you know how to utilize inheritance in Solidity, you can make use of libraries such as OpenZeppelin Contracts and thirdweb ContractKit to import core chunks of logic into your smart contracts; and customize them as you wish!

ContractKit

thirdweb's ContractKit has a vast array of plug-and-play smart contracts for you to extend, customize, and include in your own smart contracts; including ERC721, ERC1155, ERC20, staking, airdrop, and more 🤠!

Smart Contract Security

It is important to know the most common vulnerabilities of smart contracts, which again Patrick covers thoroughly in his 32-hour Solidity course in Chapter 18 at this timestamp.

youtube.com

There is also a detailed open-source repository outlining common attack vectors for smart contracts and historical exploits using these attacks:

kadenzipfel / smart-contract-vulnerabilities

A collection of smart contract vulnerabilities along with prevention methods

Smart Contract Vulnerabilities

A collection of smart contract vulnerabilities along with prevention methods

Access Control

Math

Control Flow

Data Handling

Unsafe Logic

Code Quality

View on GitHub

Conclusion

That's it! These are the resources I personally used to develop my knowledge in web3 and land a job as a developer relations engineer at thirdweb!

I'd like to reiterate that tutorials and resources alone will never be enough to become a dev. You need to get your hands dirty ASAP, come back to these resources as you run into problems in your project, and constantly fight battles on your own over many years to come.

The goal of this article isn't to give you months of resources to consume, it's here so you can come back to trusted sources of high-quality information as you build your own projects alone! 🦸

If you want to join a community of devs on your journey, jump into my community Discord server and introduce yourself! 👋

discord.com

Create a Discord Bot that Assigns a Role to NFT Holders

Jarrod Watts — Mon, 25 Jul 2022 06:25:21 +0000

In this guide, we'll set up a Discord bot that checks if a wallet has an NFT from a collection, and grants them a special role on our Discord server if they do!

Similar to Collab.Land, we'll ask the user to sign in with their wallet as well as their Discord account on our web application, and ask a bot we create to grant them a role on our server using the Discord API running on a Next.js API route.

You can grab the source code for this project using this link: https://github.com/thirdweb-example/discord-role-granter

Let's do it!

Creating a thirdweb app

To get started, we can use the thirdweb CLI.

npx thirdweb create

We'll be using TypeScript and Next.js for this guide; so give your app a name and select Next.js for the framework, and TypeScript for the language.

For this guide, we'll assume you already have a Discord server created and a role set up in the server. If you don't have one, go ahead and create one now and come back to this guide, because next up, we'll create a bot and invite it to our server!

Creating A Discord Bot

To create a Discord bot, head to the Discord Developer Portal and click on New Application, give it a name and click create!

Once it's created, head to the Bot tab, and click Add Bot.

Give your bot a username, and I'm unchecking the Public Bot field so that only we can invite our bot.

Scroll down to Bot Permissions and give our bot the Manage Roles permission:

It's important to note that you should only give your bot the roles it requires. If your bot token is compromised, other users can perform any actions you have permitted it to do.

Once you're ready, click Save Changes!

Now we're ready to invite our bot to our server!

Click OAuth2 > URL Generator on the sidebar:

Select bot and Manage Roles scopes.

Copy the Generated URL and open it in your browser.

Make sure it is the bot you expect, select the server you want to add your bot to and click Continue. It will ask you to approve this bot's permissions, you should see a prompt to authorize the bot for Manage Roles permissions:

Click Authorise, once successful, you'll see an Authorised window

And your bot will be added to your server - say hi!

Authenticating Users

To authenticate users with Discord, we'll be using the library `NextAuth

Create a new folder inside of pages called api, and within that, create another folder called auth, and within this auth folder, create a file called [...nextauth].ts!

bash yarn add next-auth

This is where we'll configure our NextAuth setup and allow people to sign in to our application using Discord.

Back in your Discord Developer Portal, copy across your Client ID and Client Secret into environment variables in your project, by creating a .env.local file at the root of the directory.

text CLIENT_ID=xxxxx CLIENT_SECRET=xxxxx

We also need to add a Redirect URL into our Application while we're here:

Now let's make our [...nextauth] API route look like this:

`ts
import NextAuth from "next-auth";
import DiscordProvider from "next-auth/providers/discord";
export default NextAuth({
// Configure one or more authentication providers
providers: [
DiscordProvider({
clientId: process.env.CLIENT_ID as string,
clientSecret: process.env.CLIENT_SECRET as string,
}),
],

// When the user signs in, get their token
callbacks: {
async jwt({ token, account }) {
// Persist the OAuth access_token to the token right after signin
if (account) {
token.userId = account.providerAccountId;
}
return token;
},

async session({ session, token, user }) {
  // Send properties to the client, like an access_token from a provider.
  session.userId = token.userId;
  return session;
},

},
});
`

You might notice we have some modifications to the data that gets returned inside these callbacks. We're doing this to add the user's ID into the token that gets returned by NextAuth, because we want to access that value when we try and grant this user the role (we'll need their ID).

To access NextAuth's hooks such as signIn, we need to wrap our application in the SessionProvider:

`jsx
import type { AppProps } from "next/app";
import { ChainId, ThirdwebProvider } from "@thirdweb-dev/react";
import { SessionProvider } from "next-auth/react";
import "../styles/globals.css";

// This is the chainId your dApp will work on.
const activeChainId = ChainId.Mumbai;

function MyApp({ Component, pageProps }: AppProps) {
return (

);
}

export default MyApp;
`

Now we're ready for users to authenticate to our application using Discord!

Let's create a folder called components and create a SignIn.tsx component within that folder. This component will ask the user to both:

Sign In With Their Wallet
Authenticate With Discord

In this component, three states can occur:

The user is connected to both wallet and Discord => We show them the main page.
The user is not connected to wallet => We ask them to connect their wallet.
The user is not connected to Discord=> We ask them to authenticate with Discord.

Once the user is in state 1, (has both wallet connected and Discord connected), we can show them a button that will run some code on our server to check if they own an NFT. If they do own the NFT, our Discord bot will assign them a role in our Discord server!

Let's write the code for these three states:

Imports and hook definitions

`jsx
import { useAddress, useDisconnect, useMetamask } from "@thirdweb-dev/react";
import { useSession, signIn, signOut } from "next-auth/react";
import React from "react";
import styles from "../styles/Home.module.css";

export default function SignIn() {
const address = useAddress();
const connectWithMetamask = useMetamask();
const disconnectWallet = useDisconnect();
const { data: session } = useSession();

// rest of the code here
}
`

State 1 - Both Wallet + Discord Connected

jsx // 1. The user is signed into discord and connected to wallet. if (session && address) { return ( <div className={styles.bigSpacerTop}> <a onClick={() => signOut()} className={styles.secondaryButton}> Sign out of Discord </a> |<a onClick={() => disconnectWallet()} className={styles.secondaryButton}> Disconnect wallet </a> </div> ); }

State 2 - Connect Wallet

jsx // 2. Connect Wallet if (!address) { return ( <div className={styles.main}> <h2 className={styles.noGapBottom}>Connect Your Wallet</h2> <p>Connect your wallet to check eligibility.</p> <button onClick={connectWithMetamask} className={${styles.mainButton} ${styles.spacerTop}} > Connect Wallet </button> </div> ); }

State 3 - Connect Discord

jsx // 3. Connect with Discord (OAuth) if (!session) { return ( <div className={${styles.main}`}>

Sign In with Discord

  <button
    onClick={() => signIn("discord")}
    className={`${styles.mainButton} ${styles.spacerTop}`}
  >
    Connect Discord
  </button>
</div>

);
}

// default return nothing
return null;
`

Back on our home page, let's change the logic to show the user the SignIn component when we can't find both an address and session:

`jsx
// index.tsx
import { useAddress, useSDK } from "@thirdweb-dev/react";
import { useSession } from "next-auth/react";
import SignIn from "../components/SignIn";
import type { NextPage } from "next";
import styles from "../styles/Home.module.css";

const Home: NextPage = () => {
const address = useAddress();
const { data: session } = useSession();
const sdk = useSDK();

return (

    {address && session && (
      <div className={styles.collectionContainer}>
        <button className={styles.mainButton}>Give me the role!</button>
      </div>
    )}
  </div>
</div>

);
};

export default Home;
`

We now have a page that prompts the user to connect their wallet, and then Sign In With Discord:

When you click the Connect Discord button, NextAuth handles the OAuth flow for us:

Once the user has connected both their wallet and Discord, we show them a button that says Give me the role!, we'll add some functionality to this button next!

Granting Discord Roles

To grant a role to the connected user, we are going to use the Discord API on behalf of the bot that we created. Specifically, we'll be hitting the Add Guild Member Role API endpoint:

To make requests from our bot, we'll need a token to act on its behalf. To generate a token, head to the Bot tab from your Discord Developer portal, and click Reset Token on your bot:

We then need to store this inside our environment variables as well securely:

text BOT_TOKEN=xxxx

Next, let's make another API route in our api folder called grant-role.ts.

Within this API route, we're going to grant a user the discord role if they own an NFT from our collection. This involves a few steps:

Authenticate the login payload of the user (ensure the user owns the wallet)
Check that wallet's NFT balance
Make a request to the Discord API to grant a role

Firstly, let's set up the barebones of our API route:

`ts
import { ThirdwebSDK } from "@thirdweb-dev/sdk";
import type { NextApiRequest, NextApiResponse } from "next";
import { getSession } from "next-auth/react";

export default async function grantRole(
req: NextApiRequest,
res: NextApiResponse,
) {
// Get the login payload out of the request
const { loginPayload } = JSON.parse(req.body);

// Get the NextAuth session so we can use the user ID as part of the discord API request
const session = await getSession({ req });

if (!session) {
res.status(401).json({ error: "Not logged in" });
return;
}
}
`

Authenticate the login payload

On the client, we're going to ask the user to sign in using the Authentication SDK. This requires the user to sign a message which generates a login payload; we'll be sending this in the body of the request.

`jsx
// Authenticate login payload
const sdk = new ThirdwebSDK("mumbai");
const domain = "thirdweb.com"; // This should be the domain name of your own website
// Verify the login payload is real and valid
const verifiedWalletAddress = sdk.auth.verify(domain, loginPayload);

// If the login payload is not valid, return an error
if (!verifiedWalletAddress) {
res.status(401).json({ error: "Invalid login payload" });
return;
}
`

This step ensures that the user owns the wallet that we are going to check. It prevents users from sending a wallet address that is not theirs to this API endpoint, and falsely granting them the role.

Check the wallet's NFT balance

We use the SDK to view the balance of the wallet address for token ID 0 of our ERC-1155 NFT collection.

`ts
// Check if this user owns an NFT
const editionDrop = sdk.getEditionDrop(
"0x1fCbA150F05Bbe1C9D21d3ab08E35D682a4c41bF",
);

// Get addresses' balance of token ID 0
const balance = await editionDrop.balanceOf(verifiedWalletAddress, 0);
`

Granting Users the role

Here, we make the request to the discord API to grant the user a role by using our bot token as the authorization header.

In order to do this, you'll need to create a role in your server, and copy both your server and role ID into the variables. You can learn how to do that from this guide.

`ts
if (balance.toNumber() > 0) {
// If the user is verified and has an NFT, return the content

// Make a request to the Discord API to get the servers this user is a part of
const discordServerId = "999533680663998485";
const { userId } = session;
const roleId = "999851736028172298";
const response = await fetch(
// Discord Developer Docs for this API Request: https://discord.com/developers/docs/resources/guild#add-guild-member-role
https://discordapp.com/api/guilds/${discordServerId}/members/${userId}/roles/${roleId},
{
headers: {
// Use the bot token to grant the role
Authorization: Bot ${process.env.BOT_TOKEN},
},
method: "PUT",
},
);

// If the role was granted, return the content
if (response.ok) {
res.status(200).json({ message: "Role granted" });
}

// Something went wrong granting the role, but they do have an NFT
else {
res
.status(500)
.json({ error: "Error granting role, are you in the server?" });
}
}
// If the user is verified but doesn't have an NFT, return an error
else {
res.status(401).json({ error: "User does not have an NFT" });
}
`

That's it for our API route, now we need to call this from our client!

Back on the index.tsx page, let's create a function called requestGrantRole inside the component and make a fetch request to this API endpoint.

`tsx
const sdk = useSDK();

async function requestGrantRole() {
// First, login and sign a message
const domain = "thirdweb.com"; // This should be the domain name of your own website
const loginPayload = await sdk?.auth.login(domain);

// Then make a request to our API endpoint.
try {
const response = await fetch("/api/grant-role", {
method: "POST",
body: JSON.stringify({
loginPayload,
}),
});
const data = await response.json();
console.log(data);
} catch (e) {
console.error(e);
}
}
`

And attach this function to our button:

tsx <button className={styles.mainButton} onClick={requestGrantRole}> Give me the role! </button>

That's it! We're ready to test it out!

Demo

Connect our wallet, authenticate with Discord, and sign in with Ethereum:

The grant-role API endpoint runs, granting the connected Discord user the role if they have an NFT from the collection:

We now have the role in our server!

Going to production

In a production environment, you need to have an environment variable called NEXTAUTH_SECRET for the Discord Oauth to work.

You can learn more about it here:
https://next-auth.js.org/configuration/options

You can quickly create a good value on the command line via this openssl command.

bash openssl rand -base64 32

And add it as an environment variable in your .env.local file:

NEXTAUTH_SECRET=<your-value-here>

Conclusion

We've made our very own Discord role granting application using thirdweb, the Discord API, and NextAuth!

You can check out the full code for this project on our GitHub:

https://github.com/thirdweb-example/discord-role-granter

For any questions, suggestions, join our discord at https://discord.gg/cd thirdweb.

Create an ERC-721A NFT Collection using thirdweb

Jarrod Watts — Wed, 20 Jul 2022 04:15:00 +0000

Introduction

In this guide, we'll use the Signature Drop
contract to create a collection of NFTs that follow the ERC-721A standard!

Compared to the regular ERC-721 standard, the ERC-721A implementation
optimizes the gas fees of the contract to enable cheaper gas fees for users when they are minting multiple tokens in one transaction.

The signature drop contract also enables Signature-based Minting
which allows us, (the admin wallet), to approve users' mint requests on-demand if they meet specific criteria, such as being a holder of another token!

Demo

Here's what we'll be doing in this guide:

Deploying the ERC-721A Signature Drop contract.
Lazy Minting our NFTs by batch uploading metadata files.
Creating a web application where users can claim NFTs.
Adding a special "Discount Claim" button where users who hold an NFT from another collection can claim an NFT for a discount!

Check out the demo here: https://signature-drop.thirdweb-example.com/

You can view the full source code below:

%[https://github.com/thirdweb-example/signature-drop]

Creating the Signature Drop Contract

To deploy one of thirdweb's Pre-built contracts, head to the dashboard and connect your wallet.

If you don't already have a wallet, learn how to get set up with MetaMask in our "Guide: Create a MetaMask Wallet"

From here, click the Deploy New Contract button -> Pre-Built Contracts -> Release a drop -> Signature Drop.

Here is where you can upload the metadata for the contract itself. This is the metadata that will show up on pages such as the OpenSea Collection page.

Give your contract a name, symbol, description, image, and configure royalty fees as you like! Here's how mine looks:

I'll be deploying to the Arbitrum Testnet as it
offers super-fast transaction approval times (which are great for testing purposes)!

When you're ready, click Deploy Now, and approve the Deploy Proxy transaction in your wallet.

You just deployed your very own ERC-721A NFT Collection!

Batch Lazy-Minting NFTs

In the Signature Drop contract, we lazy-mint all of our NFTs by uploading the metadata using the Batch Upload feature.

Click the Batch Upload button to get started.

Here, you'll be taken to a page where you can drag and drop your metadata and assets to upload them. You can use the example CSV and JSON files from the links on this page, or below:

Here is a preview of mine:

Once you've prepared the files, drag them all into the upload box on the dashboard:

This will allow you to preview your NFTs before lazy minting them.
Ensure the properties and metadata appear how you expect, as you won't be able to modify them after they have been uploaded.

Once you're happy, click Next:

You can then choose if you want to add a delayed reveal for your NFTs. For this guide, we'll leave it as Reveal upon mint and click Upload NFTs!

Configuring A Claim Phase

Claim phases are conditions that outline how, when, and who can claim NFTs from your collection; such as an allowlist, release date, or delayed reveal.

To add a claim phase, click the Claim Phases tab and then the Add Claim Phase button:

Here's where we can configure who can claim from this drop. I'm going to set the :

How much do you want to charge to claim the NFTs? to be 0.01
How many NFTs can be claimed per transaction? to be 1
How many seconds do wallets have to wait in-between claiming? to be Unlimited

Once you're happy, click Save Claim Phases!

Setting Up the project

We'll be using the thirdweb CLI to initialize our application using Next.js and TypeScript.

To create a new project using the CLI, run the following command:

npx thirdweb create

Give your application a name and the project will be initialized for us! Let's open the project up in a text editor now, I'll be using VS Code.

I'll be using the styles available in the source code,
feel free to copy these files into your project if you want to use the same styles.

If we take a look at our pages/app.tsx file, we have a configured activeChainId as Mainnet which is Ethereum Mainnet.

Since we deployed our contract on the Arbitrum Test network let's change it to:

// This is the chainId your dApp will work on.
const activeChainId = ChainId.ArbitrumTestnet;

Connecting to our contract

Now we're ready to interact with our signature drop smart contract from within our code, to do that, we'll use the useSignatureDrop hook from the React SDK.

On the index.tsx page:

const signatureDrop = useSignatureDrop(
  "0xBdEa6C9B18843cEA8262ead23767737512e452bC",
);

You can get your contract address from the dashboard:

Claiming NFTs

Since the wallet connection logic is already configured inside our application thanks to the thirdweb CLI, here's how our page looks now:

const Home: NextPage = () => {
  const address = useAddress();
  const connectWithMetamask = useMetamask();
  const disconnectWallet = useDisconnect();

  const signatureDrop = useSignatureDrop(
    "0xBdEa6C9B18843cEA8262ead23767737512e452bC",
  );

  return (
    <div>
      {address ? (
        <>
          <button onClick={disconnectWallet}>Disconnect Wallet</button>
          <p>Your address: {address}</p>
        </>
      ) : (
        <button onClick={connectWithMetamask}>Connect with Metamask</button>
      )}
    </div>
  );
};

export default Home;

The React SDK automatically uses the signer of the connected wallet when a user wants to perform an action on our smart contract such as claim an NFT.

Let's write the logic for that now. Firstly, the claim function:

async function claim() {
  const tx = await signatureDrop?.claim(1);
  console.log(tx);
}

And attach this function to a button:

<button onClick={claim}>Claim</button>

If we preview our application by running yarn dev from the terminal and visit http://localhost:3000/ we can see our claim button:

If you click the Claim button and approve the transaction, you can successfully mint the first NFT from the drop.

Now in the dashboard, we have a Claimed Supply of 1

That is the very basics of our minting page setup!

Claiming With Signature

The signature drop contract also allows users to claim using a signature generated by an admin wallet. This is a three-step process:

User requests a mint signature.
Admin wallet (on the server) approves (or denies) the claim request of the user based on any criteria the admin chooses and sends back a mint signature when they approve.
User uses the mint signature to claim NFTs from the signature drop.

This enables all kinds of possibilities for us, such as:

Restrictions of who can claim based on off-chain data
Discounts for users who meet some criteria (such as owning another NFT, or being part of a Discord server)

We're going to check if the wallet owns one of our thirdweb Early Access Card NFTs and offer them a free mint if they do!

Creating the API Route

Let's go back to our code, and under the pages folder, create an api folder. Within it, create a file called generate-mint-signature.ts.

Let's firstly create the basic structure of our API route:

import { ThirdwebSDK } from "@thirdweb-dev/sdk";
import type { NextApiRequest, NextApiResponse } from "next";

export default async function generateMintSignature(
  req: NextApiRequest,
  res: NextApiResponse,
) {
  // De-construct body from request
  const { address } = JSON.parse(req.body);

  // Next code snippet here
}

When we call this API endpoint, we'll be passing an address argument into the request body. In this API route, we de-structure that value so that we can use it when we generate the mint signature.

Since we're going to provide the NFTs for free to wallets that own one of thirdweb's Early Access NFTs, let's check that now.

To do that, we instantiate the thirdweb SDK with a read-only connection on the Polygon network and get the thirdweb-community NFT Collection using its contract address.

// Get the Early Access NFT Edition Drop contract
const polygonSDK = new ThirdwebSDK("polygon");
const earlyAccessNfts = polygonSDK.getEditionDrop(
  "0xa9e893cc12026a2f6bd826fdb295eac9c18a7e88", // this is the thirdweb-community NFT Collection address.
);

Then we can use the balanceOf function to check if the wallet that made this API request has any NFTs from that collection. Since it's an ERC-1155 collection, we check to see if they have a balanceOf any of the tokens in that collection in a loop:

// Check to see if the wallet address has an early access NFT
const numTokensInCollection = await earlyAccessNfts.getTotalCount();
let userHasToken = false;
// Check each token in the Edition Drop
for (let i = 0; i < numTokensInCollection.toNumber(); i++) {
  // See if they have the token
  const balance = await earlyAccessNfts.balanceOf(address, i);
  if (balance.toNumber() > 0) {
    userHasToken = true;
    break;
  }
}

Great! Now we have a userHasToken variable that is true if the user had a balance greater than zero for any token in that ERC-1155 NFT Collection.

Now we can use that variable to determine whether or not we generate a mint signature for this user:

  // Now use the SDK on Goerli to get the signature drop
  const arbitrumSDK = ThirdwebSDK.fromPrivateKey(
    process.env.PRIVATE_KEY as string,
    "arbitrum-testnet"
  );
  const signatureDrop = arbitrumSDK.getSignatureDrop(
    "your-contract-address-here" // Your contract address here
  );

  // If the user has an early access NFT, generate a mint signature
  if (userHasToken) {
    const mintSignature = await signatureDrop.signature.generate({
      to: address, // Can only be minted by the address we checked earlier
      price: "0", // Free!
      mintStartTime: new Date(0), // now
    });

    res.status(200).json(mintSignature);
  } else {
    res.status(400).json({
      message: "User does not have an early access NFT",
    });
  }

In the above snippet, we are using our private key to instantiate the SDK on behalf of our admin wallet.

Learn how to export your private key from your wallet.

To do this, create a file called .env at the root of your project, and add the following to it:

PRIVATE_KEY=your-private-key-here

Ensure you store and access your private key securely.

Using the API Route on the Front-end

On our home page, we need a way to call our API route, let's write that function now.

Here, we check to see if the mint signature came back from the API request. If it didn't, we display an error message. If it did, we call the
signature.mint with the mint signature to claim the NFT.

  async function claimWithSignature() {
    const signedPayloadReq = await fetch(`/api/generate-mint-signature`, {
      method: "POST",
      body: JSON.stringify({
        address: address,
      }),
    });

    if (signedPayloadReq.status === 400) {
      alert(
        "Looks like you don't own an early access NFT :( You don't qualify for the free mint."
      );
      return;
    }

    try {
      const signedPayload =
        (await signedPayloadReq.json()) as SignedPayload721WithQuantitySignature;

      console.log(signedPayload);

      const nft = await signatureDrop?.signature.mint(signedPayload);

      alert(`Succesfully minted NFT!`);
    } catch (error: any) {
      alert(error?.message);
    }
  }

Now all we need to do is add a new button that calls this function:

<button onClick={() => claimWithSignature()}>Claim Free with signature</button>

Let's test it out:

On a wallet that doesn't own one of these Early Access NFTs, the mint signature is not granted to them, meaning they are unable to mint for free using the signature minting method:

On a wallet that does own the Early Access NFTs, they are allowed to mint an NFT for free rather than paying with the regular claim method!

Once the transaction is confirmed, we should see:

Conclusion

That's it! You have successfully created your very own ERC-721A NFT collection with signature minting, and built an app to claim your NFTs on top of it!

To learn more about what you can do with the signature drop contract, check out the Portal documentation!