Comment connecter le portefeuille Coinbase à une DApp ?

Architecture d'intégration de portefeuille

1. Coinbase Wallet fonctionne comme un fournisseur injecté compatible avec les normes EIP-1193 et ​​EIP-1474. Il expose un objet Ethereum global dans le contexte du navigateur lorsqu'il est installé en tant qu'extension de navigateur ou lancé via des liens profonds mobiles.

2. Le portefeuille prend en charge à la fois le réseau principal Ethereum et plusieurs chaînes compatibles EVM, notamment Base, Optimism, Arbitrum et Polygon. La configuration de la chaîne doit s'aligner sur les paramètres réseau ciblés du DApp.

3. L'initiation de la connexion nécessite le consentement explicite de l'utilisateur via une interface modale. Aucune authentification automatique ou silencieuse n'est autorisée dans le cadre des politiques de sécurité actuelles appliquées par le SDK côté client de Coinbase Wallet.

4. La persistance de la session repose sur le stockage local limité à l'origine du domaine. Chaque dApp maintient son propre état de session isolé, empêchant ainsi les fuites d'état de portefeuille entre sites.

5. Les événements de déconnexion déclenchent la révocation immédiate de toutes les autorisations précédemment accordées, y compris les capacités d'exposition du compte et de signature de transactions.

Étapes de mise en œuvre du front-end

1. Importez le SDK officiel de Coinbase Wallet via npm : npm install @coinbase/wallet-sdk . Ce package comprend des interfaces typées, des utilitaires de gestion des erreurs et des wrappers de fournisseur prenant en compte la chaîne.

2. Instanciez le connecteur de portefeuille à l'aide de CoinbaseWalletSDK avec les champs obligatoires : appName, appLogoUrl et jsonRpcUrl correspondant au point de terminaison RPC de la blockchain cible.

3. Initialisez l'instance du fournisseur et appelez activate() pour lancer le flux de connexion. Cela ouvre un modal natif invitant l'utilisateur à approuver ou à refuser l'accès.

4. En cas de succès, l'objet fournisseur renvoyé émet des événements comptesChanged et chainChanged , permettant des mises à jour réactives de l'interface utilisateur pour l'adresse connectée et l'état du réseau.

5. Tous les appels de contrat ou soumissions de transactions ultérieurs doivent être acheminés via cette instance de fournisseur pour garantir que le routage des signatures reste cohérent avec la session active.

Mécanismes d'application de la sécurité

1. Chaque demande de transaction est soumise à une validation sur l'appareil avant la génération de la signature. Le portefeuille affiche tous les détails de la charge utile, notamment le destinataire, la valeur, les paramètres du gaz et les données d'appel de fonction.

2. Les interactions de contrats intelligents nécessitent une vérification explicite du nom de la fonction et du type de paramètre. Le décodage ABI est effectué localement dans l'environnement d'exécution en bac à sable du portefeuille.

3. Les transactions rejetées sont enregistrées dans la piste d'audit interne du portefeuille avec des horodatages et des hachages d'opération, accessibles uniquement à l'utilisateur via l'onglet historique du portefeuille.

4. La détection du phishing s'exécute en temps réel sur les domaines malveillants connus. Toute tentative de connexion à partir d’une origine sur liste noire déclenche une bannière d’avertissement immédiate et bloque toute interaction ultérieure.

5. Le matériel de clé privée ne quitte jamais l’enclave sécurisée de l’appareil. Les opérations de signature se produisent exclusivement au sein du module cryptographique isolé du portefeuille.

Portées des autorisations courantes

1. eth_accounts : accorde un accès en lecture seule à l'adresse Ethereum actuellement sélectionnée. Requis pour la détection de base du portefeuille et l’affichage du solde.

2. eth_signTypedData_v4 : Active la signature de messages structurés conforme à EIP-712. Utilisé pour les flux de connexion et les attestations hors chaîne.

3. eth_sendTransaction : Autorise la diffusion des transactions Ethereum signées. Déclenché uniquement après confirmation manuelle de l'utilisateur.

4. personal_sign : prend en charge la signature en texte brut héritée. Obsolète au profit des données saisies mais conservées pour des raisons de compatibilité ascendante.

5. eth_sign : Permet la signature de hachage brut. Limité aux dApps sur liste blanche avec des scores de réputation de domaine vérifiés.

Foire aux questions

Q : Pourquoi Coinbase Wallet rejette-t-il les tentatives de connexion de localhost pendant le développement ? R : Par défaut, le portefeuille applique uniquement les origines HTTPS pour des raisons de sécurité. Les développeurs doivent servir leur dApp locale via HTTPS à l'aide d'outils tels que mkcert ou utiliser la bascule du mode développeur du portefeuille disponible dans les paramètres.

Q : Puis-je changer de réseau par programmation après la connexion ? R : Oui, via la méthode RPC wallet_switchEthereumChain . Le portefeuille affiche un écran de confirmation répertoriant l'ID de la chaîne cible, l'URL de l'explorateur de blocs et le symbole monétaire natif avant d'appliquer la modification.

Q : Que se passe-t-il si l'utilisateur modifie le compte sélectionné dans le portefeuille alors qu'il est connecté ? R : Le portefeuille émet un événement accountChanged contenant le nouveau tableau d’adresses. Les DApp doivent écouter cet événement et mettre à jour les éléments de l'interface utilisateur en conséquence sans nécessiter de reconnexion.

Q : Est-il possible de détecter si Coinbase Wallet est installé sans déclencher une invite de connexion ? R : Oui, en vérifiant la présence de window.ethereum?.isCoinbaseWallet avant d'appeler une méthode d'activation. Cette propriété renvoie vrai uniquement lorsque l'extension de portefeuille officielle ou l'application mobile est détectée.