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.

Rollover Service

ROLLOVER SCHEME

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.

Statistics Service

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.

FUND LEADERBOARD STATS

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.

Transfer Service

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.

Monitoring Service

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)

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!

Yours,

Covesting team