Offer a way to use the injected wallet's RPC

[gpxl-dev]

I've mentioned this in a separate thread, but I wanted to explicitly surface it as a suggestion, and add a little context.

Whilst I understand that app builders being able to pay for a premium RPC provider and supply their API keys for use in the app initially appears to be a good way to ensure people aren't going to have a poor experience from using potentially ropey public RPCs, we've actually found this has caused problems.

At times of unexpectedly high demand, centralising all visitors requests through a single RPC & key has resulted in rate limiting. Furthermore, those with the know-how weren't able to bypass or relieve the issue by using their own Alchemy/Infura keys as they would be able to on other sites.

Ultimately I feel there is a good case for some implementations to prefer using the RPC from an injected wallet where possible, and would really like to see this added to wagmi. In the interim I'd love to know the best way to monkey patch this in.

[jxom]

Totally agree! I definitely feel like there should be a way to utilise the injected wallet RPC. This has definitely been on our minds. We'll have a think about this!

[gpxl-dev]

Did you make any further progress on this? If not I may spend some time looking into how this could be done, I think it would be a great value add.

[timsoulm]

I'd like to second this proposal. Our team was pretty surprised to find this feature not supported after moving to wagmi from an earlier version of web3-react

[rsodre]

me too.
using the wallet provider has always been the default for me

[nfts2me]

+1

[Clonescody]

Agreed with this, calls can quickly overload smaller RPC keys, and having the flexibility to switch to the user wallet on some occasions could be nice.

[jxom]

After careful consideration, we have decided to not add the ability to switch to a wallet RPC, at least not right now.

Why? It kicks down the "rate-limiting can" to the user – what if the wallet's RPC ends up getting rate-limited? It is definitely not guaranteed that every wallet user will be using their own RPC endpoints & API keys. In fact, most users would be using public RPC endpoints – which are more vulnerable to rate-limiting.

The dapp will have no longer have control over the RPC
a. dapps will be putting their trust into a wallet RPC – what happens if that RPC becomes vulnerable to an attack (eg. sandwich attack)?
b. they will be unable to debug RPC errors that may have been initiated from the application

In the short term, we highly recommend configuring chains with multiple providers via configureChains – this allows the dapp to fall back to another provider when something goes wrong (ie. provider has reached their quota).

In the long term, we definitely want to have a more robust solution around dealing with multiple RPC providers, and minimizing side-effects that emit unneeded/redundant RPC requests – we are working on this!

UPDATE:
Some wallet extensions also do not support "public" RPC methods like eth_blockNumber, eth_call etc... Some wallets only support "signer" RPC methods like eth_sendTransaction, which makes sense. This means your application will break for those wallets.

[gpxl-dev]

Thanks for the response. I personally think this is a mistake, and that the choice should be with the developer. The opinion could be enforced via a default, with the developer being able to override by explicit config.

Is this a technically difficult thing to achieve given the current structure of wagmi?

[rsodre]

I feel the same way. It should be the developer's decision to measure pros and cons and decide which to use.

[tmm]

First-class support in wagmi is not a priority right now, but nothing is stopping you from adding this on your own by passing whatever you want as the wagmi Client's provider (as long as it is a valid Provider).

import { createClient } from 'wagmi'

const client = createClient({
  provider({ chainId }) {
    // return `Provider` - can use `chainId` to update return when it changes
    return window.ethereum
  },
})

Warning
The above code is psuedocode. I would strongly recommend not doing this for the reasons @jxom outlined above. In addition, this has not been fully tested with wagmi so there is no guarantee this works as expected.

[jxom]

Also, keep in mind that some wallet extensions do not support "public" RPC methods like eth_blockNumber, eth_call etc... Some wallets only support "signer" RPC methods like eth_sendTransaction, which makes sense.

[polus-arcticus]

Thanks for the clarification on this, I look forward to seeing this as part of the long term vision. Delegating RPC was never intended to be a long term solution, everyone should have their own nodes or light clients and interface with dapps through them. I think the viem wagmi walletconnect stack aught to be careful not metasticize to cloudflare or the temptations of the wallet connect project id

[rsodre]

Did it just got implemented in #1406?

[tmm]

InjectedConnector allows EIP-1193 providers (like MetaMask, Brave Wallet, Trust Wallet, and more) to connect, disconnect, switch chains, sign messages, send transactions, etc.

[firnprotocol]

ok, but MetaMaskConnector connector also lets me do those things, no?

assuming i'm only interested in using a wallet for which you already have an explicit connector—e.g., MetaMask—what can i do with InjectedConnector which I can't do with MetaMaskConnector?

[tmm]

MetaMaskConnector only targets MetaMask (since other injected providers sometimes pretend to be MetaMask). InjectedProvider supports the long tail of other injected providers and wallets. If you only use MetaMaskConnector, someone using Brave Wallet would not be able to connect to your app.

[firnprotocol]

ok, right—so my intuition was correct above when i said:

is the idea that some off-the-grid, unknown, or custom wallet can be used in this way, even when y'all (i.e., wagmi) haven't developed an explicit connector for it?

[tmm]

If they support, EIP-1193, then yes!

[adrianleb]

I was also in this situation recently and found this ongoing discussion, I understand the logic behind the wagmi team decision and agree with the points raised by @jxom, can't wait for how they solve it in future versions.

But also, I still wanted to monkey patch it for now, I hope they don't get mad at me for sharing how I did it.

Simply put, extending on what @tmm wrote above, I copied the publicProvider and modified it by, when available, using the window.web3.currentProvider within an ethers Web3Provider as described in the ethers docs.

You can see a code example below, use it at your own risk as this will probably break depending on what wallet you allow users to connect with and what your project is trying to do.

function walletOrPublicProvider({ priority, stallTimeout, weight }) {
  return function (chain) {
    if (!chain.rpcUrls.default.http[0]) return null
    return {
      chain: chain,
      provider: () => {

        // check if window.web3 is available and use it as the provider
        if (typeof window !== 'undefined' && window.web3) {

          const provider = new providers.Web3Provider(web3.currentProvider, {
            chainId: chain.id,
            name: chain.network,
            ensAddress: chain.contracts?.ensRegistry?.address,
          })
          return Object.assign(provider, { priority, stallTimeout, weight })
        }

        // default to the public provider
        const provider = new providers.StaticJsonRpcProvider(chain.rpcUrls.default.http[0], {
          chainId: chain.id,
          name: chain.network,
          ensAddress: chain.contracts?.ensRegistry?.address,
        })
        return Object.assign(provider, { priority, stallTimeout, weight })
      },
    }
  }
}

[diegoalzate]

does this work with wagmi and viem? trying to do it but it seems like wagmi expects now an rpc url and becuase of privacy reasons I can not get it from the extension.

UPDATE
Could create a way to use wallet provider rpc with viem and wagmi if any here is interested.
Use at your own risk.

type EthereumProvider = { request(...args: any): Promise<any> }
type WindowWithEthereum = { ethereum: EthereumProvider};

const config = createConfig({
  autoConnect: true,
  connectors: [new MetaMaskConnector({ chains })],
  publicClient: (chain) => {
    if (typeof window !== 'undefined' && typeof (window as unknown as WindowWithEthereum).ethereum !== 'undefined') {  
    // create a special client that sends rpc calls through wallet
      return createWalletClient({
        chain: gnosis,
        transport: custom((window as unknown as WindowWithEthereum).ethereum),
      }).extend(publicActions);
    }

    // no ethereum found in window
    return publicClient(chain);
  },
  webSocketPublicClient,
});

[jxom]

Wagmi v2 will support using an Injected Wallet's RPC:

https://beta.wagmi.sh/react/api/transports/unstable_connector

[firnprotocol]

you, sir, are a gentleman and a scholar!

what's the release ETA?

[tmm]

The beta is pretty stable and going to move to release candidate later this week. Stable release first week of January.