Welcome to the newest issue of the monthly dev blog from the Biqutex team! We are performing some final tests before opening registration to the Early Birds program. Unfortunately, the launch had to be postponed from August to September. We promise to take a more responsible approach to scheduling in the future. As a reward for your patience, a $25 welcome bonus will be waiting for you after you sign up. To receive the bonus, you just need to answer a few questions and subscribe to our Twitter and Telegram channels.
About the Early Birds Program
In this issue, we will continue exploring the Early Birds Program. It consists of several updates that will be released in stages:
Stage 1. Community voting. At launch, we will open access for users to participate in voting and surveys immediately after registration opens.
Stage 2. Mystery boxes and coupons. To allow our users to reach higher tiers in the program, we will be giving them access to mystery boxes, in which they will be able to find many valuable gifts – courtesy of the Biqutex team. The gifts include coupons for free withdrawals, first deposit bonuses, trading volume bonuses, commission discounts for friends, and maybe even NFTs!
Stage 3. Prediction battles. Imagine that you have accumulated a certain number of coupons and bonuses during your participation in the Program. And, of course, you will want to use and spend them somehow. You can wait for the launch of the main exchange to use them to cover fees and as a margin. But for the most impatient, we have come up with a mini-game for predicting exchange rates as part of the Early Bird Program. The balance of the bonuses can be used for placing bets. Regular tournaments with a prize fund will be held among participants.
Stage 4. Referral program. In the final update, we will introduce a full-fledged referral program. Users will be able to invite their friends to register using your referral link and receive bonuses for their actions. There will be a separate referral program for influencers, with an income assigned from each transaction of the invited user as a percentage commission. We are also planning to launch an achievements system at this stage. By reaching new achievements, users will be able to earn additional XP.
In addition, we would like to share with our users the idea of a program ambassador, codenamed "Mega Birds" :) We will choose the best of the best Early Birds who have showcased their skills and knowledge in trading, derivatives, and risk analysis during the course of participation in the program. We will also consider those who express their sincerest desire to participate in the development of the exchange and the Biqutex community. We will invite such users to become Biqutex Ambassadors and work hand in hand with our team on a paid basis. Mega Birds will be divided into groups depending on their vector of activities:
- Researching and listing proposals for new and innovative instruments;
- Writing training materials, tutorials, documentation;
- Attracting new enterprise partners;
- Risk management;
- Community management, SMM;
- And more.
Hello, everyone, this is Alex again, and we are continuing our work on refining the internal structure of the crypto exchange. Today, let us talk about some things that matter most, namely – the architecture of trading. There are very few publications on this topic. Though seldom, it still happens, that the details of the backstage are released to the public. Among the last of such reveals on my memory is the representation of the architecture of the LMAX Disruptor in 2012.
There is far less information available about the internal workings of crypto exchanges. Therefore, if we cannot study in detail how others work, we will create a system that will be able to suit our capabilities and whims.
They say that the main things on the exchange are the speed of operation and its reliability. For a simple person, namely – a trader, this is certainly true. On the technical side, such a primitive assessment spills out into dozens and hundreds of internal parameters that need to be monitored and minimized (or vice versa, we could strive to squeeze the most out of them). But everyone agrees on one thing – the fast operation of trading, or the engine, as it may be called sometimes, is vital.
However, for the end user, and even for some of the employees of an exchange, the trading engine is a kind of black box that data flies into and transactions come out. Architecturally, this is almost true. My colleagues on a previous project even wrote an interesting mathematical paper on modeling the exchange engine as a deterministic state machine.
We are adherents of a similar approach. And so, the engine or trading engine, is a group of micro-services launched on a dedicated server that cater to all trading activity for one instrument. These instances are what matters to us, since the engine is not a monolith, it is not a single string of code that does everything at once, albeit faster. Instead, it is divided into several co-dependent services, each doing its job. We called such a dedicated super-server – the TradingBox.
Think inside the box
Inside the TradingBox, all modules work through a central broker that stores data and forwards messages. Each message is a string of information exchange between the modules. Our central part is a specialized in-memory Redis database. Allow me to confess outright – yes – this is a slightly atypical use of Redis, as we are juxtaposing it both as a data exchange bus and as a lightweight data storage unit. Few have deliberately refrained from the use of highly specialized messaging systems like ZeroMQ/Nanomessage, so as not to overcomplicate our work.
The tradingGateway module is the main link between the engine and the outside world. It is connected to both the internal message bus and the external cluster at the same time, and the exchange interacts with the trading module through this single data channel, which receives the message flow, or the orderFlow.
Strictly speaking, the orderFlow is not a pure flow of orders, since there are different classes of messages. But the point is that by accepting each message, the trading system changes its internal state. In our case of operating a derivatives exchange, the main messages are not even orders, but index change events, or markPrice, and messages about order cancellations.
All seems rather clear regarding the index, as all internal calculations are tethered to it, and each of its “ticks”, or changes, means not only a change in virtual profits and losses, called Unrealized PnL, but also constant reassessments of liquidation levels. The cancellation of orders is also connected to the mark price. Futures trading directly depends on the index, which sets the price corridor, and thus the trader is forced to adjust to it. When the price fluctuates, the robots of algorithmic traders immediately jump into action, depending on the capabilities of the exchange. They either correct previously placed orders or remove and replace new orders at new prices.
The orderBook module just stores the order book that traders see in the terminal. For ease of operation of all other exchange systems, the orderBook service periodically creates a “snapshot” once per second or faster, and re-codes it so that it is comprehensible enough to be displayed.
The Matcher, or a mechanism for matching trade orders, is an algorithm that determines which order will be matched with which, and the final price for buying or selling. The real mechanism behind it is not as simple as it might seem. In simplified form, the workflow loos so – if the buyer’s price is equal to or higher than the price requested by the seller, the Matcher combines such orders and says – Deal done!
The positionManager is a special service that manages open contracts. The position of each individual trader is simply a value – the number of contracts and their price. But the exchange engine cannot work like that, since it keeps a complete and accurate record of each position. Even in the case of laid-backtrading with several hundred orders, there can be thousands of positions open at any given time.
The Liquidator is a nightmare and the main enemy of every derivatives trader. In fact, this is the most unlucky algorithmic trader in the world! It takes over and manages all positions that have exhausted the margin limit and that need to be sold or closed.
The executionEngine is a rugged hard worker. It checks the possibility of concluding an order, generates notifications to the trading account service, and calculates the parameters of a new position. It basicallyhas a nine-to-five office job.
The fundingManager is responsible for calculating payments at the funding rate. This is the interest rate that the parties to the contract pay to each other, depending on whether it is more than 0 or less. The rate is intended to balance positions in the perpetual futures market and, in fact, acts as an additional incentive for traders to hold positions against the market trend. On our exchange, we plan to take into account the funding rate every minute, which means we need to quickly calculate exactly how much money needs to be transferred from / to the balance for each individual position.
And to make sure life does not seem too rosy, there are correctness and security checks set in place. For example, the amount of all funding payments of one party must match the payment of the other party precisely, and as a result, each settlement period must be reduced to 0. The number of all short positions must identically coincide with long positions both in the number of contracts and in the volume of the positions, as well as the amount of locked margin. Unrealized PnL as well must strictly equal 0 in total at every second. So yes, perpetual futures trading is always a zero-sum game!
That’s it for now, thank you for your attention.
And following the tradition started in the previous issue, some complicated (!) but interesting materials that we read this week.
- Vaultification of Everything by STFX - Single Trade Funds Exchange (https://medium.com/coinmonks/vaultification-of-everything-fb0aef48763 )
- The Complete Guide to Rollups - https://members.delphidigital.io/reports/the-complete-guide-to-rollups
- Evolution of Financial Exchange Architectures is not an article, but a YouTube video recording of a speech at a conference. https://www.youtube.com/watch?v=qDhTjE0XmkE
Some Design Facts
A hearty greeting from the design department. At the moment, the design team is working on the interface of the exchange and I could walk you through the process, but I think that would be incredibly dull. You want a user-friendly interface, it is best if it pleases the eye, but you seldom care how it comes into being. So here are some statistics that might surprise you:
- There are only 90 rendered elements in the girl on the main page of the site. In the future, there will be more than 2,000 in the interface after the registration stage. However, despite this relatively small number, only 17 colors are backing it, most of which are different hues of black, gray, and white.
- On average, one PC screen in a layout is 1680x1128 pixels, and the design system, which includes all the repeating elements of the design, today covers an area of 10,000x12,610 pixels and there is not much empty space in this tile. And yes, it is quite a large area.
- We monitor the quality of each screen, state and interaction, so the main page of the exchange was redrawn 4 times after the registration stage.
- When you see the functionality of the first stage of the exchange, note that we have already finalized the design for the release slated for March of 2023.
If you find it difficult to navigate our interface and you have any ideas on how to improve it, you can always write up your suggestions to us on Twitter or in the Telegram chat. I would also like to remind you that members of the Early Birds program will be able to participate in closed voting on the design of the exchange. If we consider that your feedback is valuable, you will receive a reply letter from me and a small gift :)
Have a convenient user experience and do not forget to write to us!