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 / 19
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 / 19
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 / 19
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 / 19
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.'
6 / 19
Code Review Comment: 'This component is calling ethers.js directly to sign transactions. It's not ideal; we should be using a Web3 provider like WalletConnect for secure user interaction and abstracting away the complexities of signing. Can you explain your rationale?'
The comment highlights a security and abstraction concern. Directly using ethers.js for signing can be less secure and harder to maintain than utilizing a Web3 provider like WalletConnect, which handles the complexities of wallet integration and transaction signing securely. The correct answer reflects best practices for building robust Web3 applications.
7 / 19
Slack Message: 'Hey @johndoe, just ran into an issue deploying our NFT collection. The contract deployment failed with a transaction reverted. Any ideas?'
This question tests understanding of a common error in Web3 development. A 'transaction reverted' usually indicates an issue with gas fees or incorrect ABI definition. Increasing the gas limit is merely one potential solution, and contacting the blockchain provider isn't directly related to the immediate problem.
8 / 19
PR Description: 'This PR introduces support for claiming our new wagmi-based NFTs. We're using ethers.js to interact with the contract and provide a seamless user experience.'
This PR description focuses on a core feature – claiming NFTs using wagmi. The correct answer accurately identifies the use of wagmi's built-in claimable NFT functionality, which simplifies the process compared to manually handling transaction signing and contract interaction.
9 / 19
API Response: { "status": "success", "message": "Transaction signed successfully. Waiting for confirmation...", "chainId": "0", "transactionHash": "0xabcdef1234567890abcdef1234567890" }
This scenario presents an API response indicating a signed transaction. The correct answer reflects that the transaction has been successfully processed and is awaiting confirmation on the testnet (chainId: 0). A 'reverted' status would be indicated by a different message or status code.
10 / 19
Reviewer Comment: 'The `wagmi.js` library handles wallet connection and transaction signing internally. This code is attempting to re-implement this functionality with `ethers.js`. It's likely introducing unnecessary complexity and could be vulnerable if the underlying `wagmi.js` implementation isn't thoroughly audited. Consider leveraging the established security and features of wagmi instead.'
This question tests understanding of when to use established libraries versus implementing custom solutions. The correct answer reflects that using `wagmi` is a recommended practice due to its security focus and pre-built features. Options A and B misinterpret the reviewer's intention; option C incorrectly frames it as deeper knowledge, while option D is factually wrong.
11 / 19
'@alice_dev, we're seeing a high gas usage on our NFT minting flow. The logs show several transactions failing with 'out of gas' errors. What are some potential causes and how can we optimize this without significantly impacting the user experience? We need to investigate if the smart contract itself is inefficient or if users are attempting large mints simultaneously.'
This scenario assesses the ability to diagnose a common Web3 problem. High gas usage often indicates either inefficient contract logic or excessive concurrent requests. Option A suggests a more drastic solution than necessary; B doesn't address the root cause; and D is a possible contributing factor but not the primary driver of the issue.
12 / 19
'Good morning team. I've been working on integrating the new NFT claiming flow using wagmi. We're using ethers.js under the hood for some low-level interactions, but wagmi handles most of the wallet connection and transaction signing logic. Currently focusing on ensuring smooth integration with MetaMask and handling potential gas limit issues – we've been monitoring transaction success rates closely.'
This question tests the ability to articulate progress updates concisely and highlight key considerations. The correct answer demonstrates proactive problem-solving – specifically acknowledging and addressing potential issues like wallet integration and gas costs, which are crucial for Web3 development.
13 / 19
@bob_dev Slack message: "Just deployed the new NFT collection using wagmi. Transaction hash is 0x1234567890abcdef... but it's failing with 'transaction reverted'. Any thoughts?"
The message indicates a failed transaction. Low gas limits are a common cause of 'transaction reverted' errors when deploying smart contracts, especially complex ones. While ABI issues and wallet connection problems can also contribute, the phrasing strongly suggests a gas-related problem as the primary suspect. The options provide a range of potential causes, with insufficient gas being the most relevant.
14 / 19
Code Review Comment: 'This component uses ethers.js directly to handle wallet connections and transaction signing. While it works, consider migrating to the wagmi.js library – it provides a more streamlined and secure approach for integrating with Web3 wallets, abstracting away much of the underlying complexity.' What's the *primary* benefit of using wagmi.js in this scenario?
wagmi.js is designed to abstract away much of the complexity involved in interacting with Web3 wallets and blockchains. Its core value proposition lies in simplifying wallet integration and transaction signing – reducing development time and the risk of errors or security vulnerabilities associated with directly using ethers.js.
15 / 19
Sarah, a frontend developer working on an NFT collection project, is reviewing Mark's code. Mark has implemented the logic for claiming NFTs directly using ethers.js within a React component. Which statement best describes the issue?
const signer = new ethers.Wallet(userAddress);
const tx = new ethers.Contract(contractAddress, erc721EnumerableABI, signer).claim(...)
The core problem here isn't the direct use of `ethers.js`, but rather the lack of abstraction and potential issues with wallet integration and error handling. `ethers.js` is a powerful library, but wrapping it tightly within React components can make code harder to maintain and less secure.
Furthermore, proper gas management (which isn't evident in this snippet) is crucial for successful transactions; failing to consider this will likely result in 'out of gas' errors. The correct answer reflects the best approach for a production environment.
16 / 19
"Hey @david_dev, I'm seeing some unusually high gas costs on our minting flow. The logs show multiple transactions failing with 'out of gas'. What's the MOST likely reason?"
Gas is a direct measure of computational effort. If transactions consistently fail with 'out of gas' errors, it almost certainly means the smart contract code itself – the operations being performed – are computationally intensive and requiring more gas than anticipated.
While network congestion can *influence* gas prices, it's the *contract logic* that primarily determines the gas needed for each transaction. The incorrect options present misunderstandings about how gas works.
17 / 19
"Product Design is asking me to explain ENS and IPFS. They are confused by the concept of mapping a human-readable name to an Ethereum address. Which of the following BEST describes ENS?"
ENS stands for Ethereum Name Service – it's essentially a domain name system for Ethereum. It allows users to interact with smart contracts using friendly names instead of complex cryptographic addresses.
IPFS (InterPlanetary File System) is a separate technology used for storing those large files, but ENS handles the mapping of names *to* those addresses, making interactions much more manageable.
18 / 19
"You're debugging an NFT minting flow where transactions are constantly reverting. The logs show 'transaction reverted – unexpected opcode'. What does this likely indicate?"
The 'unexpected opcode' error signifies that the smart contract was attempting to execute a specific Ethereum Virtual Machine (EVM) instruction that isn't supported or compatible with the current network.
This can happen if the contract uses outdated or unsupported features or interacts with external contracts in an incompatible manner. It's *not* necessarily a problem with the user's wallet or NFT metadata.
19 / 19
"During a standup meeting, your team lead asks: 'What are we doing to ensure our NFT minting flow is secure and reliable?' Which of the following actions would be MOST appropriate for you to describe?"
The core of secure Web3 development is abstraction – hiding complex details from developers. `wagmi.js` provides this abstraction by handling wallet connections, signing transactions, and managing gas limits in a standardized and secure way.
This reduces the risk of errors and vulnerabilities compared to directly manipulating `ethers.js`. Focusing on UI or specific gas limits would be less impactful for overall security.
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 19 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 19 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.