What this prompt does
This prompt specifies a complete Web3 wallet integration for a [frontend_framework] app, the layer where dapps most often lose users to confusing errors. You define the [smart_contracts], [target_chains], and [user_actions], and it builds connection via [wallet_library] supporting [wallet_list], network management, a transaction flow for [primary_transaction], contract reads, event listening, error handling, and mobile support.
The structure works because wallet UX is a sequence of edge cases. It handles network switching to [primary_chain], gas estimation with a [gas_buffer] buffer, confirmation modals, and graceful handling of rejection and insufficient funds. By also specifying contract reads via [read_method] refreshing every [refresh_interval], event subscriptions for [contract_events], mapping of [common_errors] to friendly messages, and deep-linking to [mobile_wallets], the whole connect-to-confirm path is designed up front rather than patched after launch. Connection state lives in [state_management], and a [multi_chain_strategy] keeps the provider and contract addresses correct as users move between [target_chains].
When to use it
- You are building a dapp frontend and want the wallet flow specified before coding
- You need multi-wallet support across
[wallet_list]with auto-reconnect - You want network detection and switching to
[primary_chain]handled cleanly - You need a two-step transaction flow like approve-then-stake done right
- You want
[common_errors]mapped to messages users can actually act on - You need live contract reads that refresh and update the UI automatically
- You need mobile support with deep-linking and WalletConnect
Example output
Expect an implementation spec for [frontend_framework]: a connect button with a wallet-selection modal using [wallet_library], auto-reconnect and disconnect logic, a network indicator with switching via wallet_switchEthereumChain, a transaction flow for [primary_transaction] with gas estimation plus [gas_buffer] and a confirmation modal showing cost in ETH and USD, contract reads via [read_method] refreshing every [refresh_interval] with multicall for [batch_reads], event subscriptions for [contract_events] with toast notifications for [user_notifications], an error map for [common_errors], and mobile deep-linking to [mobile_wallets]. Transaction status tracking from pending through a [block_confirmations] wait is included so users always know where their action stands.
Pro tips
- Name your real
[smart_contracts]and[target_chains]so the contract-address switching logic matches your deployment - Use a maintained
[wallet_library]like wagmi + viem; rolling your own provider handling is where subtle reconnect bugs live - Map every entry in
[common_errors]to a human message — "user rejected" and "insufficient funds" should never surface as raw RPC text - Add the
[gas_buffer]to estimates so transactions do not fail at the wallet on a tight estimate - Use multicall for
[batch_reads]to cut RPC calls; firing one request per value will rate-limit you fast - Test the two-step
[primary_transaction]flow carefully; approve-then-stake is where users get stuck mid-sequence - Verify mobile deep-linking to each of the
[mobile_wallets]on a real device, since desktop emulation hides the WalletConnect handoff issues
