Inspiration / What it does

There are two main issues within the cryptocurrency space in regard to token exchanges:

1) Centralized exchanges have significant counterparty risk (hacks, security issues, etc.)

2) Decentralized exchanges are seldom used because they lack liquidity due to lack of volume

Sonar attempts to fix both of these issues by creating a platform for decentralized N to N trades with built-in liquidity. Unlike Radar, we act both as an exchange and as a market maker, and do so because under a mechanism design perspective,

A) Users do not use a platform if there is no liquidity

B) Liquidity can be created/increased (e.g. we act as market maker) with higher spread

C) Users who want N to N token trading are willing to take on a higher spread if they convert for convenience as opposed to best profit (e.g. Shapeshift users)

Our platform is therefore a decentralized Shapeshift where, as an exchange, the user can provably trade any ERC20 token to any other ERC20 token through the 0x protocol. As a market maker, we offer a full order book (like Shapeshift) and thus make money by taking on a small spread on the user's trades (i.e. we simultaneously take an opposite position on centralized exchanges and thus arbitrage the spread).

This results in a win-win because the user has a convenient and provably secure way to convert any token without KYC, while we make money by shifting the counterparty risk on our end.

How we built it

Backend in Python and Django. Data from 3+ centralized exchanges is fed through a price handler, which builds a composite order book logged in Sqlite while taking into account arbitrage fees, exchange volume, etc.

That order book is then fetched both to the 0x contract and to the frontend (Dash/HTML/CSS). That's the way for the user to be up to date with open orders offered by Sonar on 0x.

The next step would be to connect order filling with the front end such that orders can be filled against our order book with a single click (+ Metamask).

Challenges we ran into

We've run into issues trying to set up the 0x infrastructure. In particular, it didn't work in the usual setup on test rpc and we were forced to implement it from scratch on a private network.

Accomplishments that we're proud of

We have managed to achieve basic 0x functionality on a private network. It was very challenging because changes needed to be made to low-level parts of 0x codebase (more details in the readme.txt in the 0xJS directory). It was particularly tricky because the private network setup wasn't accounted for in the mechanism for signing transactions which had to be identified and changed accordingly.

What we learned

Setting up the 0x infrastructure from scratch was an interesting experience giving a lot of insights into low-level details of the protocol and codebase. It allowed us to gain practice in debugging promise-based JavaScript code communicating with smart contracts deployed from scratch.

What's next for Sonar

The most important part that's missing is to actually put wire all elements together. In particular, JavaScript methods interacting with the 0x protocol could easily be invokable from the front-end using MetaMask.

The next step would be to implement more sophisticated pricing models leveraging data mined from several exchanges, and implement a machine learning model for risk management, for instance block all trades when volatility rises too quickly.

Share this project: