Four months have passed since we first revealed the demo of the Covesting Module on our partner platform PrimeXBT, and it has only added to the feverish anticipation that traders and investors feel knowing that the technology is almost ready for launch.
As the year comes to a close, and the countdown to the final launch draws closer, we wanted to provide a full status update on the Covesting Module progress, including insight into all we’ve accomplished thus far, the many difficulties and challenges we faced and how we overcame them, and provide a breakdown of the many different services and microservices that come together to make the Covesting Module work so efficiently and effectively.
Details on COV token integration will be explained in a separate announcement due to the phase 1 release of the Covesting Module not including token utility. As mentioned prior, after the successful launch of phase 1, both teams on Covesting and PrimeXBT will proceed with the integration of the token, ensuring utility, efficiency, and value for token holders.
Let’s dig deeper into what we have accomplished this year, and what remains left in our development pipeline. We sincerely hope this detailed article with provide you with a solid understanding of the Covesting Module and allow you to take a sneak peek at what’s “under the hood.”
Rebuilding The Most Secure Fund Management Module From Scratch
While there are many investment services across the globe, few are as complex and intricate as the Covesting Module, nor are they as secure.
We’ve built the Covesting Module to offer several advantages over signal or copy-trading services. For example, from the moment a trade is entered by a fund manager, the Covesting Module makes a direct connection between the investor and fund manager’s positions, ensuring the trading strategy as well as performance matches, the correct amount of margin is allocated, thus guaranteeing that no investments are liquidated ahead of the fund manager’s position. In such environment such practice as “front running” is simply impossible.
Because each of these important aspects are so critical to providing a secure service, it requires additional technical solutions, posing additional challenges and difficulties for our development teams to overcome.
It’s important to call out the fact that the current Covesting Module infrastructure and backend will be far more advanced than was what initially conceptualised and planned. Due to the fact that the original module was designed for the trading of physical digital assets, the development team was required to work closely with the PrimeXBT team to make adjustments that adopt an infrastructure designed for margin trading.
Development had to be re-done from scratch to ensure the most secure and efficient possible peer-to-peer fund management service.
Covesting Module Services Explained
The Covesting Module is composed of many unique services and microservices, that come together to create a cutting-edge fintech solution for investors and traders of any experience level that allows them to build their capital and profit alongside one another.
These services include:
Fund Activation Service
Covesting Module consists of several services coming together, but even some individual services are further broken down into microservices in order to streamline the module operations and ensure the highest level of security. The fund activation service also includes three additional microservices, as follows:
Fund Creation Microservice
This vital micro service checks compliance with all requirements necessary to create a new fund. This consists of checking the fund’s name to prevent counterfeit accounts, checking to ensure the minimum funds are available, checking for any open positions or orders, and calculating the number of units a trader will receive for making an initial investment.
Units are each participant’s relative share of the total capital applied at the time of a rollover. When the fund is first created, the unit price is set to 1 BTC at current prices, however, as the manager makes additional trades, the price of the unit will change as a result.
Once the compliance check is completed, the trading account is placed under a temporary restriction from withdrawing any capital invested into the fund. In addition, the trading account then becomes a fund account, with all bonuses, promo codes, referrals and account statuses disabled. Because our various loyalty programs are designed personally for individual accounts, they cannot be applied to an account that manages the funds of multiple investors concurrently.
The last step in creating a fund is to create secure data backups of all related fund information, distributing it across several databases geographically to prevent any loss of data. Once the backups are distributed, the fund activation procedure will commence.
Investment and Withdrawal Scheduling Microservice
At the time of the fund creation and activation, an investment and withdrawal schedule is created by the scheduling microservice, consisting of two distinct parts: an open rollover, set by the fund manager manually, and the withdrawal threshold. During this period of one hour before the open rollover begins, pending requests for withdrawals can no longer be canceled, nor can new withdrawal requests be made for the coming rollover period.
Any withdrawal request made during the withdrawal threshold will be scheduled for the next consecutive open rollover period.
Offer Management Microservice
At this point, the offer management microservice will assign the fund a specific offer. At first, there will only be a single, default offer, but in the future, Covesting may enable additional offers for fund managers. This means that every individual fund manager will be able to customize and adjust conditions, the same way as hedge fund managers can adjust entry / exit conditions, as well as success fees in traditional finance.
Once the offer is assigned, the trading account is unlocked, and trading can begin!
Investment Creation and Close Service
Investments are made into funds, and therefore require a separate service to create and close investments, as well as check that all minimum requirements are met.
This service verifies that the minimum investment amount of 0.00000001 BTC has been met and that any invested amounts are put on reserve, resulting in a decrease in the investor’s wallet balance by the reserved amount until a withdrawal is made.
The investment will then enter an activation queue until rollover, then is applied to the fund. Information related to the investment is then displayed in the investor’s portfolio.
At close, the service will calculate the percentage of profit the investor will receive and award it to the investor’s account balance.
Each rollover phase includes a variety of complex calculations that occur behind the scenes. At each rollover, the unit price is recalculated and may change depending on the trades made by the fund manager.
This is also when any pending new investments awaiting in the queue are activated. This involves withdrawing the reserved funds from investor’s wallets, calculating these new investments while closing and distributing any investments requested to be withdrawn, and changing the balance of the account.
If the fund manager’s account is lacking the equity necessary to close out any investments requested for withdrawal, the service will begin closing out the fund manager’s trading positions based on the ascending order of open positions’ PnL.
Managers can use the threshold time for the position closures based on their trading strategies.
The investment profit distribution algorithm will review PnL, and if there is no ROI, all proceeds go to the investor, with the broker and fund manager receiving nothing. If the fund manager invested into their own fund, then the broker’s interest is removed from any profit, with the remaining profit going back to the investor.
One of the most compelling and exciting aspects of the Covesting Module is the global leaderboards, ranking each fund by PnL, age of the account, and various other factors.
The statistics service is necessary to build and populate a growing table, ranking each active fund for all investors to see. These rankings are based on total profitability, daily profitability, number of investors, along with the current fund account equity.
All rating information is made available to the public so investors can make informed decisions on which funds to invest in. In the beta version of the Covesting Module, the metrics themselves will be available, but star ratings won’t be applied until more information is aggregated over time.
As we mentioned, the transfer service was among the biggest challenges we faced. The transfer system ensures data consistency across each platform, as well as ensuring the guaranteed delivery of funds from one service to another without the risk or disruption, duplication, or loss of investor’s funds.
Fund Liquidation Service
The fund liquidation service ensures that there are enough available funds in a fund manager’s account to cover collateral on all positions. If the fund’s account equity falls below the margin requirements, the service will initiate the liquidation of open positions.
Liquidation of the fund will first close all open positions, reallocate any remaining funds, credit the wallets of investors with the remaining funds, and restore the fund account to a normal, trading account.
To ensure all the above services are running properly, are interconnected with one another, and that there is data consistent throughout, an intricate monitoring system has been put into place. The monitoring system is designed to not only prevent any issues from occurring, but also to generate a warning to our developers of any possible errors so that they can be dealt with promptly by our teams.
Technical Difficulties We Faced Throughout Development
The main developmental difficulty we faced arose in the process of successfully integrating the Covesting Module into PrimeXBT’s infrastructure, as both platforms are built upon a microservice architecture.
Because of this, we had to verify both transactionality and data consistency, in an effort to ensure the delivery of all funds from one service to another without the risk of them being duplicated or lost.
In order to provide these necessary safeguards, we integrated the system detailed below:
Providing Distributed Transactions in the Microservice Architecture
At their core, microservices are simply a set of distributed systems that work together to provide interoperability between multiple services and systems. When large applications lack interoperability or are difficult to modify or maintain, they can be broken down into smaller components that can be recomposed to work more cohesively with other systems.
Applications that are built upon microservice architecture are thus composed of multiple small parts that work together, whereas more traditional monolithic applications are simply developed as one singular fixed piece.
The microservice architecture provides numerous benefits to an application or platform, as the modular constituent components are easier to test, maintain, and upgrade. It also allows for greater scalability, as the small components can be scaled to fit the specific needs of the platform.
In these distributed systems, transactions span across multiple computers or physical systems within a network, with transactions moving sequentially through multiple services in order to fully complete transactions.
In monolithic systems, processes are guaranteed something called “ACID” (Atomicity, Consistency, Isolation, Durability), which helps ensure that all failed transactions can be rolled back.
Distributed microservice databases lack the ACID nature of monolithic systems, which poses multiple challenges for ensuring that transactions are atomic — meaning that either all the steps are successfully completed or none of them are — and that concurrent microservices requests can be successfully processed.
There are multiple ways we successfully confronted the issues seen while building and integrating microservices.
The first way is by integrating a two-phase commit system, where each transaction has a preparation phase and a commit phase. In this system, a transaction coordinator orchestrates every commit or rollback command. This ensures that transactions are atomic, and also ensures that changes on transacting objects are not implemented until the transaction coordinator confirms the changes.
The second way to confront the lack of ACID within distributed systems is to implement eventual consistency and compensation. In essence, each service in this system publishes a visible event whenever it uploads data. Subsequently, other services subscribe to these events, updating their data each time a new event is received.
This process creates an “event bus” where multiple microservices are able to communicate with one another via asynchronous local transactions that fulfill distributed transactions. All event-based communication is arranged by a separate system and takes place through the event bus.
Enterprise Service Bus
Implementing an enterprise service bus (ESB) was another way in which we solved the problems that were posed by implementing the Covesting Module into PrimeXBT’s infrastructure, as ESBs allow for cohesive communication between the two systems in a service-oriented architecture.
At their core, ESBs represent a distributed computing architecture that allows for flexibility and promptness in high-level protocol communications between separate applications within a distributed system.
Enterprise service busses allow for the separate services within the network to run independently within a distributed system and helps translate and direct client requests to the proper services.
The primary focus of ESBs is to act as a moderator for the routing of communications between multiple services, while also resolving disputes and contentions between any communicating components. Enterprise service busses can also monitor redundant services and process event handling, like data transformation, data mapping, event queuing, security, and more.
By employing enterprise service busses into our network, we ensure that the service network has proper communication, is decentralised, and is scalable.
Our focus on ensuring distributed transactions within our microservice architecture whilst confronting the lack of ACID, while also employing an ESB to ensure decentralized and efficient transactions between the service network, allowed us to successfully implement the Covesting Module into PrimeXBT’s infrastructure safely and efficiently.
Current Development Status
To summarize the full release notes and the current development programs, here are status updates on each key service.
Back End Development:
- Fund Activation Service (Complete)
Fund Creation Microservice (Complete)
Investment and Withdrawal Scheduling Microservice (Complete)
Offer Management Microservice (Complete)
- Investment Creation and Close Service (Complete)
- Rollover Service (Complete)
- Transfer Service (Complete)
- Fund Liquidation Service (Complete)
- Monitoring Service (In Progress, 70%)
- Statistics Service (Complete)
- Global Rankings System (Complete)
Front End Development:
- Rating Interface (In Progress, 70%)
- Create Fund Interface (In Progress, 90%)
- Manage Fund Interface (In Progress, 60%)
- Portfolio Interface (In Progress, 70%)
What To Look Forward To From Covesting in 2020
We are proud to reveal that despite the many challenges we have faced in developing a microservice architecture that serves all of the functionality the Covesting Module requires for security and fluidity, we are approaching the final stages of development, and will soon announce the official launch date of the Covesting Module Beta on PrimeXBT.
Meanwhile, PrimeXBT is rapidly growing its customer base each and every day. This is particularly exciting for Covesting, as the more active traders using the PrimeXBT platform, the more users will be able to access the Covesting Module Beta at launch.
Our goal is never to launch as fast as possible, but instead to release a product designed for the future of the new digital economy and serve as the benchmark and standard in peer-to-peer asset management moving forward. We are confident that working hard to ensure a successful launch of the Covesting Module in partnership with PrimeXBT will open up new B2B opportunities for us in the future with new partners to integrate Covesting white label solution.
Stay tuned for exact beta launch timing, and additional updates from the Covesting team. Have a happy and safe New Year!