Vitaly Yakovlev & Tanisha Kohli
Vitaly Yakovlev & Tanisha Kohli
03 February 2023
4 min read

ZKX Architecture: A deep dive

ZKX Architecture

This blog deep dives into the ZKX Architecture. Our future blogs will cover technical papers on ZKX fundamentals such as ABR, High Tide, and specific components of the ZKX Trading platform closer to Testnet.

Introducing ZKX

We are building the first perpetual future exchange on Starknet with self-custody and true community governance. The exchange leverages account abstraction and low transaction costs to offer a new generation DEX that is as scalable as a CEX. The protocol also features improved token economics, with the staked native token receiving a share of revenue, and anyone in the community can participate in the growth of ZKX.


ZKX's architecture consists of two layers, each with its specific role.

  • The first layer is Ethereum smart contracts, using solidity, while the second layer is Starknet smart contracts, using Cairo.
  • The decentralized ZKX node network sits on top, consisting of data availability, network prediction, computation algorithms, and consensus within the network.

Decentralization and permissionless are the foundation of ZKX, ensuring that users have complete control over their investments and the protocol's functions. This is crucial in building a sustainable and trustworthy ecosystem for DeFi.

Why Starknet?

The choice to build on Starknet was made due to its environment that allows for things not possible in other web3 environments and its curated community of developers within StarkWare's ecosystem. StarkWare's credibility, consistent delivery, and great track record with StarkEx solutions make them the ideal partner for ZKX. The vision of creating tools for developers to expand the reach of web3 across the markets aligns with our goals.

Solving the Scalability and Decentralization Problem

The derivatives market in the crypto space is still evolving, and several models have been proposed. The three basic crypto derivatives models are virtual AMM, Synthetix Model, and Centralized Order Book.

  1. The virtual AMM model is similar to Uniswap, where there is a pool of two tokens, with one being the collateral (usually a stablecoin) and the other being the actual virtual asset. This model is efficient for smaller trades but not suitable for high-frequency trading as it becomes more expensive to trade on.

  2. The Synthetix Model, on the other hand, tracks synthetic positions on mutual assets through an Oracle price. The protocol has a pool of collateral that absorbs the losses or gains and provides liquidity. This model is efficient to a certain extent, but the losses are socialized towards the LPs.

  3. The Centralized Order Book model is implemented in platforms like dYdX and other exchanges. In this model, market makers provide liquidity and depth of the market for users to trade comfortably. However, this model is centralized and depends on a server running on AWS or Google Cloud, limiting its capacity to be decentralized or censorship-resistant. It also faces limitations in terms of scalability.

We have created our own node network for the ZKX exchange to address these limitations.

ZKX Node Network

The Node Network is a solution that combines the best features of virtual AMMs and CLOB without their weaknesses. It comprises a series of nodes that interact with each other using a consensus algorithm and can perform decentralized order matching.

ZKX Node Network

  • Every node is organized as an atomic node, architected as a set of super-isolated microservices with a Service Bus.
  • Every node is capable of running all possible operations in the Node network.
  • Every node is capable of being run as a
    • Compute Node (provides the storage, memory, and processing resources),
    • Signature Node (gathering consensus),
    • Dispatcher Node (connection gateway to the platform) at any given moment.


The Node Network has two fundamental parts:

  • Decentralized Limit Order Book (DLOB)
  • Data Provider Service (DPS)


The decentralized exchange (DEX) space is constantly evolving. It's time for DEX users to say goodbye to automated market makers (AMMs) and hello to an off-chain decentralized limit order book (DLOB). The ZKX Protocol offers a more efficient and user-friendly trading experience, similar to the execution mechanisms found in traditional finance, but with the added benefits of being fully decentralized and permissionless.

There are no middlemen, and there is a direct interaction between users, the ZKX node, and smart contracts. It provides a much-needed level of security and reliability that users have been craving. The ZKX Protocol is built natively on Ethereum and Starknet, making it a secure and reliable option for DEX users.

One of the most innovative features is its use of partial knowledge of state principles. This allows the ZKX Decentralized Node to host the DLOB, data provider services, price engine, and trade matching component, all while ensuring the security of the DLOB.

2. DPS

The Data Provider Service (DPS) is a gateway between the pricing engine and external data sources.

The DPS is designed to ensure data requests are processed efficiently and securely. As the single entry point for data requests, the DPS can access multiple data sources to get the information it needs. This allows for high flexibility and reliability, as the DPS can access multiple sources to ensure that data is up-to-date and accurate.

What's even more impressive is that the DPS doesn't need to get the data. Instead, it has its own Provider Library standard that connects to 3rd-party data providers. This means that the DPS can access a wide range of data sources, giving it the ability to provide accurate and up-to-date information to the ZKX Protocol. Data oracle is a layer between the ZKX system and a number of external Data Providers. In our case, it would be RedStone and other third-party providers.


Node Networking Consensus

A robust consensus algorithm is required to ensure reliable and efficient communication among ZKX nodes.

When a single node needs to communicate with other nodes (i.e. for the finding a non-native pair of an order/swap in a decentralized limit order book, finding external price, calculate ABR or High-Tide scores) it needs to decide how this information will be distributed and broadcasted in the network.

Enter Catamaran, a multi-faceted consensus algorithm that improves upon traditional algorithms like Paxos and Raft. With its enhanced leader voting algorithm and multi-group inclusion, Catamaran provides a higher level of fault-tolerance and tamper-resistance. This means that node elections are faster, more reliable, and more suitable for trustless decentralized setups.

Catamaran enhances reliability, separates the key elements of consensus, such as group’s root node voting, group replication, and safety, and it enforces a more substantial degree of coherency to reduce the number of states that must be calculated.

It builds upon the efficiency of Paxos but takes reliability to the next level. By separating the key elements of consensus and enforcing a higher degree of coherence, Catamaran reduces the number of states that need to be calculated and the transferred packet size, thus reducing the number of ways in which ZKX nodes can be inconsistent with each other.



Node Election: Randomized Timers for Reliable Leadership

One of the standout features of Catamaran is its node election process. Instead of relying on a single leader, Catamaran uses randomized timers to elect leaders, making the leadership state more robust and resolving election conflicts quickly and in parallel. This innovative approach adds a small addition to the heartbeats protocol, resulting in a more reliable and efficient system.

Group Root Node: Streamlining DLOB Order Flow

The Group Root nodes play a crucial role in managing the flow of DLOB orders, making the process easier and more linear. The DLOB orders flow only from the Group Root Node to other ZKX Nodes, done in iterations. This design feature enhances the system's overall reliability and simplifies DLOB management.

ZKX Node Groups: Double Consensus for Smooth Operations

Another impressive aspect of Catamaran is its mechanism for changing the set of ZKX nodes in the group. Using a double consensus approach during the transition of groups ensures that the group of ZKX nodes can continue operating normally, even during configuration changes. This dual consensus approach gives the algorithm its name - Catamaran.

Performance and Network size

In our pursuit to build a node network that can handle the computation of complex formulas such as ABR and High-Tide, we placed significant importance on scalability and performance. It was crucial that the network be able to grow and expand as needed while also maintaining high performance levels.

Our tests have shown that the network, in its current test form, is capable of over 9000 TPS, and the addition of new nodes leads to a linear increase in system throughput.

We have a Three-phase plan for expanding the node network:

Phase 1: The testnet launch will be powered by a small number of nodes (a few dozen) to handle the initial system load.
Phase 2: The mainnet launch will see an increase in the number of nodes to over a hundred.
Phase 3: Once demand in the network increases and we decentralize ZKX towards the DAO structure, we expect hundreds of additional nodes to come in, with the community being able to become node operators

The node network will be decentralized and open to all, with node operators able to receive a portion of the trading fees on the exchange and payments for services rendered to smart contracts. The decentralization plan will involve the token economics of ZKX, staking, and a permissionless node client. As trading volumes increase, incentives will be provided to incentivize node operators and drive revenue growth.

Smart Contracts Architecture on Cairo 0.1 version

Sharing an overview on the Smart Contract side -

Deposit and Withdraw


Users deposit funds to L1 and the corresponding amount will be updated in L2.


User withdraws funds from L2 and the corresponding amount will be transferred to L1.


Connection of L1 and L2 smart contracts

L1 - Ethereum smart contracts (Solidity):

  • Locking ZKX protocol
    • Deposit
    • Withdrawal

L2 - StarkNet smart contracts (Cairo):

  • ABR
  • Holding
  • Liquidity
  • Insurance
  • Admin Authentication
  • Registry central point
  • Markets
  • Assets
  • Account (User account)
  • Trading
  • Risk management
    • Liquidate
    • Deleverage
  • Trading fees
  • Fee balance

What’s Next?

We are thrilled to share with our community the long-awaited Testnet launch of the ZKX Exchange on StarkNet on March 14th!

The decision to open-source our smart contracts makes this even more exciting. This move demonstrates our commitment to the principles of decentralization and trust and invites the community to participate in the development and evolution of the protocol.

We would also like to highlight our first audit report, conducted by Nethermind, which can be found on our website at

Our initial Testnet audit comprised over 10,000 lines of code, and we are proud to have doubled that for our current launch. We have plans for future audits to ensure the highest level of security and reliability and ensure that any potential bugs are quickly identified and addressed.

About ZKX

ZKX is the first perpetual futures exchange on StarkNet with self custody and true community governance. The protocol is designed to provide further scalability with a decentralized node network, an elevated trading experience and offer perpetual swaps and derivatives to any user on Starknet and Ethereum. ZKX’s mission is to democratize access to global yields through its offerings to anyone, anywhere.

In July, ZKX raised $4.5m in seed funding from backers including StarkWare, Amber Group, Huobi, and others.

Twitter | Discord | Telegram | Website