Our source code is structured into five different modules: cxClient, cxServer, cxWallet, cxEngine and cxAdmin. Each module operates on its own, but all modules interact with each other.
The five modules are distributed across three servers:
Server 1: cxClient + cxServer: Responsible for everything on the enduser (trader) side.
Server 2: cxWallet: Responsible for storing all cryptocurrency funds.
Server 3: cxEngine + cxAdmin: Responsible for matching trades and administrative functions.
Except for the cxClient, all modules save their data on a decentralized database cluster. The database cluster is spread across all three servers. If one or two servers go down, the complete database can always be recovered as long as one server remains live. In other words, all three servers share the same database information. However, depending on the module, each server possesses different write permissions.
The cxEngine module matches trades on the exchange.
The cxServer processes everything that comes from the cxClient side
The cxWallet is the multicurrency wallet module which stores all funds.
The cxClient is the frontend user interface of our exchange software
The cxAdmin module provides the administrative interface for the operator.
skalex Software provides the option of adding a wide range of extra features
The source code in our software modules is modified appropriately to either work in an exchange or ICO/STO environment. To better understand how the modules interact with each other in our exchange software, let’s explore three exchange-specific use cases
Essentially, an ICO/STO is not that different from an exchange. For instance, if an investor buys tokens, an exchange takes place. The investor (usually) exchanges bitcoin or ethereum for ICO/STO tokens. Hence the fundamental source code in an exchange software and ICO/STO platform is quite similar. We will explore 3 ICO/STO use cases and how our software modules handle them: