Compatibility mode for sendCalls

[johanneskares]

I see that sendCalls is now out of experimental status. Great news.

However, it's still not ready to use as default option for sending contract calls, as many wallets have not yet implemented EIP-5792 and it might possibly take years until all wallets have.

To drive adoption of 5792 it would be great, if there was a compatibility mode (not on by default, so wallets realize they need to support it) that falls back to using standard transactions sequentially if the wallet doesn't have support for atomic operations. I'm trying to build a small wrapper around sendCalls. Here's what I came up with, not tested yet. But having something similar ready in viem would be great, so we can start using sendCalls as default for any blockchain interactions.

export async function sendCallsSafe<
    chain extends Chain | undefined,
    account extends Account | undefined,
    const calls extends readonly unknown[],
    chainOverride extends Chain | undefined = undefined,
>(
    client: Client<Transport, chain, account>,
    parameters: SendCallsParameters<chain, account, chainOverride, calls>,
): Promise<SendCallsReturnType> {
    try {
        const result = await sendCalls(client, parameters);
        return result;
    } catch {
        const hashes: string[] = [];
        for (const callTemp of parameters.calls) {
            const call = callTemp as Call;

            if (call.abi && call.functionName && call.args) {
                const hash = await writeContract(client, {
                    account: parameters.account,
                    address: call.to,
                    abi: call.abi,
                    functionName: call.functionName,
                    args: call.args,
                    value: call.value,
                    chain: parameters.chain,
                    // biome-ignore lint/suspicious/noExplicitAny: types are not compatible
                } as any);
                hashes.push(hash);
            } else {
                const hash = await sendTransaction(client, {
                    account: parameters.account,
                    to: call.to,
                    value: call.value,
                    chain: parameters.chain,
                    data: call.data,
                    // biome-ignore lint/suspicious/noExplicitAny: types are not compatible
                } as any);
                hashes.push(hash);
            }
        }

        const result = { id: `0x${hashes.map((hash) => hash.replace("0x", "")).join("")}` };
        return result;
    }
}

[johanneskares]

In the specification it mentions: https://eips.ethereum.org/EIPS/eip-5792

Apps may begin using these first three methods immediately, falling back to eth_sendTransaction and eth_getTransactionReceipt when they are not available.

It would be amazing if viem could handle this case

[jxom]

#3648

[johanneskares]

Looks great! Let me know if I can support finalizing it. Is there a way to test PRs using npm?

[johanneskares]

ahh, looks like I can do npm install viem@2.30.0-jxom-send-calls-fallback-20250514150632

[azf20]

this is great! testing with a few different wallets (experimental section at the bottom when you connect a wallet here)

Not sure how much viem wants to try to catch all the edge cases, but below are a couple where the fallback didn't work out:

Metamask extension, on network where the EOA is using a different delegate account:

{
  "cause": {
    "details": "Account upgraded to unsupported contract",
    "shortMessage": "An internal error was received.",
    "version": "2.30.6",
    "name": "InternalRpcError",
    "code": -32603
  },
  "details": "Account upgraded to unsupported contract",
  "metaMessages": [
    "Request Arguments:",
    "  from:  0x60Ca282757BA67f3aDbF21F3ba2eBe4Ab3eb01fc"
  ],
  "shortMessage": "An internal error was received.",
  "version": "2.30.6",
  "name": "TransactionExecutionError"
}

Metamask extension on a network without 7702 support:

{
  "cause": {
    "details": "EIP-7702 not supported on chain: 0x89",
    "shortMessage": "This Wallet does not support the requested chain ID.",
    "version": "2.30.6",
    "name": "UnsupportedChainIdError",
    "code": 5710
  },
  "details": "EIP-7702 not supported on chain: 0x89",
  "metaMessages": [
    "Request Arguments:",
    "  from:  0x60Ca282757BA67f3aDbF21F3ba2eBe4Ab3eb01fc"
  ],
  "shortMessage": "This Wallet does not support the requested chain ID.",
  "version": "2.30.6",
  "name": "TransactionExecutionError"
}

Uniswap mobile wallet via WalletConnect:

{
  "cause": {
    "details": "Unsupported wc_ method.",
    "shortMessage": "An unknown RPC error occurred.",
    "version": "2.30.6",
    "name": "UnknownRpcError",
    "code": -1
  },
  "details": "Unsupported wc_ method.",
  "metaMessages": [
    "Request Arguments:",
    "  from:  0x25171bD3cD3231c3057c96F38E32E3bA6681497a"
  ],
  "shortMessage": "An unknown RPC error occurred.",
  "version": "2.30.6",
  "name": "TransactionExecutionError"
}

Finally, behaviour is to initiate all of the fallback transactions at once, so if the user rejects one they'll still see the others (which might be confusing / will likely fail). Some wallets (e.g. Rabby extension) detect this queue and let you reject them all at once, but others just show them one after the other. Would it be possible to have a mode where fallback transactions are only submitted when the preceding one is approved in the wallet? I guess that makes sendCalls somewhat async which might not be desirable. Either way it's probably worth adding this expected behaviour to the docs, can open a PR if you agree.

[azf20]

Opened a PR to trigger the fallback for those specific edge cases in case helpful: #3717