Research UX approach for address confirmation

[avious00]

Context

We've seen tx where the address is sent to an address the user hasn't intended
Examples:

• Wallets intercepting each other and ends up in another wallet, e.g. Support OKX wallet / explicitly surface Keplr errors #85 Trust Wallet, Pontem
• WalletConnect multiple accounts + wagmi choosing not the one
• wagmi bug to not switch chains (zksync to arbitrum) Message signed on the wrong chain #148

Solution Design

Rossy to explore different UX/IxD approaches and review other interchain defi apps. Considering removing self and/or adding more explicit confirmations around addresses.

[AlexBHarley]

@avious00 and @jmrossy interested for your thoughts on the below. Would say that there's no 100% sure fire way to ensure users don't send to the wrong address, it's probably the biggest problem CEXs deal with, but combining the below items together could prevent some of the problems reported.

Recommended

• Upgrade to RainbowKit & Wagmi V2
  • Bug fixes
  • Allow detecting users installed wallets rather than having a hardcoded list of recommended wallets
  • More likely to get help from teams behind these products if we can show reproductions of issues with the latest versions
• Visibility into recipient address
  • Show registered name in addition to address
    1. ENS + ICNS to start, optional follow with Unstoppable Domains, Stargaze Names
    2. Some wallets expose the (locally given) name of the wallet.
       • Here we can also be tricky with detecting extensions overwriting MetaMask. If we're using an injected provider we can check the window.ethereum object and sometimes they set some flags indicating which wallet it is
    3. Some connectors expose the type of wallet, ie MetaMask, OKX
  • Show image in addition to connected address
    1. NFT loaded from name service
    2. Locally derived image, ie MetaMask blockie/identicon, Rainbow icon, CB wallet
• Automatically load connected wallet address instead of making people click "self"
• If we've never bridged to this address before, flag as a new address

As a side note, some things I noted while checking out the warp route UI. If these are captured elsewhere apologies.

• Don't allow connecting wallet type if no chains of this type are configured
• Allow disconnecting each wallet rather than all at once
• Disable bridge button + show info rather than showing an error after clicking "Continue"
  • if insufficient balance
  • no token selected
• Choose first available token for route by default
• Remember selected token when switching network
• Info indicator on disabled tokens doesn't do anything

[jmrossy]

@AlexBHarley @avious00

Upgrade to RainbowKit & Wagmi V2

Definitely. Been wanted to, just hasn't been prioritized yet. I would strongly recommend also updating the cosmos and solana wallet libs to latest at the same time.

Visibility into recipient address

I'm open to this. I think it won't help in most cases because it's amateur users who fall into these traps most often but it's worth a try.

Some connectors expose the type of wallet

Yeah we try to get the connector name from wagmi and show it in the sidebar menu. It doesn't work well when wallets masquerade as others, such as OKX pretending to be MM or Leap pretending to be Keplr.

Automatically load connected wallet address

Slightly disagree on this one. I think forcing a user interaction helps force a small amount of thought about the recipient.

If we've never bridged to this address before

Makes sense! The app keeps a history of transfers in the zustand store.

Don't allow connecting wallet type if no chains of this type are configured

Yeah, dynamic protocols based on the route chains is an idea we've had before. Agreed it's strictly better, just never got prioritized.

Allow disconnecting each wallet rather than all at once

Yep, agreed.

Disable bridge button

The validation steps for warp transfers are complex. We can do some simple checks yes but just pointing out there's some trickiness here. See the WarpCore's validation methods.

Choose first available token

Yes we're considering an overhaul of the current chain + token selection flow. Now that there are many chains and routes, it's not so good anymore.

Remember selected token

Def possible and I'm in favor but a bit trickier than it seems

Info indicator on disabled tokens

Good catch, we should fix

[jmrossy]

@AlexBHarley Great suggestions here, looking forward to making these improvements with you.

RE the recipient address UX, my general intuition is that some kind of more explicit review stage is needed in the transfer flow. Atm the fields lock and users submit again to confirm. Maybe a more different review stage with extra recip address info is required.

[AlexBHarley]

OK so following up on this.

• A move to V2 for wagmi, rainbowkit and viem also implies moving the Hyperlane SDK to viem V2. Might need to consider supporting two versions like was explored (but ultimately shelved?) with Ethers V5 and Ethers V6
  • Action item, new ticket to capture & discuss this work
• A bump of the Cosmos and Solana wallets is mostly without issues
  • PR Bump dependencies #170
• A button to disconnect individual wallets should wait for this refactor as the UX is gross when you disconnect your Neutron wallet but all the others Injective, Osmosis, etc disappear
• A UX win to only show relevant wallets is an easy lift
  • PR Feat: only show wallets useful to loaded warp routes #171
• I think with a designer it's worth tackling a multi-step confirmation modal
  • Present any info we can show about the recipient
    • An addendum to the above username/image/metadata notes is if the sending account is a contract and they're sending to the same address, we should ensure the user confirms they own the account
  • Highlight if we trust this user, ie
    • several transfers to them previously
    • never transferred to them before
    • if it's our wallet on another network
  • Allow the user to confirm expected gas costs (+ in fiat if we can get somehow) and expected duration
• A quick win to prevent users signing with the wrong wallet or sending to the wrong wallet, hacky but we can sometimes detect if something like OKX is overriding MetaMask
  • PR Investigation: trying to detect overwritten connector names #172