StarkExchange
Traders and consumers are about to experience a dramatic change in crypto trading. Traders will be able to trade in the most intuitive way: directly from their own wallets, maintaining custody at all times, tapping into the liquidity pools offered by Centralized Exchanges (CX). Furthermore, traders’ funds will be readily available for payments.
Things will also change for exchanges: they will offer their customers a choice between custodial and Self-Custody (SC)-trading, all from the same liquidity pool, at scale. They will reduce the operational risk associated with custody of crypto assets. They will be able to offer their customers shielding of trades, and protect them from front-running. Crypto exchanges with their superior offering tailored for any tokenized asset, will be well-positioned to take on the incumbent exchanges on Wall Street.
We read regularly about the risks of CX maintaining custody of crypto-assets: Binance most recently, Bithumb and Quadriga before that, and many other CX hacks, going all the way back to the infamous Mt. Gox hack. Without car chases, each one of these hacks resulted in theft of crypto-assets worth tens to hundreds of millions of USD.
We don’t hear of exchanges outside the blockchain space getting hacked. Why not? The reason is trivial: they do not maintain custody of assets on behalf of traders. Those exchanges have no financial assets that can be stolen. What’s different about CX in the blockchain space? They maintain custody of crypto-assets and by doing so present traders with massive counterparty risk. This is a historic “bug”, an artifact of lean cryptographic design and limited blockchain bandwidth, which somehow turned into a supposed “feature”. Worth emphasizing, in the blockchain space, custody is actually far more dangerous than elsewhere, as there is no trusted party to mandate a reversal of illegitimate trades: assets stolen are unlikely to be retrieved. By maintaining custody, CX form a massive honeypot, ripe for hacking and theft.
StarkWare recently demonstrated the ability to handle high SC-trading at scale: 500 trades/sec over Ethereum — a 200X improvement over Ethereum’s current capacity. We expect this metric will grow significantly in the coming months. We believe SC-trading is now ready for prime time, and is therefore inevitable.
This post will focus on StarkExchange, StarkWare’s solution for CX, which will bring to their large liquidity pools the benefits of SC-trading. We believe that once CX introduce StarkExchange into their backbone, crypto-asset trading will become more efficient, safer, and much bigger.
We’ve recently launched — together with 0x — our Alpha for StarkDEX, a scalability solution for decentralized exchanges (DEX). Here is a comparison of CX and DEX on several important dimensions, and how StarkDEX and StarkExchange alleviate their main drawbacks.
Background
Liquidity requires scale — an exchange must be able to match and settle a high volume of trades in order to offer liquidity. Blockchains (i.e. Layer-1), as a public ledger, are a very natural place to document ownership of crypto-assets, and in particular the settlement of trades. But blockchains are hugely limited in their operations and storage capacity: Ethereum, for example, can currently support at most about 40–50 trades/block, or about 3 trades/second, a remarkably low glass ceiling on scalability, and therefore on liquidity.
CXes — in reality these are trust-based Layer-2 solutions — are currently the only means of tapping into high liquidity. In order to do so, traders must hand over custody of their crypto-assets. If traders insist on retaining custody, they are required to operate on highly illiquid decentralized exchanges (DEXes).
The market voted clearly on this matter: CXes are much bigger than DEXes. When forced to choose between high liquidity and SC-trading, traders opted for liquidity. But traders still want the best of both worlds: high liquidity and SC-trading. With StarkExchange, they can have their cake and eat it too.
The Problem with CX Maintaining Custody
By maintaining custody centralized exchanges (CX) are exposed to a host of problems, which affect their profitability, their ongoing operations, and their regulatory exposure.
Hampered Profitability: decreased revenues, increased costs.
- Revenues: On the retail front, there is a general sense of crypto-trading being a Wild West. This may not deter early adopters, but may well get in the way of the next massive wave of adoption. Customers, in spite of abundant evidence to the contrary, are asked to trust exchanges with custody. Demand from institutional investors is also negatively affected: if custody is handed to a CX, tapping in a timely fashion to liquidity opportunities present elsewhere becomes more challenging.
- Costs: Protecting massive honeypots results in increased costs; quality opsec is expensive. Sizeable honeypots motivate proportionally sizeable attacks. By removing the honeypot (or shrinking it), the motivation to attack is removed, and the cost to protect the system is reduced. Insurance is expensive, not only because the insurance industry doesn’t have a sufficiently refined understanding of the space just yet, but also because of the unique ownership model of crypto-assets, where there is no trusted party to revert malicious acts.
Operational Penalty: There is substantial operational overhead to maintaining custody of billions of USD worth of crypto-assets. Anecdotally, CXes are struggling with staffing adequately-vetted teams that can be trusted with keys that control these crypto-assets. Security needs push towards small staff counts, the larger the assets handled, whereas workflow needs pull in the other direction. The burden of custody means that CXes are not as nimble an organization as they could be.
Regulatory Exposure: Regulatory regimes commonly require the separation of custody from investment or trading. Such investor safety priorities are easier for regulators to achieve in a world where CXes do not maintain custody of crypto-assets.
STARKs to the Rescue
STARKs can provide a Layer-2 solution over Ethereum (i.e. a solution running on top of the Ethereum blockchain) — a scalability engine that will allow CXes to offer SC-trading which taps into their massive liquidity pools. Like other zero-knowledge proof (zkp) based scalability solutions, we do not change the fundamental scale of blockchains, but rather alter their purpose: from computing small payloads on-chain to verifying exponentially larger payloads computed off-chain.
“Don’t compute, verify!”
At the basis of a zkp scalability engine is the realization that blockchains should be used for verification of computational proofs, not for general computations. Instead of settling trades directly on the blockchain (compute), one should use the blockchain to verify a STARK proof which attests to the validity of a large batch of trades to be settled (verify).
The STARK proof system is highly asymmetric in its division of computational labor: the prover does lots of work, the verifier does very little (exponentially less) work. Now, if provers run in the cloud (off-chain), and verifiers run on the blockchain (on-chain), we can leverage this asymmetry in order to verify on-chain massive computations done off-chain. Note the prover can run not merely off-chain, but in fact is not required to run open-source, as in proof systems there are no trust assumptions regarding the prover. The blockchain is used sparingly: a commitment to an off-chain state continues to be stored there, and a verifier does very little computational work on-chain in order to validate off-chain state transitions.
What Ensures Self Custody?
Since only valid trades are accepted by StarkExchange, the prover itself cannot generate a proof for a trade that was not properly signed by the user. This means user funds cannot be stolen. If the off-chain state is available to the user, they can always walk away with their funds. Neither the exchange nor the prover can withhold those funds, as the user can activate an “escape hatch”, which is in essence an emergency mode activated at the user’s discretion when they’re denied service: they can withdraw funds directly from the smart contract running on-chain.
Data Availability
In order to activate the “escape hatch”, which is a critical component in ensuring SC-trading, the trader must have the ability to prove their updated ownership of assets. Ideally, one would want to have both SC-trading and privacy. Currently, there is a tradeoff between the two: DEXes offer SC-trading with no privacy, CXes offer privacy from other traders (not from the CX itself!), but no SC-trading. StarkExchange may eventually do away with this tradeoff by introducing shielded trades.
In the absence of shielded trades, different data availability solutions can be chosen based on the degree of trust towards the exchange. A few possible options we envision (other flavors surely abound):
- Trust-Free: trading data is sent on-chain. In order to minimize its size, digital signatures, which are checked by the prover as part of the proof, are not stored on-chain. This presents an effective cap — determined by Ethereum’s capacity — on trading volume. Worth noting: a rather naive implementation of StarkExchange with on-chain data would easily yield an effective throughput of 3,000 trades/block, which is in and of itself a 100X improvement over its current capacity.
- Trust-Minimized: a cryptographic commitment to the state of the accounts at the exchange is placed on-chain. The full encrypted state is stored publicly off-chain, and its availability is guaranteed by a trusted federation. This federation will guarantee that it has seen a public copy of the state.
- Trust-based: a cryptographic commitment to the state of the accounts at the exchange is placed on-chain. The full state is stored privately by the exchange, which means that traders have privacy from 3rd parties. This approach ensures that users’ funds cannot be stolen, though does not protect against censorship or freezing of assets inside the exchange.
Bringing Liquidity to SC-Trading
Right out of the gate, CXes can offer their SC-trading users liquidity from their existing custodial business. The CX can share orders from the custodial pool, by acting as a maker for those orders in the SC-trading pool (or, conversely, as a taker). It can do so in the following manner:
- For pairs of Ether/ERC-20 tokens (e.g. ETH/MKR, REP/ZRK), it can do so in a trivial fashion.
- Interestingly, it can also do so for assets which are already tokenized over Ethereum, even if the order on the custodial side involves the native asset, and not the tokenized one. In such a case, the exchange itself will trade the native asset with the tokenized one. For example: Alice places an ETH/USD order (buy ETH for USD) using the custodial service. Assume further that the CX has an adequately liquid USD-USDC (or some other USD stablecoin flavor) of an underlying USD deposit with a stablecoin issuer. The CX places a corresponding trade on the SC-trading side, replacing USD with USDC, and changing the exchange rate to account for the USD/USDC conversion. Bob, who uses SC-trading, can now take this ETH/USDC trade.
By doing so, the CX brings the ETH/USD liquidity (as well as ETH/BTC, and any other pairs involving tokenized assets) to the SC-trading pool. The CX piggybacks on the custodial services of a third-party tokenizer of real-world assets (the USDC issuer in the example above), without itself tokenizing any assets and without taking on any additional custodial risk. Since most of the volume of trading on CXes involves fiat, by using this technique we bring instant massive liquidity to SC-trading.
- As third party custodians and STO issuers tokenize more real-world assets, CXes can introduce them non-custodially into the mix in a similar fashion. In this model, token issuers undertake the structuring and custodying, and exchanges — in a risk-light non-custodial way — simply specialize in acquiring customers, and running deep liquidity pools.
The World We Envision
We envision a world where centralized exchanges (CX) offer:
- Marketing and customer acquisition
- KYC/AML services
- Liquidity shared across custodial and SC-trading
- Matching of makers and takers
Traders at a CX will be able to tap into a single liquidity pool via either SC-trading (their own wallets!) or custodial trading, as they see fit.
And the future? We are surely only starting to understand the exciting possibilities ahead. Some ideas that are on our minds for using STARKs:
- Payment services will be integrated seamlessly into CX.
- Better liquidity: traders will be able to transfer assets between accounts across exchanges much faster: transfers would be delayed merely by the time to commit the new states on-chain, as opposed to delays that are intended to minimize the risk of reorgs/double-spends. This would mean easier access to liquidity across multiple exchanges.
- Fairness of matching: CXes will be able to prove the integrity of the matching algorithms they employ, as well as prove publicly other fairness indicators (e.g. scale of wash-trading).
- Shielding: Traders will be able to shield their trades, not only from other traders (and miners), but also from the CX itself, thus ensuring their trading strategies remain confidential, and that market participants don’t front-run them.
- Fast settlement: Settlement of trades (not only in crypto-assets!) will be done in almost real-time. What is currently a complex, expensive and time-consuming ordeal lasting 48 hours, will be greatly improved. A dramatically shorter process will mean fewer participants, less risk, and therefore less of a need for regulatory protections.
- Compliance metrics: custodians, for example, will be able to prove solvency in zero-knowledge, thus greatly reducing the likelihood of gossip and rumors instigating a “run on the bank”.
Summary
StarkExchange will use STARK, a zero-knowledge proof protocol, to improve crypto-asset trading at centralized exchanges (CXes). CXes, with their large liquidity pools, will offer customers the ability to trade at scale in these same liquidity pools, but without forcing any custodial risk.
StarkWare sees an exciting product roadmap ahead, which will make exchanges increasingly faster, safer, better.
Matt Levine, the famous columnist, said “The fate of all crypto exchanges is to be hacked”. With StarkExchange, we intend to change their fate.
Thanks to Dan Robinson for his comments.
Tom Brand, Harish Devarajan, and Uri Kolodny
