Layer 1: the chain and its nodes
The bottom of the stack is the network itself: Ethereum mainnet, a layer 2 such as Base or Arbitrum, or a non-EVM chain like Solana. The choice fixes the contract language, the fee model and the wallets your users will have.
Your app reaches the chain through a node. Ethereum.org explains that running your own nodes can be expensive in storage, bandwidth and engineering time, and that node-as-a-service providers exist so teams can call a hosted endpoint instead.[1]
Ethereum clients implement a uniform JSON-RPC API, with methods such as eth_blockNumber, eth_call, eth_getLogs and eth_sendRawTransaction. Because the interface is shared, moving from one RPC endpoint to another usually means changing one URL.[2]
Provider plans are priced in requests or compute units, and ethereum.org's list shows most providers offering a free tier. Configuring a second provider as a fallback keeps the app working when one has an outage.[1]
See also: Alchemy · Infura · QuickNode · Chainstack · Ethereum RPC endpoints
Layer 2: contracts, languages and frameworks
On EVM chains, contracts are written mostly in Solidity, with Vyper as the second option. The Solidity docs cover the language, compiler and the contract structure that other tools rely on.[3]
Frameworks wrap compile, test and deploy. Ethereum.org lists Foundry, Hardhat and several others, and describes frameworks as bundling a local blockchain, compile and test utilities, and deployment configuration.[4]
Most teams also pull in audited building blocks such as OpenZeppelin's token and access-control contracts rather than writing them from scratch, and they deploy first to a testnet funded from a faucet.
Foundry ships four tools: forge to build, test and deploy, cast to query chains and send transactions, anvil to run a local node with forking, and chisel as a Solidity REPL. Running anvil creates 10 pre-funded test accounts.[9]
Hardhat 3 takes a plugin-based approach in a Node.js project: tests can be written in TypeScript or in Solidity, and the same tool runs a local development node and can fork a live network, so the edit, compile and test loop needs no external service.[10]
See also: Hardhat · Foundry · Remix · OpenZeppelin · Crypto faucets
Layer 3: indexing and data
JSON-RPC answers point questions well, such as a balance at the latest block. It answers history questions badly: The Graph's docs note that answering all transfers for a user means scanning the chain block by block, and that raw RPC offers no way to filter, aggregate or join.[5]
Indexers solve that. The Graph lets developers define a subgraph that maps contract events into entities, then serves them through a GraphQL API. Its docs describe the problem directly: contract data lives in low-level storage slots and event logs, and a blockchain has no query language of its own.[5]
Large files do not belong on chain at all. Ethereum.org's storage docs cover IPFS, Arweave and similar networks used for NFT media and app assets.
Indexing can also be done in-house by reading logs from a node and writing them to a regular database. That gives full control at the cost of handling chain reorganizations: the JSON-RPC spec marks a log as removed when a reorganization drops its block.[2]
See also: The Graph · Goldsky · Dune Analytics
Layer 4: client libraries and the wallet
The frontend talks to the chain through a TypeScript library. viem describes itself as a TypeScript interface with low-level stateless primitives and automatic type safety, built as an alternative to ethers.js and web3.js.[6]
Writes pass through the user's wallet. EIP-1193 defines the provider interface that browser wallets expose, a single request method plus events, so one integration covers MetaMask, Rabby, Coinbase Wallet and others.[7]
Libraries encode calls using the contract ABI produced by the Solidity compiler, so the frontend and the contract stay in sync as long as the ABI is regenerated after every contract change.
Error handling deserves early attention: EIP-1193 defines codes such as 4001 for a rejected request and 4900 or 4901 for a disconnected provider or chain, while reverted transactions return errors from the RPC method itself. Users need a clear message for each.[7]
See also: MetaMask · WalletConnect · Privy · thirdweb
The stack at a glance
One common EVM setup in 2026 looks like this. Each row can be swapped for an alternative that speaks the same interface.
| Layer | Job | Common choices |
|---|---|---|
| Network | Consensus and execution | Ethereum, Base, Arbitrum |
| Node access | JSON-RPC reads and broadcasts | Alchemy, Infura, QuickNode, own node |
| Contracts | On-chain logic | Solidity with Hardhat or Foundry |
| Indexing | Queryable history | The Graph subgraphs |
| Client library | Typed calls from the app | viem, ethers |
| Wallet | Keys and signatures | Any EIP-1193 wallet, WalletConnect |
Worked example: budgeting one user action
Take a page that shows a balance and lets the user send ETH. The balance is one eth_call or eth_getBalance request: free for the user and one unit of your provider's quota. The transfer is one eth_sendRawTransaction, signed in the wallet.[2]
The user pays for the write. A plain transfer uses 21,000 gas; at a 10 gwei base fee and a 2 gwei tip that is 0.000252 ETH, of which 0.00021 ETH is burned. Your infrastructure bill covers only the RPC requests, which is why read-heavy pages drive provider costs far more than writes do.[8]
Scale changes the ratio but not the rule. A dashboard that refreshes ten balances every few seconds for a thousand users generates millions of reads a day, while the same users might sign only a handful of transactions. Caching reads in the backend is usually the first cost saving a team makes.
See also: Glossary: gas fee
Security and testing tools around the stack
Contracts cannot be patched after deployment, so testing gets more weight than in web development. Foundry's fuzz tests call a function with random inputs; the sample project in its getting-started guide runs one fuzz test 256 times.[9]
Hardhat can fork a live network so tests run against real deployed contracts, and it also supports fuzz tests written in Solidity.[10]
Simulation and monitoring sit next to the framework. Ethereum.org lists Tenderly as a platform to build, test, debug and monitor smart contracts.[4]
Reusable, audited libraries cut risk further. OpenZeppelin Contracts supplies ERC-20, ERC-721, access control and upgrade proxy code, so a new team inherits reviewed code instead of writing its own token logic.
Deployment scripts belong in version control like any other code. Recording the compiler version, optimizer settings and constructor arguments is what lets a block explorer verify the source later and lets users confirm the deployed bytecode matches the repository.
The last layer is the user's wallet itself. Test every flow with at least two wallets, one browser extension and one mobile wallet over WalletConnect, because EIP-1193 standardizes the interface but each wallet still renders prompts and errors differently.[7]
See also: Tenderly · OpenZeppelin · Cyfrin Updraft
The bottom line
Start with the pieces that are hardest to change: the chain and the contract framework. Node provider, indexer and client library sit behind standard interfaces (JSON-RPC, GraphQL, EIP-1193), so pick a reasonable default for each, keep them configurable, and revisit them only when quota, latency or price data from your own traffic says to.
Educational content, not financial advice. Crypto assets are volatile; do your own research.