Ability to call executeSignatures() by an end user from Bridge UI

[akolotov]

In some configurations of the token bridge, the bridge validators will have no ability to call executeSignatures on the Foreign side (e.g. they have zero balance on the Foreign network by intent). In this case the end user will be responsible for passing the validtors' confirmation to the Foreign side to release/mint tokens.

It is necessary to think of the work flow and the interface in the Bridge UI to provide the end user ability to call executeSignatures and implement it.

[akolotov]

Before any code changes please suggest the best user experience to: how user will interact with the UI in this scenario.

[fernandomg]

Technical challenges

In this section we're exploring the different techinal aspects that we must consider at the moment of implementing this issue.

Delegate executeSignatures payment to the user

From now on, the bridge-ui will be able to handle the situation when the validator responsible of signing the executeSignatures tx rans out of funds to do so.

To handle this situation we are going to monitor how many blocks old is the transfer request/confirmation/completion, and provide information/actions to the user. So if a transfer was confirmed but not completed for more than [FOREIGN|HOME]_REQUIRED_BLOCK_CONFIRMATIONS blocks, it will provide the user with the option to [Complete] it:

0x25d...b83 1000 Transfer of POA to POA20 not confirmed during 5 blocks
** 0xa8a...7fb Transfer of 300 POA20 to POA confirmed but not completed during 21 blocks [Complete]
0xae9...0b5 400 POA20 to POA transferred successfully in the 1198782 block
0xf3e...4e1 750 POA to POA20 transferred successfully in the 661490 block
0x1a4...f86 300 POA to POA20 transferred successfully in the 658745 block 

The different statuses that we're going to handle are:

1. 0xa8a...7fb Request to transfer of 300 POA20 to POA waits for finalization for X blocks
2. 0xa8a...7fb Transfer of 300 POA20 to POA not confirmed during X blocks
3. 0xa8a...7fb Transfer of 300 POA20 to POA confirmed and waits for finalization for X blocks
4. 0xa8a...7fb Transfer of 300 POA20 to POA confirmed and waits for completion for X blocks
5. 0xa8a...7fb Transfer of 300 POA20 to POA confirmed but not completed during X blocks [Complete]

Validate user's funds

At some point of the transfer process, the app will require to check user's funds in the destination network.

Currently we're checking for funds in the origin network after the users clicks [Transfer] button. We can use this same moment to check for funds in the destination network, as there are some scenarios where let the user know that it may need funds in the destination network is a must.

Track transfer status

event based networks

We should keep using the current method to gather information based on the network events.

non-event based networks

To keeptrack of the bridging process we should:

1. call numMessagesSigned
2. call isAlreadyProcessed

And persist the information we retrieve from the network in the browser's localStorage

store information in the browser'slocalStorage

We must listen to the status of the network status block-by-block. So we can give feedback to the user as previously stated in Delegate-executeSignatures-payment-to-the-user

On the other hand, once the signatures where collected, we need to:

1. call message
2. call signature(msgHash, index)
3. store encodedABI
   ... after switching the network:
4. use the encodedABI to sign executeSignatures

One thing that arises due to the network swap requirement. Is the need to persis the app state in the localStorage (changing networks in Metamask/Nifty Wallet, forces a page refresh with the subsequent data loss). There's an already purposed issue #124 that tackles this requirement. We will need to persist:

1. 1st txHash
2. User account
3. Transfer direction (Foreign <-> Home)
4. encodedABI

Note: We can reconstruct the transfer status in an event based network, so we may not need it in that scenario.

Resilience

There is a last aspect about the need for a 2nd tx. If it doesn't succeed, the user may have his funds locked and never minted in the destination network. So we should have a way to validate txs status and allow the option to retry a tx that was accidentally rejected, or wasn't executed, etc. We can replicate what was done in the Token Wizard:

---

UX challenges

In this section we're exploring how to properly present the information, and bridging conditions to the user.

A second required tx

Given the scenario where the user may need to pay in the destination network to complete the transfer.

We need to explore/decide how to properly let the user know that he/she may have his funds locked if doesn't have funds in the destination network.

In this situation we must provide the user with plenty information:

• RPC address for the destination network (in case the user doesn't have it in his wallet)
• Explicit information on how to change the network
  • go to to wallet
  • switch network
  • wait for the page to reload
  • sign tx

Transfer roadmap

Present all the steps required to accomplish the task and mark its progression: or as purposed in #1208

tx retry

We must keep track of the txs statuses, and provide the ability to retry a tx that failed for any reason.

---

Scheme

[fernandomg]

In this issue we're going to focus only on networks that support eth_getLogs, for networks that don't, a different issue was created: #160.