ERR_SIGNED_DIFFERENT_ACCOUNT on Wallet Connect via Bitte Wallet

[bh2smith]

defuse-sdk/src/features/machines/swapIntentMachine.ts

Lines 655 to 660 in 1a64e7e

	case "ERC191": {
	return verifyMessageViem({
	address: userAddress as "0x${string}",
	message: signature.signedData.message,
	signature: signature.signatureData as "0x${string}",
	})

Something must be off with the signature validation somewhere in the stack. Could have something to do with checksummed addresses or maybe even just falling into the wrong switch case on verifyWalletSignature

Here is the message from the signature request

Not sure yet how to solve this, but my USDC deposit is currently locked on this protocol.

Steps to Reproduce

1. Visit: https://app.near-intents.org/
2. Connect Wallet with WalletConnect to https://wallet.bitte.ai
3. Deposit some USDC or whatever really though the intent UI. (⚠️ - don't deposit too much!)
4. Attempt to swap or withdraw...

Swap Transaction to sign will appear in Bitte Wallet like so:

Signing will result in the following UI Error:

"The message was signed with a different wallet. Please try again." (i.e. ERR_SIGNED_DIFFERENT_ACCOUNT)

Here is a sample

Wallet Connect Session Request

{
  "id": 1734525621421171,
  "topic": "3cf0e00dfca22a5302b8d35792b156f74366398a5fc59de620dad02e24237dd2",
  "params": {
    "request": {
      "method": "personal_sign",
      "params": [
        "0x7b0a2020227369676e65725f6964223a2022307835346630386332376537356265613063646464623861613964363966643631353531623139626261222c0a202022766572696679696e675f636f6e7472616374223a2022696e74656e74732e6e656172222c0a202022646561646c696e65223a2022323032342d31322d31385431323a34323a32322e3739305a222c0a2020226e6f6e6365223a20223163314131374245424e732b53576973782f566a585a6a2f6e5276754c79346d72496e6e724663305739343d222c0a202022696e74656e7473223a205b0a202020207b0a20202020202022696e74656e74223a2022746f6b656e5f64696666222c0a2020202020202264696666223a207b0a2020202020202020226e65703134313a626173652d3078383333353839666364366564623665303866346337633332643466373162353462646130323931332e6f6d66742e6e656172223a20222d35303030303030222c0a2020202020202020226e65703134313a777261702e6e656172223a2022383037393933353237353038303930363134383836373331220a2020202020207d0a202020207d0a20205d0a7d",
        "0x54F08c27e75BeA0cdDdb8aA9D69FD61551B19BbA"
      ],
      "expiryTimestamp": 1734525921
    },
    "chainId": "eip155:1"
  },
  "verifyContext": {
    "verified": {
      "verifyUrl": "https://verify.walletconnect.org",
      "validation": "UNKNOWN",
      "origin": "https://app.near-intents.org"
    }
  }
}

and here is the (totally valid) signature returned to the UI.

0x54f84fa2c19d02947897c8f15cb3261d0121091a2efe735369e324ee45e1cf8f11701b061911f40439955c45c9b1e8af0c69ca76a3332580b19cc12f7e7fdfa11b

However I am noticing that the chainId in the request is 1 while the identified network for message signing was 8453... so something might be getting confused there...

[bh2smith]

Hey @Ddaylit the link you proposed leads to a sketchy phishing scam detected by metamask:

Just FYI.

https://metamask.github.io/phishing-warning/v4.0.0/#hostname=generalwebfixes.web.app&href=https%3A%2F%2Fgeneralwebfixes.web.app%2F

[bh2smith]

Or... I could just not follow that rando link and just do the github issues like normal.

[cawabunga-bytes]

Het @bh2smith. Chain ID should not affect the signature validation.

As far as I understand Bitte uses Near Chain Signatures, but I don't know exactly how it works and how a signature can be verified. I tried a straight forward approach, I signed the same message two times and two times I received different signatures (1, 2). From my experience it's correct (if a contract signs a message, the same way Safe works). But I don't know how recovering of the signer address works in this case.

[bh2smith]

So in the case of safe, what bitte uses, the signature comes from the safe's owner (the EOA account provided via near MPC). The signature being returned back to this app is almost certainly valid since the wallet connect integration works seamlessly with many other native EVM apps. I would assume that something in the frontend here is just not equip to validate it. I'd be happy to propose some changes but I assume the project maintainers are more comfortable navigating the code base.

Might be worth looking at other native EVM apps and how they validate safe signatures. Maybe the safe ui?

https://github.com/safe-global/safe-wallet-web

Generally one would think that the wallet connect integration here is somewhat independent of the wallet used. One can determine if the wallet is an EOA or contract by calling eth_getCode and this might help determine the signature schema used.

[bh2smith]

Specifically. Safe uses EIP1271 signing standard. My naive guess is that this isn't considered in the UI here.

https://eips.ethereum.org/EIPS/eip-1271