Ethers.js v6 - Polygon provider.call() Issue: "could not decode result data (value="0x", info={ "method": "resolver", ...})"

This repository provides a minimal test case to reproduce an issue encountered with ethers.js (v6.11.1, also observed with v6.14.1) when interacting with Polygon Mainnet. A direct provider.call() to a simple view function on a deployed contract, as well as contract interactions via Hardhat's ethers wrapper, unexpectedly trigger internal ENS resolver logic, which fails with a BAD_DATA or UNCONFIGURED_NAME error.

Problem Description

We are encountering a persistent error when attempting to make simple view function calls (e.g., name()) to a deployed and verified smart contract on Polygon Mainnet (chainId 137).

1. When using ethers.JsonRpcProvider.call() directly (via a plain Node.js script): The call fails with a BAD_DATA error (info: { "method": "resolver", "signature": "resolver(bytes32)" }, value="0x").
2. When using Hardhat's ethers wrapper (hre.ethers via npx hardhat run scripts/...): The call previously failed with a NotImplementedError: Method 'HardhatEthersProvider.resolveName' is not implemented. After applying a workaround (overriding provider.getResolver to return null), the error changed to UNCONFIGURED_NAME for the contract address.

This issue has been observed with ethers version 6.11.1 (after downgrading from 6.14.1), across different Node.js versions (v18.20.8 LTS, and previously v22.15.1), and using different Polygon RPC providers (QuickNode, public nodes like https://polygon-rpc.com).

The stack traces indicate that ethers.js internally attempts to use JsonRpcProvider.getResolver() or similar ENS-related logic. This internal call to the RPC for an ENS resolver(bytes32) function apparently returns 0x (no data / zero address), which ethers.js then fails to decode as a valid resolver address, throwing the BAD_DATA error. Direct provider calls like getBlockNumber() work correctly.

This behavior is unexpected as no ENS names are being used for the contract interaction, and the target is always a valid hexadecimal contract address.

Environment & Versions

• Node.js: v18.20.8 (LTS) - also tested with v22.15.1 with same fundamental issues

• npm: v10.8.2 (with Node v18) - also tested with v10.9.2 (with Node v22)

• ethers.js: v6.11.1 - issue also observed with v6.14.1

• Hardhat (for testConnection.cjs context): v2.22.19

• @nomicfoundation/hardhat-toolbox (for testConnection.cjs context): v5.0.0

• Network: Polygon Mainnet (Chain ID: 137)

• // In scripts/testEthersDirect.js const contractABI = [ {"inputs":[],"name":"name","outputs":[{"internalType":"string","name":"","type":"string"}],"stateMutability":"view","type":"function"}, // Aggiungi qui l'ABI per pricesInWei se vuoi testarlo anche // {"inputs":[{"internalType":"uint256","name":"","type":"uint256"}],"name":"pricesInWei","outputs":[{"internalType":"uint256","name":"","type":"uint256"}],"stateMutability":"view","type":"function"} ];

• • **`(Optional)
  • contracts/LHILecceNFT.sol`**: Full contract source code is provided for completeness.
  • The testEthersDirect.js script uses an embedded minimal ABI for the name() function.
  • • (Optional) hardhat.config.cjs: Included for context if one wishes to understand
    • the original Hardhat environment setup or run other Hardhat-based scripts
    • (like an alternative test case showing the issue with hre.ethers).

• RPC Providers Tested:

  • QuickNode (e.g., https://proportionate-dry-brook.matic.quiknode.pro/YOUR_QUICKNODE_KEY/)
  • Public RPC (e.g., https://polygon-rpc.com, https://polygon-bor-rpc.publicnode.com)

• Operating System: Ubuntu 22.04.5 LTS (running on Windows 11 Home, 64-bit, via WSL2)

• Hardware: Lenovo IdeaPad 5 14ALC05, RAM 8GB, AMD Ryzen 7 5700U with Radeon Graphics 1.80 GHz

• Host OS Version (Windows): Windows 11 Home, Version 24H2, OS Build 26100.4061, Experience Pack 1000.26100.84.0

Contract Information

• Contract Name: LHILecceNFT
• Deployed Address (Polygon Mainnet): 0x6a6d5c29ad8f23209186775873e123b31c26e9
• PolygonScan Link: https://polygonscan.com/address/0x6a6d5c29ad8f23209186775873e123b31c26e9#code
• Relevant Function (minimal ABI used in testEthersDirect.js):

  [
      {
        "inputs": [],
        "name": "name",
        "outputs": [
          {
            "internalType": "string",
            "name": "",
            "type": "string"
          }
        ],
        "stateMutability": "view",
        "type": "function"
      }
  ]

Files in this Repository (Minimal Test Case)

• scripts/testEthersDirect.js: A minimal Node.js script using ethers.js directly (run with node scripts/testEthersDirect.js) to reproduce the BAD_DATA error. The minimal ABI for the name() function is embedded.

• scripts/testConnection.cjs: A Hardhat script (run with npx hardhat run ...) that demonstrates a similar issue (UNCONFIGURED_NAME after applying a provider.getResolver hack, or NotImplementedError originally) when using Hardhat's ethers wrapper. (This script is provided for additional context on the pervasiveness of the ENS-related issues encountered).

• package.json: Defines dependencies.

• .env.example: Example environment file.

• hardhat.config.cjs: Hardhat configuration file, relevant if running testConnection.cjs.

• contracts/LHILecceNFT.sol: Full source code of the smart contract.

• Repository Structure (Minimal Test Case)

This repository is structured to provide a minimal environment to reproduce the issue:

ethers_v6_polygon_issue_testcase/ ├── .env.example # Example environment file for RPC URL and Private Key ├── .gitignore # Standard gitignore for Node.js/Hardhat projects ├── contracts/ # Solidity smart contract │ └── LHILecceNFT.sol # The smart contract source code ├── hardhat.config.cjs # Hardhat configuration file (relevant for compiling and if using Hardhat scripts) ├── package.json # Project dependencies (ethers, dotenv, hardhat, etc.) ├── package-lock.json # Exact dependency versions ├── scripts/ │ └── testEthersDirect.js # The Node.js script using direct ethers.js calls that reproduces the error └── README.md # This file: detailed issue description

This file: detailed issue description

Steps to Reproduce

1. Clone the repository:

   git clone [https://github.com/avvstancamarcello/ethers_v6_polygon_issue_testcase.git](https://github.com/avvstancamarcello/ethers_v6_polygon_issue_testcase.git) # Or your actual repo URL
   cd ethers_v6_polygon_issue_testcase

2. Install dependencies:

   npm install

3. Set up environment variables:
   • Create a .env file by copying .env.example.
   • Edit the .env file and add your Polygon Mainnet RPC URL to the QUICKNODE_MATIC_URL variable (e.g., your QuickNode endpoint or a public one like https://polygon-rpc.com). Also, add your PRIVATE_KEY if you intend to run scripts that require a signer (though testEthersDirect.js for name() does not strictly need it).

     QUICKNODE_MATIC_URL="YOUR_POLYGON_MAINNET_RPC_URL_HERE"
     PRIVATE_KEY="YOUR_PRIVATE_KEY_WITHOUT_0X_PREFIX"

4. Run the primary test script (direct ethers.js):

   node scripts/testEthersDirect.js

5. (Optional) Run the Hardhat context test script:

   npx hardhat run scripts/testConnection.cjs --network polygon --show-stack-traces

Expected Result

Both scripts should successfully call the name() view function on the contract and print the contract's name ("LHI Lecce NFT").

Actual Result

1. Output from node scripts/testEthersDirect.js (with ethers@6.11.1):

The script successfully calls provider.getBlockNumber() but fails when provider.call() is executed for the name() function:

Utilizzo RPC URL (diretto da .env): https://proportionate-dry-brook.matic.quiknode.pro/752b1e43a682209ddc19a49978c10acac9458739 Tentativo di chiamare provider.getBlockNumber()... Numero blocco attuale: 71674569 Tentativo di leggere il nome del contratto con provider.call... Calldata: 0x06fdde03 --- ERRORE DURANTE provider.call DIRETTO --- Messaggio: could not decode result data (value="0x", info={ "method": "resolver", "signature": "resolver(bytes32)" }, code=BAD_DATA, version=6.11.1) Stack: Error: could not decode result data (value="0x", info={ "method": "resolver", "signature": "resolver(bytes32)" }, code=BAD_DATA, version=6.11.1) at makeError (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/lib.commonjs/utils/errors.js:129:21) at assert (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/lib.commonjs/utils/errors.js:149:15) at Interface.decodeFunctionResult (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/lib.commonjs/abi/interface.js:780:31) at staticCallResult (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/lib.commonjs/contract/contract.js:254:35) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async staticCall (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/lib.commonjs/contract/contract.js:219:24) at async Proxy.resolver (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/lib.commonjs/contract/contract.js:259:20) at async #getResolver (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/lib.commonjs/providers/ens-resolver.js:455:26) at async EnsResolver.fromName (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/lib.commonjs/providers/ens-resolver.js:486:26) at async JsonRpcProvider.getResolver (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/lib.commonjs/providers/abstract-provider.js:832:16)

"Actual Result" -> "1. Output from node scripts/testEthersDirect.js".

node scripts/testEthersDirect.js Using RPC URL (direct from .env): https://proportionate-dry-brook.matic.quiknode.pro/752b1e43a682209ddc19a49978c10acac9458739 Attempting to call provider.getBlockNumber()... Current block number: 71721940 Attempting to read contract name with direct provider.call... Calldata: 0x06fdde03 --- ERROR DURING DIRECT provider.call --- Message: could not decode result data (value="0x", info={ "method": "resolver", "signature": "resolver(bytes32)" }, code=BAD_DATA, version=6.11.1) Stack: Error: could not decode result data (value="0x", info={ "method": "resolver", "signature": "resolver(bytes32)" }, code=BAD_DATA, version=6.11.1) at makeError (/home/avvocato/LHI-NFT-CORRETTO/LHI-CLONE/ethers_v6_polygon_issue_testcase/node_modules/ethers/lib.commonjs/utils/errors.js:129:21) at assert (/home/avvocato/LHI-NFT-CORRETTO/LHI-CLONE/ethers_v6_polygon_issue_testcase/node_modules/ethers/lib.commonjs/utils/errors.js:149:15) at Interface.decodeFunctionResult (/home/avvocato/LHI-NFT-CORRETTO/LHI-CLONE/ethers_v6_polygon_issue_testcase/node_modules/ethers/lib.commonjs/abi/interface.js:780:31) at staticCallResult (/home/avvocato/LHI-NFT-CORRETTO/LHI-CLONE/ethers_v6_polygon_issue_testcase/node_modules/ethers/lib.commonjs/contract/contract.js:254:35) at process.processTicksAndRejections (node:internal/process/task_queues:105:5) at async staticCall (/home/avvocato/LHI-NFT-CORRETTO/LHI-CLONE/ethers_v6_polygon_issue_testcase/node_modules/ethers/lib.commonjs/contract/contract.js:219:24) at async Proxy.resolver (/home/avvocato/LHI-NFT-CORRETTO/LHI-CLONE/ethers_v6_polygon_issue_testcase/node_modules/ethers/lib.commonjs/contract/contract.js:259:20) at async #getResolver (/home/avvocato/LHI-NFT-CORRETTO/LHI-CLONE/ethers_v6_polygon_issue_testcase/node_modules/ethers/lib.commonjs/providers/ens-resolver.js:455:26) at async EnsResolver.fromName (/home/avvocato/LHI-NFT-CORRETTO/LHI-CLONE/ethers_v6_polygon_issue_testcase/node_modules/ethers/lib.commonjs/providers/ens-resolver.js:486:26) at async JsonRpcProvider.getResolver (/home/avvocato/LHI-NFT-CORRETTO/LHI-CLONE/ethers_v6_polygon_issue_testcase/node_modules/ethers/lib.commonjs/providers/abstract-provider.js:832:16)

2. Output from npx hardhat run scripts/testConnection.cjs --network polygon

(with ethers@6.11.1 and provider.getResolver hack applied in script):

This script, when using Hardhat's ethers provider and applying a hack to make provider.getResolver return null, still fails, but with a different error, further indicating ENS involvement: Target network specified: polygon Using RPC URL: https://proportionate-dry-brook.matic.quiknode.pro/MY_QUICKNODE_RPC_ENDPOINT Attempting to call provider.getBlockNumber()... Current block number: 71640171 Attempting to get ENS resolver for 'unlikelyname.eth'... [HACK] provider.getResolver called for: unlikelyname.eth, returning null. ENS Resolver for 'unlikelyname.eth': null Attempting to connect with account: 0xf9909c6CD90566BD56621EE0cAc42986ae334Ea3 (Please ensure to replace YOUR_RPC_URL_PART, ... (other logs) ..., and the specific function call in the stack trace (Proxy.pricesInWei or Proxy.name) and LINE_NUMBER:COLUMN_NUMBER with the actual details from your original error log for this specific test.)

This demonstrates that the ENS-related issues or provider interaction problems were present even when using the standard Hardhat ethers integration, manifesting as a NotImplementedError within the HardhatEthersProvider.

Important Notes: Original Error Context: I recall that the NotImplementedError: Method 'HardhatEthersProvider.resolveName' error occurred when using hre.ethers (i.e., the provider and signer managed by Hardhat). The testConnection.cjs script that I used to produce the UNCONFIGURED_NAME or BAD_DATA error was a modified version that directly used new ethers.JsonRpcProvider() and new ethers.Wallet(). It's important to provide the correct stack trace for each error scenario.

Placeholder in Stack Trace: In the stack trace I provided [referring to a previous draft of the README or issue], there is // ... (rest of stack trace for this specific error) .... Please replace this line with the complete and relevant stack trace for the NotImplementedError.

Account balance: 365.977862946638599478 MATIC Loading contract ABI from artifacts... Contract ABI loaded successfully. Connected to contract instance at address: 0x6a6d5c29ad8f23209186775873e123b31c26e9 Attempting to read contract name (view function)... [HACK] provider.getResolver called for: 0x6a6d5c29ad8f23209186775873e123b31c26e9, returning null. --- ERROR DURING CONNECTION OR READ TEST (WITH DIRECT ethers.js PROVIDER AND SIGNER) --- Message: unconfigured name (value="0x6a6d5c29ad8f23209186775873e123b31c26e9", code=UNCONFIGURED_NAME, version=6.11.1) Stack trace: Error: unconfigured name (value="0x6a6d5c29ad8f23209186775873e123b31c26e9", code=UNCONFIGURED_NAME, version=6.11.1) at makeError (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/src.ts/utils/errors.ts:694:21) at assert (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/src.ts/utils/errors.ts:715:25) at checkAddress (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/src.ts/address/checks.ts:62:15) at processTicksAndRejections (node:internal/process/task_queues:105:5) at async Promise.all (index 0) at resolveProperties (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/src.ts/utils/properties.ts:35:21) at populate (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/src.ts/providers/abstract-signer.ts:50:12) at Wallet.populateCall (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/src.ts/providers/abstract-signer.ts:91:21) at Wallet.call (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/src.ts/providers/abstract-signer.ts:221:49) at staticCallResult (/home/avvocato/LHI-NFT-CORRETTO/node_modules/ethers/src.ts/contract/contract.ts:337:22)

The script Hardhat testConnection.cjs original (whitouthack) produceva l'errore NotImplementedError: Method 'HardhatEthersProvider.resolveName'

Additional Context

2. Initial Output from npx hardhat run scripts/testConnection.cjs --network polygon (using hre.ethers wrapper, before direct provider tests and without hacks):

The original Hardhat script testConnection.cjs (without any hacks, using hre.ethers) produced the NotImplementedError: Method 'HardhatEthersProvider.resolveName' error.

When initially attempting to read contract data (e.g., pricesInWei or name()) using Hardhat's ethers wrapper (hre.ethers.getContractFactory and contract instance methods via hre.ethers), the following error was observed:

The core issue appears to be that ethers.js v6 (tested with v6.11.1 and v6.14.1) incorrectly triggers ENS resolution logic (specifically involving a call to a method like resolver(bytes32) internally via JsonRpcProvider.getResolver) even when a direct hexadecimal address is provided for a contract call on Polygon Mainnet (chainId 137). The RPC provider's response of 0x to this internal ENS-related query is then not handled gracefully, leading to a BAD_DATA error when ethers.js attempts to decode 0x as a valid resolver address. This makes basic view function calls using provider.call() (and by extension, Contract object interactions) unreliable under these conditions.

Any insights or guidance on how to correctly perform provider.call() or contract view function calls on Polygon with ethers.js v6 without triggering this ENS-related error pathway would be greatly appreciated.

Evolution of Observed Errors

Important Notes on Error Context:

It's crucial to distinguish between the error scenarios observed:

1. Initial Error with hre.ethers (Hardhat's Ethers Wrapper): The NotImplementedError: Method 'HardhatEthersProvider.resolveName' error originally occurred when using scripts that relied on Hardhat's default ethers integration (e.g., hre.ethers.getSigners(), hre.ethers.getContractFactory()). This happened when attempting to call contract view functions like pricesInWei() (in the mintNFT.cjs script) or name() (in early versions of testConnection.cjs that used hre.ethers).

2. Errors with Direct ethers.JsonRpcProvider and ethers.Wallet/Contract (testConnection.cjs - Modified Versions): The scripts named testConnection.cjs were subsequently modified to bypass hre.ethers and use new ethers.JsonRpcProvider() and new ethers.Wallet() (or new ethers.Contract()) directly.

   • When an experimental hack was applied to this direct-ethers script (overriding provider.getResolver to return null), the error changed to UNCONFIGURED_NAME (value="0x6a...").
   • When the testConnection.cjs script (or testEthersDirect.js) was run using direct provider.call() (without the getResolver hack), the error observed was could not decode result data (value="0x", info={ "method": "resolver", "signature": "resolver(bytes32)" }, code=BAD_DATA).

It's important that any stack traces provided in this issue report are correctly attributed to the specific script version and interaction method (direct ethers.js vs. Hardhat's ethers wrapper) that produced them. The primary focus of this repository is now the BAD_DATA error occurring with direct provider.call() in testEthersDirect.js.

Regarding the placeholder // ... (rest of stack trace for this specific error) ...: Please ensure this is replaced with the full, relevant stack trace for the NotImplementedError if you are including a section detailing that specific error scenario from the Hardhat-wrapped ethers interaction. This helps show that the problem isn't just a single error message but a persistent issue manifesting in different ways depending on the level of abstraction used with ethers.js. This helps show that the problem isn't just a single error message but a persistent issue manifesting in different ways depending on the level of abstraction used with ethers.js.

---

Hello team, I'm posting an update on this issue as we've successfully identified and resolved the root cause! Closing Issue: Resolved Contract Recognition Problem on Polygon (EIP-55 Checksum)

Hi everyone,

I'm pleased to announce that the issue encountered in our test script, which was preventing the correct recognition and interaction with our smart contract on the Polygon network, has been resolved!

The error manifested with messages like "could not decode result data (value="0x", info={ "method": "resolver", ...})" and was due to a subtle, yet crucial, difference in how addresses are handled when they are not properly checksummed (EIP-55).

The Root Cause: EIP-55 Checksumming vs. Case Sensitivity

Initially, we suspected the error might be related to the address length (e.g., whether it had 40 or 42 characters including the "0x" prefix). While an incorrect length would certainly cause an error, the specific "could not decode result data" error with the resolver(bytes32) method pointed to a different underlying issue.

The problem was that the address used in our script was in all lowercase characters (e.g., 0x6a6d5c29ad8f23209186775873e123b31c26e9). Although Ethereum addresses are case-insensitive at the blockchain protocol level, and completely lowercase addresses are technically valid, the EIP-55 checksum standard introduces a mix of uppercase and lowercase letters. This mixed-case formatting is not arbitrary; it serves as a checksum mechanism to help detect typos in addresses.

Libraries like Ethers.js, when provided with a string that has the correct length and "0x" prefix but does not conform to the EIP-55 checksum format, will often interpret it as a potential ENS (Ethereum Name Service) name that needs to be resolved. This led Ethers.js to attempt calling a resolver() function, which then failed, causing the "could not decode result data" error because the address was neither a valid ENS name nor a properly checksummed address for direct contract interaction.

The Solution:

The solution was to ensure the contractAddress variable in our script used the exact EIP-55 checksummed address provided by PolygonScan. This address explicitly includes the correct mix of uppercase and lowercase letters.

The correct and working address is: const contractAddress = "0x6a6d5Dc29ad8ff23209186775873e123b31c26E9"; Okay, here is the GitHub post draft in English, incorporating your specific clarifications about the address format and the EIP-55 checksum standard.

Closing Issue: Resolved Contract Recognition Problem on Polygon (EIP-55 Checksum)

Hi everyone,

I'm pleased to announce that the issue encountered in our test script, which was preventing the correct recognition and interaction with our smart contract on the Polygon network, has been resolved!

The error manifested with messages like "could not decode result data (value="0x", info={ "method": "resolver", ...})" and was due to a subtle, yet crucial, difference in how addresses are handled when they are not properly checksummed (EIP-55).

The Root Cause: EIP-55 Checksumming vs. Case Sensitivity

Initially, we suspected the error might be related to the address length (e.g., whether it had 40 or 42 characters including the "0x" prefix). While an incorrect length would certainly cause an error, the specific "could not decode result data" error with the resolver(bytes32) method pointed to a different underlying issue.

The problem was that the address used in our script was in all lowercase characters (e.g., 0x6a6d5c29ad8f23209186775873e123b31c26e9). Although Ethereum addresses are case-insensitive at the blockchain protocol level, and completely lowercase addresses are technically valid, the EIP-55 checksum standard introduces a mix of uppercase and lowercase letters. This mixed-case formatting is not arbitrary; it serves as a checksum mechanism to help detect typos in addresses.

Libraries like Ethers.js, when provided with a string that has the correct length and "0x" prefix but does not conform to the EIP-55 checksum format, will often interpret it as a potential ENS (Ethereum Name Service) name that needs to be resolved. This led Ethers.js to attempt calling a resolver() function, which then failed, causing the "could not decode result data" error because the address was neither a valid ENS name nor a properly checksummed address for direct contract interaction.

The Solution:

The solution was to ensure the contractAddress variable in our script used the exact EIP-55 checksummed address provided by PolygonScan. This address explicitly includes the correct mix of uppercase and lowercase letters.

The correct and working address is:

< const contractAddress = "0x6a6d5Dc29ad8ff23209186775873e123b31c26E9"; > It is crucial that this address is copied and used exactly as it appears on PolygonScan, with the precise capitalization, to enable Ethers.js to immediately recognize it as a valid contract address and bypass the ENS resolution attempt.

Corrective Action in the Script:

For anyone facing similar issues, please ensure the line defining your contract address in testEthersDirect.js (or similar script) is as follows: // BEFORE: const contractAddress = "0x6a6d5c29ad8f23209186775873e123b31c26e9"; // INCORRECT (all lowercase) // AFTER: const contractAddress = "0x6a6d5Dc29ad8ff23209186775873e123b31c26E9"; // CORRECT (with EIP-55 checksum) After correcting this line and saving the file, the test should now produce a successful output similar to this: << Using RPC URL (direct from .env): https:// Attempting to call provider.getBlockNumber()... Current block number: 71832116 Attempting to read contract name with direct provider.call... Calldata: 0x06fdde03 Raw result from provider.call: 0x0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000d4c4849204c6563636665204e465400000000000000000000000000000000000000 Contract Name (from direct provider.call): LHI Lecce NFT Test with DIRECT provider.call completed successfully.>> A huge thanks to everyone for their patience and assistance in debugging this!