shapeshift
[Feature Request] Sending modals confirm button update
Overview
Recommended by Product and Willy
Currently, users sending a TX with anything besides native are given multiple types of messages after clicking confirm.
After pressing Confirm when sending a TX, you are given a message that says "Broadcasting Transaction" with a spinner. A user with KK would have no idea what to do next (accepting by pressing the button on their keepkey). If a users metamask didn't open up, some new users might not know what to do next.
The suggested fix is that all sending buttons (defi, sending, trading, atom modals) after pressing confirm the button should be pulling data on what wallet the users is using and say "Confirm on [Wallet]" inside the button before moving to the next page.
References and additional details
https://discord.com/channels/554694662431178782/988892734133768192/988892737929617488
Acceptance Criteria
When a user confirms a tx in app.shapeshift.com, if a confirmation on the wallet is required (every wallet besides native) display a pending state in the CTA "Confirm on [wallet]" (ie. "Confirm on KeepKey) until they have confirmed the transaction
Need By Date
No response
Screenshots/Mockups
No response
Estimated effort
No response
The wallet info for the current connected wallet can be pulled by using useWallet().state.wallet / useWallet().state.walletInfo.
Each hdwallet has an helper to keep the checks declarative e.g:
-
isNative -
isMetaMask
From a flow perspective, this means that these components:
-
<Confirm />(https://github.com/shapeshift/web/blob/develop/src/components/Modals/Send/views/Confirm.tsx and https://github.com/shapeshift/web/blob/develop/src/plugins/cosmos/components/modals/Send/views/Confirm.tsx) -
<ClaimStatus />(https://github.com/shapeshift/web/blob/develop/src/features/defi/providers/foxy/components/FoxyManager/Overview/Claim/ClaimStatus.tsx)
will need to show a confirm state (if on any wallet other than native), until the confirm actually happened.
Awaiting on user interaction will actually be easy, given how unchained/Ethereum JSON-RPC providers work. Digging all the way down to the hdwallet implementation, this is where the signed Tx send is handled:
https://github.com/shapeshift/hdwallet/blob/9ada7ded938f7a8ee752517523a724d6a18d5f3e/packages/hdwallet-metamask/src/ethereum.ts#L83-L86
ethereum.request() actually behaves optimistically on user-approved (but not yet broadcasted) Tx, so we can assume that while this promise is pending, the user hasn't approved the Tx (in e.g MetaMask), and when the promise resolves, it has been approved by user, but not yet broadcasted and picked by unchained. You can have a look at https://github.com/shapeshift/web/pull/1787 on how a successfully broadcasted Tx is detected.
Effectively, this means we are safe to simply change the "Broadcasting Transaction" to a "Confirm on [Wallet]" message.
Note that in the scope of this PR, that's the only change required. As a nice-to-have follow up on this, we should now be in a state to properly await the broadcasted Tx for sends with a logic similar to https://github.com/shapeshift/web/pull/1787 (cc @0xdef1cafe) and remove the current 5s optimistic toast timeout:
https://github.com/shapeshift/web/blob/8770737be7fe61363970659bfaf51d76c1361377/src/components/Modals/Send/hooks/useFormSend/useFormSend.tsx#L150
tl;dr, effectively, we are already waiting on user interaction, not broadcasted Tx, but displaying "Broadcasting Transaction" when really it should be "Waiting on [wallet]"
