Radar Relay Technical Overview
Insight into features and community feedback
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:
- 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.
- 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.
- 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!
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.
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!
Typescript + Øx.js
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.
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.
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
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).
- 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.
- 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.
- 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.
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.
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:
- Give us night mode. We’re on it. Radar will be going nocturnal soon for all you night owls.
- 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.
- 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.
- 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.
- 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.
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!
Join us on Slack.
We have a Slack channel called “beta” where we will be collecting feedback, bug reports, answering questions, and announcing changes and updates. If you are helping with our beta please join that channel.
Visit our site at RadarRelay.com