Frontend Minting and Integration Flashcards

Why should a frontend estimate gas (e.g., estimateGas) before submitting a mint transaction?

Answer: To catch reverts early and show the user an accurate fee preview

estimateGas simulates the call, surfacing reverts and giving a fee estimate before the user signs.

What is a common cause of a mint transaction reverting that a frontend should validate beforehand?

Answer: Exceeding the per-wallet mint limit enforced on-chain

Many contracts cap mints per wallet, so the UI should check the user's count before allowing another mint.

When supporting an allowlist mint, what does the frontend usually pass to the contract to prove eligibility?

Answer: A Merkle proof for the user's address

Allowlist mints typically verify a Merkle proof against a root stored on-chain, keeping gas low.

Why is it good UX to disable the mint button while a transaction is pending?

Answer: It prevents accidental duplicate transactions and wasted gas

Disabling the button during a pending tx stops users from submitting duplicate transactions.

What information from a confirmed transaction receipt can the frontend use to link the user to a block explorer?

Answer: The transaction hash

The transaction hash builds an explorer URL (e.g., etherscan.io/tx/) for the user to view their mint.

When a user rejects the MetaMask signature prompt, what error pattern should the frontend handle gracefully?

Answer: A user-rejection error (code 4001) without treating it as a crash

EIP-1193 returns code 4001 for user rejection, which should be handled as a normal cancellation, not a fatal error.

Why might a frontend prompt the user to switch networks using 'wallet_switchEthereumChain' before minting?

Answer: The contract is deployed on a specific chain the user must be on

Transactions must target the chain where the contract lives, so the UI prompts a switch if needed.