HYBRID EXCHANGE / CEX + DEX ARCHITECTURE
PROPELOO engineers hybrid cryptocurrency exchanges — centralised order matching with decentralised custody and settlement. Users keep self-custody of their funds while the exchange provides the performance, liquidity and user experience of a centralised exchange. This is the architecture that resolves the CEX-vs-DEX tradeoff.
Centralised exchanges require users to trust the exchange with their funds — a trust that FTX proved cannot be assumed. Pure DEXes require paying gas for every trade, suffer from MEV sandwich attacks, and cannot match the performance needed for professional trading. Hybrid exchanges solve both problems: the matching engine runs off-chain for speed and efficiency, but user funds remain in self-custody smart contract accounts, and settlement is cryptographically verified on-chain. Users cannot be rugged because the exchange never holds their assets. Traders get CEX-level performance because matching is centralised.
High-performance central matching engine processing 50K+ orders/second with sub-millisecond latency. All standard order types. Users sign orders with their wallet key — matching engine cannot submit unauthorised orders.
Periodic batch settlement on-chain: balances of matched trades committed to smart contracts. Settlement can be validated cryptographically — anyone can verify that settlement matches the off-chain trade log.
ZK rollup settlement — validity proofs submitted on-chain proving that all state transitions are correct. Users can force-withdraw from the ZK contract even if the operator is offline. Maximum trust.
MetaMask, WalletConnect, hardware wallets, ERC-4337 smart accounts — users connect their existing self-custody wallets. Deposits stay in user-controlled smart contracts.
Even if the exchange operator disappears or becomes malicious, users can trigger a forced withdrawal from the on-chain smart contract after a time delay. The exchange cannot block it.
Every trade is cryptographically verifiable: signed by both parties (or the matching engine acting under user's signed delegation), committed on-chain in a Merkle tree, queryable by any observer.
The hybrid exchange design goal is: the exchange operator should be unable to steal user funds even with full control of the system.
In a hybrid exchange, users sign each order (or sign a delegation key) with their wallet. The matching engine cannot submit trades that the user did not authorise. Even if the matching engine is compromised, it cannot move user funds without valid user signatures. This is the core security property that distinguishes hybrid from CEX.
Axiom:
The longer between on-chain settlements, the larger the window in which the operator could theoretically go offline with unconfirmed user balances. Hourly settlement balances gas cost against user risk. Real-time settlement (ZK validity proofs) eliminates the window but requires ZK infrastructure (dYdX v4 StarkEx model).
Axiom:
Even with periodic settlement, users need a way to exit even if the operator goes offline. The escape hatch: after the settlement period passes without a new commitment, any user can trigger a withdrawal from the last committed on-chain balance. The operator cannot block this. This feature is what makes the hybrid model trustless, not just self-custody.
Axiom:
Every batch settlement transaction costs gas. More frequent settlement means more gas costs, which either reduces profitability or increases fees. ZK rollup settlement (single proof per batch of thousands of trades) amortises gas cost effectively. Optimistic settlement with fraud proofs is simpler to implement.
Axiom:
Impact: ZK rollup for highest trust guarantees (dYdX v4, Stark-based). Optimistic for faster development timeline. Batch commit without proofs if on-chain verification is not a requirement — suitable for exchanges where the operator is trusted but funds are self-custodied as a safety net.
Impact: Arbitrum or Base for most hybrid exchanges — EVM compatible, low gas costs, established ecosystem. StarkNet for ZK-native settlement. Ethereum L1 only for very high-value protocols where L2 trust is insufficient.
Impact: Session key delegation or ERC-4337 smart account for production — requiring MetaMask popups for every trade is unusable. Session keys allow professional trading UX while maintaining self-custody security.
Impact: Single L2 at launch (Base or Arbitrum). Cross-chain after proving the protocol — cross-chain hybrid exchanges require solving cross-chain settlement consistency which is significantly complex.
Impact: Start with native chain assets (ETH, USDC, USDT, major ERC-20). Add bridged assets after launch when compliance with bridge security risks is evaluated.
Off-chain CLOB matching + ZK or optimistic on-chain settlement with forced withdrawal guarantee and non-custodial wallet integration.
Spot trading with off-chain order book for professional trading UX + on-chain settlement and self-custody of all user assets.
Perpetuals and futures with CEX-level matching performance + on-chain risk management and user-owned position contracts.
Hybrid exchange for institutional clients — FIX protocol, batch settlement designed for audit requirements, enhanced KYB, OTC desk.
Deploy existing CEX matching engine with on-chain settlement layer on Arbitrum/Base — add self-custody guarantee to existing trading infrastructure.
Unified order book across multiple chains — user assets stay on their preferred chain, trades settle cross-chain via LayerZero or CCIP.
Stack: Go / Rust (off-chain engine), Redis (order book state), Kafka (event log)
Stack: StarkEx, zkSync (ZK Stack), Polygon zkEVM, Linea
Stack: Custom fraud proof contracts, Arbitrum SDK, Dispute resolution
Stack: Solidity (custody), OpenZeppelin, Foundry + Echidna, ERC-4337 (session keys)
Stack: React + TradingView, wagmi + viem, WalletConnect v2, Session key SDK
Stack: AWS multi-region, Kubernetes, Tenderly (monitoring), Datadog
The core security property: smart contract must allow any user to withdraw their assets after the settlement deadline passes, regardless of operator cooperation. Test this path rigorously — it must work when the operator is actively resisting.
Session key delegation: signed permission for a specific key to trade on behalf of the user wallet, with value limits and expiry. If the session key is compromised, losses are bounded by the session key parameters.
For ZK settlement: the validity proof must be verified on-chain for every batch. Invalid state transitions must be rejected. For optimistic: robust fraud detection and incentivised challengers.
Custody contracts, settlement contracts and forced withdrawal mechanisms require full third-party audit. The security model depends entirely on these contracts being correct.
The operator signing key for batch settlement must be HSM-backed with multi-party approval for emergency operations. A compromised signing key cannot steal funds (user assets self-custodied) but can halt settlement.
The settlement incentive structure must prevent the operator from selectively withholding settlements to harm specific users. Time-based forced settlement prevents this.
Settlement mechanism, custody model, order signing, L2 selection, forced withdrawal design.
Custody contracts, settlement contracts, forced withdrawal logic.
Off-chain order book, order validation (signature check), batch settlement preparation.
ZK prover (if applicable), batch commitment, on-chain state update.
Non-custodial wallet connection, session key implementation, deposit/withdrawal UX.
Professional trading UI, self-custody indicators, forced withdrawal UI.
Smart contract audit, settlement mechanism security review, staged launch.
A hybrid exchange combines a centralised order book (for speed and professional trading UX) with on-chain settlement and self-custody of user funds (for security). The matching happens off-chain like a CEX — fast and efficient. But user funds are held in smart contracts that only the user controls. The exchange cannot withdraw user funds without user signatures. Settlement is committed on-chain so anyone can verify correctness.
When a user's funds are committed on-chain in the latest settlement proof, the smart contract maintains that balance. If the operator stops processing withdrawals or disappears, users can trigger a forced withdrawal: submit a transaction to the smart contract claiming their on-chain committed balance after a waiting period (typically 24-72 hours). The operator cannot block this withdrawal. This is the safety valve that makes the hybrid model trustless.
A hybrid exchange provides CEX-level performance (sub-millisecond matching, all order types, no gas per trade) with self-custody security. A pure DEX pays gas for every trade (expensive on L1), suffers from MEV sandwich attacks, has slower settlement, and cannot offer limit orders without significant complexity. The hybrid model is better for professional trading use cases where order book dynamics and execution quality matter.