chainsafe / chainbridge-ui

ChainbridgeUI

Introduction

Chainbridge UI is an OpenSource (under GNU Lesser General Public License v3.0) whitelabel application for developers to work with Chainsafe Chainbridge. UI consist of two part: BridgeUI is used to interact with Bridge smart contracts in order to send deposits. ExplorerUI is used to track and navigate every bridging that happens over specific Bridge smart contract.

Live demo

You can test UI with our live demo This demo is a working bridge between Rinkebay <> Goerly <> Alfajores (celo). It requires you to have MetaMask wallet and to have some ETH on those network in order to pay tx fees, also you need to request some ERC20 tokens in our discord channel

NOTE this is under an active development so can be broken occasionally.

Running locally

TODO

FAQ

Please check our Q&A section

Support

License

GNU Lesser General Public License v3.0

chainbridge-ui's Issues

Make changes related to gas optimizations on solidity

General information about changes could be found here: ChainSafe/chainbridge-solidity#255

Implementation details

Make sure to check all the possible places that could be changed according to changes related to Solidity side

Testing details

Manual tests with new smart contracts

Acceptance Criteria

Manual tests with new smart contracts are passing

Transfer add transition state awaiting executeDeposit()

@GregTheGreek - Can we get a different state while waiting for execeuteDeposit() to trigger?

Metamask manual configuration docs for Alfajores

In order to use manually configurable CELO provider we need to provide guide that helps with that

Implementation details

Guide should include reallife example params (RPC endpoints or address, if needed) to connect to Celo Alfajores testnet
Documentation should be done in MarkDown and include screenshots.
For now it should be somewhere inside chainbrdige-ui repo docs
Tip: you can use https://hackmd.io/ for drafting

Testing details

Non tech person is able to use this guide to send transactions to Alfajores

Acceptance Criteria

Non tech person is able to use this guide to send transactions to Alfajores

Bad mobile rendering

To many proposals on token transfer

After a transfer takes place, there are to many proposals that were initiated

EIP1559 gasEstimation

Add support of EIP1559 gasEstimation
Read about eip1559: https://hackmd.io/@timbeiko/1559-resources
Currenlty gasEstimation is happen on the UI side that leads to the situation that when we send Deposits to the chains with EIP1559 we set maxGasPrice that leads to errors like ChainSafe/ChainBridge#700

Implementation details

Put all the gasPrice estimation on the MetaMask

Testing details

Test on chain with EIP1559 (Rinkeby or Goerli) and on chain without EIP1559 (Celo Alfajores)

Acceptance Criteria

Manual tests are passes

Autoupdate for transfer page at the explorer UI

The page should show spinner at the end of Transfer Timeline if Deposits status is NOT Executed or Canceled and update data until the transfer is finished or canceled.

Fix "transfer executed on Mainnet"

Expected Behavior

It should show "transfer executed on {destination chain}" on the transfer detailed view

Current Behavior

Transaction dedicated detailed view for explorer UI

Create the transaction detail view page that currently can only be accessible from explorer/list page.

Implementation details

The proposed routing is explorer/list/<transaction id>

Write Guide for setting up metamask networks manually

Currntly to use UI with Celo network we need to setup it manually. It is not hard process but we need to provide guiding documentation for users.

Implementation details

Try to use UI with along with CELO ALfajores <> RInkebay deployment and write the guide about how it should be done.
Guide should include sreen shots. And should be written in abstract manner but using Alfajores network as example.
@jon is responsible for writing the docs, @taha-be should help and test @enemycnt will help with process

Testing details

Non tech user is able to setup metamask and send transactions

Acceptance Criteria

Non tech user is able to setup metamask and send transactions

Token icons for explorer UI

Implementation details

Front end should map the corresponding sourceTokenAddress and destinationTokenAddress with token addresses from UI config and use its imageUrl and symbol.

Prevent users from transfers tokens if supply on the opposite side is not enough

IN order to provide tokens transfers between chains wee need to have curresponding supply of tokens on the opposite side to transfer.
And here we have 2 options. First one is when ERC20Handler is able to mint tokens, then its not a problem at all bcs tokens will be minted in required amount.
But in case when ERC20Handler is not a minter its is (theerc20 handler) supposed to have sufficient balance of tokens that will be sent on the destination chain. In this case we should check that balance on handler is enough to cover the transfer.

Implementation details

To check that ERC20Handler is able to mint tokens use https://github.com/ChainSafe/chainbridge-solidity/blob/master/contracts/handlers/ERC20Handler.sol#L104. If True that check is not required, other wise check that blaance of ERC20 Handelr is enought for transfer
Message to use as error:
Can't process the transfer. Erc20Handler balance on destination chain is not sufficient. Please contact support.

Testing details

Could be tested on Alfajores <> Rinkeby instance bcs we can't mint cUSDs on Alfajores

Acceptance Criteria

Trying to send N cUSD from Rinkeby to Alfajores given that ERC20 Handler on ALfajores has balance of M cUSDs and N >M will inform that handelr does not have sufficient balance
if M > N then transfer should pass ok.
IN case of sending tokens from Alfajores to Rinkeby not messages ever appear since we are minitng tokens on Rinkeby

Add select for home and destination network

We should have two select dropdowns to filter source and destination network.
The list of the network should be requested from the API
NOTE Filtering should happen on the server side. Front end need to knows about possible options only for UX purposes. When user selects some filter, new request should went to server

Can't build UI due to missing dependency

I'm trying to build the UI. I've provided access token with "package:read" permissions, started yarn build and seeing the following error:
2:57:40 PM: error An unexpected error occurred: "https://npm.pkg.github.com/download/@imploy/common-components/1.0.24/bc910d5393b6486beb75326b0761fa2fff80dbaf8b43f6f018156c1ba4fb5f38: Request failed "404 Not Found"".

This is what I see when using my creds to access this site manually:

Configurable support

The support buttons "Ask a question on Discord" etc.. should be configurable in the ui since they are quite nested and not obvious to change.

I propose that the configurable options are:
supportPlatformName: Name of the platform where support is (i.e Discord, Telegram, etc..)
supportLink: The URL to the channel where support can be found

Therefore it would look something like Ask a question on <a href=${supportLink}$>{supportPlatformName}</a>

Add filter for "my" and "all" transfers

Add a button to filter "my" or "all" transfers.
Show all transfers by default
If the user clicks on "my" we should connect user's meatamask and use his wallet address to filter the transactions.
If the user has already connected his metamask, show the user's transfers. Otherwise, show all transfers

Link to block explorer for addresses

Add the link to every address at the explorer UI If there is blockExplorer in the runtime config

Separate decimal places for different tokens

Token decimal places should be configurable for each token separately. Currently it is common for all tokens

Implementation details

Change config and the way ho front end renders amount and calculates balances + balances check on transfer should be revisited with taking in mind that different decimals is possible

Testing details

Add some unit tests that check how UI validates balance of Handler on destination chain in terms it is not mintable and tokens have different decimal palces

Acceptance Criteria

Manual tests passes
Unit tests passes

Hide token wrap tab and view transaction button

Remove the tab and the button that are circled in the screenshot.

## Implementation details

Testing details

Acceptance Criteria

Functional bridge without the wrap token tab and the view transaction button being hidden.

Save pending trasnfer state in local storage

Its often happens that users reload their page after submitting the deposit, so they are not able to define in state or find it in block explorer

Implementation details

Store details of submited deposit in localsotrage so after page is reloaded user is end up on the pending transfer page

Testing details

Reload pages on different states of submitted deposit.
Add some unit tests

Acceptance Criteria

[] Unit tests and manual tests are pass
[] After ussers submits deposit he can reload the page on both deployed version and the widget

handle DECIMALS = 0

Fix the regex to handle DECIMALS = 0 and prevent the app from crashing...

How can we limit the transfer amount on the Transfer Page.jsx

How can we limit the transfer amount on the Transfer Page.jsx page.
For example, the user can transfer a maximum of 5000 units. If user want to transfer more than that, he should be warned about the limit.

Implement transfer details static page for ExplorerUI

After finishing Transfers list page, page with transfer details should be added. Transfer details page displays detail about exact Transfer in more details.

Implementation details

Design https://www.figma.com/file/BGduu0djnopu1y3MCBWDaZ/Chainbridge-Token-Swap-Dapp---Light?node-id=561%3A22242

When any Transfer from transfer list is pressed, page with Transfer details should be PopUped.
All data on page should be hardcoded for now.

Testing details

Check that transfers details properly displays on different screens and browsers. (Do not overwork with responsiveness. Since we do not have any mobile screens design, just make at looks ore or less affordable)

Acceptance Criteria

Transfer details properly displays on different screens and browsers.

Implement ExplorerUI static main Transfers list page

In order to start working on ExplorerUI we need to have Main page with all coded CSS styles and interface components that will be reused on other pages.

Implementation details

Use this design for implementation
https://www.figma.com/file/BGduu0djnopu1y3MCBWDaZ/Chainbridge-Token-Swap-Dapp---Light?node-id=561%3A22242

ExplorerUI should be part of ChainbrdigeUI application.

Add route to the chainbrdigeUI that opens Explorer transfers list page. Route should be {host}/explorer/list

Transfers should be hardcoded for now (took data from design)

Testing details

Check that transfers list properly displays on different screens and browsers. (Do not overwork with responsiveness. Since we do not have any mobile screens design, just make at looks ore or less affordable)

Acceptance Criteria

Transfers list properly displays on different screens and browsers.

Doesn't detect metamask in Brave

See the screenshot:

Expected – see metamask, request account connection.

"max" button does nothing

I am unable to select "max" when wrapping, and for transfers it does nothing.

Add support of basic auth

Expected Behavior

Connect to ethereum compatible RPC

Current Behavior

Connection to RPC is failed if URL has user and password of basic auth

Possible Solution

Detect password in URL and convert it to object for JsonRpcProvider

Steps to Reproduce (for bugs)

1. add rpcUrl like "https://john:doe@host"
2. try to transfer the token to this chain

UI for Celo

wrap page graphics not displaying

due to changes, this page also requires the updates the transfer page received.

like so, minus the "Shyft" icons, will work for your main application.

UI for Celo with manual configuration

Add CeloProvider that is able to communicate with Celo networks

Implementation details

Provider could use manually configurated MetaMask to sign Celo transactions.

Testing details

Send Deposits from UI on Alfajores

Acceptance Criteria

Deposits successfully sent to Alfajores

Full address view

Show full address everywhere at the Explorer UI instead of a shorter one.

UI element that displays number of relayers online

Story

As a maintainer of a bridge relayer
I want a UI element that displays the number of relayers online and disables the rest of the bridge UI if the threshold of signers isn't met.
So that I can avoid having to enter into recovering funds if somebody used the bridge while the relayers were done

Background

I am running a bridge from our network to the Ethereum chain. I don't like that there isn't any error checking that the bridge is capable of making the transfer (i.e. enough relays are online) before allowing users to attempt to send their funds across. This would be a nice feature to avoid having to enter into recovering lost funds.

Implementation details

A small UI element that displays a red or green circle with a x / total relayers online next to it. the circle is green if enough relayers are online and the rest of the UI is visible and usable. If there are not enough relayers online the circle is red and the UI becomes greyed out (not accepting input or interacting with the send button) and displays a message to the effect of: "sorry, the bridge is offline please check back later."

rename chainID to domainID

We really should start the discussion about renaming ChainID param in Chainbridge that conflicts with the EIP-155's ChainID and brings a lot of confusion. This param should be renamed in both Chainbridge and Solidity.

Implementation details

rename chainID to domainID everywhere
docs and code related to chainbridge-ui

This version of UI will be non compatible with previous version, because some changes to how we communicate with Solidity required (Events signatures, and some function will be changed)

Make sure that you are not renaming chainID that is related to EIP-155, but rhater the chainID that is part of our internal protocol https://github.com/ChainSafe/chainbridge-ui/blob/main/config/chainbridge-runtime-config.celo.js#L5

Testing details

Manual tests

Acceptance Criteria

Enable Substrate support

Substrate HomeChain Adapter

• Handle connection to network and setting main context state to correct network
• Handle retrieving user token balances
• Initiating a Deposit on the chain
• Setting the Context Deposit Nonce variable

Substrate DestinationChain Adapter

• Waiting for Deposit Nonce to be set, and setting up listeners for Destination Chain events, and dispatching actions at the appropriate reducers on Chainbridge Context

UI Updates

• When connect is clicked, a modal (or other UI element) should be displayed to the user to allow them to select the type of wallet they would like to connect.
• This dialog should then handle the appropriate connection logic

Chainbridge Explorer Event Indexer

Notion
An indexer should be built that exposes a REST/GraphQL endpoint

• Substrate does not support event querying and as such getting this data quickly enough for good UX will require an indexer.
• Since the current client-side indexing architecture is clearly constrained by RPC, it makes sense to also handle indexing of EVM events in the same database.

• An indexer will require:
  • A full network bridge config (RPC, contract addresses
  • Database config
• The indexers will handle storing the following events:
  • Add Deposit Record
  • Add Proposal Vote
  • Add Proposal Event

The events above should be used to build up the following object describing each transfer:

type DepositRecord = {
  fromAddress?: string;
  fromChainId?: number;
  fromNetworkName?: string;
  toAddress?: string;
  toChainId?: number;
  toNetworkName?: string;
  tokenAddress?: string;
  amount?: BigNumber;
  timestamp?: number;
  depositTransactionHash?: string;
  depositBlockNumber?: number;
  proposalEvents: Array<{
    proposalStatus: ProposalStatus;
    dataHash?: string;
    proposalEventTransactionHash?: string;
    proposalEventBlockNumber: number;
    timestamp: number;
  }>;
  votes: Array<{
    voteStatus: boolean;
    voteTransactionHash?: string;
    voteBlockNumber: number;
    timestamp: number;
    dataHash: string;
  }>;
};

Following deployment and testing of the indexing & querying API, all the event listener code in ExplorerContext.tsx should be removed and replaced with API queries.

The current code in ExplorerContext should be used as a base for the EVM chain indexer.

Fetch Transfers list from API

After getting static pages with all required layouts all the necessary structures and API layer code should be added.

Implementation details

Add API layer that fetches list of transfers for transfers list.Add all the rendering staff, react components, reducers and structures that are required.
The request should be
GET {explorerui.com}/transfers
Example Response:

transfers: [
{
  fromAddress: "0x1234";
  fromChainId: "1";
  fromNetworkName: "ETH Mainnet;
  toAddress: "0x321";
  toChainId: "4";
  toNetworkName: "ETH Rinkeby";
  tokenAddress: "0x567573";
  amount: "100000000000000000";
  decimals: "18",
  timestamp: "1232131";
  status: "1",
  depositEvent: {
    destinationChainID: "4";
    resourceID: "000000000000012312312300";
    depositNonce: "1";
    transactionHash: "0xdasd123123123";
    timestamp: "123123123";
},
  proposalEvent: {
    destinationChainID: "4";
    resourceID: "000000000000012312312300";
    depositNonce: "1";
    transactionHash: "0xdasd123123123";
    timestamp: "123123123";
    by: "0x123231323";
},
voteEvents: [{
    status: "1",
    destinationChainID: "4";
    resourceID: "000000000000012312312300";
    depositNonce: "1";
    transactionHash: "0xdasd123123123";
    timestamp: "123123123";
	  by: "0x123123123123";
}],
},
]

where URL should comes from runtime config param named: indexerURL or any other name you wish)
Write some unit tests as well
NOTE: do not implent the proper deposit timeline (in deposit details) in terms of the issue, wiill be done separate issue for tihs

Testing details

Write unit tests.

Acceptance Criteria

Unit tests are passed
Transfers lists shows predefined list of transfers from mock.

Transfer timeline for explorer UI

Add the timeline for a detailed view of the transfer

Implementation details

Were not be any line saying Ignoring vote from ....
then all is displayed based on statuses and events UI receives from indexer:

response.transfer - corresponds for Deposit submitted, use its timestamp for timeline time

response.proposal - corresponds for ProposalCreated on {response.toChainID}

response.votes - if voteEvent status Active (1) then it was just vote, so timeline

if voteEvent.status = Passed (2), then displays "Waiting for execute" (based on previous document shapter)

if voteEvent.status = Cancelled (4), then Cancel event should be in timeline

Statuses enum:

enum ProposalStatus {Inactive, Active, Passed, Executed, Cancelled}
refer to: https://github.com/ChainSafe/chainbridge-solidity/blob/master/contracts/Bridge.sol#L27
Inactive - default status for solidity (Never to appear in events)
Active - Proposal was created and waits for more votes
Passed - Votes amount meets threshold
Executed - Proposal was executed by the relayer
Cancelled - The proposal was canceled by someone

Displaying general status on the UI list and details:

if indexer response.Stauts == 1, then should be Active status and **"waiting for more votes" message displays on the end of the timeline
if response.Status == 4, then proposal should have canceled status, and canceled event should be displayed on the timeline
if response.Status == 2 then status sould be Passed and "waiting for execute" message should be displayed in the end of the timeline
if response.Status = 3 then the status should be Completed (!) and execution timeline should be at the end of timeline

ChainbridgeUI Explorer

Basic information could be found here
https://www.notion.so/chainsafe/Explorer-Project-Plan-2d6d9c5bb34f4b1698e447efddceb838#7c23aecd074a40848636986e56d63d8c
and
https://www.notion.so/chainsafe/ChainBridge-Explorer-UI-Design-Doc-876e7064d87e4de49616b22dd9810234

Fix race conditions for messages displayed on TransferActiveModal

Expected Behavior

Render first the messages that signal the transfer has started and the the messages related to vote casted by contract

Current Behavior

When transferring tokens, due to current fix on #93 sometimes the message related to the vote it get's rendered first than the other messages that signals the beginning of the transfer.

Possible Solution

Convert useState to useReducer to provided sync update on message array

Steps to Reproduce (for bugs)

1. Connect to metamask wallet
2. Select amount of tokens to send
3. Start the transfer
4. Watch the vote messages being rendered first.

Versions

ChainBridge commit (or docker tag):
chainbridge-solidity version:
chainbridge-substrate version:
Go version:

Bridge Explorer Context

A React context to collect and keep track of all data necessary for the Explorer view

Disable Substrate or Ethereum wallet options

Story

As a user
I want clearly understand which wallets I can use
So that I can use the UI without any issues.

Background

We recently added Substrate support which added the option of using a Substrate wallet. However, this is always presented as an option regardless of the configuration. If you select an "invalid" wallet the UI just hangs.

Details

Based on the chains in the config file we should enable/disable the necessary wallets.

Scenarios

N/A

Implementation details

N/A

Testing details

N/A

Acceptance criteria

The correct wallet options are displayed when the user goes to connect a wallet.

Deploy UI for Kovan <> Rinkebay live demo

Wrapping progress improvements

Currently the window has not edge and just blends into the background. There is also no way to tell if it's processing or frozen.

Cannot enter amout without selecting token

The amount field is locked before selecting a token. This is an annoying UX, we should either unlock it or add some signal the user should select a token (or reverse the order of these two components?)

Incorrect token balance when no tokens owned

Expected Behavior

Token balance should show zero if user has no tokens in wallet. And this is ERC20 tokens, not CELO (native).

Current Behavior

Currently shows Balance: 5e-16 cUSD when user has zero tokens in wallet. See screenshot below.

Possible Solution

Display a zero balance instead of 5e-16.

Steps to Reproduce (for bugs)

1. Access WB UI
2. Change network to Celo
3. Change wallet to one with zero token (cUSD) balance

UI not finalizing "In Transit" Events - not progressing to tx completed stage

stalls here indefinitely, on-chain events/progression does occur, so tx does go through it's just not reflected on the UI

Add filter for deposit hash

Connect deposit hash search form markup to the API

Chainbridge Context and EVM Homechain/DestinationChain Adapters

The current Chainbridge Context needs to be split into 3:

• Chainbridge Context - This should be entirely chain-agnostic, and solely used as a store of state, and a tool to enable coordination of the UI and adapters

  • Home network connection state
  • Transfer details
  • Active Deposit Nonce
  • Proposal Votes
  • Proposal Events

• EVM HomeChain Adapter

  • Handle connection to network and setting main context state to correct network
  • Handle retrieving user token balances
  • Initiating a Deposit on the chain
  • Setting the Context Deposit Nonce variable

• EVM DestinationChain Adapter

  • Waiting for Deposit Nonce to be set, and setting up listeners for Destination Chain events, and dispatching events at the appropriate reducers on Chainbridge Context

---

Login Connection

• Today

  1. User clicks button and metamask connection dialog is displayed
  2. When the wallet connection is complete the Context identifies the EVM chainId and displays messages to the user if the chain they have selected is not supported
  3. The CB Context sets the HomeChain state variable to the connected EVM chain (based on ChainId) or shows an error message that an invalid home network is currently connected.
  4. If there are only 2 bridges configured, the Destination Chain is automatically set
  5. The Bridge parameters are fetched from the Bridge contract (Approval Threshold, Bridge Fee)

• Proposed Change

  1. User clicks Connect and is displayed a modal with overarching wallet choices (Substrate and Metamask).
  2. User chooses the applicable wallet
  3. A Chainbridge adapter specific to that chain type should then be instantiated
  4. The adapter handles the connection call as well as cases where an invalid network is selected
  5. Chainbridge adapter sets the HomeChain state on Chainbridge Context to update the UI
  6. If there are only 2 bridges configured, the Destination Chain is automatically set
  7. The BridgeAdapter should fetch the Bridge parameters from the contract/palette (Approval Threshold, Bridge Fee)
  8. The bridge adapter should also fetch all user token balances for all tokens configured for the home chain

Deposit Flow

• Today

  1. User completes the deposit details and calls ChainbridgeContext.Deposit() to initiate the transfer
  2. The context starts a listener for the Deposit() event.
  3. Once the Deposit transaction is confirmed, the DepositNonce is picked up by the listener in step 5, and Chainbridge Context is updated.
  4. As soon as the deposit nonce has been set on the Chainbridge context, the Destination Chain event listeners are registered (ProposalVote and ProposalEvent).
  5. Each time these events are received, they are transformed into a Redux Action body that is dispatched to the TransferEvents reducer to update state.
  6. Once a ProposalEvent with a status of 3 (Completed) or 4 (Aborted) is received, the process is completed, the listeners are torn down and the results are displayed to the user.

• Proposed Change

  1. User completes deposit details and calls ChainbridgeAdapter.Deposit - This call should set the deposit nonce on Chainbridge Context
  2. As soon as the deposit nonce has been set on the Chainbridge context, the Destination Chain ChainbridgeAdapter event listeners are registered (ProposalVote and ProposalEvent). These event listeners will dispatch actions against the reducer in Chainbridge Context to keep state updated
  3. Once a ProposalEvent with a status of 3 (Completed) or 4 (Aborted) is received, the process is completed, the listeners are torn down and the results are displayed to the user.

UI aborting transfers

Expected Behavior

The UI submits the transaction

Current Behavior

2021-08-23_10h57_09.mp4

Pagination for transfers page

Add pagination for transfers page.