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

Wallet - Creating a watched address account with a multichain address goes unresponsive at the confirmation screen #18950

Closed
Tracked by #18611
smohamedjavid opened this issue Feb 22, 2024 · 3 comments · Fixed by #19185
Assignees

Comments

@smohamedjavid
Copy link
Member

Bug Report

Problem

Creating a watched address account with a multichain address goes unresponsive at the confirmation screen

Enter multichain address Confirm page where Add watched address btn is unresponsive

⚠️ NOTE: The reason why the creation is stuck is because status-go doesn't accept multichain addresses on account creation. It returns the following error:

invalid argument 1: json: cannot unmarshal hex string without 0x prefix into Go struct field Account.address of type types.Address

Expected behaviour

The app should not accept multichain addresses on the address input (same as Desktop behaviour)

Reproduction

  1. Open Status
  2. Navigate to the Wallet tab
  3. Tap on + to add new watch address
  4. Enter a multichain address (Eg: eth:opt:arb1:0x9bf27d0c9aba562dc33bc4b60c233a6609ce2987)
  5. Tap on Confirm to navigate to the next screen
  6. Enter a name
  7. Tap on Add watched address

Additional Information

  • Operating System: Android, iOS
@ulisesmac
Copy link
Contributor

Hey @smohamedjavid

The app should not accept multichain addresses on the address input (same as Desktop behaviour)

According to designs, the input should accept it:

image

https://www.figma.com/file/HKncH4wnDwZDAhc4AryK8Y/Wallet-for-Mobile?type=design&node-id=2052-522338&mode=dev

Probably a status-go issue instead?

@briansztamfater
Copy link
Member

@ulisesmac @smohamedjavid I am thinking that maybe just ignoring the prefix would be a solution to this issue. For example, if user enters eth:opt:arb1:0x9bf27d0c9aba562dc33bc4b60c233a6609ce2987 we can send just 0x9bf27d0c9aba562dc33bc4b60c233a6609ce2987 to the status-go endpoint, and therefore prevent blocking the UI. WDYT?

@ulisesmac
Copy link
Contributor

@briansztamfater

Sounds good as long as there's no difference for a multi-chain address on status-go

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
4 participants