Accelerating the build of a matching engine

In order to attract institutional investors, ErisX planned to use traditional matching and clearing models. Chippas, CEO of ErisX explained, “This reflects the structure that institutional investors expect from other asset classes and will help drive the crypto markets toward greater relevance and accessibility.”

ErisX intended to offer spot trading, crypto futures, and clearing services for fully collateralized virtual currency futures with physical delivery.

They knew that their institutional clients would need to integrate diverse financial modelling, account structures and settlement systems. While the ErisX team planned to build the clearinghouse functionality internally, they also needed an enterprise grade matching engine that met all their requirements, and was up and running by their year end goal. With the Exchange’s internal resources stretched, ErisX evaluated third party assistance.

To build or to buy

Initially, ErisX planned to buy an existing matching engine. The internal development team had a precise understanding of their requirements and issued an RFI. They looked at more than a dozen systems, including all of the prominent exchange platforms and several crypto-specific products. But their requirements made buying an existing platform tricky. Not only did it need to support crypto spot and futures in the same system, but it also had to accommodate a constantly evolving crypto market.

During their evaluation process, the team ran into multiple hurdles. None of the vendors ErisX assessed were able to implement the combined fully collateralized futures and spot risk model that the Exchange required while meeting their aggressive performance needs.

Trudeau said, “The choice to build was not a trivial decision. But we had unique requirements that the existing platforms either didn’t support out of the box or couldn’t support architecturally.”

Once the ErisX team realized that building the matching engine inhouse was their best option, they understood that they would need additional people with a high level of expertise. But hiring a team would take time and resources that were already under constraint.

Chippas, ErisX CEO explained, “As a startup, we needed to be prudent about how we staff the company. We needed to build a platform that met our tight timeframe, but also ensure that it was robust and extensible.”

In the traditional outsourced development model, ErisX would pick a vendor, prepare detailed specifications, the vendor would go away to develop, and ErisX would test what they delivered a few months later. This classical dataprocessing era style of working was not logical for ErisX. The ErisX team was looking for a collaborative environment and partnership to enable development of key features and requirements as the cryptocurrency space kept evolving.

One of the reasons ErisX selected Adaptive was in fact the flexible approach they took to the project. Acuña-Rohter said, “the mutual tight feedback loop between ErisX and Adaptive was a huge selling point.”

Trudeau said, “Another factor we appreciated about Adaptive during the selection process was that we were able to work directly with Olivier Deheurles (Adaptive cofounder and CTO) and Harsha Sri-Narayana (Adaptive’s technical lead). They understood our unique needs and had a very organized, efficient approach.”

From the very beginning, the Adaptive and ErisX teams were tightly integrated. Trudeau said, “We were very fortunate to find Adaptive, because they have the subject matter expertise, the ability to bootstrap the project and bring in accelerators like Hydra and work closely with our team.”

Building with Adaptive also meant that ErisX stayed in control of their matching engine platform. Acuña-Rohter said, “Taking this route meant we could walk away with the code and decide on a case-by-case basis whether we wanted to extend it ourselves or continue working with Adaptive.”

ErisX had a very precise concept of the requirements for the matching engine with Acuña-Rohter leading the combined teams. He was able to provide instruction and oversight while Adaptive’s knowledge and skill set made their iterative approach to the project a success. One of the advantages of working with Adaptive is that they had the technical expertise to quickly grasp what ErisX wanted. Acuña Rohter would walk the team through a few bullets explaining the “what” and “why,” knowing Adaptive’s team would figure out the “how.” The joint team of Adaptive and ErisX developers would debate approaches and then work on iterations. The combined teams met every 3 to 4 days to review code, talk about direction and course correct when needed. Acuña-Rohter said, “This allowed us to see exactly the system being built and make sure that we received what we wanted.”

One example of this was how ErisX wanted to design the market data system. They wanted to provide nanosecondprecision timestamps to all messages published from the matching engine. This would allow customers to precisely correlate messages across drop copy, order entry and market data feeds. Ralph Swann, Adaptive’s delivery lead said, “They had a very specific implementation in mind. After discussing it, we understood what they wanted and got to work.”

“The team’s depth of expertise really sped up this project,” Deheurles said, “Also, Acuña-Rohter was able to clearly articulate the outcome ErisX wanted. He trusted us to work out the solution. Then he checked the solution functionally and technically to verify that it was in line with what they wanted, and they could course-correct immediately.” Swann agreed, “There are countless times when this saved us weeks of work.”

Adaptive’s Deheurles said, “The ErisX team’s degree of sophistication is very unusual. Most of our clients don’t have that level of expertise in house, so we provide both product management and engineering skills.”

Most established exchanges use a traditional exchange model design originally developed in the 2000’s. They restart the matching engine and re-load reference data at the beginning of each trading day.

Messages are sequenced as they come in. If the system fails, it recovers by restarting and replaying all the messages since the beginning of the day. But the crypto market trades 24 hours a day. That means the support team doesn’t have a daily market close period when they can load new products or make system updates. If you restart a crypto exchange, you might have to replay a week’s worth of activity or worse, restart from the last snapshot of activity.

On Deheurles’ recommendation, ErisX decided to deploy Adaptive’s Hydra Technology. Hydra is essentially a set of infrastructure accelerators specifically designed for deploying a high speed, highly reliable exchange platform. It is purpose built to enable 24×7 operations.

Hydra has a feature called “Snapshotting.” A snapshot is an image of the full state of the system. If the exchange needs to be restarted during the day, the platform automatically takes a snapshot. Then when it restarts, Hydra automatically reloads the snapshot to restart trading exactly where it left off. Hydra can be configured to automatically take snapshots at a predetermined frequency throughout the day. This enables a 24/7 operation: there is no longer the need to restart the system each day as with the traditional exchange model. If the system shuts down unexpectedly, support engineers can reload the snapshot when restarting, and then just replay the messages that occurred between the snapshot and reboot rather than having to reply multiple days worth of messages.

When a system update is performed, the snapshot is automatically migrated to the new version. This enables ErisX to evolve the technology and upgrade the platform as needed. In addition to supporting 24×7 operations, Acuña-Rohter said, “The snapshotting mechanism is also extremely helpful for reproducing state when needed. It’s like a VHS tape. You can replay to any frame to see the actions of a customer. So it’s helpful for troubleshooting and finding bugs.”

While the ErisX and Adaptive teams worked well together, the project was not without its challenges.

As they reached the third milestone of the project, they realized that they would not be able to complete some of the final elements in the functional backlog by the year-end deadline. This is a common challenge with any development project. Deheurles said, “Many customers want to push the vendor at this point to squeeze everything out before the deadline. But that creates more risk, because not enough testing occurs. ErisX’s team understood this. We had to hit the deadline, and we had to get regulatory approval and had our hands full delivering essential functional requirements, non functional requirements, an infrastructure build, and a disaster recovery strategy. So we modified scope to ensure we met that goal.”

During the last three months, the team reviewed the remaining backlog items to re-prioritize and de-scope requirements that would not present a risk to launching. “We had to launch a system that met our migration requirements, it had to replace an existing spot exchange production system and we had to move all those clients to the new exchange, and switch on futures trading functionality for the first time,” Acuña-Rohter said. So that’s what the team prioritized.