search

hyperlane-xyz / hyperlane-warp-ui-template

A web app template for building Hyperlane Warp Route UIs
https://hyperlane-warp-template.vercel.app
Other
126 stars 102 forks source link

Research UX approach for address confirmation #153

Open avious00 opened 6 months ago

avious00 commented 6 months ago

Context

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

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 commented 3 months ago

@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

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

jmrossy commented 3 months ago

@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 commented 3 months ago

@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 commented 3 months ago

OK so following up on this.