Bringing STARKs to Ethereum

0x and StarkWare have developed a proof-of-concept scalability engine that features simulated data sampled from a live Binance feed.


Up to 20x more trades per minute, compared to current DEX throughput


Up to 95% improvement in gas efficiency

Scalability Engine



0 gasaverage gas per trade

0average trades per proof

0settled trades

0 gasaverage gas per proof

500StarkWareStarkDEX Services

The simulator replays a set of trades through our engine at a sustained rate of 10 trades per second. You can verify these trades yourself by looking into the latest proofs at the bottom of the page.

Signed transactions are sent to StarkWare's StarkDEX Service to be included in a batch. The StarkDEX Service verifies the signatures, checks that the trades can be executed properly, and updates the token balances in the off-chain state. Once a batch is complete, the StarkDEX Service generates a proof attesting to the computational integrity of the entire batch and sends it along with the state root to the Verifier Contract.

The Verifier Contract receives a request to change the state - as represented by the new state root - along with the proof. The contract verifies the proof and accepts the state transition only after the proof was accepted. Since a proof for an invalid state transition cannot be generated, only valid state transitions are accepted.

The Verifier Contract connects with the 0x smart contract pipeline that funnels transactions to be settled on the Ethereum blockchain. On average it takes about 10 minutes for a trade to be settled on-chain.

To withdraw funds, the Verifier Contract verifies the proof containing the withdrawal, then updates the user token balance on-chain. If the StarkDEX Service does not fulfill the user request within a given timeframe, the user can withdraw their funds directly from the 0x smart contract.

Latest Proofs

Frequently Asked Questions


What Is StarkDEX?

StarkDEX is a scalability engine - currently handling only settlements - for non-custodial exchanges. It allows the lion’s share of the exchange's workload to be done off-chain and provide the blockchain an easily verifiable proof of the integrity of the work performed. This is the Alpha of StarkDEX for 0x Relayers, deployed on a public Ethereum testnet.

What Is STARK?

STARK is a succinct proof protocol that is scalable and transparent. Transparent (the T in STARK) means it requires no trusted setup (unlike other proof systems). Scalable (the S in STARK) means the prover time scales quasi-linearly with respect to a native computation, while verifier time scales logarithmically.

This inherent asymmetry makes STARK an ideal instrument for scaling computations on blockchains. It allows a batch of transactions to be computed off-chain and verified on-chain in an exponentially smaller time, without adding any trust assumptions. Batch size can grow with only a small increase in cost, allowing scaling up to thousands, and eventually tens of thousands of trades per second.

How Does StarkDEX Enhance Decentralization?

STARK enhances decentralization by supporting Inclusive Accountability: the (computationally) inexpensive verification on-chain of massive computations done off-chain, allows even the multitude of computationally-weak devices on the blockchain to fully verify its integrity.

StarkDEX will support Inclusive Accountability by dramatically reducing the computational cost of verifying the integrity of huge crypto-assets trading systems.


System Overview - What Does the StarkDEX Alpha Include?

The StarkDEX Alpha includes on-chain and off-chain components. On-chain, there is the verifier contract and the deposit contract. Off-chain, there is the StarkDEX service, the proof generation service, and a data structure representing account balances.

The Alpha will include a simulation based on a sampling of live Binance transactions (with up to five minutes delay), which will be fed to the system. A transaction can be a trade, a withdrawal, or a deposit.

System Flow - How Does It Work?

StarkDEX utilizes STARKs to batch transactions into a single proof that is verified on Ethereum. The proof-of-concept utilizes both on-chain and off-chain components to settle trades.

  1. The DEX (or in the Alpha, the simulator) sends a batch of 0x orders to the StarkDEX Service, run by StarkWare.
  2. The StarkDEX Service checks the signatures of each transaction in the batch, and the validity of the transactions. The StarkDEX Service then stores the data off-chain and adds it to the execution trace it keeps.
  3. The StarkDEX Service creates a proof of the validity of the entire batch and sends it along with the most recent state root to be verified by the on-chain Verifier Contract, which verifies the proof and sends the state root to the DEX’s on-chain contract to be stored.
  4. The Verifier Contract connects to the 0x smart contract pipeline that moves the batch to be confirmed on the Ethereum blockchain.
What Is the Role of the Deposit Contract?

StarkDEX stores crypto-assets off-chain. When a user wants to trade, they deposit the desired amount into the deposit contract. The smart contract relies on STARK proofs to transfer these assets off-chain, and from then on to guarantee the integrity of the off-chain state.

Users must lock assets on-chain in order to ensure that assets are not spent in parallel both on-chain and off-chain.

Who Are the Participating Developers?

The StarkDEX Alpha is developed by StarkWare and 0x.

0x is an open protocol that enables the peer-to-peer exchange of assets on the Ethereum blockchain. 0x provides exchange infrastructure for the entire crypto economy and is working toward building a new financial stack that is more efficient, transparent, and equitable than any system in the past.

StarkWare solves the two most pressing problems of permissionless blockchains: scalability and privacy. StarkWare’s cryptographic proofs are zero-knowledge, succinct, transparent and post-quantum secure.

How Is Data Availability Ensured?

Conceptually, one could store trade data either on-chain or off-chain. The advantage of storing trades on-chain is that data availability is as resilient as the blockchain itself; the disadvantage is that blockchain resources (gas, in the case of Ethereum) are consumed linearly with the volume of trading. We chose to store trade data (and account balances) off-chain, to avoid this linear consumption of blockchain resources. By doing so, we allow StarkDEX to massively scale. This requires us to guarantee data availability off-chain.

We will start out with data availability being guaranteed by a trusted committee of participants (example of potential participants: 0x, StarkWare, DeFi participants, etc.). Down the road we plan to replace it with a blockchain-based solution.

What Are the Software Licenses Used?

The verifier smart contract software will be available under the Apache License, Version 2.0 available here:

The DEX smart contract software will be available under the Apache License, Version 2.0 available here:

The StarkDEX Service software is proprietary and available only under a commercial license from StarkWare Industries Ltd. Please contact to discuss license terms. Our proprietary software is available for download only with a license key.


When Will This Reach Mainnet?

We plan to launch a Minimally Viable Product (MVP) on Mainnet which will support live users. This MVP will include at least one DEX, and will allow trading. Release date to be announced.

What Is the Data Availability Committee's Long-Term Role?

In the interest of enhancing decentralization, the intent is to eventually decommission the data availability committee, and replace it with a blockchain-based solution.

What Is the Expected Latency?

Latency depends on whether a Relayer wishes to trust the StarkDEX Service to indeed generate a proof in a timely fashion for every batch of trades sent to it.

Relayers who make that assumption (or protect themselves against its violation) will be able to allow users to continue trading based on their settlement history, as recorded in the Relayer’s internal order book, even if proof for these transactions has yet to be presented to the Verifier Contract. In this case latency is actually better than current blockchain transaction latency. The only thing a user won't be able to do before a proof is presented, is to withdraw funds.

A Relayer that wishes not to make that assumption will not need to maintain an internal order book: they will wait until a proof is presented before allowing a user to continue trading on the basis of a given trade. In this case latency will be a few minutes starting from the initiation of a settlement.

Is There an Escape Hatch?

The MVP will include an escape hatch. If any of the entities participating in operating the MVP (StarkWare, 0x, the 0x Relayer, the data availability committee) become unresponsive, users will know that they still retain self-custody of their own crypto-assets.

Want to receive updates? Sign up below.

Thank you! You were added to the list.