How to connect a wallet to a dApp? (Web3 basics)

Understanding Wallet Integration Mechanics

1. A decentralized application relies on a cryptographic identity to authenticate users and sign transactions. This identity resides in a wallet, which holds private keys and manages digital signatures.

2. Wallets like MetaMask, Phantom, or Trust Wallet expose a standardized interface known as the Ethereum Provider API (EIP-1193), allowing dApps to detect and communicate with them.

3. When a dApp initializes, it checks for the presence of window.ethereum or similar provider objects injected by browser extensions or mobile wallets.

4. The absence of such an object triggers fallback logic—either prompting installation or suggesting a wallet-connect modal for mobile users.

5. Once detected, the dApp requests permission to access the user’s accounts using ethereum.request({ method: 'eth_requestAccounts' }), initiating a secure, user-approved handshake.

Handling Connection States and Events

1. Wallet connection is not static—it can change due to account switching, network switching, or disconnection. dApps must listen for events like 'accountsChanged', 'chainChanged', and 'disconnect'.

2. The 'accountsChanged' event fires when the user selects a different account or removes access. It delivers an array of new addresses or an empty array if permissions are revoked.

3. The 'chainChanged' event signals a switch between networks (e.g., Ethereum Mainnet to Sepolia). Applications must reload or reinitialize contract instances accordingly.

4. Disconnection may occur silently—especially after wallet lock or extension disablement—so periodic health checks via ethereum.isConnected() help maintain UI consistency.

5. Persistent state management requires storing the selected chain ID and account address in memory or local storage, but never the private key or seed phrase.

Signing Transactions Without Exposing Secrets

1. All transaction signing happens inside the wallet environment—not in the dApp’s JavaScript context. The dApp constructs raw transaction parameters and passes them to ethereum.request({ method: 'eth_sendTransaction', params: [...] }).

2. The wallet renders a confirmation UI showing recipient, value, gas estimates, and data payload. Users approve or reject without exposing their private key to any external code.

3. For off-chain messages—like login challenges or governance votes—the dApp uses personal_sign or eth_signTypedData_v4 to request cryptographically verifiable signatures.

4. Typed data signing enforces structured domain separation and prevents replay across chains or applications through domain-specific salt and versioning.

5. Signature verification on-chain or in backend services relies on ecrecover or equivalent cryptographic primitives to derive the signer’s address from the signature and message hash.

WalletConnect Protocol for Mobile and Non-Extension Scenarios

1. WalletConnect v2 establishes end-to-end encrypted sessions between dApps and wallets using relay servers and pairing URIs. It avoids browser injection entirely.

2. The dApp generates a session proposal containing required chains, methods, and metadata, then displays a QR code containing a pairing URI.

3. The user scans the QR code with a compatible wallet app—such as Rainbow or Coinbase Wallet—which validates the proposal before approving the session.

4. Once connected, all JSON-RPC requests flow through the relay network, with encryption keys negotiated during pairing and rotated per session.

5. Session persistence is managed client-side; revocation occurs when either party calls session.disconnect(), invalidating all associated keys and clearing stored metadata.

Frequently Asked Questions

Q1: Can a dApp read my private key during connection?A1. No. Wallets never expose private keys to dApps. Signing always occurs within the wallet’s secure boundary.

Q2: Why does my wallet ask for approval every time I switch networks?A2. Each EVM-compatible chain has its own namespace and account derivation path. Permissions are scoped per chain, requiring explicit re-approval.

Q3: What happens if I clear my browser cache after connecting?A3. Connection state is lost unless the dApp implements session recovery via WalletConnect or stores non-sensitive identifiers like wallet address and chain ID separately.

Q4: Is it safe to connect to a dApp that isn’t verified on Etherscan?A4. No. Unverified dApps may inject malicious scripts or spoof wallet prompts. Always verify contract addresses, check domain legitimacy, and avoid entering seed phrases anywhere.