Smart Contract call is reverted when using WalletConnect

[pathornteng]

Description

One of the projects is developing a dApp using WalletConnect (https://docs.walletconnect.com/web3modal/nextjs/about) to sign a transaction with Metamask.

The smart contract call is reverted every time. On the other hand, if they call the smart contract with the same set of parameters via HashScan, the call is successful.

This is the smart contract with source code verified https://hashscan.io/testnet/contract/0.0.4331816?p=1&k=1715155435.191447039
Failed txn - via dApp - https://hashscan.io/testnet/transaction/1715155115.601245554
Success txn - via hashscan - https://hashscan.io/testnet/transaction/1715155435.191447039

Looking closer, I can see that the call to addMemberFx failed when trying to access msg.sender (Debug event). I am not sure if this is something we have to fix at the relay or EVM.

A side note from @Neurone
I noticed the failed tx has the entity_id=null and not set to 0.0.4331816. Can it be the problem?
Failed: https://testnet.mirrornode.hedera.com/api/v1/transactions/0.0.902-1715155104-774615333
Ok: https://testnet.mirrornode.hedera.com/api/v1/transactions/0.0.902-1715155425-668777573?nonce=0

@Nana-EC The input is the same for both calling from HashScan (ABI) and the dApp (NextJS)

Steps to reproduce

The source code is in HashScan but I don't have access to the dApp source code so it's not reproducible. I hope we can investigate using the tx call / smart contract source code

Additional context

No response

Hedera network

testnet

Version

latest

Operating system

None

[quiet-node]

Hey @pathornteng thanks for openning the ticket and sorry that your client has to experience such struggle!

A couple of things that I have noticed are that the failed tx does not have any child txs or event logs. Also, the failed tx does not have a valid contract id (a.k.a. entity_id like mentioned in question). This sort of suggests that the tx failed early in the transaction making process, and it's WalletConnect in this case so the wallet provider would be a different object that other wallets. This is indeed an odd behavior. I'm sort of leaning on the possiblity that the dapp's setup has something to do with this.

So, let me ask you a couple of questions:

1. Is there a public accessible link to the dapp so I can try it out?
2. If there's not a link, then what are the behaviors the dapp has when other functions (not addMemberFx) are called using WalletConnect?
3. What does the process of calling the same addMemberFx function with the same data set, but on Hashscan, look like? An e2e description would be appreciated.

[app-matt]

Hey @quiet-node happy to share more info with you on this. Are we able to connect on Slack?

[quiet-node]

After digging around in the source code, I found out that the problem lies into the _fxContract param of the addMemberFx() function. This _fxContract address appears to only accept evm address, not the associated long zero address. I have provided @app-matt a workaround and it seems to unblock the current problem for the dapp. However, I have also opened a ticket on the SDK to capture my findings and to find out what the problem is.