• Speed: The performance and speed limitations of DEXs make them unsuitable for Scalping or Day trading. Scalping trades happen in a second or less, but, a transaction confirmation for finalising a trade might take several seconds if not minutes, by the end of which there might be price changes.

• Scalability: Whereas prominent centralised exchanges process hundreds of thousands of orders per second, blockchains, where decentralised exchanges are deployed, can only manage hundreds of orders each second. As a result, the number of users who could use a decentralised exchange is way smaller and more limited compared to that of centralised exchanges.

• Cross-Chain Trading: Decentralised exchanges are limited to the liquidity volumes available on their chosen blockchain which is relatively small due to liquidity fragmentation as a result of ever growing number of blockchains. Centralised exchanges, on the other hand, pool all the liquidity available on all chains together which enables cross-chain trading and makes them much more capital-efficient in comparison.

• Capital Efficiency: Decentralised exchanges commonly use automated market makers (AMMs) for trading, but this method is not capital efficient. AMMs require large liquidity pools that often lock up significant capital, particularly in low-volume pairs where returns may not justify the investment. In contrast, centralised exchanges match buyers and sellers through order books, optimizing capital use and providing more flexible liquidity.

Features

Zelullar Exchange is capable of providing the following distinctive features:

By enabling the features above, Zellular Exchange aims to capture a significant share of the market currently dominated - by over 90% - by centralised exchanges.

Bridging the Gap Between DEXs and CEXs

As previously discussed, Zellular Exchange (Zex) is designed to bridge the gap between decentralized exchanges (DEXs) and centralized exchanges (CEXs). More specifically, Zex is a decentralized exchange that offers the security and transparency of a DEX while providing the user interface and trading experience of a CEX.

Traditionally, users interacting with centralized exchanges must transfer their funds to wallets, multisigs, or smart contracts controlled by the exchange. The exchange then updates their balance on its internal ledger, allowing them to trade across various markets. However, in this model, the centralized exchange has complete control over users' funds and balances, exposing them to custodial risks.

Zex takes a fundamentally different approach by prioritizing decentralization and user security. Instead of requiring users to entrust their assets to a centralized entity, Zex ensures that users retain full custody of their funds while benefiting from an efficient and high-performance trading environment.

Exploring Zex Architecture

DEX Architecture: Smart Contracts, Blockchain, and Consensus

Decentralized exchanges (DEXs) rely on blockchain technology and smart contracts to enable trustless, peer-to-peer trading. Unlike centralized exchanges, where an intermediary processes transactions, DEXs execute trades programmatically through smart contracts that run on a distributed network of blockchain nodes.

Core Components of a DEX

1. Blockchain as the Settlement and Execution Layer The blockchain serves as the foundational layer for a DEX, recording all transactions, executing smart contract logic, and ensuring immutability. The blockchain operates as a distributed ledger maintained by multiple nodes, preventing centralized control or tampering.

2. Smart Contracts as the Automated Execution Layer Smart contracts are self-executing code deployed on the blockchain. Once deployed, these contracts become immutable and autonomously execute based on predefined rules. They handle trade execution, liquidity management, and other key DEX functions.

   • How Smart Contracts Are Executed

     • When a user initiates a transaction (e.g., placing an order on a DEX), they submit it to the blockchain network, where it is picked up by blockchain nodes.

     • The smart contract code is executed within a virtual machine (e.g., Ethereum Virtual Machine - EVM). The EVM ensures that all nodes execute the contract code in a deterministic manner, meaning the same input always produces the same output.

     • Nodes validate the transaction, compute the required state changes, and prepare it for inclusion in a block.

Transaction Sequencing and Consensus

For a DEX to function securely and efficiently, transactions must be ordered correctly and agreed upon by the network. This process involves sequencing and consensus mechanisms.

1. Transaction Propagation and Sequencing

   • When a user submits a transaction to the blockchain, it enters the mempool, a waiting area where pending transactions are stored before being confirmed.

   • Miners or validators select transactions from the mempool, prioritize them based on gas fees

2. Consensus Mechanism: Ensuring Network Agreement Since blockchains operate as decentralized networks, a consensus protocol is required to ensure all nodes agree on the transaction order and validity.

3. Finalizing Transactions and State Updates

   • Once a block is confirmed through consensus, the transactions within it are permanently recorded on the blockchain.

   • The smart contract state updates accordingly (e.g., user balances are adjusted, liquidity pools are updated).

   • The transaction is now irreversible and trustlessly settled.

User Interaction with Smart Contracts on a DEX

From a user’s perspective, interacting with a DEX follows these steps:

1. Connecting a Wallet

   • Users connect their Web3 wallet (e.g., MetaMask, WalletConnect, RabbyWallet) to the DEX interface.

   • The wallet does not store funds but manages private keys and signs transactions.

2. Approving Smart Contracts

   • Users must approve smart contracts to access their tokens. This ensures that the contract can execute swaps or liquidity transactions on their behalf.

3. Submitting Transactions

   • When a trade is placed, the transaction is sent to the blockchain network, where nodes validate and execute the corresponding smart contract logic.

4. Transaction Confirmation and Settlement

   • After passing through the consensus process, the trade is recorded on the blockchain, and the user’s balance is updated.

   • The transaction is final and cannot be reversed, ensuring security and transparency.

Challenges of Traditional DEX Architecture

While DEXs offer self-custody and decentralization, they face limitations:

• Scalability & Latency – Since transactions require blockchain validation, network congestion can cause delays and increased gas fees.

• Liquidity Fragmentation – Assets are often confined to specific blockchains, making cross-chain trading inefficient.

• MEV and Front-Running – Malicious actors can manipulate transaction sequencing for profit.

By understanding these architectural components, it becomes clear why traditional DEXs, while innovative, have struggled to compete with centralized exchanges in terms of efficiency and usability. In the next section, we will explore how Zex redefines this architecture to offer a decentralized exchange that overcomes these limitations while maintaining the benefits of self-custody and transparency.

Verification in Zex AVS

When we speak of verification, we may refer to:

1. Verifying sequenced transactions received from the Master Sequencer to ensure proper ordering.

2. Verifying transactions received from users (e.g., open orders) before execution in Zex AVS.

Zellular Clients: Verification of Sequenced Transactions

Zex AVS: Verification of User Transactions

In addition to sequence verification, we need a mechanism to verify and validate transactions to ensure they originate from legitimate sources. This verification process occurs within Zex AVS before execution.

To fully understand this verification flow, we must first elaborate on the internal structure of Zex AVS. In the following pages, we will:

1. Explain how a Centralized Exchange (CEX) operates, focusing on its order book, matching engine, and custodial control over user funds.

2. Illustrate how Zex enhances and improves the conventional CEX architecture, integrating decentralization while maintaining efficiency and high performance.

CEX Architecture: Order Books, Matching Engines, and Custodial Control

Centralized exchanges (CEXs) are the dominant trading platforms in the cryptocurrency market, offering high-speed trade execution, deep liquidity, and a user-friendly experience. Unlike decentralized exchanges (DEXs), CEXs maintain full control over user funds by managing balances through internal ledgers and executing trades via a centralized matching engine and order book.

Core Components of a Centralized Exchange

1. Order Book: The Heart of Market Liquidity

   • An order book is a real-time record of buy and sell orders submitted by traders.

   • Orders are categorized into:

     • Limit Orders: Users specify a price at which they want to buy or sell an asset.

     • Market Orders: Users execute a trade immediately at the best available price.

     • Stop Orders: Orders that trigger once the asset reaches a predefined price.

   • The order book ensures price discovery and allows traders to see market depth and liquidity.

2. Matching Engine: Executing Trades Efficiently

   • The matching engine is a high-performance system responsible for executing trades by pairing buy and sell orders.

   • It uses algorithms to:

     • Match market orders with the best available limit orders.

     • Maintain the order book by prioritizing orders based on price-time priority (earlier orders at the same price execute first).

     • Prevent anomalies such as self-trading or invalid transactions.

   • The matching engine ensures low-latency execution, processing millions of orders per second on high-frequency exchanges.

How CEXs Maintain User Balances

Unlike DEXs, where funds remain in users' wallets, CEXs custody user assets and manage balances through an internal ledger. This process involves:

1. Deposit & Custody of User Funds

   • When a user deposits assets, the funds move to the exchange's hot wallet (for active trading) or cold wallet (for long-term storage & security).

   • The CEX updates the user’s balance on its internal database, allowing them to trade.

2. Trade Execution and Balance Updates

   • When an order is filled, the exchange updates the buyer’s and seller’s balances internally, rather than executing transactions on-chain.

   • This system removes blockchain latency and fees, enabling faster trading.

3. Full Custodial Control Over User Assets

   • Since the CEX manages all funds, it has full control over withdrawals, deposits, and security measures.

   • While this allows for efficient trading, it also introduces risks such as:

     • Hacks & Security Breaches: If an exchange is compromised, user funds can be stolen.

     • Operational Risks: Insolvency or mismanagement can lead to loss of assets.

     • Censorship & Freezing of Accounts: Users rely on the exchange’s policies and can be restricted from accessing funds.

Zex: A New Era of Decentralized Exchange

Zex Architecture: Rethinking the DEX Model

1. EigenLayer Nodes as the Execution & Security Layer

   • Instead of using a traditional blockchain, Zex operates on EigenLayer, a decentralized network where staked Ethereum (ETH) validators secure execution through restaking.

   • These nodes validate transactions, ensure security, and maintain data availability, removing reliance on standard blockchain consensus mechanisms.

   • Restaking allows validators to secure multiple protocols simultaneously, increasing capital efficiency while preserving decentralization.

2. AVS (Autonomous Verifiable Service) instead of the Smart Contract

   • Instead of conventional on-chain smart contracts, Zex develops an AVS to process transactions and automate trading logic. We will delve deeper into this AVS to explain how we offer the user interface of a centralized exchange.

   • AVS enables off-chain computation with cryptographic verification, ensuring security and trustlessness while significantly improving execution speed. We refer to this as Zex being "sufficiently decentralized."

3. Zellular Sequencer: Coordinating Transactions and Finality

   • Zex leverages the Zellular Sequencer to provide deterministic ordering of transactions and bring sub-second finality for transactions.

   • The sequencer aggregates and orders transactions before execution in EigenLayer nodes, ensuring syncronization while maintaining decentralization.

   • Unlike blockchain-based mempools, the sequencer optimizes sequencing off-chain.

How Zex Works: A User’s Perspective

1. Connecting a Wallet

   • Users connect their Web3 wallet (MetaMask, WalletConnect, RabbyWallet) to the Zex interface.

   • Unlike traditional DEXs, no blockchain fee is required, as execution happens on EigenLayer.

2. Trade Execution

   • When a user places an order, the transaction is sent to the Zellular Sequencer, which determines the order of execution.

   • The Zex AVS gets the ordered transaction batch from the sequencer and using its matching engine component to execute the transactions.

   • Transactions are executed, finalized and the user’s balance is updated in a decentralized and immutable manner.

Zex AVS: Decentralization and State Synchronization

To address this issue, we first introduce the concept of a Replicated State Machine (RSM).

Replicated State Machine

A Replicated State Machine (RSM) is a distributed computing model that ensures multiple nodes in a network execute the same sequence of transactions in the same order, thereby maintaining a consistent system state. In a decentralized environment like Zex AVS, where different nodes process transactions independently, an RSM guarantees that all nodes remain synchronized regardless of execution order discrepancies.

To achieve this, RSMs rely on deterministic execution and consistent transaction ordering. Each node starts from the same initial state and processes an identical sequence of transactions in a predefined order. This order is enforced by a leader-based or consensus-driven mechanism, such as Byzantine Fault Tolerant (BFT) consensus or a decentralized sequencer like the Zellular Sequencer in Zex. By doing so, the network prevents state divergence and ensures that every node reflects the correct, agreed-upon state at any given time.

Using the Zellular Sequencer

In Zex AVS, the combination of Replicated State Machine (RSM) principles and the Zellular Sequencer ensures seamless transaction synchronization, eliminating the risk of inconsistent states across nodes while maintaining decentralization and high throughput.

Zex AVS includes an integrated Zellular Sequencer client that processes unsequenced transactions. When a transaction is received, Zex AVS sends it to this client, which then forwards all transactions to an EigenLayer node hosting the Zellular Master Sequencer. The Master Sequencer orders the transactions in a consistent and deterministic manner, ensuring that all network participants execute them in the same order. Once sequenced, the transactions are sent back to the Zellular Sequencer client within Zex AVS, ensuring proper execution across all nodes.

This structured approach guarantees transaction finality while preventing inconsistencies, allowing Zex AVS to function as a high-performance, decentralized exchange system.

Verification in Zex: Validating Transactions and Their Sources

Every transaction originates from one of two sources:

1. User Transactions

User transactions typically involve activities such as user registration, opening and closing orders, and sending withdrawal requests. For these transactions, users issue signatures, usually via their wallets. The ZexCora module is responsible for validating these signatures and verifying the source of the transaction to ensure it originates from an authorized user.

2. Deposit Transactions

When a user makes a deposit to the Zex platform, the system needs to acknowledge the on-chain transfer and update the user’s balance accordingly. To handle this process in a decentralized manner, Zex employs multiple instances of observers, collectively referred to as ZexPorta. These observers issue a threshold signature using the FROST (Flexible Round-Optimized Schnorr Threshold Signatures) algorithm. This threshold signature is then verified by the FROST Verifier within ZexCora, ensuring that the deposit is valid and securely processed.

Zex AVS Architecture

The Autonomous Verifiable Service (AVS) of Zex is designed to function similarly to a centralized exchange (CEX), incorporating components such as a matching engine and order books. However, key modifications have been made to enhance decentralization and security:

• Integration of the Zellular Sequencer Component: This addition ensures the proper sequencing of transactions across the network.

• Inclusion of the FROST Verifier Component: This component facilitates secure and efficient threshold signatures.

• Removal of On-Chain Interaction Modules: Components responsible for on-chain interactions, such as the deposit handler and withdrawal manager, have been omitted to streamline operations.

FROST Algorithm

Zellular Sequencer Component

On-Chain Interactions and ZexProta Module

Zex’s Smart Contracts form the first core module of our system. Although relatively straightforward in design, these contracts are essential for user interaction, serving as the primary gateway for secure deposits and withdrawals. By leveraging these contracts, Zex ensures that users can seamlessly move assets into and out of the platform while maintaining robust fund management and security.

Vault Contract

The Vault securely holds user funds and processes withdrawals. Upon verifying signatures from the D/W module, it transfers tokens to the designated user. Additionally, the Vault features a specialized permission allowing Zex to withdraw funds under emergency circumstances, ensuring both flexibility and safeguarding of assets.

User Deposit Contract

For each user and on every supported EVM chain, Zex deploys a User Deposit Contract to receive NFTs, ERC20 tokens, and native assets. The Deposit component of the D/W module continuously observes these chains, retrieving deposits data, issuing signature that updating user balances in Zex Core upon validation. Once confirmed, the deposited assets move to the Vault. Notably, the address of each User Deposit Contract remains consistent across all chains, automatically deploying the first time a deposit is detected.

User Deposit Factory

The User Deposit Factory is responsible for deploying each User Deposit Contract at a predetermined address based on a unique user ID. This ensures that every user’s deposit address remains uniform across multiple blockchains. By simplifying and standardizing deployment, the User Deposit Factory plays a crucial role in delivering a seamless cross-chain experience for Zex users.

The Latin word porta means "gate" or "entrance" and as the name suggest, the ZexPorta is responsible for two critical tasks:

1. Monitoring Blockchain Deposits Tracking blockchain activity to extract token deposits directed to ZexCora.

2. Processing Withdrawal Requests Retrieving and processing withdrawal requests from the ZexCora in a secure and efficient manner.

ZexPorta Components

The ZexPorta module comprises three key components:

1. Deposit Component

   • Monitors blockchain activity to identify ERC20 token transfer transactions.

   • Filters transactions where the recipient matches a user’s deposit address within the platform.

   • Acts as a data layer to store deposit transaction details.

   • Serves as the Signature Aggregator (SA) for PyFrost, sending deposit data to be verified.

2. Withdraw Component

   • Retrieves withdrawal requests from the Zex core and stores them in a database for processing.

   • Functions as the Signature Aggregator (SA) for PyFrost, coordinating signature handling.

   • Sends withdrawal requests to validators for data verification and issuing a signature share for execution.

3. Validator

   • Validators act as nodes within the PyFrost network.

   • Responsible for validating both deposit and withdrawal transactions.

   • Issues partial signatures, which are aggregated and verified by the Zex core and Vault contract before final approval.

Benefits of Validator-Based Validation

• Decentralization: Validators distribute the responsibility of transaction validation across multiple independent nodes, minimizing the risk of centralization.

• Security: The use of threshold signatures ensures that no single Validator can compromise the system. A quorum of Validators must collaborate to approve a transaction.

• Scalability: The Validator architecture can scale with the growth of the Zex ecosystem, ensuring efficient validation even as transaction volume increases.

In the upcoming sections, we provide a detailed breakdown of each component, highlighting their roles and how they contribute to the secure and decentralized operation of Zex.

Comparing Blockchains, DEXs, CEXs, and Zex

Traditionally, in blockchains and DEXs, funds are either held in user wallets or in liquidity pools, which are governed by smart contracts. These smart contracts are designed to ensure that only users can initiate and authorize transfers of their funds. This setup gives users full authority over their assets. Furthermore, because of the transparency inherent in blockchain technology, there is no need to verify whether a DEX holds the assets it claims to have—there is simply no room to falsify such statistics, as all transactions and balances are publicly visible and no need for submiting any proof of reserve.

In contrast, CEXs operate differently. Once users deposit their assets into a CEX, they relinquish control over those funds and essentially trust the CEX to safeguard their assets, execute trades on their behalf, and complete withdrawal requests. In other words, a CEX has complete control over the deposited funds. Moreover, due to the lack of transparency in most centralized exchanges, users cannot independently verify whether the CEX genuinely holds the assets and liquidity it claims to possess. Without proof of reserves, users have no assurance that the exchange isn’t falsifying its statistics or over-leveraging its holdings.

How Zex Differs: Decentralized Custody and Full Transparency

Furthermore, due to the transparency of the Zex system, there is no need to provide proof of reserves. Every token transfer, deposit, trade, and withdrawal is recorded in Zex logs, which are fully public and auditable. This eliminates any doubts about the platform's integrity and ensures trust through transparency.

Zex is composed of three core modules, each serving a critical role in its operation:

1. Smart Contracts

   Zex utilizes three specialized smart contracts to facilitate its ecosystem:

   • Vault Contract: Manages and secures the assets held within the platform.

   • User Deposit Contract: Acts as a personal wallet for each user, enabling seamless interaction with the platform.

   • User Deposit Factory: Automates the deployment of individual user deposit contracts, streamlining onboarding and ensuring scalability.

2. ZexPorta Module The ZexPorta module continuously monitors blockchain activity, extracting and filtering token transfers relevant to the platform (i.e. user deposits to our platform). It also handles user withdrawal requests, ensuring efficient and secure processing.

3. ZexCora Module It consist of the Matching Engine as the heart of Zex's trading system. It maintains a comprehensive record of user orders and balances, enabling efficient and accurate order matching. This ensures a smooth trading experience comparable to centralized exchanges while preserving the benefits of decentralization.

In the subsequent sections, we delve deeper into each module, detailing the innovative architecture that makes Zex a game-changer in decentralized trading.

The Withdraw is a component of the ZexPorta module and responsible for ensuring that all user withdrawal requests are securely processed and finalised. It leverages the decentralized architecture to maintain transparency and integrity throughout the withdrawal process. Below is a detailed breakdown of its services and workflow:

Services within the Withdraw Component

The Withdraw Component consists of the following key services:

1. Database

   • Functionality: Tracks and updates the status of withdrawal transactions. Withdrawal requests progress through states such as pending and successful.

   • Technology: Uses a MongoDB database for efficient data management.

2. Observer

   • Functionality: Monitors and records withdrawal requests submitted by users via the ZexCora. Inserts new withdrawal requests into the database with a pending status for further processing.

3. Signature Aggregator (SA)

   • Functionality:

     • Sends pending withdrawal requests to Validators for verification.

     • Aggregates the signature shares issued by Validators.

     • Issues an ECDSA signature to enhance the security of the process.

   • Technology: Implements the Signature Aggregator component of the PyFrost library.

Withdrawal Transaction Workflow

The withdrawal transaction process follows the sequence outlined in the diagram. Each step ensures that user requests are securely validated and completed efficiently.

1. Read Withdrawal Requests

   • The Observer retrieves withdrawal requests submitted by users through the ZexCora.

2. Insert Withdrawal Request into the Database

   • The Observer records the withdrawal request in the database with a pending status.

3. Fetch Pending Withdrawal Requests

   • The SA retrieves pending withdrawal requests from the database for validation and processing.

4. Send Withdrawal Nonce to Validators for Verification

   • The SA sends the nonce (i.e. a unique identifier for withdrawal on each chain) associated with the withdrawal request to Validators for verification.

5. Validators Retrieve Withdrawal Data

   • Validators independently fetch withdrawal data using withdrawal nonce from the ZexCora.

6. Validators Verify and Send Signature Shares

   • Validators validate the data of the withdrawal transaction and issue partial signatures.

   • These signature shares are sent back to the SA.

7. Send Withdrawal and Signatures to the Vault

   • The SA aggregates the signature shares and issues an ECDSA signature itself to enhanced security.

   • The aggregated data, including the signatures, is sent to the Vault interface.

8. Update Withdrawal Status to Successful

   • The SA updates the transaction status in the database to successful.

   • The Vault interface completes the withdrawal process by transferring tokens from the Vault to the user’s address.

The primary goal of the Deposit Component is to ensure that all user deposits are accurately observed, processed, and passed on to the ZexCora. Below is a detailed breakdown of the deposit component services and workflow:

Services within the Deposit Component

The Deposit Component is composed of five specialized services:

1. Database

• Functionality: Manages the lifecycle of deposit transactions by maintaining their status. Transactions are tracked with one of the following states: pending, finalised, verified, successful, reorg, or rejected.

• Technology: A MongoDB database is used to store and update deposit transaction records.

2. Observer

• Functionality: Continuously monitors new blockchain blocks to extract ERC20 transfer transactions. Identifies and inserts transactions directed to Zex user deposit addresses into the database with a status of pending.

3. Finaliser

• Functionality: Monitors finality of blocks and validates pending deposits against finalised blocks.

• Reorg Handling: If a transaction is not included in a finalised block, it marks the deposit status as reorg.

4. Signature Aggregator (SA)

• Functionality: Sends finalised deposit transactions to Validators for verification. Then aggregates the signature shares issued by Validators. Furthermore, issues an additional ECDSA signature for further security.

• Technology: Implements the Signature Aggregator component of the PyFrost library.

5. Vault Depositor

• Task: Processes verified deposit transactions to transfer funds to the Vault.

• Additional Functionality: Deploys user deposit contracts through the factory if they are not already deployed, ensuring seamless fund transfers.

Deposit Transaction Workflow

The deposit transaction process follows the flow illustrated in the diagram above. Each step ensures that user deposits are securely processed and efficiently transferred to the Zex Vault. Below is a detailed explanation of each step:

1. Observer Reads Blockchain Blocks

   • The Observer continuously monitors blockchain activity, extracting ERC20 token transfer transactions from each block.

2. Insert New Deposit Transactions into the Database

   • The Observer identifies transfers where the recipient matches a Zex user’s deposit address.

   • These transactions are marked as deposits and inserted into the database with a pending status.

3. Retrieve Pending Transactions

   • The Finaliser retrieves pending deposits from the database for further validation.

4. Finalise Pending Transactions

   • The Finaliser checks if pending transactions are included in a finalised block.

   • If the transaction is included, its status is updated to finalised.

   • If not, the transaction is marked as a reorg.

5. SA Fetches New Finalised Transactions

   • The Signature Aggregator (SA) retrieves finalised transactions from the database to initiate the signature process.

6. Send Deposit Transaction Hash to Validators for Verification

   • The SA sends the hash of finalised transactions to Validators for validation.

7. Validators Retrieve Transaction Data

   • Validators independently fetch transaction data from the blockchain and verify the finality of the block containing the transaction.

8. Validators Verify and Send Signature Shares

   • Validators validate the deposit transaction and issue partial signatures, which are sent back to the SA.

9. Send Deposit and Signatures to ZexCora

   • The SA aggregates the signature shares from Validators and creates an additional ECDSA signature for security.

   • The finalised deposit data, along with the aggregated signatures, is sent to the ZexCora.

   • ZexCora verifies the data and updates the user’s balance.

10. Update Transaction Status to Verified

    • The SA updates the deposit transaction status in the database to verified.

11. Vault Depositor Fetches Verified Transactions

    • The Vault Depositor retrieves verified transactions from the database for further processing.

12. Transfer Funds to the Vault

    • The Vault Depositor transfers the deposited tokens to the Zex Vault.

    • If the user’s deposit contract is not yet deployed, the Vault Depositor deploys the contract using the factory before completing the transfer.

On-Chain Interactions in Zex: Deposits and Withdrawals

The on-chain interactions of any off-chain exchange occur usually when users initiate deposit or withdrawal requests. In Zex, all such interactions are managed through the ZexPorta module.

Deposits

As mentioned earlier, ZexPorta constantly monitors blockchain transactions and filters out transfers that correspond to deposits made to our platform. Once a deposit is identified, ZexPorta requests its validators to confirm the deposit and generate a threshold signature using the FROST algorithm. After the individual signature shares are aggregated, the deposit data, along with the aggregated signature, is sent to ZexCora for sequencing and execution.

Withdrawals

When a user initiates a withdrawal request in ZexCora, the request is first processed off-chain. ZexPorta observes this new withdrawal request registered and finalised in ZexCora. After preprocessing steps (which may vary depending on the specific blockchain), ZexPorta requests the ZexCora nodes on EigenLayer to issue a threshold signature for the withdrawal. Once the signature shares are aggregated, ZexPorta broadcasts the withdrawal transaction on-chain, completing the transfer from the platform to the user’s wallet, along with the verified signature.

Validators are pivotal in maintaining the security, integrity, and decentralization of the ZexPorta module. They function as decentralized PyFrost Nodes, tasked with validating both deposit and withdrawal transactions. Validators ensure that all data corresponding to these operations meet stringent standards and pass accurately to the ZexCora and the Vault contract.

Role in the Decentralized Architecture

Validators are integral to the decentralized design of ZexPorta module, ensuring that no single entity has control over the transaction approval process. By distributing responsibility across multiple Validators, Zex achieves a high level of security and decentralization.

Threshold Signature Protocol

• This protocol ensures that no single Validator can unilaterally sign a transaction, requiring collaboration among a quorum of Validators to generate a valid signature.

Signature Aggregation

• Validators issue partial signatures for both deposit and withdrawal transactions.

• These partial signatures are aggregated by the SA to produce a complete, secure signature, which is then forwarded to the ZexCora or to the Vault contract for final processing.

Validator Workflow

Validators in the ZexPorta module are designed to handle tasks associated with both deposit and withdrawal processes:

1. Deposit Validation

• Validators retrieve finalised deposit transactions from the blockchain using the hash provided by the SA.

• They verify the finality of the block containing the transaction.

• Upon successful verification, Validators generate partial signatures for the deposit transaction data and send them to the Signature Aggregator (SA).

2. Withdrawal Validation

• Validators fetch withdrawal requests from the ZexCora by the corresponding transaction nonce provided by SA. Then the Validators generate partial signatures for the withdrawal request and send them back to the SA.

Derived from the Latin word cora, meaning "heart" or "core," ZexCora serves as the central hub of our platform. It is responsible for fundamental exchange functionalities, such as the matching engine and maintaining user balances and states.

To optimize system performance and accessibility, ZexCora operates with two types of nodes:

• Light Node: Light nodes are responsible for maintaining the system state and tracking transactions that alter the state. Anyone can read the state from any light node.

• Full Node: Full nodes, in addition to maintaining records, can process external requests and transactions. Running a full node requires more resources than a light node due to the additional responsibilities.

ZexCora Architecture

The ZexCora platform employs a robust system to process transactions efficiently and securely. Below is a step-by-step explanation of how the architecture handles transactions:

1. Transaction Submission Transactions are initiated by ZexPorta SA, user interfaces (UI), or other external sources acting as ZexCora clients. These transactions, such as deposits, buy orders, and sell orders, are sent to ZexCora Full Nodes.

2. Processing by Full Nodes The Full Nodes receive the transactions, place them in a transaction queue. Full Nodes then prepare the transactions to be forwarded to the Sequencer for ordering.

3. Forwarding to Sequencer Nodes Full Nodes send the transactions to one of the Sequencer Nodes in the Zellular Sequencer. These Sequencer Nodes collect transactions for ordering and send them to the Master Sequencer.

4. Global Ordering by Master Sequencer The Master Sequencer collects transactions from all Sequencer Nodes and organizes them into a single, definitive sequence. For example, if transactions A, B, C, and D are received, the Master Sequencer may arrange them as A, B, D, C. The ordered sequence is then broadcast to all nodes within the Zellular Sequencer.

5. Verification by Light Nodes ZexCora Light Nodes receive the sequenced transactions and verify their integrity and validity. Light Nodes ensure the transactions are consistent with the current system state.

6. Validation by Full Nodes Verified transactions are collected by Full Nodes for detailed validation. Each transaction is checked for source authenticity and applicability to the current system state. For example, in a withdrawal transaction, the system checks if the user has sufficient funds available.

7. Transaction Execution Once validated, the transactions are forwarded to the Matching Engine and executed:

   • For deposits and withdrawals, the user’s balance is updated.

   • For buy and sell orders, based on the order price, the transactions are registered in an order book or executed instantly.

This step-by-step architecture ensures secure, transparent, and efficient transaction processing within the ZexCora platform.

Transaction Data Formats

The following tables outline the data format for all transaction types.

1. Registration Transaction

The sender should sign the follwing massege:

Welcome to ZEX.

2. Order Transaction

The sender should sign the follwing massege:

v: {version}
name: {"buy" if side == BUY else "sell"}
base token: {base_token}
quote token: {quote_token}
amount: {np.format_float_positional(amount, trim="0")}
price: {np.format_float_positional(price, trim="0")}
t: {t}
nonce: {nonce}
public: {public}

3. Cancellation Transaction

The sender should sign the follwing massege:

v: {tx[0]}
name: cancel
slice: {order_tx}
public: {public_key}

4. Deposit Transaction

The sender should sign the encoded message that is described above.

5. Withdrawal Transaction

The sender should sign the follwing massege:

v: {version}
name: withdraw
token chain: {token_chain}
token name: {token_name}
amount: {amount}
to: 0x{destination.hex()}
t: {t}
nonce: {nonce}
public: {public.hex()}