multiCall rejects EIP-55 checksummed addresses with "Bad encoding"; single `call` accepts them

[Himess]

Summary

sdk.api2.abi.multiCall rejects calls whose target or params are EIP-55 mixed-case addresses with Error: Bad encoding, while sdk.api2.abi.call accepts the exact same arguments without complaint. Lowercasing the addresses works around it for multiCall.

This is surprising because:

1. EIP-55 checksummed addresses are the canonical form (Etherscan, deployment manifests, etc.).
2. The asymmetry between call and multiCall for byte-identical input means an adapter that runs cleanly for a single read suddenly breaks when batched.

Environment

• @defillama/sdk 5.0.211
• Node 22

Minimal reproduction

const sdk = require('@defillama/sdk');

(async () => {
  const target = '0xA0b86991c6218b36c1D19D4a2e9Eb0cE3606eB48';      // USDC, EIP-55
  const owner  = '0x40ec5B33f54e0E8A33A975908C5BA1c14e5BbbDf';      // Polygon predicate, EIP-55
  const abi    = 'function balanceOf(address) view returns (uint256)';

  // 1. call — mixed case → OK
  console.log(await sdk.api2.abi.call({ chain: 'ethereum', target, abi, params: [owner] }));

  // 2. multiCall — same input → FAILS
  try {
    await sdk.api2.abi.multiCall({
      chain: 'ethereum', abi, calls: [{ target, params: [owner] }],
    });
  } catch (e) {
    console.log('multiCall (mixed case):', e.message.split('\n')[0],
                'underlying:', e._underlyingErrors);
  }

  // 3. multiCall — same input but lowercased → OK
  console.log(await sdk.api2.abi.multiCall({
    chain: 'ethereum', abi,
    calls: [{ target: target.toLowerCase(), params: [owner.toLowerCase()] }],
  }));
})();

Output

1102611120377950                          // (1) call OK
multiCall (mixed case): Multicall failed!   underlying: [ 'Error: Bad encoding' ]
[ '1102611120377950' ]                    // (3) lowercase multiCall OK

Impact

For the common case of pasting Etherscan-canonical addresses into an adapter, the developer hits an opaque Bad encoding only at batch time, with no hint that lowercase fixes it. Surfaced while writing PoR adapters in DefiLlama/defillama-server#PR_LINK_TBD — the workaround there is to write all addresses lowercase, but a saner fix would be to checksum-normalize inside multiCall the way call evidently already does (or share whatever normalization step call uses).

Happy to open a PR with a normalization fix if pointing me at the right module would help — looks like it would land somewhere around the multicall encoder path.

[Himess]

Update / correction: I dug deeper and the framing in the original report was off. The address I used as target (0xA0b86991c6218b36c1D19D4a2e9Eb0cE3606eB48) actually has an invalid EIP-55 checksum — the canonical form is 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 (lowercase d instead of uppercase D). I confirmed this against ethers across 6.12.1, 6.13.0, and 6.16.0 — all three reject it consistently with bad address checksum.

So ethers itself is behaving correctly. The actual bug is twofold:

1. Asymmetric strictness between call and multiCall. With the same byte-identical mis-checksummed target:

• sdk.api2.abi.call succeeds — the target is passed as the raw to field of eth_call and ethers never gets a chance to validate it.
• sdk.api2.abi.multiCall fails — multicall3.ts adds an explicit ethers.getAddress(call.contract) check (line ~235) which surfaces the bad checksum.

That asymmetry is fine to keep (the strict version actually catches a real typo), but two callers reading the same address from the same source will get inconsistent behaviour, which is hard to reason about.

2. The original ethers error is dropped. In the catch block at multicall3.ts:244, the exception (TypeError: bad address checksum (argument="address", value="0xA0b8…", code=INVALID_ARGUMENT, version=6.x)) is swallowed and replaced with a generic new Error('Bad encoding') at line 253. A developer who sees this only learns that something failed encoding — the actual cause (which character was wrong, in which address) is unrecoverable without instrumenting the SDK.

I will follow up with a small PR that preserves the original error in the failed-call response, so the surface error reads e.g. Multicall failed! [...] underlying: bad address checksum (argument="address", value="0xA0b86991…D19D…", version=6.x) and points the developer straight at the fix. That's the least-invasive change that solves the real pain without touching the strictness contract.