A Web3 developer explains wallet connection to a traditional web developer: "In Web3, there's no username/password login. Users connect with a crypto wallet — MetaMask, Coinbase Wallet, WalletConnect. The wallet holds the user's private key. When they 'connect wallet,' your dApp requests access to their public address. To verify identity, you ask them to sign a message — the signature proves they control the private key without revealing it. wagmi is a React hooks library that abstracts all wallet connection logic: useAccount(), useConnect(), useDisconnect(), useSignMessage()." What is the difference between a provider and a signer in ethers.js?
Provider: a read-only connection to an Ethereum node (via RPC). Operations: get balance, read contract state (view functions), get transaction by hash, get block number, estimate gas. Examples: JsonRpcProvider (any RPC URL), BrowserProvider (window.ethereum from MetaMask). Signer: a provider + private key. Enables: signing messages, signing transactions, sending transactions to the network. In a dApp: the user's wallet IS the signer. wagmi vocabulary: useAccount(): returns the connected account address and connection status. useConnect(): initiates wallet connection with a specific connector. useDisconnect(): disconnects the wallet. useBalance(): queries ETH or token balance. useContractRead(): reads from a smart contract. useContractWrite(): writes to a smart contract. useWaitForTransactionReceipt(): waits for transaction confirmation. Connector: wagmi abstraction for a wallet type (MetaMaskConnector, WalletConnectConnector, CoinbaseWalletConnector). window.ethereum: the EIP-1193 provider injected by browser extension wallets. In conversation: 'For read-only dashboards, we use a public provider (Infura, Alchemy). As soon as the user needs to sign anything — transaction, message — we need a signer from their wallet.'
2 / 5
A developer explains smart contract interaction to a new team member: "To interact with a smart contract from the frontend, you need two things: the contract address (where it's deployed on-chain) and the ABI — Application Binary Interface. The ABI describes the contract's functions: their names, input parameters, output types, and whether they modify state. Read functions (view/pure) are free — they don't cost gas and don't require a signer. Write functions modify blockchain state — they require a transaction, cost gas, and need the user's signature." What is the ABI and why is it required to interact with a smart contract from the frontend?
ABI (Application Binary Interface): a JSON array describing a smart contract's public interface. Contains: function names, parameter names and types (uint256, address, bytes32, string, bool, etc.), return types, whether a function is view/pure/payable, events (with indexed parameters). Why needed: Ethereum transactions are binary — function calls are ABI-encoded. ethers.js uses the ABI to: encode function arguments into call data, decode the returned bytes back into readable values. Without the ABI, you'd have to manually encode/decode hex. Smart contract vocabulary: View function: reads blockchain state, returns a value, no state modification, no gas cost (when called off-chain), no transaction needed. Write function: modifies state. Requires a transaction (signed + broadcast). Costs gas. Returns a transaction hash (not the result — the result is in the receipt/event). Event: emitted by contracts when state changes. Indexed in the blockchain, queryable by the frontend. Event log: the record of an event emission in a transaction receipt. Contract address: the deployed contract's address on a specific chain. Bytecode: the compiled EVM binary of the contract. Not needed by the frontend — only the ABI. In conversation: 'Copy the ABI from the Hardhat artifact or from Etherscan. Without it, your contract calls are blind — you're sending raw hex bytes.'
3 / 5
A Web3 developer explains gas to a developer who just got a 'transaction reverted' error: "Gas is the unit measuring computational cost in Ethereum. Every transaction costs gas — more complex operations cost more. You set a gas limit (maximum gas you're willing to use) and a gas price (in Gwei, how much you pay per unit). Total cost: gas used × gas price. If your gas limit is too low, the transaction runs out of gas and reverts — but you still pay for gas up to that point. EIP-1559 introduced a base fee (burned, not paid to miners) and a priority fee (tip to validators). Setting gas limit 20% above the estimate is standard." What is a nonce in Ethereum and why does it matter?
Nonce: a per-account, monotonically increasing integer. Starts at 0. Each sent transaction increments it by 1. Purpose: ordering — transactions execute in nonce order. Replay protection — a transaction can't be rebroadcast on the same network (nonce already used). Stuck transaction: if your nonce 5 transaction is stuck (low gas price), nonce 6 and later can't execute until nonce 5 is resolved. Fix: resubmit nonce 5 with higher gas price ("speed up" in MetaMask). Gas vocabulary: Gas: unit of computational work. Gas limit: max gas you allow the transaction to use. Under-estimate: transaction reverts, you pay for gas used up to the limit. Gas price: Gwei per unit of gas. Gwei: 1 billion Gwei = 1 ETH. Base fee (EIP-1559): market-determined fee, burned. Adjusts per block based on demand. Priority fee (tip): paid to the validator. Incentivises inclusion. Max fee: the maximum total fee (base fee + tip) you'll pay. Transaction hash: the unique identifier of a submitted transaction. 0x + 64 hex chars. Receipt: returned after transaction confirmation. Contains: gas used, logs (events), status (success/fail), block number, transaction index. Confirmation: each new block on top of the block containing the transaction. More confirmations = more secure. In conversation: 'Always add 20-30% to the estimated gas limit. A failed transaction that used all the gas is the worst outcome — state reverted, gas wasted.'
4 / 5
A Web3 developer explains ENS and IPFS to a product designer: "ENS — Ethereum Name Service — maps human-readable names like 'vitalik.eth' to Ethereum addresses. Instead of copying a 42-character hex address, users send to 'vitalik.eth.' dApps resolve ENS names using ethers.js: provider.resolveName('vitalik.eth') returns the address. IPFS — InterPlanetary File System — is a decentralised file storage network. Instead of a URL pointing to a server, IPFS uses a CID — Content Identifier — derived from the file's content hash. The same content always has the same CID, anywhere in the world." What is content addressing in IPFS and how does it differ from location addressing (traditional URLs)?
Content Identifier (CID): a hash-based address derived from the content itself. ipfs://QmXoypiz... or ipfs://bafybeig... Properties: deterministic (same content = same CID, always), immutable (change the content = new CID), self-verifying (you can verify you got the right file by hashing it). Location addressing (HTTP): https://server.com/file.jpg identifies where the file is, not what it is. Problems: the server can change the file (same URL, different content — no way to know). The server can go down (broken links). IPFS use cases in Web3: NFT metadata and images (store off-chain assets that can't change), dApp frontends (host on IPFS so the app is censorship-resistant), decentralised document storage. IPFS vocabulary: IPFS gateway: HTTP bridge to IPFS content (ipfs.io/ipfs/CID, Cloudflare IPFS gateway). Allows accessing IPFS content via a browser without IPFS node. Pinning: explicitly keeping content available on IPFS. Without pinning, content may be garbage collected. Pinning services: Pinata, Infura IPFS, nft.storage. IPNS: InterPlanetary Name System — mutable pointer to IPFS content (like a DNS name for IPFS). Filecoin: incentive layer on top of IPFS — pay to have content stored persistently. In conversation: 'We store NFT images on IPFS with Pinata. The metadata JSON in the smart contract references the IPFS CID — if we ever changed the image, the CID would change, making any tampering detectable.'
5 / 5
A Web3 senior developer explains testnet workflow to a junior developer: "Never test with real ETH. Use testnets — Ethereum networks with fake ETH you get from a faucet. Sepolia is the current standard testnet. Your MetaMask has a 'Show test networks' option. Deploy your contract to Sepolia first, test all interactions, then deploy to mainnet. Your RPC endpoint is the node you connect to — we use Alchemy or Infura. Chain ID identifies the network: Ethereum mainnet is 1, Sepolia is 11155111. Your contract address is different on every network — you need to track which address corresponds to which chain." What is an RPC endpoint in Web3 and why do most dApps use a service like Alchemy or Infura?
RPC (Remote Procedure Call) endpoint: a URL that exposes Ethereum's JSON-RPC API. Standard methods: eth_call (read contract state), eth_sendRawTransaction (broadcast a transaction), eth_getBalance, eth_blockNumber, eth_getLogs. Used by ethers.js, wagmi, web3.js to communicate with the blockchain. Why not self-host? A full Ethereum node requires: 1+ TB SSD, significant bandwidth, ~1 week initial sync, 24/7 uptime. Alchemy/Infura provide: managed nodes, 99.9% uptime SLA, enhanced APIs (getAssetTransfers, NFT APIs), webhooks, analytics. Web3 infrastructure vocabulary: JSON-RPC: the protocol Ethereum nodes expose. Request: {"jsonrpc":"2.0","method":"eth_blockNumber"}. WebSocket RPC: for subscriptions (new blocks, pending transactions). Chain ID: integer identifying the network. Prevents replay attacks across chains. Mainnet: 1. Sepolia: 11155111. Polygon: 137. Arbitrum: 42161. Faucet: a service that gives free testnet ETH. sepoliafaucet.com, Alchemy Faucet. Block explorer: Etherscan (mainnet), Sepolia Etherscan. View transactions, contract code, events. Multicall: batch multiple contract reads into a single RPC call. Reduces latency and API rate limit usage. Rate limit: free Alchemy/Infura tiers have request limits. In conversation: 'We use Alchemy for production — the enhanced APIs and analytics are worth it. For local development, we use Hardhat's built-in node — 1,000x faster than testnet.'
What does the "Web3 Frontend Vocabulary (wagmi, ethers.js)" vocabulary exercise cover?
This exercise tests real IT vocabulary related to web3 frontend vocabulary (wagmi, ethers.js) through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.