Hybrid vs Full On-Chain Perpetual Futures
Key Concepts
| ID | Term | Definition |
|---|
| 1 | HotStuff | a consensus algorithm that uses a leader-based approach to achieve consensus in a partially synchronous network. It is the basis for HyperBFT, used in Hyperliquid's App-Chain |
| 2 | BST | Binary Search Tree, a data structure that allows for efficient searching, insertion, and deletion of elements. |
| 3 | CLOB | Central Limit Order Book, a type of order book where all orders are visible and matched based on price-time priority. |
| 4 | Front-run | the act of executing a trade based on advance knowledge of pending orders, potentially leading to unfair advantages. |
| 5 | AppChain | is a custom-built blockchain designed to host a single decentralized application. |
1. Summary
This document analyses the architectural spectrum for perps infrastructure, from hybrid models that split execution across off-chain and on-chain components to fully on-chain designs where every operation is a verifiable transaction.
2. The Architecture
Perps protocols exist on a spectrum defined by two questions:
- Where does matching happen? (off-chain vs on-chain)
- Where does settlement happen? (on-chain vs off-chain)
| Category | Matching | Settlement | Trust Model | Examples |
|---|
| Centralised Exchange | Off-chain (internal) | Off-chain (internal) | Trust the operator | Binance, MEXC, Bybit, etc.. |
| Hybrid | Off-chain (node/sequencer) | On-chain (smart contract) | Trust the operator (matching + settlement) | Strike Finance V2 |
| App-Chain | On-chain (own L1) | On-chain (own L1) | Trust the L1 validators | Hyperliquid (HyperL1), dYdX v4 |
| Fully On-Chain | On-chain (shared L1) | On-chain (shared L1) | L1 + smart contracts | Phoenix, Drift |
3. Case Study: Strike Finance V2 (Hybrid on Cardano)
Architecture
Strike Finance V2 operates on Cardano with a hybrid architecture:
- Order book & matching: Off-chain, managed by the Strike Node (a centralised operator)
- Settlement & custody: On-chain via locker contracts on Cardano
- Liquidations: Triggered off-chain by the Strike Node, executed on-chain
How It Works
- Order submission: Traders send an order to the Strike Node via API
- Matching: The Strike Node matches orders using a centralised matching engine (sub-second latency)
- Settlement: Once matched, the settlement is recorded on-chain through Cardano smart contracts (locker/validator scripts)
- Position management: Position state lives on-chain, collateral is locked in on-chain vaults
- Liquidations: The Strike Node monitors positions off-chain and triggers liquidation transactions on-chain when margin thresholds are breached
Trust Model
| Component | Trust Assumption |
|---|
| Matching | Trust the Strike Node to match fairly (price-time priority) |
| Order book state | Trust the off-chain matching engine's order book |
| Settlement | Trustless. on-chain verification possible |
| Liquidations | Semi-trusted. off-chain triggers, chain validates |
Trade-offs
| Advantage | Disadvantage |
|---|
| Low matching latency | Centralised operator can censor trades |
| Low on-chain compute requirements | Order book state not verifiable in real-time |
| Compatible with chains that lack throughput | Replay-based auditability (deterministic log) |
| Easier to build complex orders | Operator downtime halts all trading |
Structural Challenges of Hybrid Architectures
| Challenge | Why It Matters |
|---|
| Closed-source matching engines | Off-chain matching engines are typically proprietary. Users cannot inspect the matching logic, verify price-time priority. The execution layer is a black box. |
| Limited operators | Off-chain execution layers are believed to operate with relatively few operators. |
| Opaque order flow | Orders are submitted to a private API. There is no public mempool, no visible order book state, and no way for users to verify that orders are processed in the announced order. |
| Limited censorship resistance | The off-chain matching engine can silently delay, reorder, or reject orders. There is no on-chain mechanism to prove that censorship occurred. |
| Operator dependency | If the single operator goes offline, all trading halts. Redundancy depends on having multiple independent operators. |
Key Insight
Hybrid architectures represent a pragmatic trade-off: use off-chain infrastructure for performance-sensitive operations (matching) while leveraging on-chain contracts for trust-sensitive operations (settlement, custody). This is a valid engineering decision, especially on chains where L1 throughput is insufficient for a CLOB.
However, the trade-off is trust, users must believe the node operator behaves correctly. On-chain settlement protects custody of funds, but does not protect the integrity of the trading process itself. The promise of future decentralisation does not change the current reality: today, the matching layer is a black box.
4. Case Study: Hyperliquid (App-Chain)
Architecture
Hyperliquid takes a different approach: instead of splitting across off-chain and on-chain, it builds everything on-chain but on its own dedicated L1 blockchain (HyperL1) running the HyperBFT consensus algorithm.
- Order book & matching: On-chain (HyperL1)
- Settlement: On-chain (HyperL1)
- Risk management: On-chain (HyperL1)
- Oracle: Native oracle system integrated into HyperL1
How It Works
- Order submission: Orders are submitted to a fully on-chain CLOB.
- Matching: The HyperBFT consensus engine matches orders with sub-second latency
- Settlement: All state transitions (positions, balances, funding) are consensus-validated
- Risk management: Margin checks, liquidations, and funding rate updates all occur on-chain
- Oracle: Validators publish spot oracle prices every 3 seconds, computed as weighted median of external CEX prices (Binance, OKX, Bybit, etc.) weighted by stake
Trust Model
| Component | Trust Assumption |
|---|
| Matching | Trust HyperL1 validators (stake-weighted) |
| Consensus | Trust HyperBFT (HotStuff variant) |
| Settlement | On-chain, verifiable by any HyperL1 node |
| Oracle | Validator-computed from CEX prices (weighted median by stake) |
Trade-offs
| Advantage | Disadvantage |
|---|
| Everything on-chain (no off-chain components) | Separate L1 - ecosystem fragmentation |
| Sub-second latency (median 0.2s) | New consensus mechanism (HotStuff variant) |
| High throughput (~200k orders/sec) | Limited validator set (centralisation concerns) |
| Full auditability of all operations | Assets bridged from other chains (bridge risk) |
| No sequencer dependency | Not composable with Solana/Ethereum ecosystem |
| No gas fees for traders | Oracle depends on external CEX price feeds |
Key Insight
Hyperliquid proves that fully on-chain perps can work at scale, processing ~200k orders/sec with sub-second latency. HyperCore's design principle of no off-chain order books is a meaningful step toward decentralisation. However, the system still relies on a limited validator set and a new consensus mechanism (HyperBFT).
5. Fully On-Chain CLOB
Architecture
Fully on-chain CLOB protocols execute every operation, order placement, cancellation, matching, settlement, liquidation, funding as on-chain transactions. No off-chain sequencer or matching engine.
- Order book: On-chain data structure (slab, BST, or similar)
- Matching: On-chain (price-time priority matching engine)
- Settlement: On-chain (position creation, PnL settlement)
- Risk management: On-chain (margin checks, liquidations, funding rates)
- Oracle: Decentralised oracle network or validator-computed prices
Requirements for a Fully On-Chain CLOB
Not every chain can support a fully on-chain CLOB. The requirements are demanding:
| Requirement | Why It Matters |
|---|
| High throughput | Order books generate massive state writes, the chain must handle thousands of TPS |
| Low latency | Traders expect sub-second order confirmation |
| Low transaction fees | High fees make frequent order placement/cancellation uneconomical |
| Parallel execution | Matching engine must process orders concurrently without bottlenecks |
| Rich state model | Need to store order book, positions, margins on-chain |
Trust Model
| Component | Trust Assumption |
|---|
| Matching | Deterministic price-time priority enforced by on-chain program |
| Order book | Fully verifiable state, reconstructable from on-chain data |
| Settlement | Executed via smart contracts and L1 consensus |
| Liquidations | Permissionless execution, validated by protocol rules |
| Oracle | Decentralised oracle or validator-computed prices |
Trade-offs
| Advantage | Disadvantage |
|---|
| No operator to trust - only L1 + smart contracts | Higher on-chain compute costs |
| Censorship-resistant - anyone can submit tx | Latency limited by block time |
| Fully verifiable - all state on-chain | Introduces additional trust assumptions and upgrade risk |
| Composable - integrates with on-chain ecosystem | Complex program architecture |
| Upgradeability via governance or admin-controlled mechanisms | Requires chain with high throughput |
Notable Projects
| Project | Chain | Status | Notes |
|---|
| Phoenix | Solana | Live | CLOB, fully on-chain |
| Drift | Solana | Paused | CLOB, fully on-chain |
6. Detailed Comparison
Architecture Comparison
| Aspect | Hybrid | App-Chain | Fully On-Chain |
|---|
| Matching | Off-chain node | On-chain (own L1) | On-chain (smart contract) |
| Settlement | On-chain (parent chain) | On-chain (own L1) | On-chain (same L1) |
| Order book | Off-chain (node) | On-chain (own L1) | On-chain (smart contract) |
| Risk management | Semi-off-chain | On-chain | On-chain |
| Latency | Sub-second | Sub-second (median 0.2s) | Depends on L1 (~400ms on Solana) |
| Throughput | High (off-chain) | High (dedicated L1) | Depends on L1 |
| Trust model | Trust operator | Trust validators + bridge | L1 + smart contracts |
| Matching open-source | Depends on protocol | Yes | Depends on protocol |
| Auditability | Replay-based (after the fact) | Full on-chain | Full on-chain (real-time) |
| Decentralisation | Depends on node operators | Depends on L1 validators | Depends on L1 |
| Censorship resistance | Low (operator controls order flow) | Medium | High (permissionless tx) |
| Ecosystem composability | Full L1 ecosystem | Own L1 only | Full L1 ecosystem |
| Bridge risk | None (native) | Yes (bridged assets) | None (native) |
| Gas fees | Depends on L1 | Varies | Depends on L1 |
Trust Assumptions
| Model | What You Must Trust |
|---|
| Hybrid | The node operator matches fairly, doesn't front-run, doesn't censor. Execution layer is typically closed-source. No public mempool. No real-time order book verification. |
| App-Chain | The L1 validators are honest, the consensus is secure, bridges work |
| Fully On-Chain | The smart contract code and the underlying L1 consensus |
| Latency | Throughput | Trust Required |
|---|
| Hybrid | Sub-second (off-chain matching) | High (off-chain) | Trust operator |
| App-Chain | Sub-second (own L1) | High (own L1) | Trust validators + bridge |
| Fully On-Chain | Depends on L1 | Depends on L1 | L1 + smart contracts |
Hybrid and App-Chain models offer comparable high performance. App-chains achieve this through a dedicated L1, while hybrid models achieve it through off-chain matching. Fully on-chain CLOBs on shared L1s offer the highest trust level but are constrained by the L1's throughput and latency.
7. Conclusion
The perps market is converging on a single insight: verifiable execution matters. Hybrid models offer convenience but require trust. App-chains offer performance but fragment the ecosystem. Fully on-chain CLOBs on shared L1s offer the highest trust level but depend on chain capabilities.
The architecture that will dominate depends on the trade-offs each protocol is willing to make. However, the trend is clear: the market is moving toward greater transparency, verifiability, and decentralisation. Fully on-chain CLOBs represent the natural end state of this evolution.
References