Building on Web3
Web3 development combines traditional software skills with blockchain-specific tools and patterns. This topic walks through the technical stack, the developer workflow, and what it actually takes to build a functioning Web3 application.
The Web3 Development Stack
┌─────────────────────────────────────────┐ │ USER INTERFACE (Frontend) │ React / Next.js ├─────────────────────────────────────────┤ │ WALLET CONNECTION │ wagmi / ethers.js / viem ├─────────────────────────────────────────┤ │ SMART CONTRACTS (Backend) │ Solidity / Vyper / Rust ├─────────────────────────────────────────┤ │ BLOCKCHAIN │ Ethereum / Solana / etc. ├─────────────────────────────────────────┤ │ STORAGE │ INDEXING │ ORACLE │ IPFS │ The Graph │ Chainlink └─────────────────────────────────────────┘
Smart Contract Languages
Solidity (Ethereum and EVM chains)
Solidity is the most widely used smart contract language. It resembles JavaScript and C++ and compiles to bytecode that runs on the Ethereum Virtual Machine (EVM). Any EVM-compatible chain — Polygon, Arbitrum, BNB Chain, Avalanche — runs Solidity contracts.
// A minimal Solidity contract
pragma solidity ^0.8.0;
contract SimpleStorage {
uint256 public storedNumber;
function store(uint256 number) public {
storedNumber = number;
}
}
Vyper (Ethereum)
Vyper is a Python-like language for Ethereum. It is designed for simplicity and auditability — no inheritance, no function overloading. Fewer features means fewer places for bugs to hide.
Rust (Solana, NEAR, Polkadot)
Solana programs (smart contracts) are written in Rust. Rust is lower-level and more complex than Solidity, but offers superior performance and memory safety. The Anchor framework makes Solana development more approachable.
Key Developer Tools
Hardhat
A development environment for Ethereum. It lets you compile contracts, run a local blockchain for testing, write automated tests, and deploy to any network. The most popular choice for Solidity developers.
Foundry
A faster, Rust-based development framework for Ethereum. Tests are written in Solidity instead of JavaScript. Increasingly preferred for advanced development and security testing.
Remix IDE
A browser-based IDE. No installation required. Beginners write, deploy, and interact with smart contracts entirely in the browser. Ideal for learning and rapid prototyping.
OpenZeppelin Contracts
A library of audited, reusable smart contract components. Instead of writing an ERC-20 token from scratch, you inherit from OpenZeppelin's tested implementation and add only your custom logic. This dramatically reduces the risk of introducing bugs.
Connecting the Frontend to the Blockchain
The frontend communicates with the blockchain through libraries that handle wallet connections and contract interactions.
ethers.js / viem
JavaScript libraries that let your frontend read blockchain data and send transactions. viem is a newer, typed alternative to ethers.js — faster and with better TypeScript support.
wagmi
A React hooks library built on top of viem. It simplifies wallet connection, network switching, and contract reads to a few lines of code.
WalletConnect / RainbowKit
These handle the "Connect Wallet" button experience. They present users with a selection of wallets, manage connection state, and work across mobile and desktop.
The Development and Deployment Workflow
- Write the contract in Solidity using Remix or a local Hardhat/Foundry project
- Test locally — run a local blockchain node and deploy to it for testing
- Write automated tests — test every function, including edge cases and attack scenarios
- Deploy to a testnet — Sepolia or Goerli (Ethereum testnets) with free test ETH
- Get an audit — for any contract that will hold real user funds
- Deploy to mainnet — the live blockchain, using real ETH for gas
- Verify the contract — publish source code on Etherscan so users can read it
Reading Blockchain Data — The Graph
Blockchains are poor databases for queries. You cannot simply ask "show me all swaps above $10,000 in the last week." The Graph indexes blockchain events and exposes them through a GraphQL API, making complex queries fast and easy.
Every major DeFi protocol — Uniswap, Aave, Compound — uses The Graph to power their dashboards and front ends.
Oracles — Bringing Real-World Data On-Chain
Smart contracts cannot fetch data from the internet on their own. An oracle is a service that brings external data onto the blockchain in a verified, tamper-resistant way.
Chainlink is the dominant oracle network. It provides:
- Price feeds (ETH/USD, BTC/USD, etc.) used by DeFi protocols
- Verifiable random numbers (for fair NFT mints and games)
- Any API data (sports scores, weather, election results)
Account Abstraction
Standard Ethereum accounts require a private key and ETH for gas — a significant barrier for new users. Account abstraction (ERC-4337) lets developers create smart contract wallets with powerful features:
- Pay gas fees in any token, not just ETH
- Sponsor gas fees for users (gasless transactions)
- Social recovery — restore wallet access through trusted contacts instead of a seed phrase
- Batch multiple actions into one transaction
Common Web3 Developer Patterns
Upgradeable Contracts (Proxy Pattern)
Smart contracts are immutable after deployment. The proxy pattern separates the contract's logic from its data storage. Upgrading means deploying new logic and pointing the proxy to it — while user data remains unchanged.
Multisig Admin Keys
Contracts with admin keys (for upgrades or parameter changes) should be controlled by a multisig — requiring multiple signers to approve any change. A single compromised key cannot drain or sabotage the protocol.
Events and Logging
Smart contracts emit events when important actions occur (a transfer, a swap, a vote). Front ends and indexers listen to these events to update UIs and build data history. Every significant state change should emit an event.
Security Practices for Web3 Developers
- Always check for reentrancy vulnerabilities — the root cause of many major exploits
- Use OpenZeppelin's ReentrancyGuard for any function that sends ETH
- Never trust user-supplied input in contract logic without validation
- Write tests that attempt to exploit your own contract before deploying
- Engage a professional security firm for audit before mainnet deployment
- Plan an incident response — how will you pause the contract if a bug is discovered?