ethers.js: Invalid ENS name error when a signer is used instead of an address

Hey @ricmoo

I’m creating this issue cause I’ve seen lots of people confused about an ENS related error being thrown when a signer is used instead of an address. To make things worse, the signer gets JSON.stringifyd so the error is HUGE sometimes.

Have you consider treating this as a special case and throwing something like “hey, you should use an address instead of a signer”? Or maybe add a toJSON to the abstract signer to at least avoid those huge errors?

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 11
  • Comments: 26 (5 by maintainers)

Commits related to this issue

Most upvoted comments

Example problematic code:

const C = await ethers.getContractFactory("Contract");
const [owner, addr1, ...addrs] = await ethers.getSigners();
const c = await Contract.deploy(owner);

Yields confusing error:

 Error: invalid ENS name (argument="name", value="<SignerWithAddress 0x10957970C51812dc3A010C7d01b70e0d17dc79A8>", code=INVALID_ARGUMENT, version=providers/5.0.22)

Fix:

const c = await Contract.deploy(owner.address);

I guess extra confusing for typescript users, as the types are happy with it, only breaks at runtime.

This has already been added to my local v6. You should actually generally call .getAddress() instead of .address, since .address is not part of the Signer API (most signers do not have synchronous access to their address).

For v5, I can add a condition like that to the JavaScript side, but cannot change the signature to allow Signer and Contract since that would break any existing sub-classes.

I haven’t looked much into this, but there is no getContractFactory on ethers. I think that is something Hardhat adds? Are you using Hardhat? Could there be a problem there?

One of my deepest regrets 🥲 We need to come up with a better way of doing this. Originally that ethers object just contained some helpers, and some users asked for it to re-export the actual ethers because the name clash made importing it annoying.

This problem mostly happens when users pass a Signer or Contract instead of an address. I think something that would improve it is checking if the value is a string, and only throw ENS-related errors in that case.

This should be better in 5.5.0. The error thrown is more meaningful and does not mention ENS.

In v6, Signers and Contracts inherit Addressable, so they are valid to passed in for addresses, but in v5 this change seems riskier than I’d prefer, so the current behaviour is preserved, but with better errors. 😃

Thanks! 😃

Hey thanks for the quick reply ! That’s totaly on me. I found out the problem 5 mins after posting (stupid bad venv ariable names hidden deep in my code…). Sorry for the inconvenience !

There is also no getSigners, maybe something else Hardhat added?

My guess is you want to call deploy(owner.getAddress()) instead?

I’m still getting an error when I try to run this code. I’m new to frontend smart contract work, so this may be an obvious error, but I can’t figure out what I’m doing wrong here:

var contract = new Contract(addresses.erc20, abis.erc20, provider.getSigner(0));

  var spender = addresses.smartContract;

  const signer = await provider.getSigner();
  const owner = await signer.getAddress();
  
  console.log("Account:", owner.toString());

  
  

  var allowance = await contract.allowance(owner, spender);

  console.log(allowance);

  return allowance;

I get the owner.toString() to come back as expected, but afterwards I get the ‘invalid ENS name’ error

Hey there, same problem as @slhodak if anyone found a solution please let me know

I haven’t looked much into this, but there is no getContractFactory on ethers. I think that is something Hardhat adds? Are you using Hardhat? Could there be a problem there?