• UI for searching for a whitelist of ERC20 tokens, set by environment variables
• allow setting unlisted ERC20 via URL param (show warning for these)
• if user selects ERC20 that has no matching ERC20-as-NEP21 deployed via Token Factory in NEAR
  • UI explains situation
  • user can pay tx / storage fee to deploy NEP21 Wrapper

found that error when I tried to transfer more tokens than I had.

Tried to send 100 when I had 99

Got a metamask error, if ignore it then tx failure https://ropsten.etherscan.io/tx/0x1f4883b28b4412b74524a1e994d79922ffd0c17df468216d13583552c4aa4c5d

This import import Tree from 'merkle-patricia-tree' is causing the issue: https://github.com/near/rainbow-bridge-client/blob/5e48919bf878cd742417dd146ce114b6ba8a1e23/packages/nep141-erc20/src/natural-erc20/sendToNear/findProof.js#L1

At the moment every time when a user switches NEAR account he asked to add the app key in the NEAR Wallet

• UI for searching for a whitelist of NEP21 tokens, set by environment variables
• allow setting unlisted NEP21 via URL param (show warning for these)
• if user selects NEP21 that has no matching NEP21-as-ERC20 deployed via Token Factory in Ethereum
  • UI explains situation
  • user can pay tx / storage fee to deploy ERC20 Wrapper

• Disable the input field if the user's balance of the selected token is zero.
• Disable the approve button (I suppose that's anyway enabled by something being typed into the amount field.)

There will be several bridges running at the same time between different networks (Near mainnet, Near testnet, Ethereum Mainnet, Rinkeby and Ropsten).

The relevant difference between them from the frontend point of view, are the addresses of deployment and endpoint RPC. We should have a dropdown on the UI that allows user to change between bridges, (similar to how it is done in the explorer)

On a new transfer page, if the user changes Ethereum account, the balances should be queried again.

• Ethereum -> Near: update "Available to transfer"
  

• Near -> Ethereum: update "Current balance" in To (destination)
  

#120 (review)
featuredErc20s seems like something that is app-specific, but the rest of the config seems like info that should either live in the main client library or a connector library.

When, as shown above, someone has existing balance on NEAR of an ERC20 that has been wrapped as an NEP21 on NEAR, they should be able to send some balance from NEAR back to Ethereum. In the view below, there should be arrows pointing in both directions.

This should be done in the same way as rainbow-bridge-cli

Ledger-based wallets are not able to sign finalisation transactions. See more here: aurora-is-near/rainbow-token-connector#48

Currently bridged tokens use the same token icons in the withdrawal dropdown. This can be enhanced by an approach to modifying existing ERC-20 tokens in similarly.
The main goal is to give a user a visual confirmation of two facts:

1. Bridged token is different from the source token
2. Bridge token is a representation of the source token on NEAR (has a 1:1 exchange ratio)

CC @chadoh

Currently, the bridge, and perhaps the wallet, display ERC-20 tokens as the Ethereum name, prefixed with an "n", e.g. "nALCX". This exposes in the UI the underlying mechanics of what's happening, i.e. that the token they are using on NEAR is a different token than what they had on Ethereum.

An alternative, currently in use by BSC and Terra, would be to use the original name of the token, e.g. just "ALCX". This has some benefits:

• We hide the underlying mechanics from the user, and reinforce that "transferring" across the bridge is actually "moving" their tokens.
• Interacting on NEAR has some familiarity (they're using the same tokens they are used to).
• The UI of the Rainbow Bridge could be simplified, dropping the "Received as" row.

The withdraw() function of the BridgeToken should be #[payable] like the ft_transfer() of NEP141 and require a near deposit so that it is not possible to transact with an access key to that token contract. Instead the user should always sign a withdraw/lock transaction via the near wallet.

Minting/unlocking on near can be done safely with access keys as the receiver and amount are determined at lock/burn.

Once the change has been made and NEP141 is applied, this rainbow-bridge-frontend interface will have to be updated since it currently uses access keys for withdraw/lock on the near side.

index.ts:205 :

Uncaught (in promise) Error: overflow (fault="overflow", operation="BigNumber.from", value=1000000000000000000, code=NUMERIC_FAULT, version=bignumber/5.0.8)
at l.makeError (index.ts:205)
at l.throwError (index.ts:217)
at m (bignumber.ts:335)
at Function.from (bignumber.ts:226)
at r.encode (number.js:13)
at array.js:41
at Array.forEach ()
at l (array.js:27)
at t.encode (tuple.js:19)
at C.encode (abi-coder.js:82)

During the TST token transfer from Ropsten to TestNet, the front-end stales at the syncing stage, though the transaction was included in the block already.

Transaction: 0xbafee58f33a7d2441026e0e05272d1a0d8eb7396793e9331d930a5867af8471f

When someone has existing balance on Ethereum of an NEP21 that has been wrapped as an ERC20, they should be able to send some balance from NEAR back to Ethereum. This is the inverse of near/rainbow-bridge#394

This should be done in the same way as rainbow-bridge-cli

This task essentially amounts to a refactor.

• Keep hard-coding same ERC20 address into https://near.github.io/rainbow-bridge-frontend/
• BUT, use Generic Token Connector bridge to send it across

This will rely on on using the CLI to deploy an NEP21 token to wrap the ERC20 using the Factory contract

Should we clarify to users that this is Beta software and there are potential risks with using it.

See how https://aeb.xyz/#/transfer does it:

This link is broken:
https://helper.testnet.near.org/

https://coinmarketcap.com/tokens/

Bridge FE does not query correctly the balances of the tokens and because of this does not allow to start the transfer.

Only 15 characters can fit into the amount field. This would for sure be not enough for the majority transfers given decimals == 18 is a de-facto standard.

While Job Stories (being defined for this project in #42) are useful for collecting a list of the granular motivations and decisions that users will be making as they interact with our product, it's also important to keep in mind the higher-level user journey.

Unlike job stories, a critical path can be illustrated in a number of ways (text, flowcharts, other diagrams). It's up to the author. The ultimate goal is to illustrated a single primary/critical path (ignoring major divergences) that a user will take from the point at which they enter the application, to the point at which they have achieved their primary goal, and all the steps in between (in our case: from sign in to the successful exchange of a certain amount of a single ERC20 to its NEAR equivalent).

As a design reference for how we envision a user traveling between points A > B > C, let's define the Critical Path that a user is most likely to traverse during their initial encounter with our MVP.

• #149
• #136 (functionality only, may be without nice-looking UI) + PR#10 PR#11
• Update the list of tokens according to #112 (comment)
• #105 (comment)
• Change on the login screen 'Don’t have a NEAR account? Create one here.' -> 'Need a NEAR account? Create one here.'
• Change the links to the URLs according to #105 (comment) when switching between the networks
• During scheduling the deployBridgeToken transaction change the appropriate amount for contract storage
• Change everywhere the NEAR-side token names from DAI^n to nDAI
• Update the wording for the transfer steps:
  • Approve transfer of 5.1 TST from Ethereum
  • Convert 5.1 TST to nTST
  • Wait for 20 Ethereum confirmations for security
  • Deposit 5.1 nTST on NEAR

  ---

  • Withdraw 0.1 nDAI from NEAR
  • Convert 0.1 nDAI to DAI
  • Sync withdrawal transaction to Ethereum (up to 24 hours)
  • Deposit 0.1 DAI in Ethereum

checkMint() gives a failed transfer status if balanceBefore + transfer.amount != balanceAfter.
But the user may be doing other transfers (via bridge or regular token transfer) so checkMint() may give a failed status even though the mint transaction was successful.

The same problem can occur when the near.wallet informs : Error: send_tx_commit has timed out (balanceAfter queried before the tx is executed ?)

The bridge frontend should be served at *.near.org url rather than in *.github.io for production.

We can keep *.github.io for staging, testing and iterating fast on new changes, but ultimately the stable and trusted deployment of the bridge should be at bridge.near.org.

After #104 we can have different url for different bridges, such that is clear for the user reading at the URL which bridge they are using. (Example https://bridge.rinkeby-testnet.near.org / https://bridge.ropsten-testnet.near.org)

Reason: incompatibility of the licenses

eth-object also uses web3.js
eth-util-lite -- no

I was syncing blocks on the frontend and it got to 25/30.

Said "Failed" and the UI went red.

I clicked retry.

It is now orange, but still stuck at 25/30 block.

Now my TST isn't minted on the receiving side.

It's been several minutes now. Nothing on explorer.

Not sure what appropriate course of action is?

Perhaps we need some sort of unlocking if tokens are stuck and not minted?

From metamask a user may speed up an approve or lock transaction. Since the dapp frontend has no knowledge of this, it will keep checking the status of a transaction which has already been replaced and will never be mined. This is common behavior on eth mainnet especially with recent gas price variations. For dapps like uniswap this is not an issue as nothing depends on the execution result of the swap. But for the bridge:

• If this happens on an approve tx, the user will never be able to create another transfer to Near due to the double approval override safety
• If this happens on a lock tx, the dapp frontend will keep waiting for that lock tx and never be able to build a lock proof to mint the tokens on Near.

Discussions on the topic:
web3/web3.js#3585
web3/web3.js#3723
https://eips.ethereum.org/EIPS/eip-2831

Also there doesn't seem to be a good way to check transaction statuses with the account nonce since that would require an indexing service such as etherscan.

cc @djsatok

Currently, in getNep21Balance function we use the following code:

const nep21Address =
    transfer.sourceToken.replace('0x', '').toLowerCase() +
    '.' +
    process.env.nearTokenFactoryAccount

Though at the moment this is correct, a connector might change the way how it maps addresses of the tokens on both sides. For the consistency, we should use get_bridge_token_account_id view method of the bridge factory

Overview

I started an "Approve" TX, then used the MetaMask "speed up" feature to get the TX mined quicker. By doing this, the frontend never detected my successful TX (likely due to the TX having a different hash than the original), and there was no way for me to advance in the flow. I had to send another "Approve" TX, even though I'd just approved the contract.

Expected Behavior

If I've approved the vault for a token at any time, I shouldn't have to re-approve.

Steps to Reproduce

1. Click "Approve Transfer"
2. Authorize the TX in MetaMask
3. Either click "Speed Up" in MetaMask, or leave the page and clear the browser cache
4. The only path forward is to click "Approve" again and sign another, redundant TX

In case a user would like to manually enter the token contract address, the FE does not close the dropdown dialog after hitting enter. If manually close it, the displayed info in the transfer form is correct. This might be misleading for a user.

Desired behavior: once a user entered an address of his token in the field and hit enter, the dialog should be closed.

Fully support the generic token connector, https://github.com/near/rainbow-token-connector, in https://github.com/near/rainbow-bridge-frontend

At the moment we use hardcoded number of the confirmations required by the client contract.

This should be updated with the. view method of the same contract, once it's implemented. Corresponding client issue is here

I cant see my transfers but I see console errors like this:

Error: Unregistered library for transfer with type=@neareth/nep141erc20/natural-erc20/sendToNear
Error: Can't find library for transfer with type=@neareth/nep141erc20/natural-erc20/sendToNear

Source: https://near.github.io/rainbow-bridge-frontend

this is unrelated to this example, so feel free to close and point me to the right repo

in the transfers section, the last bullet-point says

in-progress transers

When designing an MVP, it's beneficial to lay out user stories at the outset of a project as a means to comprehensively survey the various user tasks and motivations.

In contrast to user stories, I actually favor Job Stories to fill this role. Job stories tend to be less prescriptive of user actions or solutions, and tend to provide more information about a user's context and motivations, which help to frame the problems we're solving more effectively.

The job story format looks like the following:

When I [situation], I want to [motivation] so I can [outcome/benefit].

In preparation for designing the front-end for the rainbow bridge, let's go through and define our job stories for our v0, making sure to focus not on prescribing specific solutions (eg "we need a button for..."), but rather our users' context, motivations, and outcomes. This list should be focused only on the stories we will be solving for for the MVP. These stories will be used to set and maintain context for decision making during the UX and UI design process.

Job Stories

A few examples to start:

- [x] When I first set out to transfer tokens from my Ethereum wallet to my NEAR wallet, I want to know which ERC20 tokens are available to transfer, so I can ensure I have the correct ERC20 tokens available in my Ethereum wallet.

• After I initiate a transfer, I want to follow the progress of my transfer every step of the way, so that I can stay informed about the state of the transfer and any significant events that occur during processing.

- [ ] When a transfer I initiated is successful, I want to be notified about its completion, so I know when my transferred tokens are available to use.

• When a transfer I initiated encounters a problem, I want to be notified of and be given context about the issue, so I can make an informed decision about what I might need do to resolve it.

Rust throw an exception about "invalid digit found in string" when we transfer amount of tokens with the numeric separator (0.5, 0.777 etc)

The frontend at https://near.github.io/rainbow-bridge-frontend/ should allow sending a specific NEP21, with a hard-coded address for now, across to Ethereum. This will require using the CLI to deploy an ERC20 to wrap it on the Ethereum side using the Factory contract.

This may take some collaboration with a designer to figure out a sensible way to show all of these new options.

These links are not available
https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/ethereum/assets/0x722dd3F80BAC40c951b51BdD28Dd19d435762180/logo.png

When I call mint, I got redirected to wallet to approve the tx. If I close that tab without approving (or canceling) the tx. The UI stays in a state where it is waiting for approval, and I can’t call mint again from the UI.

This can be done using https://www.cypress.io/ or anything similar

Currently for locking a token, it's allowance needs to be set so that the lock contract can pull the tokens.
This allowance is currently set by calling erc20Contract.methods.approve().
If a user initiates two eth -> near transfers, then the allowance will not have been increased by the 2nd transfer (because approve only sets approval and simply overrides the previous approval) and the erc20Contract.methods.lock() will fail.

Possible solutions:

• Increase the allowance instead of setting it. But some erc20 tokens implement increaseAllowance() and others increaseApproval().
• Prevent the user from initiating a transfer while the previous one is not locked.
• Give the maximum allowance to the lock contract.

This will help to completely resolve #113

Fully support the generic token connector, https://github.com/near/rainbow-token-connector, in https://github.com/near/rainbow-bridge-frontend