Architecture

ZibaXeer system architecture, component relationships, and data flow

Architecture

ZibaXeer is a full-stack on-chain protocol. This page covers how every layer connects — from the smart contracts on HyperPaxeer through the off-chain indexer and backend, to the React dashboard.

---

System Overview

---

Monorepo Structure

ZibaXeer/
├── apps/
│   ├── backend/          # Express.js API + BullMQ workers
│   ├── frontend/         # Next.js 15 dashboard
│   └── indexer/          # ethers.js on-chain event listener
├── contracts/            # Foundry smart contract project
├── packages/
│   ├── db/               # Shared Prisma client + schema
│   ├── sdk/              # Protocol SDK (WIP)
│   ├── types/            # Shared TypeScript types (job payloads)
│   └── utils/            # Shared utility helpers
└── docs/                 # This documentation

---

Trade Execution Flow

The complete sequence from a leader executing a trade to it appearing in the dashboard:

---

Vault Deployment Flow

---

Follower Subscription Flow

---

Revenue Distribution Flow

The split percentages are configurable per vault and stored in leaderShareBps and protocolFeeBps on the RevenueSplitter contract.

---

Queue Architecture

The indexer produces to four named BullMQ queues. The backend workers consume them.

Queue	Producer	Consumer	Purpose
TradeProcessingQueue	trade.processor.ts	trade.worker.ts	Persist trade to DB
SnapshotCalculationQueue	pnl.processor.ts	snapshot.worker.ts	Recalculate ROI/drawdown
VaultDeployedQueue	vaultFactory.listener.ts	vault.worker.ts	Register new vault in DB
FollowerEventQueue	vault.listener.ts	follower.worker.ts	Sync follower subscriptions

---

Sidiora Perpetuals Trust Model

Sidiora integration introduces an intentional split of responsibility between on-chain controls and off-chain execution.

Layer	Responsibility	Trust Boundary
On-chain adapter (SidioraVaultAdapter)	Margin movement and delegate management	Enforced by Solidity access control
Indexer + mirror workers	Signal handling, risk checks, and order forwarding	Trusted service boundary
Sidiora sequencer	Order matching and batch settlement	External dependency boundary

Non-negotiable constraints:

• Mirror delegation must never include withdrawal permission.
• Delegate compromise must be recoverable by on-chain revoke/rotate flows.
• Risk checks must execute before any follower order is signed.

See the detailed spec in backend/sidiora-mirroring.

---

Sidiora Failure Domains

Domain	Example Failure	Mitigation
Sequencer dependency	Sequencer API outage	Queue buffering, backoff, temporary freeze
Mirror bot operations	Signing key compromise	On-chain delegate revoke + key rotation
Risk policy enforcement	Incorrect sizing across followers	Hard policy gate + freeze endpoint
Event pipeline	Queue lag and delayed mirrors	Backpressure + autoscaling workers

Failure handling runbooks and message schemas are defined in backend/sidiora-mirroring.

---

Vault Lifecycle

---

Contract Dependency Map