The accountChanged event isn’t working on ethers Providers

[mightymatth]

In ethers version 5.1.4, a way of subscribing to Metamask (Web3Provider) events is broken:

1. The types are wrong. It lets you create a provider and subscribe to the provider's events, but it doesn't get subscribed to Metamask events.
2. The documentation is misleading about this topic.

The example:

// Register Metamask as provider
const provider = new ethers.providers.Web3Provider((<any>window).ethereum);
// Choose at least 2 accounts so you can switch between them.
const _accounts: string[] = await provider.send('eth_requestAccounts', []);

// According to [docs](https://docs.ethers.io/v5/api/providers/provider/#Provider--event-methods)
// and types definition, this should work, but it doesn't get registered (silently fails).
provider.on('accountsChanged', (accounts: string[]) => {
  console.log('accountsChanged on provider (on Web3Provider)');
});

// This works, but it's required to ignore types on Web3Provider and pull the Proxy object
// on which we can register the listeners.
(<any>provider).provider.on('accountsChanged', (accounts: string[]) => {
  console.log('accountsChanged on provider.provider (on Proxy)');
});

Full working example:

• code: https://stackblitz.com/edit/angular-ivy-fhcwrw?file=src/app/app.component.ts
• website: https://angular-ivy-fhcwrw.stackblitz.io

Ways to reproduce:

• have Metamask installed,
• open website,
• choose at least 2 Metamask accounts so you can switch between them,
• open dev console,
• try switching between accounts in Metamask.

[ricmoo]

The accountChanged event is an EIP-1193-specific event, not one that ethers supports. In the future a similar event will be available, although likely not on the Provider object, the Signer object (which will probably emit an "invalidated" event; but that’s still being thought out and experimented with). Keep in mind in ethers Signer-specific information is kept on Signers and not affiliated with a Provider. And an ethers Provider is not related to an EIP-1193 Provider. In hindsight, I wish I’d chosen a different name.

You will need to use the window.ethereum.on method to listen to EIP-1193-specific events.

For a list of events that ethers providers, see this link.

Does that make sense? :)

(moving to discussions)

[mightymatth]

@ricmoo thanks for the reply. It makes sense, but it would be really handy to have Proxy object exposed on Provider or Signer object so we don't need to cast it to any and then call .provider to pick it up and subscribe to Metamask-specific events. If we already initialize Metamask Web3Provider with window.ethereum object, it seems redundant to repeat yourself again. We all can agree that Metamask is the most popular provider (Signer) used nowadays and subscribing to network and account changes is very crucial for a decent UX on frontend parts. Maybe adding the examples for making Web3Provider specific events wouldn't be that bad.

[ricmoo]

Proxy will not be introduced until v6, as v5 is designed to be ES3-compliant, which unfortunately precludes Proxy.

But in your case, the Proxy object won't really solve the problem. The ExternalProvider type is more vague than an EIP-1193-compliant provider (which is itself relatively new), since ExternalProvider supports a large host of legacy providers, such as Web3.js' providers and web3-like provider.

If you need to use the .provider property, it is only available on Web3Provider, so your code would actually have a dependency on a Web3Provider and Provider is not sufficient, and would fail if any other was used. So, consider:

// This sounds like the sort of thing you have, which requires the cast to `any`, and would
// fail unexpectedly if a non-Web3Provider was used
function doSomething(provider: Provider): void {
  provider.on("block", () => { ... });
  (<any>provider).provider.on("accountChanged", (account) => { ... });
}

// But what you probably want in this case, since you *depend* on provider.provider:

interface Eip1193Provider extends ExternalProvider {
  on(eventName: string, listener: (account: string) => void): this;
}

interface WrappedProvder extends Web3Provider {
  provider: Eip1193Provider;
}

function doSomethingSpecific(provider: WrappedProvider): void {
  provider.on("block", () => { ... });
  // no cast necessary, since you specified the specific type in the signature
  provider.provider.on("accountChanged", (account) => { ... });
}

I haven't tried that out though, so even that may not work, it's just off the top of my head.

It might make sense in the future for me to template the Web3Provider, so the type definition of the wrapped provider could be included, for example:

interface LegacyWeb3Provider extends ExternalProvider { ... }
interface Eip1193Provider extends ExternalProvider { ... }
class Web3Provider<T extends ExternalProvider = ExternalProvider> extends BaseProvider {
  provider: T;
}

// Now existing code would work as it does today, but anyone who wanted could explicitly specify:
function doSomething(provider: Web3Provider<Eip1193Provider>): void { ... }

This would allow some extra type-checking, but I would need to add the constraint to the type too. I'll add it to my "mull over" list. :)

[mightymatth]

Sorry for the late response, I missed the comment.
Thank you for the explanation, this helps a lot. A basic wrapper idea is just what I need for now to keep type-checking on provider.

The ExternalProvider type is more vague than an EIP-1193-compliant provider (which is itself relatively new), since ExternalProvider supports a large host of legacy providers, such as Web3.js' providers and web3-like provider.

In relation to this, I am curious if there are any examples of implementation of some 3rd-party providers (signers) such as Metamask or Arkane that are maintained by community. For example, if I want to wrap Metamask and Arkane web3-like provider to ethers provider (signer), what would be preferred way of implementing it? By extending JsonRpcProvider, or JsonRpcSigner, or ExternalProvider? Sorry about this noobish question, but some example of implementing these would help me gather the important parts implementing a custom provider (signer).

[harshitsinghai77]

.provider

Thanks a lot. This works.

const setAccountListener = (provider) => {
    provider.provider.on("accountsChanged", (accounts) => {
      setAccount(accounts[0]);
    });
  };

[mightymatth]

@ricmoo, it seems like provider.provider.on("accountsChanged", ...) doesn't work anymore because in v6 BrowserProvider we don't keep a reference to our subprovider (e.g. Metamask in window.ethereum) like we used to do in v5 Web3Provider, but rather pass this reference in the closure during BrowserProvider construction.
I see that it's an elegant solution, but again we cannot access the "real" subprovider to do stuff like subscribing to accountsChanged event, read its specific properties, and so on.

It's not always the case that this subprovider is on window.ethereum so we can access it whenever we want.
Sometimes we:

// create subprovider in place
const subprovider = new CustomProvider(opts)

// pass it to create ethers BrowserProvider instance
const provider = new BrowserProvider(subprovider, 'any')

// then pass this provider further (or convert it to signer) and use it in the app
return provider

Currently, we need to keep track of both; ethers provider and our custom provider. However, it would be handy if this custom provider could be fetched via ethers provider/signer.

Is there anything I'm missing in v6? I haven't been around here for a while.

Thanks!

[formysister]

Without using ethers.js provider, you can monitoring account change event for browser wallet.

// Check if MetaMask is available
if (typeof window.ethereum !== "undefined") {
  // Listen to account change events
  window.ethereum.on("accountsChanged", (accounts) => {
    console.log("MetaMask account changed:", accounts[0]);
  });
} else {
  console.log("MetaMask not detected");
}

Secondly, update ethers.js version and try following code.

import { ethers } from 'ethers';

// Create an ethers provider using Metamask as the provider
const provider = new ethers.providers.Web3Provider(window.ethereum);

// Request permission to access accounts
window.ethereum.request({ method: 'eth_requestAccounts' })
  .then((accounts) => {
    // Listen for the 'accountsChanged' event
    provider.on('accountsChanged', (newAccounts) => {
      // Handle the account change event
      console.log('Account changed:', newAccounts[0]);
    });
  })
  .catch((error) => {
    // Handle error if permission is denied
    console.error('Permission denied:', error);
  });