Migrating Multiple ERC20 to ERC20 bridge to The Graph

L;DR We at Fuse provide a multiple ERC20 to ERC20 bridge to transfer any ERC20 token on the Ethereum network to an ERC20 (ERC677 actually) token on the Fuse network easily after creating a community using our Studio.

The goal

As we started developing the Fuse Network, we understood that users need to have an easy way to transfer their assets on the Ethereum network to the Fuse network in a fast and frictionless fashion.

Our goal was to have users create a community using our Studio and immediately be able to transfer their new or existing ERC20 token from Ethereum to Fuse without the need and cost of deploying new servers and without having to deal with too much technical details.

A bit of background

The first stage was to take a look at the TokenBridge created by our friends at POA. This solution provided the basic functionality we needed, but it had one downfall which is that an oracle needs to run for each pair of tokens. So, we decided to make it a multiple token bridge — a single oracle will process multiple ERC20-ERC20 token pairs.

We developed Factory contracts which are responsible for creating the bridges on both networks (Ethereum and Fuse), deploying an ERC677 token on Fuse network as well as a BridgeMapper contract holding the mapping between the tokens and bridges on both networks. A new watcher process was added to the oracle, querying the BridgeMapper contract and finding out all the “token pairs” needed to be monitored for events. We’ve also contributed this solution back to POA and opened a PR for them to review.

This solution was fine, but as the usage started to grow and more “token pairs” were created we understood that it is not scalable. Querying for past events for multiple tokens was costly in terms of request amount and time consumption, and we encountered delays in getting the tokens transferred between networks as well as some timeouts.

So we went back to the drawing board…

Using The Graph

We’ve decided to replace the event polling from the blockchain network and instead use The Graph.

By using The Graph, we can index all relevant events for all tokens and bridges created on both networks, and the oracle can query all of the required data in one request instead of going over all the mappings from the BridgeMapper one by one and polling the networks.

You can see our graph schemas here and the bridge implementation here. Note that we’re working heavily on the graph schemas to use the graph protocol on all our products (Studio, Wallet, etc.). Thanks to using The Graph the bridge experience is seemless and other than block verifications times the transfer between the networks is almost immediate:

The fastest bridge experience is here — give it a try