Radar Relay Technical Overview

Insight into features and community feedback

Introduction

We are humbled by the response to Radar. This small relayer startup we began working on a few months ago has gained traction and momentum quicker than we ever imagined. Our initial Medium post on August 11th caught fire and we’ve been sprinting to meet the ambitious goals we’ve set for ourselves. This post shares technical details on how Radar is built and insight into the community input we’ve received. But, first, a few updates for the community:

1. Radar is a small team (less than 10 people) and we’re a lean startup. We’ve set a course and we strive to be directionally correct. For example, we set a course for a main net release by August 31st. Then, two things happened. First, we had technical challenges with migration from the test net to main net. Second, we received persuasive input from partners and highly motivated users to be cautious. So, we pivoted to a Kovan release to mitigate any unforeseen user risk.
2. Radar has a strong vision to help create a new category. Radar is a relayer, not an exchange, and our product decisions reflect that differentiation. However, we can’t grow this new category in a vacuum. In fact, we are relying on you, a member of our community, to help us shape this space.
3. We are learning, in live time, alongside the community. Sometimes we’ll be teaching and sometimes we’ll be the students. Either way, we are exploring new territory, together.

How Radar Relay is Built

Users have asked for more information on our architecture. Our infrastructure, tech stack, and some specific beta details are described below. Warning: technical jargon ahead!

Infrastructure

Google Cloud, Kubernetes, Travis, Tick

The server and deployment infrastructure for Radar is powered by a provider agnostic Kubernetes framework. This allows for us to scale rapidly when the traffic spikes and significantly mitigate risks associated to deployment orchestration. All of our backend services are stateless and can be scaled independently without cross-instance state management and draining, allowing us to react to load and rollout updates easily.

We are using node.js and eventloop monitoring via the TICK stack allowing us to graph our instance load down to the specific method calls and how long they block the event loop.

Radar — Monitoring Dashboard

Lastly, for our Blockchain infrastructure, we host several custom Parity RPC nodes for certain backend actions along with utilizing Infura. We’d like to recognize Infura as they have been instrumental in supporting our beta! They provide an excellent service!

Tech Stack

Typescript + Øx.js

Both our backend and frontend codebase utilize Typescript, a strict syntactical superset of JavaScript. Typing and schema validation are critical in the design and architecture of a platform that deals with conversion and relation of many different abstractions of a single type. In the case of Radar Relay, we have many tokens that implement the ERC20 standard definition of an Ethereum network token and many orders that extend the Øx definition of peer-to-peer orders.

Using Typescript, we can ensure that strict typing is followed throughout both the backend and frontend, meaning, if a variable is declared to hold a string, it’s value will only ever be of type string.

Typescript’s implementation of Interfaces allows our codebase to have one reference to the base schema definition for objects. With Øx.js object interfaces, object schemas can be defined once and any instance of an object that extends or inherits that interface is guaranteed to have the fields defined in the interface.

Server-side Øx.js Wrappers

In addition to strict typing, implementing our backend in Typescript enabled the use of the Øx.js library. This means that SignedOrders are validated in the same manner as any other dApp that implements the Øx.js library, providing a consistent and stable validation across all applications that use Øx.js. The Øx.js library includes standard types that we can use without implementing the types ourselves, again, providing a consistent and stable definition of the types.

In addition to interfaces provided by the Øx.js library, interaction with the Exchange and Token contracts are abstracted away as well.

Server Side Web3

In order to utilize the Øx.js library on our backend, we wrote custom wrappers around the web3-provider-engine library. These libraries wrap the interactions with JSON-RPC and Web3 communication so we can communicate with the Ethereum blockchain similar to how users interact with the Ethereum network with browser Web3 providers.

Websockets

To stream data, the backend provides a websocket endpoint for clients to connect to, that streams changes to the peer-to-peer order book for the token pair that the client has selected. This ensures that clients receive new peer-to-peer orders as soon as they are submitted. This reduces the bandwidth requirements versus the client repeatedly polling an endpoint. We scan orders on the backend to check for order state changes and broadcast these changes to the client immediately to mitigate stale orders.

Frontend

As mentioned above, the frontend utilizes Typescript. In order to build a fast, lightweight, and efficient frontend, we implemented a custom Typescript based Vue.js framework. To deal with state management, we used Vuex, but created a custom wrapper around it in order to have strongly typed state.

Beta Technical Details and Bugs

ZRX Fees

There are three steps to calculating the fees, and for simplicities sake, we will only refer to the order position amount (maker fee). This process is the same for the seeking amount (taker fee). The rates are the average rate of an order within the most recent Ethereum block (that contains transactions for the pair).

1. We take the order position amount (amount you are selling) and multiply it by the current W-ETH rate to the selected token based on our order books. The result of this is the order position amount total represented in ETH.
2. We take the order position amount total represented in ETH and divide it by the current ZRX to ETH rate on our books. The result of this is the order position amount total represented in ZRX.
3. Lastly, we take the order position total represented in ZRX and multiply it by our maker fee (currently 0.0045 or 0.45%).

W-ETH Wrapping Bug

We disable most of the application if you are on the wrong network, however, we overlooked the fact that you can wrap ETH while on the main network. This caused approximately 6 individuals or 2.5 ETH to be locked in the main net W-ETH contract. The funds are fine, it’s just difficult to withdraw them because all of the interfaces that support W-ETH on main net are unavailable at the moment. This issue was resolved quickly.

Thanks to Brandon Curtis (a member of the Radar community), there is a guide (and a brief explanation of Radar) available to assist if you have deposited ETH into the main net W-ETH contract.

BigNumber.js

Because we pivoted to Kovan, we encountered an unexpected bug where we were accidentally passing undefined to BigNumber which threw an exception. This issue was resolved quickly.

Intermittent Outages of the RPC / Chain Watching Service

The most critical roadblock we encountered was our chain watching service. Like any typical software release, this process was working properly up until 24 hours before our launch. Our engineers battled the intermittent outages right up to our delay, and for the next 24 hours. The graphic below displays the event idle loop of our Node.js backend. We kept seeing these massive spikes which caused cascading issues related to our datastores and our connections to the Ethereum RPC.

After significant debugging we found a minor bug in our code and a misconfiguration of our Parity RPC nodes. After resolving the bugs and switching to specially configured Infura nodes we have been running stable.

Radar — Event Loop Idle

Community Input

The community input has been significant and we’re excited to be able to work through lean development together. We’ve been recording features, tracking bugs, and talking in depth with some of our more passionate users. To date, we’ve heard the following comments most often:

1. Give us night mode. We’re on it. Radar will be going nocturnal soon for all you night owls.
2. The order creation, rates, and order books are confusing. There are two things contributing to the confusion. First, the rates and charts are illogical and prices swing wildly because the Kovan orders use play money and are arbitrary. Second, we are still experimenting with order book structure and naming conventions, which means new vocabulary and user actions.
3. The chart needs more functionality. Agreed. We’ve collected some exciting UI suggestions and we’ll be working with a small group of users for testing.
4. Where is the API? Coming soon! We are working with professional traders to understand desired functionality. This is one of the projects our engineers are most excited about implementing.
5. UI / UX. Our designer is working through a few different mockups and ideas and we’ll be working with a small group of users for testing.

Conclusion

Thanks to our community we’ve been able to quickly compile a (long) list of feature suggestions. Now, the fun of lean development really begins! As the community is aware, Radar is attempting to accomplish something that has never been done before, building a relayer with NxN token pairs. Fortunately, the community-driven roadmap we have in front of us shows a clear path to success. Our job is to turn our beta into the fully functioning product that you’ve asked for!

Thank you for your support and feedback!

Visit our site at RadarRelay.com