At Bitior, we took the top down approach to building the next-generation cryptocurrency hub. The question we asked ourselves was what would the next generation cryptocurrency exchange be like, if it had all the features we could possibly need. And, of course, we had to also make a priority building a very high performance and resilient system.
Given our objectives, we first had to decide on the technology stack for our system. From the beginning, we chose not to use the standard webserver architecture such as LAMP or MEAN stack. The problem with webservers and websites that run on them is that they are better suited to displaying static content. Whereas, an exchange or a wallet application needs to constantly update information on the screen without any page reloads. Sure, some websites use webservers and socket technology together for real time updates in the app. But then, these apps become cumbersome to develop and maintain.
Another downside of using a webserver is the potential security vulnerabilities. A webserver is designed to perform a large variety of different tasks, including running scripts. As it is a complex piece of software developed by a third party, we can never be certain that it is 100% secure.
So, we decided not to use a standard webserver at all. Instead we developed our own server, which only responds to requests initiated by our app.
As a result, our client application is not a website. It is a web app. What this means is when a new page or a screen is requested in the app by a user, the app does not load it from the server. The entire app is loaded in memory. When a new page is requested by a user, it appears instantly on the screen. Compared to regular websites, Bitior page changes are lightning fast.
We also added plenty of animated transitions to make our app look even cooler. For example, if a user clicks on the account in the Accounts screen, the new account screen kind of slides from the right, similar to an iPhone animated screen transition.
Because we built our system from the ground up without a webserver and without a lot of third-party components, the result was an extremely fast system, which is also very efficient on resources.
While we do use a conventional database for persistent data storage, most of trade-related data is kept in memory for very fast access. For example, if you use Bitior API and request the order book for let us say ETH-BTC pair, the server response is near instant. That is because the order book is immediately fetched form memory, there is no database query or disk access of any kind involved.
Likewise, the trades are matched at near instant speed. Bitior order matching engine is divided into two stages: order matching and settlement. The order matching happens extremely fast, based on the data loaded in memory. The settlement stage is slightly slower (but still very fast). It transfers assets between accounts and commits data to persistent storage. The architecture of the matching engine allows for a very high order throughput even on modest hardware architectures.
Because of the unique proprietary architecture Bitior is also very secure. Our server does not respond to any requests, except the ones initiated by our app, and we have full control of each end point one can use to access our system from the outside.
Unlike some other software developers, we did not develop our product first and then added an API as an afterthought. Instead, we developed the API first, and then developed an app using that API. Our Bitior application connects to the Bitior server via this API. It is not a separate product. It is an integral part of our system.
If you are a developer, or an operator of another exchange, you can easily access all of Bitior's features by using our API.
The Bitior server supports two APIs: REST and sockets. The REST API is used to get snapshots of data, such as the order book at any given time. The socket API is used to receive real time updates such as order book changes or user transactions.
We are proud to say that Bitior offers a variety of useful features not found at any of the competitors. When we designed our system, if there was ever a compromise of shortening the development time or making the system more flexible for the future, we opted for the latter.
Case in point, in our ideal cryptocurrency wallet, we envisioned that users would be able to create multiple accounts per asset on the fly. For example, a user could have two bitcoin accounts. One for personal and one for business use. None of the existing exchanges that we know of had that feature. Neither, although useful, it appeared to be immediately monetizable. In addition, the feature was not trivial to implement, as it would require changes to the database schema, such as adding an extra database table and adjusting all database queries accordingly.
This posed a dilemma. On one hand, it was important to launch the minimum viable product as soon as possible. On the other, if we opted for no multiple accounts per asset at launch, it would be very difficult to add this feature later, as it would require a significant change to the database schema and all account-related queries.
So, the decision was made to build the system from the beginning with multiple account per asset support. This is just one example of compromises that were made to make Bitior as feature-rich and as flexible as possible.
Not using standard components, such as a webserver, also had an impact on the final product. For example, we found that the standard Google reCAPTCHA that many websites use, would not work for our chosen architecture. At Bitior, even the captcha feature is custom built. It does not rely on off-the-shelf components.
We also questioned a lot of other standard features that most of websites, including other exchanges, use. For example, most internet services use email for signup and for password reset and recovery. We found that email was a very unsecure method to use for managing cryptocurrency wallet credentials.
And, so was a phone. For example, a few customers of xCoins.io had reported that they received phone calls from people posing as xCoins' customer support representatives. The imposters sounded authentic, they even had a call center sounding background noise. Note, by the way, xCoins does not have a call center and never calls customers. The fake representatives asked customers to tell them the SMS code they had just received from xCoins for two factor verification.
So, the decision was made not to use email or phone verification for any type of account credentials management. Instead, Bitior uses a mnemonics recovery seed, similar to a bitcoin or Ethereum wallet.
To perform two factor verification, Bitior uses time-based one-time password generators such as Google Authenticator or Authy. Unlike some of other websites, Bitior supports all OTP generators, not just one specific generator.