ethers.js v6 (6.11.1 & 6.14.1) JsonRpcProvider.call() on Polygon incorrectly invokes ENS resolver logic, leading to BAD_DATA error

[avvstancamarcello]

Ethers Version

6.11.1 (also observed with 6.14.1)

Search Terms

ethers.js v6 polygon BAD_DATA resolver ethers.js polygon getResolver 0x ethers.js v6 contract call ens error polygon ethers JsonRpcProvider polygon ens issue ethers could not decode result data resolver

Describe the Problem

We are encountering a persistent BAD_DATA error (info: { "method": "resolver", "signature": "resolver(bytes32)" }, value="0x") when attempting to make a simple view function call (e.g., name()) to a deployed and verified smart contract on Polygon Mainnet (chainId 137) using ethers.JsonRpcProvider.call(). 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 trace indicates that even for a direct provider.call() with a hex contract address and encoded calldata, ethers.js internally attempts to use JsonRpcProvider.getResolver(). This internal call to the RPC for resolver(bytes32) (a standard ENS resolver function signature) apparently returns 0x, 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.

Link to Minimal Reproducible Test Case Repository:
https://github.com/avvstancamarcello/ethers_v6_polygon_issue_testcase
(The README.md in this repository contains the full environment details, contract information, steps to reproduce, and actual error outputs.)

Environment & Versions (summary, full details in linked README):

• Node.js: v18.20.8 (LTS) & v22.15.1
• ethers.js: v6.11.1 (also observed with v6.14.1)
• Network: Polygon Mainnet (Chain ID: 137)
• RPC Providers Tested: QuickNode, public Polygon RPCs
• Operating System: Ubuntu 22.04.5 LTS on WSL2 (Host: Windows 11 Home)

Contract Address (Polygon Mainnet):
0x6a6d5c29ad8f23209186775873e123b31c26e9

Steps to Reproduce (summary, full details in linked README):

1. Clone the repository: https://github.com/avvstancamarcello/ethers_v6_polygon_issue_testcase
2. Run npm install.
3. Set up .env with a Polygon RPC URL (as per .env.example).
4. Run node scripts/testEthersDirect.js.

Expected Result:
The script should successfully call the name() view function on the contract and print the contract's name.

Actual Result:
The script successfully calls provider.getBlockNumber() but fails when provider.call() is executed for the name() function with the BAD_DATA error related to resolver(bytes32). The full console output is in the README of the linked repository. Example message:
Message: could not decode result data (value="0x", info={ "method": "resolver", "signature": "resolver(bytes32)" }, code=BAD_DATA, version=6.11.1)

Additional Context (summary, full details in linked README):
The core issue appears to be that ethers.js v6 incorrectly triggers ENS resolution logic even for direct hexadecimal addresses on Polygon. The RPC provider's 0x response to an internal resolver(bytes32)-like query is then not handled gracefully, leading to the BAD_DATA error. This makes basic view function calls unreliable under these conditions. We also observed a NotImplementedError: Method 'HardhatEthersProvider.resolveName' when using Hardhat's ethers wrapper, indicating a broader theme of ENS/resolver related issues.

Code Snippet

// Requires ethers.js v6.11.1 (or v6.14.1)
// Assumes 'provider' is an ethers.JsonRpcProvider connected to a Polygon Mainnet RPC
// (e.g., using QuickNode or a public RPC, with chainId 137 explicitly set).
// Assumes 'contractAddress' is "0x6a6d5c29ad8f23209186775873e123b31c26e9"
// Assumes 'contractABI_minimal_name_function' is the ABI for:
//   function name() view returns (string memory)

/*
const contractABI_minimal_name_function = [
     {
"inputs": [],
"name": "name",
"outputs": [{"internalType": "string", "name": "", "type": "string"}],
"stateMutability": "view",
"type": "function"
}
];
*/
async function testContractCall(provider, contractAddress, contractABI_minimal_name_function) {
    console.log("Attempting to call provider.getBlockNumber()...");
    try {
        const blockNumber = await provider.getBlockNumber();
        console.log(`Current block number: ${blockNumber}`); // This part works
    } catch (e) {
        console.error("Error calling getBlockNumber():", e.message);
        return;
    }

    const iface = new ethers.Interface(contractABI_minimal_name_function);
    const calldata = iface.encodeFunctionData("name");
    console.log(`Attempting direct provider.call to ${contractAddress} with calldata: ${calldata}`);

    try {
        const result = await provider.call({
            to: contractAddress,
            data: calldata
        });
        console.log(`Raw result from provider.call: ${result}`);
        // Expected to decode the contract name, but fails before this with BAD_DATA resolver error.
        // if (result && result !== "0x" && result.length > 2) {
        //     const decodedResult = iface.decodeFunctionResult("name", result);
        //     console.log(`Contract Name: ${decodedResult[0]}`);
        // } else {
        //     console.error("provider.call returned empty or null result.");
        // }
    } catch (error) {
        console.error("ERROR during direct provider.call:", error.message);
        // Error observed: "could not decode result data (value="0x", info={ "method": "resolver", "signature": "resolver(bytes32)" }, code=BAD_DATA, version=6.11.1)"
        // Stack trace points to JsonRpcProvider.getResolver()
    }
}

// To run (example setup):
// const providerUrl = "YOUR_POLYGON_RPC_URL";
// const provider = new ethers.JsonRpcProvider(providerUrl, 137);
// const contractAddress = "0x6a6d5c29ad8f23209186775873e123b31c26e9";
// const contractABI_minimal_name_function = [{"inputs":[],"name":"name","outputs":[{"internalType":"string","name":"","type":"string"}],"stateMutability":"view","type":"function"}];
// testContractCall(provider, contractAddress, contractABI_minimal_name_function);

Contract ABI

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

Errors

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)

Environment

node.js (v12 or newer)

Environment (Other)

Node.js versions tested: v22.15.1 and v18.20.8 (LTS). The issue persists on both. npm versions: v10.9.2 (with Node v22) and v10.8.2 (with Node v18). Operating System (WSL2): Ubuntu 22.04.5 LTS (running on Windows 11 Home). Full environment details and reproduction repository linked in the main description.

[ricmoo]

The reason is the address looks incorrect. Your address "0x6a6d5c29ad8f23209186775873e123b31c26e9" is 2 nibbles short; any string that is not a valid Address is assumed to be an ENS name.

My guess is that you had a string address somewhere, and you used value.substring(0, 40), which didn't account for the 0x prefix, so you got the 0x and the following 38 nibbles of data (which represent 19 bytes), but an address is 40 nibbles (20 bytes) long. When snipping an address from a prefixed hex string you need to (counter-intuitively) use value.substring(0, 42).

Let me know if that helps. :)

[ricmoo]

(moving to discussions)

[avvstancamarcello]

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";
const contractAddress = "0x6a6d5Dc29ad8ff23209186775873e123b31c26E9";
const contractAddress = "0x6a6d5Dc29ad8ff23209186775873e123b31c26E9";
A huge thanks to everyone for their patience and assistance in debugging this!

[avvstancamarcello]

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";
const contractAddress = "0x6a6d5Dc29ad8ff23209186775873e123b31c26E9";
const contractAddress = "0x6a6d5Dc29ad8ff23209186775873e123b31c26E9";
A huge thanks to everyone for their patience and assistance in debugging this!

[avvstancamarcello]

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!

[avvstancamarcello]

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";
const contractAddress = "0x6a6d5Dc29ad8ff23209186775873e123b31c26E9"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!

[ricmoo]

Quick note; Ethers will definitely accept an address that is all lowercase or all uppercase. EIP-55 is only checked when an address contains a mix of lowercase and uppercase. The address in the body of the OP though was 2 nibbles short, which is why I mentioned length. ;)