Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(WalletConnect): Fixing sign for uniswap and paraswap #16168

Merged
merged 1 commit into from
Aug 26, 2024

Conversation

alexjba
Copy link
Contributor

@alexjba alexjba commented Aug 21, 2024

What does the PR do

There are two fixes needed here.

  1. Status-go fix for unknown primitive when signing the message
  2. Fix for Paraswap pairing failure due to required namespaces mismatch

Needs for: status-im/status-go#5755

Affected areas

Wallet Connect
Message signing

Architecture compliance

  • I am familiar with the application architecture and agreed good practices.
    My PR is consistent with this document: Architecture guidelines

Screenshot of functionality (including design for comparison)

  • I've checked the design and this PR matches it

Impact on end user

Before:
The user could not use Paraswap services
The user could not sign messages using uint160 type

After:
The user can use Paraswap services
The user can sign messages using all types

How to test

Case 1:
Connect to Paraswap (make sure the events in requiredNamespaces.eip155.events is not empty in the pairing message)

Case 2:
Try to swap more than USDC to DAI using Uniswap. Not sure of the repro steps. Probably can be reproduced when connecting new accounts because it would reproduce while signing the authorisation request. The message needs to contain a value of uint160. This can be seen in the message we're showing in the sign dialog.

Risk

Described potential risks and worst case scenarios.

Tick one:

  • Low risk: 2 devs MUST perform testing as specified above and attach their results as comments to this PR before merging.
  • High risk: QA team MUST perform additional testing in the specified affected areas before merging.

@@ -68,7 +68,7 @@ function buildSupportedNamespaces(chainIds, addresses, methods) {
"eip155":{
"chains": [${eipChainIds.join(',')}],
"methods": [${methodsStr}],
"events": ["accountsChanged", "chainChanged"],
"events": ["chainChanged","accountsChanged","message","disconnect","connect"],
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@saledjenic @clauxx Do you know if we'll need additional implementations in the integration layer for these extra events? Can't find anything meaningful in docs, integration or testing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you mean the "chainChanged" and "accountsChanged" events? we don't use them as of know from what I know, and doesn't seem like we need them, since we agree ahead of time with the dapp on the account/chains. e.g. whenever the dApp changes the chain, we don't need to react to that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm referring to "message","disconnect","connect". The Paraswap pairing fails because they mark these evens as required and we don't declare them as supported.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whenever the dApp changes the chain, we don't need to react to that

Really? Didn't know that was our intention.

Do you know if we'll need additional implementations in the integration layer for these extra events?

When the dapp asks for supported namespaces it actually asks if our wallet supports all events/methods that the dapp needs for functionating. In order to connect to the dapp we should at least support "required" events/methods, otherwise that dapp won't be successfully connected to our wallet.

Now if we extend namespace we want to support, we have to add necessary listeners for those events (or connect them to appropriate handlers if already added) and also extend functionality with newly added methods to support all that the namespaces said.

At least that's how I see it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@saledjenic Looks like we're being called through methods and we're supposed to call WC APIs through events. https://docs.walletconnect.com/walletkit/web/usage#emitting-session-events

IDK why Paraswap requires us to send all these events, but I think it's up to us to decide when we should send these events. The difficulty I see is to find the appropriate when to send these events.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's how it should be, we have to listen for events sent from the dapp and react to them and notify the dapp about the change on the wallet side.

During the negotiation process, when we're building a namespace, we should always respond with all chains/events/actions we're supporting in our wallet.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense! I'll add the events to enable the connection and add another task to go deeper in each signal. Looks like we're missing more handlers, not just these here and it's probably worth it's own space.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@status-im-auto
Copy link
Member

status-im-auto commented Aug 21, 2024

Jenkins Builds

Commit #️⃣ Finished (UTC) Duration Platform Result
✔️ 8009cee #1 2024-08-21 06:45:44 ~6 min tests/nim 📄log
✔️ 8009cee #1 2024-08-21 06:49:44 ~10 min macos/x86_64 🍎dmg
✔️ 8009cee #1 2024-08-21 06:50:05 ~10 min macos/aarch64 🍎dmg
✔️ 8009cee #1 2024-08-21 06:52:51 ~13 min tests/ui 📄log
✔️ 8009cee #1 2024-08-21 06:54:43 ~15 min linux-nix/x86_64 📦tgz
✔️ 8009cee #1 2024-08-21 06:56:28 ~17 min linux/x86_64 📦tgz
✔️ 8009cee #1 2024-08-21 07:10:24 ~31 min windows/x86_64 💿exe
✔️ cc655f2 #2 2024-08-22 16:27:56 ~6 min macos/aarch64 🍎dmg
✔️ cc655f2 #2 2024-08-22 16:28:27 ~6 min tests/nim 📄log
✔️ cc655f2 #2 2024-08-22 16:30:54 ~9 min macos/x86_64 🍎dmg
✔️ cc655f2 #2 2024-08-22 16:32:56 ~11 min tests/ui 📄log
✔️ cc655f2 #2 2024-08-22 16:36:28 ~14 min linux-nix/x86_64 📦tgz
✔️ cc655f2 #2 2024-08-22 16:37:43 ~16 min linux/x86_64 📦tgz
✔️ cc655f2 #2 2024-08-22 16:53:21 ~31 min windows/x86_64 💿exe

There are two fixes needed here.
1. Status-go fix for unknown primitive when signing the message
2. Fix for Paraswap pairing failure due to required namespaces mismatch

Needs: status-im/status-go#5755
@alexjba alexjba force-pushed the fix/solidity-types branch from 8009cee to cc655f2 Compare August 22, 2024 16:21
@alexjba alexjba marked this pull request as ready for review August 23, 2024 11:06
@alexjba
Copy link
Contributor Author

alexjba commented Aug 23, 2024

This PR is ready to review 😄

@alexjba alexjba merged commit 736075b into master Aug 26, 2024
9 checks passed
@alexjba alexjba deleted the fix/solidity-types branch August 26, 2024 08:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants