Contract Function Execution Error Due To Different Contract Function Param Name

[Metaxona]

Check existing issues

• I checked there isn't already an issue for the bug I encountered.

Viem Version

2.19.7

Current Behavior

i am having a problem using erc20Abi specifically approve since in the erc20Abi the approve uses

approve(address spender, uint256 amount) 

while the contract i am trying it on uses

approve(address _spender, uint256 _amount)

which made it impossible for me to call the function and will likely happen on every erc20 tokens that uses a different param name

and throws an error like this

Expected Behavior

the call should use the signature without the param name like this

approve(address,uint256)

which from what I know, what evm uses when calculating function signatures instead of including the param names (correct me if i am wrong on this one)

by ignoring the param names, it won't affect the contract interactions due to having a conflict in param names from the standard abi and the one being implemented on the contract

---

there's also the issue about that from both the eip site and the one openzeppelin use being different

EIP-20

Openzeppelin

here you will see that the EIP-20 one uses the version with _ while the Openzeppelin one does not

Steps To Reproduce

1. deploy 2 basic erc20 token that has different param names

one with

approve(address spender, uint256 amount) 

another with

approve(address _spender, uint256 _amount)

2. setup interaction client (@wagmi/core | viem)
3. use erc20Abi from viem
4. interact with it using either @wagmi/core or viem's writeContract

Link to Minimal Reproducible Example

No response

Anything else?

No response

[jxom]

I can't reproduce this. Can you provide a minimal reproduction, or try break mine?

[github-actions]

Hello @Metaxona.

Please provide a minimal reproduction using StackBlitz, TypeScript Playground (for type issues), or a separate minimal GitHub repository.

Minimal reproductions are required as they save us a lot of time reproducing your config/environment and issue, and allow us to help you faster.

Once a minimal reproduction is added, a team member will confirm it works, then re-open the issue.

[Metaxona]

I can't reproduce this. Can you provide a minimal reproduction, or try break mine?

Here's a reproduction repo without the private ley so you have to provide yours

https://github.com/Metaxona/viem-issue-2703

this one also has the address of the contract being used which is causing an error.

the contract is verified on sepolia etherscan

also i forgot to mention i am simulating the transactions first before sending them so that might be the problem

[jxom]

The approve method on that contract doesn’t return a boolean value. The ERC20 spec specifies that approve must return a boolean.

To get this to work, you will need to make outputs an empty array on the approve function of the ABI.

[Metaxona]

The approve method on that contract doesn’t return a boolean value. The ERC20 spec specifies that approve must return a boolean.

To get this to work, you will need to make outputs an empty array on the approve function of the ABI.

hmmm, i did not notice that. so i got this code from usdt deployed on ethereum mainnet which is weird too since they are linking the implementations on the code to the eip 20 docs

and another weird thing is using cast sig from foundry-rs returns the same thing with or without the return

cast 0.2.0 (6de15b0 2024-07-15T00:21:23.265849459Z)

viem-issue-2703 git:(main) cast sig "function approve(address _spender, uint256 _value) returns (boolean success)"

0x095ea7b3

viem-issue-2703 git:(main) cast sig "function approve(address _spender, uint256 _value)"                          

0x095ea7b3

viem-issue-2703 git:(main) cast sig "function approve(address spender, uint256 value)"  

0x095ea7b3

viem-issue-2703 git:(main) cast sig "function approve(address spender, uint256 value) returns (boolean success)" 

0x095ea7b3

viem-issue-2703 git:(main) cast sig "function approve(address spender, uint256 value) returns (boolean _success)"

0x095ea7b3

so with this, that call should work since they all generate the same function signature with or without the return output

[jxom]

That is correct. Selectors are computed from the keccak256 hash of a contract signature, and a signature only contains the method name + parameters.

The call is not working because Viem is expecting a return value (boolean), however, the contract method is returning nullish data (0x).

[Metaxona]

That is correct. Selectors are computed from the keccak256 hash of a contract signature, and a signature only contains the method name + parameters.

The call is not working because Viem is expecting a return value (boolean), however, the contract method is returning nullish data (0x).

hmmm that checks out, cause if viem is not expecting anything to return it would still work

though there's a problem with this making the built-in erc20Abi from viem unable to be used on all erc20 tokens that follows the standard or atleast most of it like in the case of USDT on ethereum mainnet

so i guess to solve this problem without relying on viem to fix it on the source side of the code would be to set the exact abi used by the contract for this kind of situations then and just put it in an object like { [chainId]: { [tokenAddress] : tokenAbi } } and populate it with the custom abi while using the standard ones if they don't exist

also yeah the error also says that it returned not data 0x

[github-actions]

This issue has been locked since it has been closed for more than 14 days.

If you found a concrete bug or regression related to it, please open a new bug report with a reproduction against the latest Viem version. If you have any questions or comments you can create a new discussion thread.