The Developer’s Guide to the Web3 Stack

This guide provides an overview of the web3 stack and is designed to help developers understand the essential technology and tooling to build full stack, decentralized blockchain applications.

At Infura, we believe the best way to achieve decentralization is by empowering developers with the tooling, technology, and knowledge to build it. Defining the web3 stack requires thorough research and an in-depth understanding of the web3 ecosystem. The Developer's Guide to the Web3 Stack details all you need to start building full stack, decentralized applications.

Part one, “What is Web3?” defines web3 and compares it to previous evolutions of the web. Part two, “What is the Web3 Stack?” defines the web3 stack in the context of traditional tech stacks. Part three, “Components of the Web3 Stack” discusses in detail the tools and technologies that enable the creation of web3 applications. And in part four, "Start Building" we show you how to get started.

What is Web3?

To fully understand web3, we need context. The Internet has evolved since inception, so let’s start by taking a look at the previous iterations.

Web1

The first mainstream version of the Internet came about in the mid-1990s and consisted primarily of content distributed via self-hosted websites and personal webpages. While users could now disseminate content to a wider audience than previously possible, online content remained static and read-only.

This meant website owners couldn’t update published content, nor could site visitors interact with content in any way. Besides, publishing content online demanded a high level of skill and effort—limiting usage of Web1 to technical skilled individuals.

Web2

The next version of the Web evolved in the early 2000s. During this phase, websites like Twitter and Facebook made the internet interactive—for example, website visitors could like, comment, and share posts. For this reason, this era of the Internet is often described as the read-write phase.

Web2 also made it easier for the average user to create and distribute content online without needing extensive skills. This blurred the line between content consumer and content creator and kickstarted the era of user-generated content that still continues today. Wikipedia and YouTube are examples of how web2 enables users to interact with and upload content while abstracting away complex details of the underlying technology.

Web3

While web2 has created many indispensable services such as e-commerce, digital banking, social networking, it is rife with various issues. For example, a large portion of web traffic and user data today is owned and controlled by a handful of Big Tech companies.

Such centralized control of Internet infrastructure creates problems including censorship, security breaches and theft of user data, vendor lock-in, and increase in proprietary software. More so, web2 platforms extract higher profits from user-generated content and data, but choose to leave users only a tiny portion of the revenue.

The problems with web2 are precisely what necessitated the next iteration of the Internet (web3). Often described as the read-write-own era of the Internet, web3 aims to be a decentralized, trustless, open evolution of the Internet—one where users create, own, and profit from their content.

Unlike web2, decentralization and composability are built into the core of web3. Decentralized control of digital infrastructure guards against censorship, minimizes the need to trust central authorities, and protects against corruption and inequality. Furthermore, composability ensures anyone can build off of another’s technology in a permissionless manner.

These features—coupled with other improvements like provision of a native payment layer and self-sovereign identity—make web3 useful in many contexts. From decentralized finance (DeFi), decentralized autonomous organizations (DAOs), and non-fungible tokens (NFTs) to decentralized identity and decentralized social networks, web3 can benefit users in many ways.

What is the Web3 Stack?

A tech stack is the collection of technologies and services used to build and manage an application or project. Web2 developers are likely familiar with LAMP and MEAN—terms that refer to software stacks for building certain classes of applications. For example, a developer working with the LAMP (Linux, Apache, MySQL, and PHP) stack will often use these technologies in building applications:

Linux as the operating system (OS) for managing memory and processes in an application.

Apache as the web server for serving data to different clients (e.g., delivering a set of HTML pages in response to a URL request from a user’s browser).

MySQL as the database management system for storing and querying an application’s real-time and historical data.

PHP as the programming language for scripting server-side functionality, including components that communicate with the web server and database.

Other components of the web2 stack include frontend frameworks for managing UI/UX (e.g., React and jQuery), authentication frameworks for identity and access management (e.g., OAuth and Auth0), and API services for connecting to other components in the tech stack. This list is hardly exhaustive, but provides enough context as we go about defining the web3 technology stack.

Defining the Web3 Development Stack

With web3, the notion of a tech stack is not cleanly defined (a testament to the nascent nature of the technology). Moreover, as decentralization is the core ethos of web3, it is important that components in the tech stack be sufficiently decentralized—making the web3 stack more complex compared to the techstacks in traditional programming.

Nevertheless, years of continued development and innovation in web3 have produced a collection of different tools for developing web3 apps. While the web3 development stack has some similarities with the web2 stack (particularly with frontend development), it is quite different from what traditional developers are familiar with.

By “web3 stack,” we refer to the combination of technologies that enable decentralized, composable, and trustless (or trust-minimized) applications. Like other programming stacks, the web3 stack comprises programming languages, backend tools, frontend frameworks, database infrastructure, and APIs for applications to communicate with other systems.

The next section takes a deep dive into different parts of the web3 stack. There, you’ll learn how each component of the web3 stack functions and how they all work together.

Components of the Web3 Stack

Blockchains

A blockchain can be described as a distributed digital ledger that stores information in cryptographically linked blocks. Blockchains are a foundational component of the web3 stack and perform a critical role in enabling functional dapps.

Blockchains as state machines

The blockchain maintains the state of a web3 application and stores information like user accounts and balances in a key-value store. Although similar to traditional databases and servers, blockchains have some distinctive qualities:

1. No entity controls read-write operations. The blockchain is a public database of sorts—one that anyone can write to or read from. When people describe blockchains as “decentralized” and “censorship-resistant,” they usually mean no individual or group controls who can interact with the blockchain and under what conditions.

While no one controls read-write operations, it is still important to ensure that only valid information is written to this public database—otherwise applications would execute off invalid information. As such, blockchains have consensus algorithms that allow participants in a peer-to-peer network to collectively verify and validate the blockchain’s state.

2. Information stored in the blockchain is publicly verifiable and auditable. Information is written to the blockchain via transactions. These transactions are batched into blocks (for efficiency), with copies of each block stored across a large network of nodes (computers owned by participants in the peer-to-peer network).

This system ensures anyone can easily access the blockchain and verify information without needing to trust that blockchain data is valid. This is what people mean when they say blockchains are “trustless” or “trust-minimized”.

3. Blockchain data is immutable. Besides consisting of a set of transactions and a timestamp, every block contains a cryptographic hash of the previous block (forming a “chain”). As time passes and more blocks are created and chained, the data inside the older blocks becomes highly resistant to modification.

To change past data, you would also need to change the data of every subsequent block. But this is difficult to pull off since each block is replicated across thousands of computers (nodes). Hence, we consider the data inside a blockchain to be immutable and resistant to modifications.

Blockchains as operating systems

Besides storing application state, blockchains provide an execution layer (typically a virtual machine) for running application logic embedded in smart contracts (more on this later). This execution layer is the equivalent of an operating system (OS) in the web2 development stack.

The Ethereum Virtual Machine (EVM) is an example of a runtime environment for web3 applications. The EVM stores accounts, balances, transaction data, and most importantly, smart contract code. With each transaction involving a specific dapp, the code for the application’s smart contract is executed by Ethereum nodes—causing a change in the EVM’s global state.

Blockchain-based VMs remove the need for developers to manage backend infrastructure (e.g., a database or web server). This task is handled instead by nodes who store an application’s state and code and cooperate to execute operations triggered by an application’s users. This is why blockchains are also described as “distributed computing platforms”.

EVM-Compatible vs Non-EVM Blockchains

While the EVM was the first to introduce programmable on-chain logic, it suffers from several limitations—especially scalability and cost-effectiveness. Several blockchains try to solve this problem by implementing a custom variant of the EVM while optimizing architecture for high speeds and low computational costs. These are described as EVM-compatible blockchains and have the advantage of seamlessly integrating with EVM tooling and infrastructure. Thus learning how to build applications targeting the EVM allows you to transfer those skills to building dapps in other ecosystems apart from Ethereum.

Differences in execution layers aside, all blockchains have a native token (a token is a unit of value that represents asset or enables some form of utility). These tokens are required to compensate nodes for computational resources. A blockchain’s token may also be used as an economic incentive for participants to secure and maintain the blockchain infrastructure.

The table below highlights some popular (EVM and non-EVM) blockchains use today include:

Smart Contracts

Smart contracts are software programs (arbitrary blocks of code) that run on the blockchain’s execution layer. The term “smart contract” derives from different qualities of these programs. For example, a smart contract encodes rules of an agreement and executes these once predefined conditions are met. Say Alice and Bob want to make a bet without relying on an intermediary that prevents cheating. In this case, the winning conditions would be written into the rules of a smart contract, which would release the funds to the winner only if the conditions are satisfied.

Because a smart contract lives on the blockchain, the terms of the contract (written in lines of code) are immutable and the outcome is publicly known—all without relying on an intermediary to enforce the rules. Moreover, smart contracts execute near-autonomously and significantly reduce the risk of human error or corruption.

Within the web3 stack, smart contracts can be seen as the backend for blockchain applications. Whereas traditional applications are managed from a company-controlled backend server (physical or cloud-based), smart contracts stored on the blockchain dictate the business logic of web3 applications. But smart contracts aren’t just any backends, they are open, composable, and public backends:

Public: A smart contract is stored at a specific location in the blockchain (via deployment). Like other information stored on-chain, smart contract code can be inspected by anyone with access to a blockchain node. There are no hidden algorithms—every line of code can be checked to confirm what a dapp developer intends for the application to do.

Open: Once deployed on the network, a smart contract’s logic can be triggered by anyone capable of submitting transactions to the blockchain. This makes web3 different from web2 where software companies control the backend and  determine who can or cannot interact with an application.

Composable: Composability describes the ability to modify, reuse, and combine existing software components to create new applications. As programs living on a shared computing platform, smart contracts are composable by default. Smart contracts can trigger specific logic in other contracts at execution time, reducing the need to build every part of an application’s logic from the ground up.

Also, smart contract code is typically open-source. Open-source code reduces the need to trust application developers, but more importantly, enables developers to build off each other’s work. Today, you can quickly create a dapp by forking the codebase of a popular web3 protocol and tweaking the business logic for your specific application.

Smart Contract Programming Languages

If smart contracts are blocks of code, web3 developers will need to learn programming languages for writing smart contracts. Fortunately, there are many smart contract programming languages to pick from.

Each smart contract programming language varies in the availability of tooling, documentation, ecosystem support, size of the developer community, ease of use, and degree of functionality. Your choice of a smart contract programming language will depend on individual factors like what blockchain ecosystems you want to build for.

As a quick example, learning Solidity puts you in a great position to build dapps for multiple blockchains. Solidity was created for the EVM; hence, other EVM-compatible blockchains support using it to write smart contracts.

A simple “HelloWorld!” smart contract written in Solidity:

You could also consider other factors like a language’s popularity and ease of use. For instance, some blockchains allow for writing smart contracts in Rust since the latter feels more familiar and easier to use for web2 developers. Below is an example of a simple “Hello World” program written in Rust for the Solana VM:

A simple “Hello Solana!” program written in Rust:

Frontend Libraries

In software development the frontend architecture controls the user’s interactions with an application. Hence you’ll often see the frontend described in the context of an application's user interface (UI) or UX (user experience).

For the most part, frontend technology remains the same from web2 to web3, with developers relying on well-known frameworks like HTML, CSS, and JavaScript. React (a JavaScript library) is especially popular among developers building out user interfaces for web3 applications. This familiarity makes building dapp frontends easier for devs with web2 frontend development experience.

What changes, however, is how the frontend (the client) communicates with the backend (a blockchain-based smart contract). In a regular web2 application, the frontend, such as a web app UI, communicates user requests to backend servers using a request-response mechanism (typically HTTP). The server receives the request, does some processing based on the request data payload, and sends a response back to the client (via the frontend).

Note: While the backend of a web2 web app generally refers to a server, it can also include all of the underlying components that a server might communicate with in order to process requests—databases (e.g., MySQL or PostgreSQL), key-value stores (e.g., Redis), or persistent file storage (e.g., MongoDB).

In web3, users still (primarily) interact with applications via a frontend created with HTML, CSS, and JavaScript. However, the client must connect to a node (more on this later) before sending requests to a dapp’s backend (i.e., a blockchain-based smart contract). Additionally, communication between frontend and backend in web3 apps is handled via custom JavaScript libraries, notably ethers.js and web3.js (used in EVM-compatible blockchains).

Ethers.js and web3.js provide utilities for handling frontend logic for dapps, including signing transactions, getting user balances, retrieving account information, managing web3 wallets, and so on. Both libraries also support making RPC (Remote Procedure Calls) to blockchain nodes—making it easier for developers to read and write to the blockchain.

The image below describes the typical workflow for a user (client) trying to interact with a Web3 application. The client would connect to a node, typically through a node provider like Infura, and submit a request (via a transaction) triggering specific smart contract logic. The results of this operation may be obtained via a blockchain node or from a block explorer.

Besides ethers.js and web3.js, you’ll find other custom JavaScript libraries for managing client-side interaction with blockchains. Below are some frontend libraries useful building UI components for dapps on other blockchains:

Note: the frontend of a web3 application is stored off-chain unlike smart contracts, which live on-chain. As on-chain computation is expensive, executing complex frontend logic would be economically infeasible. There are decentralized web3-native solutions gaining traction, such as Skynet Labs' Homescreen, but no industry-wide standard yet. Initializing web3.js and using it to get a list of accounts:

Nodes and Node Providers

There are many definitions of a node in blockchain architecture, but in general, a node is a computer connected to a blockchain that participates in the network. Bitcoin nodes, for example, typically mine, store, and validate blocks. In Ethereum, a node provides the processing power for the EVM; they also store and execute smart contract code, keep track of the EVM state, create and validate new blocks, and more.

RPC Endpoints

Nodes operate at the blockchain interaction layer and provide access to on-chain data. Interacting with any blockchain requires connecting to a node, and you’ll often do that using RPC endpoints.

By definition, RPC endpoints enable developers to communicate with the blockchain using a remote procedure call. This basically means there are rules or specific data structures to facilitate the communication. For example, you can send transactions, read blockchain data, and execute other useful functions using the JSON-RPC specification. This is usually abstracted away from developers through libraries built on top of this specification, such as web3.js (which we discussed earlier).

Running Nodes vs Using Node Providers

Because most blockchains are fundamentally decentralized, anyone (including developers) can run a node depending on the hardware requirements. Theoretically, the more nodes in a network, the more secure that network becomes. Having more nodes diversifies the operating power, provides more participants to help with consensus, and improves network resiliency.

However, not everyone has the hardware or the time to commit to running and maintaining their own nodes. In particular, developers may find managing in-house node infrastructure too costly or non-scalable. This is where node providers—which we discuss subsequently—come into the picture.

Node Providers

A blockchain node provider makes it easy for developers to interact with the blockchain by providing an API and dedicated RPC endpoint for web3 projects. Instead of wasting valuable resources on maintaining node hardware, development teams can outsource this task to a node provider and focus on building and improving products for users.

Node providers are usually built as an Infrastructure as a Service (IaaS) model and scale easily depending on requirements. Some node providers may also provide other tooling such as software development kits (SDKs) and useful APIs to streamline the web3 development workflow for teams.

Using Infura to get the balance of an address:

The list below highlights some popular blockchain node providers with additional information on supported blockchains and tooling available to developers:

APIs (Indexing & Querying)

In the traditional tech stack, databases structure and organize data in formats that enable applications to consume it efficiently. Blockchains store data differently and are more suited to returning information for basic read operations. To perform complex sorting/querying operations—like building indexes and relational databases—you’ll need to manage expensive backend infrastructure to cache and sync data.

This is where indexing protocols like The Graph, HAL, and Moralis become useful in building web3 apps. Blockchain indexers make data querying easy and efficient by acting as the middle-man between the blockchain and a dapp. Essentially, they pull information from the blockchain and allow you to query/index the data efficiently in your application.

The Graph is quite popular in this context and allows anyone to create custom and publicly accessible APIs (subgraphs) for indexing blockchain data. HAL and Moralis also provide utilities for tracking on-chain events and  filtering through on-chain data to find information specific to a particular dapp.

Querying The Graph from an application:

Development Environments

Web2 developers rely on development environments to manage the end-to-end process of building applications. A development environment usually provides resources for software editing, testing, building, and packaging in one comprehensive application.

Web3 isn’t any different, and several development environments for managing the development lifecycle for dapps exist. These are fairly similar to web2 development environments and provide utilities for writing, debugging, and optimizing code. They also provide features specific to web3 application development including:

• Dapp project templates and default file structure
• Scripts for compiling smart contracts to bytecode
• Scripts for deploying smart contracts to a blockchain network
• Flexible plugins to customize local development environments

Along with a development environment, a local blockchain instance is usually required for testing. These can be lightweight, single-use instances that live and die within a single command or complete persistent forks of the entire Ethereum blockchain (or any EVM blockchain) from genesis. For example, Hardhat excels at creating single-use local instances, while Ganache makes it simple to create a local blockchain instance with archive node access using ganache --fork.

These development tools may not even need to exist on your local machine. Similar toolchains such as Remix and ChainIDE offer a range of tools for every part of the development lifecycle but exist entirely online.

ConsenSys created one of the first development environment tooling kits for web3 developers, Truffle. Since then Truffle has grown into a suite of developer tools including Truffle CLI, Ganache the local blockchain simulator, Truffle debugger, Truffle for VS Code extension and Truffle dashboard.

The goal for Truffle Suite is to provide all the necessary toolings a developer would require to build a functional dapp from start to finish, as well as create an easy pipeline for deployment to testnets and Mainnets leveraging node providers like Infura and Alchemy.

Below is a list of different blockchain ecosystems and associated development environments. Note that some of these frameworks and environments are useful for building dapps across different chains while others are designed for specific ecosystems.

Below is a list of different blockchain ecosystems and associated development environments. Note that some of these frameworks and environments are useful for building dapps across different chains while others are designed for specific ecosystems.

Smart Contract Testing

Since most smart contracts handle some form of monetary exchange, it is crucial to test them thoroughly before deploying to the blockchain. Testing is critical for securing smart contracts, particularly because the immutability of public blockchains prevent post-launch bug fixes. You can simulate upgrades to a dapp's business logic, but these require complex procedures and can introduce hidden vulnerabilities.

Thus, “move fast and break things” isn't an option for web3 developers; it is better to simply “do it once and do it right.” The best way to start? Test your code thoroughly to ensure it doesn't fail arbitrarily or produce unexpected results at runtime.

Many of the development environments and IDEs discussed previously, especially Truffle, Brownie, Foundry, and Remix, provide utilities for running unit tests. With these tools, you can write tests that capture different user interactions—both malicious and benign—and analyze how your smart contract behaves in those conditions.

But you may also need more advanced testing capabilities, such as the option to test contracts against a broad class of inputs to see if anything breaks functionality or triggers a bug. Property-based testing is arguably the most ideal option here, as it can verify whether security assumptions hold under various execution scenarios (or not).

QuickCheck, Hypothesis, and American Fuzzy Lop (AFL) are some property-based tools familiar to Web2 developers. While these tools are hardly suited to analyzing contract code, there are similar variants designed with smart contracts in mind. These include:

Testnets

Like in traditional development, web3 developers can access staging environments called test networks (testnets). A testnet is a production-like environment for interacting with contracts to understand how they behave in real-world conditions. By deploying on a testnet—after running tests in a local development environment—you can easily detect smart contract bugs before releasing your dapp to users on the main network (mainnet).

You can do all of this without putting funds at risk since funds on a testnet hold no real value. Still, you’ll need to source those funds before sending testnet transactions, which is where faucets come in. Faucets freely give out the tokens you’ll need to make transactions (eg. calling a contract) on a testnet.

Infura has released a faucet for developers that need ETH to deploy and test contracts on the Ethereum Goerli testbet. The table below highlights different testnets for different blockchain ecosystems and where you can find faucets to source testnet tokens.

Decentralized Storage

Contrary to popular notion, not all data generated by web3 applications need to be stored on the blockchain. Examples include sensitive information such as KYC (Know-Your-Customer) profiles, user-generated data (e.g., blog posts, reputation scores, and social graphs), and multimedia files (e.g., images and audio).

Storing these types of data on-chain would incur massive costs, given limits on blockchain storage and the need to pay transaction fees. However, it is possible to use decentralized storage solutions to store web3 application data off-chain without introducing the availability, integrity, and consistency issues affecting centralized databases.

Decentralized storage networks replicate files across nodes in a distributed peer-to-peer network to ensure high availability and persistence of data. Some of these platforms also ensure resiliency and uptime for web3 applications by splitting files and distributing shards between different nodes. Furthermore, cryptoeconomic mechanisms and cryptography are employed to enable interactions between mutually distrusting parties. The result is a decentralized storage marketplace where developers can pay nodes around the world to lease unused hard drive space. Decentralized storage networks ideal for applications such as NFT-based games or blockchain-based social networks that generate copious data, but need a decentralized and cost-effective storage solution.

Some popular decentralized storage solutions include:

Here's how to use Infura to upload a file to IPFS via command line:

Improving Off-Chain Data Storage and Access for Web3 Applications

Even with the existence of decentralized storage platforms, some developers still opt for centralized databases like Amazon Simple Storage Service (S3) or Fauna for off-chain storage. This can happen for a number of reasons:

1. Privacy: Although decentralized storage networks use some form of encryption, storing data in a p2p network prevents applications from guaranteeing users full privacy.

2. Non-mutability: Like blockchains, decentralized storage networks render stored information immutable. For example, uploading NFT metadata to IPFS prevents attempts to modify it in the future. While immutability is certainly necessary, some use cases (e.g., dynamic NFTs) may require some part of the data to be mutable.

3. Querying and indexing issues: Unlike traditional, application-specific databases, decentralized storage networks like IPFS lack utilities for querying, sorting, and indexing information efficiently. This can present problems for developers working on use cases that need efficient access to information (e.g., on-chain games or decentralized social networks).

4. Composability: Data stored by dapps on off-chain storage networks—for example, a user’s social profile—cannot be reused by other applications. This re-introduces the siloed architecture of web2 and makes it difficult for Weh3 users to truly own their data.

Some projects are already working towards creating off-chain storage solutions that combine decentralization with useful features from traditional database management. Such features include role-based and application-based access control, utilities for efficiently querying information (like SQL), advanced sorting and indexing capabilities, and more.

For example, Ceramic is a decentralized data storage layer built on IPFS that allows developers to store mutable data using “streams”. Each stream stores a specific type of information (e.g., user profiles, on-chain reputation, social media posts, etc.). Ceramic uses cryptography to ensure only the right parties can update streams while using version control capabilities to capture changes made to data.

Tableland is an early-stage project building a web2-style relational database with SQL integration and smart contract compatibility. Like Ceramic, Tableland leverages popular data persistence layers like Arweave, Filecoin, and IPFS to store data. However, it introduces new off-chain infrastructure to enable data queries (using familiar SQL) and uses EVM chains to facilitate access control (and the ability to mutate metadata).

Both Ceramic and Tableland introduce composability to web3 data storage. For instance, Ceramic lets dapps create “data models” (i.e., streams for storing specific information). A developer might create a data model for a user’s identity metadata and another developer can reuse the same data by plugging the data model into a dapp. Similarly, Tableland guarantees data composability between different dapps by making “tables” (i.e., individual storage layers) interoperable with each other.

Oracles

As a requisite for trustlessness, blockchains are deterministic state machines. In English, this means different blockchain nodes can compute changes to a smart contract’s state (using similar data) and arrive at the same results. This is how distributed computing platforms like the EVM can reach consensus on a shared state without any entity acting as a “source of truth.”However, this presents a tradeoff for web3 applications since it prevents smart contracts from accessing off-chain data. As real-world information (e.g., the price of ETH) often  changes over time, nodes cannot use it without arriving at conflicting results after executing smart contract transactions. Oracles solve this problem by connecting blockchains to external systems, enabling smart contracts to execute functions based on off-chain data.

Oracles comprise on-chain components (oracle contracts) and off-chain components (oracle nodes). Oracle nodes source off-chain information (e.g., asset prices and capital market data), which they store in the oracle contract’s storage. Other smart contracts can then query the oracle contract for the information when performing operations.

To illustrate, a DeFi lending protocol may require the current price of a token to calculate the value of collateral deposited by users. Because this information is stored on-chain, nodes re-executing the transaction can reference the same value and avoid conflicting results and breakdown in consensus.

Off-chain computation is another use case for blockchain oracles. Oracle nodes can execute resource-intensive computation (like securely generating a verifiably random value for blockchain games) and publish the result(s) on-chain for smart contracts to use. Such operations would be economically infeasible to conduct on-chain, but can be executed cheaply in an off-chain environment.

Some popular oracle networks include:

Identity Management

Identity and access management (IAM) is a core part of any application—applications need to verify the identity of users and confirm their right to access the platform. In web2, this can be handled using a custom solution that stores user-related information in a database and uses it to authenticate user logins.

Using OAuth (Open Authorization) forms is a popular alternative to in-house identity systems. Users’ identity credentials are stored with a third-party service like Facebook, Google, or Twitter, and apps can access this information once a user completes the OAuth form.

While this improves UX—for example, by eliminating the need to memorize long passwords—it puts Big Tech companies in control of users’ personal data. Worse, corporations use the data for self-seeking ends (profit) or may even prevent users from accessing the information at will.

In contrast, web3 gives users authority over their online identity and data (often described as decentralized or self-sovereign identity). This requires a new system for authenticating users—one that doesn’t rely on centralized databases or identity providers.

Web3 Wallet-Based Authentication

When creating a new blockchain account, users generate a public-private keypair. Public keys are, well, public, and are used to verify transactions signed with the corresponding private key. Private keys are stored in a wallet and help users prove ownership of assets.

Wallets are also building blocks for managing identity and reputation in web3. Since Externally Owned Accounts (EOAs) are controlled by individuals (contract accounts don’t have private keys), users can authenticate their identity with a dapp by proving ownership of an account. For example, a user could sign a message (after clicking “connect wallet”) while the backend decodes the message and verifies the signature using the public key.

Ethers.js, which we discussed previously, provides utilities for Web3-based authentication. You can also use SDKs provided by Web3Auth, and WalletConnect, and SpruceID (among others) to set up wallet-based authentication with minimal configuration. The Ethereum Name Service (ENS) also provides Javascript libraries for retrieving a user’s ENS records to verify identity data.

Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs)

Wallets can provide basic authentication for one-off sessions, but what if you want a more layered system of verifying user identities? For instance, a DAO can assign reputation scores to recognize high-profile contributors while a play-to-earn game can issue badges to simplify login workflows, inform application logic, or unlock certain features. This is where decentralized identifiers (DIDs) and Verifiable Credentials (VCs) can help.

Unlike traditional identifiers (e.g., an email address or social media account), decentralized identifiers decouple a person’s identity from any centralized authorities or identity providers.  DIDs provide a means for individuals to completely control their online identity—sharing information when and where the user deems appropriate.

Although decentralized identifiers come in different forms, blockchain accounts are commonly used in web3 as DIDs. Public-private key cryptography enables organizations to issue credentials to users, which anyone can verify without contacting the issuer. Here’s how this can work for dapp developers:

1. A dapp issues Verifiable Credentials (VCs) to users—documents attesting to claims about their identity (e.g., membership of a DAO or decentralized social network or level in a game).

2. The dapp attaches its DID to the credential by signing with a private key. This simplifies authentication, as signatures can be verified using the associated public key (stored on the blockchain). It also makes verifiable credentials immune to tampering and altering.

3. Credentials can be encrypted with the user’s DID and securely stored off-chain (using something like Ceramic or IPFS). This safeguards user privacy (nobody else can decrypt the information) and guarantees self-ownership of identity data (unlike traditional databases, Ceramic and IPFS are decentralized datastores).

4. When next the user signs in to the dapp (using a wallet), the dapp can retrieve and authenticate credentials associated with the user’s DID (i.e., public key). This can significantly improve UX, especially when paired with session keys that enable continuous interactions with a dapp (without needing to re-authenticate identities during a session).

Decentralized identifiers provide a web3-native system for managing identity profiles and authenticating users in trust-minimized fashion. However, it can be difficult to build a robust decentralized identification system from scratch without necessary tooling. Fortunately, some projects are tackling this hard-to-implement feature (some of which are already in production):

Blockchain Automation

Blockchain automation tools empower developers to automate processes by “listening” for conditional triggers on a blockchain network. These services run specific action(s) whenever a predefined event occurs on-chain—or sometimes, off-chain—providing web2-style IFTTT/Zapier automation for web3 applications.

Importantly, blockchain automation tools enable seamless integration of components of your dapp’s infrastructure to improve performance and efficiency. Such components could include, but aren’t limited to, smart contracts, frontend applications, on-chain/off-chain events, APIs, and other services. Below are some other advantages of including web3 automation tools in your development stack:

1. Improving dapp UX: Some web3 automation services function as active monitoring systems that report important information—like changes in a smart contract or blockchain’s state. This way you can improve dapp UX by providing users with timely and convenient access to on-chain information (relevant to your application).

Typically, web3 automation tools allow you to define custom rules around when and where users get notified of on-chain activity. For example, you may want to notify users of changing gas prices (updated at every block) by posting a message to Discord or Telegram.

2. Managing protocol operations: Ensuring your protocol operates seamlessly requires executing administrative actions at intervals. These operations are usually critical to the health and utility of a protocol and must be performed regularly. Here are some examples:

• Liquidating negative debt positions in a DeFi lending protocol
• Triggering daily payouts in a blockchain game
• Distributing on-chain payments in a DAO
• Updating values from a price oracle
• Starting and stopping NFT mints, etc.

Since smart contracts cannot self-execute, someone needs to routinely trigger these maintenance actions. For instance, some in-house teams will manually inspect smart contracts and call admin functions in a contract to perform upkeep actions. That said, this approach often requires considerable investment in manpower and infrastructure costs and may be prone to user error and downtimes.

Alternatively, projects can delegate smart contract administration to third-party automation services. These are usually networks of incentivized operators (aka “keepers”) that execute administrative functions in smart contracts based on job descriptions. The process is automated since operators subscribe to on-chain events and immediately execute administrative functions if conditions specified in the task are satisfied.

Below are some tools for automating smart contract monitoring and execution:

Start Building with the Web3 Stack

As you can see, web3 development is nascent but extensive. The web3 development stack introduces many new technologies, all with decentralization and composability at the foundation.

If you are coming from web2, you are already at an advantage. Many of the frontend technologies you already use are directly applicable in web3. Knowing how these technologies work together with the new web3 stack will bolster your skills at developing applications for the web3 ecosystem.

Developing smart contracts involves a steeper learning curve, but you can take advantage of many resources aimed at reducing learning difficulties for new web3 developers. ConsenSys Academy offers multiple online programs for those who thrive in structured learning environments.

Regardless of how you learn best, the key is to start and stay persistent—try the #30DaysOfWeb3 challenge or start building some projects. web3 is a revolution, but your journey to becoming a part of this revolution is in your control.

At ConsenSys, we believe web3 can create a trustless, open-source, and decentralized foundation for the digital economy of tomorrow. This is why we continue to invest in infrastructure to help developers and enterprises build the next generation of web3 apps.

Ready to start building on the web3 stack? Check out offerings from the ConsenSys product suite family, including Linea, Infura, Hal, Quorum, Truffle, MetaMask, and Diligence.

Happy buidling!