Developer resources for every chain

Testnets

A testnet is a separate blockchain network that mirrors mainnet functionality using tokens with no monetary value. Developers deploy smart contracts, simulate transactions, test gas estimation, and debug reverts on testnets before committing real assets on mainnet. Without testnets, every bug costs money.

Testnet architectures vary. Ethereum's Sepolia is a proof-of-stake network that replaced the older Goerli testnet. Holesky runs as a separate beacon chain testnet for staking and validator testing. Solana uses Devnet (persistent, reset periodically) and Testnet (validator performance testing). Cosmos SDK chains typically run their own independent testnets with separate chain IDs and genesis files. L2 testnets (Arbitrum Sepolia, Base Sepolia, OP Sepolia) settle to Ethereum Sepolia, so their state depends on the L1 testnet remaining operational.

Deprecation is a recurring problem. Ropsten, Rinkeby, Kovan, and Goerli are all deprecated. Projects that hardcoded testnet configurations had to migrate. Sepolia is now the standard EVM testnet, but individual L2s may introduce and retire their own test networks independently. Key parameters to verify for any testnet: chain ID, block time, finality model, which EIPs are supported, and whether the network has a reliable block explorer.

Multi-chain applications complicate testing. If a protocol deploys on Ethereum mainnet and bridges to Arbitrum and Base, the developer needs testnet environments for all three, with a working bridge between them. L2 testnets that settle to Sepolia support this, but cross-chain message testing remains one of the harder parts of multi-chain development. Testnet directory.

RPC endpoints

An RPC endpoint is a URL that applications use to read from and write to a blockchain. The interface is JSON-RPC: the client sends a JSON payload with a method name and parameters, the node processes it, and returns the result. Core methods include eth_call (read contract state without a transaction), eth_getBalance (check an address's native token balance), eth_sendRawTransaction (submit a signed transaction), and eth_getLogs (retrieve event logs filtered by address, topic, or block range). Non-EVM chains use different interfaces: Solana has its own JSON-RPC spec, Cosmos chains use gRPC and REST, Substrate chains use a WebSocket-based API.

Public RPCs are free endpoints maintained by chain foundations or community operators. They have rate limits (typically 10 to 100 requests per second), no uptime guarantees, and limited historical data. Private RPC providers (Alchemy, Infura, QuickNode, Blast API, dRPC, Chainstack) offer dedicated throughput, WebSocket connections for streaming events, archive node access for querying historical state at any block height, and SLA-backed availability. Production applications and analytics pipelines require private RPCs. Development and testing can often use public endpoints.

The distinction between full nodes and archive nodes matters for anyone building analytics or block explorers. A full node stores the current state and recent blocks. An archive node stores every historical state trie, allowing queries like "what was this contract's storage slot at block 15,000,000." Archive nodes require significantly more storage (Ethereum archive nodes exceed 15 TB) and most free RPC providers do not offer archive access.

WebSocket connections (wss://) allow the client to subscribe to new blocks, pending transactions, or specific contract events in real time. HTTP connections require polling. For applications that need to react to on-chain events within seconds (liquidation bots, MEV searchers, real-time dashboards), WebSocket RPCs are necessary. For batch data retrieval or occasional reads, HTTP is sufficient. Self-hosted nodes (Geth, Reth, Nethermind for execution; Lighthouse, Prysm, Teku for consensus) eliminate provider dependencies but require infrastructure maintenance. RPC directory.

Faucets

A faucet is a service that distributes test tokens to developer wallets. Deploying a contract on Sepolia costs test ETH for gas. Interacting with the deployed contract costs more test ETH. Without a faucet, developers cannot test anything. Most faucets distribute between 0.01 and 0.5 test ETH per request, with cooldown periods of 24 hours between claims.

Authentication requirements vary. Some faucets are open: paste an address, receive tokens. Others require signing in with a GitHub or Google account. Alchemy's Sepolia faucet requires an Alchemy account. PoW faucets make you solve a mining puzzle to prove you are not a bot. The anti-abuse measures exist because bots drain open faucets within hours of deployment, leaving real developers with no tokens.

Multi-chain development requires faucets for each target network. Testing on Arbitrum Sepolia, Base Sepolia, and OP Sepolia means three separate faucet requests. An alternative for L2 testnets: get Sepolia ETH from one faucet, then bridge it to the L2 testnet using the chain's official bridge. This works because L2 testnets settle to Ethereum Sepolia, so the bridge infrastructure operates on testnet as well. For non-EVM chains, faucet infrastructure is chain-specific: Solana Devnet has its own airdrop command (solana airdrop 2), Cosmos testnets use Discord bots, and Sui has a CLI faucet. Faucet directory.

Wallets for development

Browser extension wallets are the primary interface between a developer and a blockchain during development. MetaMask is the standard for EVM chains. It injects a provider object into the browser's JavaScript context, which dApps use to request account access, sign transactions, and switch networks. Rabby supports most EVM networks and adds transaction simulation before signing. Both allow adding custom RPC URLs, which is required for connecting to testnets and L2 networks not included in the wallet's default network list.

Adding a custom network to MetaMask or Rabby requires four values: the RPC URL, chain ID, currency symbol, and block explorer URL. Getting any of these wrong results in failed transactions or connections to the wrong network. The Builder Hub's RPC pages list these values for every supported chain, eliminating the need to hunt through documentation.

Chain-specific wallets serve non-EVM ecosystems. Phantom is the standard wallet for Solana. Keplr handles Cosmos SDK chains (Cosmos Hub, Osmosis, Sei, Berachain). Polkadot.js covers Substrate-based networks. Sui Wallet and Martian handle Move chains. For development teams building cross-chain applications, maintaining multiple wallets with multiple accounts on multiple networks is unavoidable.

Programmatic wallets are used in automated testing and CI/CD pipelines. In ethers.js, new Wallet(privateKey) creates a signer that can submit transactions without a browser extension. Viem's privateKeyToAccount does the same. Hardhat and Foundry both support configuring test accounts with private keys for scripted deployments. Hardware wallets (Ledger, Trezor) are relevant for testing multisig flows and production deployment signing, where the deployer key should not exist as plaintext on a development machine. Wallet directory.

How data is maintained

The Builder Hub is backed by a Notion CMS. Each chain and each resource category exists as a structured page in Notion. The DIA team maintains these pages directly: adding new chains at testnet or mainnet launch, updating RPC URLs when providers change endpoints, removing faucet links that go offline, and reflecting wallet support changes as extensions add or drop networks.

Verification is manual. RPC endpoints are tested for availability and correct chain ID responses. Faucet links are checked for functionality and token distribution. Wallet listings reflect current compatibility as confirmed in the wallet's documentation or release notes. Testnet configurations are validated against the chain's official documentation, including chain ID, block explorer URL, and native currency symbol.

Content is published through DIA's infrastructure with ISR (Incremental Static Regeneration) on a 60-second revalidation cycle. When the Notion source is updated, the next page request after the revalidation window triggers a rebuild with fresh data. This means changes propagate to the live site within minutes of being saved in Notion, without requiring a full deployment.

Data sources and methodology.