From f3352cdeaf5985910c47f51a02f5e719cbc75591 Mon Sep 17 00:00:00 2001 From: Erik Marks Date: Tue, 10 Aug 2021 12:31:21 -0700 Subject: [PATCH] Fix typos, edit copy --- EIPS/eip-3326.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-3326.md b/EIPS/eip-3326.md index 035f29d2e6cf0a..800144b145887f 100644 --- a/EIPS/eip-3326.md +++ b/EIPS/eip-3326.md @@ -38,7 +38,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S ### `wallet_switchEthereumChain` The method accepts a single object parameter with a `chainId` field. -The method returns `null` if wallet switched its active chain, and an error otherwise. +The method returns `null` if the wallet switched its active chain, and an error otherwise. The method presupposes that the wallet has a concept of a single "active chain". The active chain is defined as the chain that the wallet is forwarding RPC requests to. @@ -102,8 +102,7 @@ To switch to the Goerli test chain: ## Rationale -`wallet_switchEthereumChain` is a simple method with a simple specification. -Its purpose is to provide dapps with a way of requesting to switch the wallet's active chain, which they would otherwise have to ask the user to do manually. +The purpose `wallet_switchEthereumChain` is to provide dapps with a way of requesting to switch the wallet's active chain, which they would otherwise have to ask the user to do manually. The method accepts a single object parameter to allow for future extensibility at virtually no cost to implementers and consumers. @@ -124,8 +123,7 @@ In light of this, the wallet should: ### Preserving User Privacy Automatically rejecting requests for chains that aren't supported or have yet to be added by the wallet allows requesters to infer which chains are supported by the wallet. -In the interest of preserving user privacy, implementers of `wallet_switchEthereumChain` should consider displaying user confirmations even in cases where the chain has yet to be added. -If the user denies the request, the wallet should return the same user rejection error as normal so that requesters cannot learn which chains are supported by the wallet without explicit permission to do so. +Wallet implementers should consider whether this communication channel violates any security properties of the wallet, and if so, take appropriate steps to mitigate it. ## Copyright