DEX Chain
Provision and operate your own trading chain. DEX Chain is the infrastructure layer that builds, configures, and runs purpose-built chains across any execution environment, with a decentralized central limit order book that lives in chain state rather than sitting on top of it.
Set the Rules at the Protocol Level
Operators define the execution environment, sequencing model, settlement path, data availability source, and proof system, then run the resulting chain as their own network. This is chain provisioning and chain operation. It is not a routing layer between existing networks, and it does not depend on bridging assets across them. The output is a functioning chain with its own block production, its own state, and a matching engine built into the protocol.
Any Virtual Machine. Any Runtime.
Nothing in the stack assumes a single VM standard. The execution environment is a configuration choice, and the surrounding infrastructure adapts to it.
EVM-Compatible Environments
Solidity and Vyper tooling, standard RPC surface, and existing developer workflows carried over without modification
Validity Proofs, Fraud Proofs, or Neither
Proof systems are a design decision with real cost and latency implications. Zero-knowledge proving is one path among several, not a prerequisite. DEX Chain treats the proving model as configurable and supports ZK-based and non-ZK-based verification with equal standing.
Validity Proof Configuration (ZK)
Decentralized CLOB
DEX Chain runs a decentralized CLOB as a native chain primitive. The matching engine is part of the state transition function, so order book state is chain state: every validating node reconstructs the same book from the same block data and arrives at the same fills.
Deterministic Matching
Price-time priority is enforced by the protocol. Order placement, modification, cancellation, and execution are chain operations with defined ordering, which makes fills reproducible and independently verifiable by any node.
Order Book State as First-Class State
Resting orders, depth, and open interest are maintained in the chain's state tree rather than in an off-chain database with periodic commitments. There is no operator-held book to trust and no reconciliation gap between what traders see and what the chain settles.
Market Maker Economics
Maker and taker fee schedules, rebates, cancellation costs, tick and lot sizing, and rate limits are chain parameters. Operators can tune quoting economics for professional liquidity providers without redeploying the venue or renegotiating with a host network.
Ordering and MEV Policy
Ordering policy is enforceable when block production is yours. Batch execution windows, encrypted submission, and explicit sequencer rules close the extraction paths that open mempools leave available.
Ordering Policy Is a Configuration, Not a Constraint
Single Sequencer
Lowest latency and simplest operations, paired with forced inclusion so users retain the ability to submit transactions if the sequencer censors or stalls
Decentralized Sequencer Set
Block production distributed across multiple sequencers under BFT consensus, removing single-operator control over ordering
Validator-Based Production
Standalone chains produce blocks through their own staked validator set, with slashing and reward parameters set at genesis
Inherited Sequencing
Ordering delegated to the underlying layer, trading throughput control for the security and neutrality of the base chain
Configured at Genesis. Governed After Launch.
| 1 | EVM-compatible, non-EVM, WASM, or custom runtime | Execution environment |
| 2 | ZK validity proofs, fraud proofs, or no proof system | Proving model |
| 3 | external settlement layer or internal finality | Settlement path |
| 4 | external DA layer, DA committee, or own consensus | Data availability |
| 5 | single, decentralized, validator-based, or inherited | Sequencing |
| 6 | native token, stable-denominated fees, or sponsored execution | Fee asset and gas policy |
| 7 | markets, tick sizes, fee tiers, rebates, and risk limits | CLOB parameters |
| 8 | open participation or restricted validator and market maker sets | Permissioning |
| 9 | governance process, upgrade keys, and parameter change controls | Upgrades |
FAQ
No. The execution environment is selected per deployment and can be EVM-compatible, non-EVM, WASM-based, or a custom deterministic runtime. The requirement is verifiable state transition, not a specific bytecode standard.
No. ZK validity proofs are one option. Optimistic designs secured by fraud proofs, sovereign rollups, and standalone L1 appchains with their own consensus are equally supported. Proving is a configuration choice, and a chain can run with no proof system in its verification path.
A central limit order book matches explicit bids and offers under price-time priority, giving makers direct control over quoted price and size. An AMM prices along a curve against pooled liquidity. A decentralized CLOB preserves order book market structure while keeping matching and settlement verifiable on chain.
In chain state. Orders, cancellations, and fills are protocol operations, so any validating node can reconstruct the book and confirm execution independently.
Yes. Upgrade authority, governance process, and parameter change controls are defined at genesis and can be structured around multi-signature approval, on-chain governance, or a validator vote.
Provision Your DEX Chain
Review the architecture options, walk through CLOB configuration, and scope a deployment against your throughput and settlement requirements.
Book a Demo