Adding API tokens to default provider

[cliffhall]

The documentation suggests we use getDefaultProvider unless running our own nodes:

ethers . getDefaultProvider( [ network = “homestead” ] ) => Provider
This creates a FallbackProvider backed by multiple backends (INFURA and Etherscan).

This is the recommended method of connecting to the Ethereum network if you are not running your own Ethereum node.

However, Etherscan says:

Note: Starting from February 15th, 2020, all developers are required to use a valid API key to access the API services provided by Etherscan. Learn More.

Both the EtherscanProvider and the InfuraProvider give us a way to pass these API tokens:

new ethers . providers . EtherscanProvider( [ network = “homestead” ] [ , apiToken ] )
new ethers . providers . InfuraProvider( [ network = “homestead” ] [ , apiAccessToken ] )

It seems that if getDefaultProvider doesn't provide the ability to add API tokens for the Etherscan and Infura providers that it creates that we won't really be getting the benefit of the fallback. Based on their statement, it seems Etherscan will just not work without the API token. Looking at Infura, the docs all suggest a project id is required for access to its API.

I have dapp that is working, but I want to understand whether the more appropriate and reliable thing to do would be to create an EthereumProvider and an InfuraProvider with my API tokens
and finally build a FallbackProvider using those other two providers as opposed to using getDefaultProvider which doesn't allow me to send any API tokens.

Any advice from the team on this matter?

[cliffhall]

I noticed that you add a default Etherscan API key in this commit: a930047 and a default Infura project id in this commit: 9f201c3

That's cool, but if a lot of people are using ethers.js, this doesn't scale. We will get rate limited.

[ricmoo]

The v5 getDefaultProvider does though. See here for the properties to use. :)

More details will be added to the docs soon.

INFURA and Etherscan will no longer return any result without an API key. For now, the API keys seem mostly for metric purposes and throttling is (as it probably should be) based on the source IP address.

I would recommend you use v5, and certainly pass in your own API keys. At the very least, it gives you useful metrics into the usage of your app. Also, if you pay extra for INFURA, you can get archival access and other perks. :)

[ricmoo]

That's cool, but if a lot of people are using ethers.js, this doesn't scale. We will get rate limited.

To be clear though, the rate limit applies mostly to the IP address than the API key, as far as I know, so far.

[cliffhall]

To be clear though, the rate limit applies mostly to the IP address than the API key, as far as I know, so far.

Verified for Etherscan:

The APIs are free for the community with a maximum rate limit of up to 5 calls per sec/IP with a valid API key

Looks legit

[cliffhall]

Concerning at Infura though:

Rate limiting will be applied account wide after the accounts daily request limit is exceeded.

They take ip into account but the limiting happens account-wide, not per ip

[cliffhall]

I would recommend you use v5, and certainly pass in your own API keys.

This is a production site. Is V5 ready for prime time? Or should I just create a FallbackProvider using an initialized EtherscanProvider and InfuraProvider? That would be equivalent, right?

[ricmoo]

Yes, that would be the equivalent for v4.

I personally use v5 in production services and I think the last hold up I s the documentation, which is what I'm working on getting out the door right now. :)

[ricmoo]

I think this has been answered? If not, please feel free to re-open.

Thanks! :)