Unpacking The Optimal DEX – Mapping Out Vertex’s Design

All trading venues share a relatively simple goal – to enable cheap and efficient trading for users in the greatest volume possible. That means liquidity, defined as:

1. Tight spreads
2. Low slippage

The differences between CEXs and DEXs force trade-offs between control and performance for traders in the context of spreads and slippage. Both models work within their limitations to provide the best liquidity for users, which choose the venue most suited to their preferences.

CEXs are currently winning by a landslide.

As expressed in the last Vertex blog post, however, the fallout from the FTX debacle is shifting user preferences heavily toward one side. Notably, the self-custody, transparency, and autonomy of DeFi are gathering converts.

Despite the shift in user preferences, the elephant in the room remains:

Can DEXs ultimately compete with the performance and features of CEXs and meet the overwhelming demand for the UX of trading crypto on centralized venues?  

Crypto may be the closest industry in the world to a free, competitive market: an Internet-native financial stack built on permissionless protocols. FTX’s blunders could spark the demand to tilt the scales towards an emerging supply of DEXs as legitimate contenders to CEX dominance. But until CEXs face viable competition, the moat of superior UX appears immutable.

Having evolved over the past several years, DEXs face a unique situation. Armed with lessons derived from the successes and failures of past iterations, the road toward viable alternatives to CEXs lies open. All innovation stands upon the shoulders of previous trials and errors. Vertex is no different.      

Fusing both the advantages of DEXs and CEXs, a new crop of decentralized protocols is brimming with potential.

Combining advantages isn’t enough, however. Exchanges blurring the line between DEXs and CEXs must minimize the limitations of each – to foment a DEX capable of rivaling CEX incumbents. When Binance commands 75% of crypto’s monthly trading volume, systemic risks posed to the entire industry are localized to the accounting whims of one company – largely controlled by one powerful man.  

DeFi must prevail.

With Vertex, users and builders don’t need to compromise. Vertex delivers an unrivaled trading experience by integrating the orderbook model typical to CEXs with an AMM architecture characteristic of the “lazy capital” model that drove DEXs to soaring heights when Uniswap unleashed the x*y=k constant product AMM on the world of DeFi.

Vertex manifests an optimal outcome where users receive the best price matching, trade execution, and access to opportunities.

How does it work? Let’s dive in.

Orderbooks vs. AMMs - The Ideal Experience

Known as a Hybrid Orderbook-AMM, Vertex’s design considerations provide a mechanism to remedy the competing limitations of DEXs and CEXs.

One unified source of liquidity for traders everywhere.  

Both AMMs and orderbook exchange models maintain distinct advantages. Successfully merging the benefits of both while suppressing their limitations requires examining several core components of exchange design.

The core technical factors worth examining include the following:

1. Speed & Performance – Markets move constantly, and the ability to react dynamically to changing market conditions is essential.
   
2. Flexible Liquidity Expression – Traders need to express their views on the market with maximal elasticity – via both the integration of related instruments and the specifics of preferred levels to buy and sell.
   
3. Market Information – All market information should be easily accessible by every trader without any embedded information asymmetries.

All three factors suggest a CLOB structure as the most effective exchange model. Unsurprisingly, CLOB exchange models predominate in both CEXs in crypto and exchanges in TradFi.

Orderbooks in DeFi aren’t new, either. Instead, their requirements for optimized performance aren’t well-suited for an on-chain environment. The limitations of on-chain orderbooks are primarily a function of blockchain-native elements, including:

1. Scalability – Most blockchains are not scalable enough for a fully on-chain orderbook. Even on high-TPS blockchain networks, block times are significantly inferior to centralized processing models. Broadly, blockchains are effective at minimizing trust for composing financial transactions on permissionless networks rather than being optimized for trading performance – with the veracity of consensus being the foremost cap on scalability. Gas fees also hamper the countless variables that market makers need to adjust for when providing liquidity over the course of a trading day.
   
2. Low Latency – Traders want to place, cancel, and view the results of trades on the order of milliseconds. On-chain latency, as a function of block consensus across a distributed node infrastructure, is orders of magnitude behind TradFi standards, which introduces vulnerabilities to risk mechanisms.
   
3. MEV and Front-Running – Validators can rearrange and front-run transactions via “pay-for-play” models with third parties to opportunistically extract value from pending transactions in the mempool. The result is further complexity for DeFi traders, who face the daunting threat of sophisticated and competitively superior MEV bots – a true “Dark Forest.” MEV adds no tangible value to most market participants and is more value-extractive than anything except for bespoke MEV operators and validators. However, the value of MEV is constrained by the ability to reorder transactions between blocks. The longer the block time, the bigger the potential MEV extraction.

The prevailing DEX solutions in DeFi orient around two well-known concepts.

The first includes utilizing AMMs as passive retail trading venues where latency and scalability are ignored, and MEV is rife. Despite the overwhelming problems, AMMs remain dominant compared to other DEXs, with Uniswap alone still accounting for more than 68% of DEX trading volume in the past 7 days. It seems counterintuitive, but what’s evident is that the irresistible appeal of passive LP’ing and accessing long-tail DeFi token support renders the disadvantages of on-chain AMMs virtually mute. The people simply like to speculate – whatever the cost.

The second idea is to circumvent on-chain shortcomings entirely via off-chain orderbooks. Trade matching is performed off-chain on independent nodes from the blockchain network, while execution of trades and custody of assets remain on-chain. It’s an attempt to preserve the self-custodial benefits of DeFi while bypassing its performance and risk (i.e., MEV) boundaries.

But what if you could unify the performance benefits of off-chain order matching with the persistently strong demand for the passive LP’ing and long-tail asset support on-chain? And further, what if you could spice it up with cross-margined accounts for spot, perps, and money markets instead of siloed products?

Enter Vertex.

Vertex’s core protocol is a fully on-chain trading venue (constant product AMM) with an off-chain orderbook, known as the “sequencer,” layered on top. The risk engine is fully contained on-chain (on Arbitrum), and settlement execution is also entirely executed on-chain. Vertex’s default state is the execution of the on-chain AMM for trades, but with an off-chain sequencer, traders can plug into the Vertex API and conduct trades directly from a lightning-fast orderbook matching engine with speeds of 10 - 30 milliseconds – competitive with most CEXs.

The AMM’s pool liquidity is injected into the off-chain orderbook, offering deeper liquidity, tighter spreads, and lower slippage for traders on a much broader set of token pairs than a conventional matching engine can deliver. Consequently, traders can flexibly express liquidity preferences with both optimal performance and minimized information asymmetries.

Users interact with Vertex the same way they interact with any decentralized protocol like Uniswap or Aave. However, with a sequencer-maintained orderbook, traders can place, manage, and view orders on a performance scale similar to that of CEXs, with cross-margining accounts for spot, perpetual swaps, and borrowing and lending on a money market.

Summarily, Vertex offers the performance and features of popular CEXs while preserving the on-chain advantages of DeFi. The attendant benefits of AMMs and off-chain order books are expressed while the scope of their drawbacks compresses.

While most difficult problems in crypto ultimately end up depicted as “trilemmas,” Vertex resolves the outstanding issues affecting exchange venues in crypto with a “trifecta” of design considerations derived from past lessons.

• Passive liquidity & long-tail asset support of AMMs.
• Off-chain order book performance on par with CEXs.
• Non-custodial & transparent on-chain risk engine.

Let’s dive deeper into the plumbing of Vertex’s design.  

Hybrid OrderbookAMM: Bringing Performance to DeFi

Vertex’s design can be broken down into three pillars:

• A fully on-chain trading venue (constant product AMM) – protocol level.
• A fully on-chain risk engine – protocol level.
• An off-chain sequencer for order matching.

Graphical Overview of Vertex Technical Design

Traders can interact with Vertex the same way they would with any other DeFi protocol, such as Uniswap or Aave. However, Vertex’s sequencer will combat issues of scalability, latency, and front-running to deliver a competitive trading experience to CEXs.

The hybrid orderbook-AMM design has numerous advantages for Vertex users. Namely:

• Improved Execution – Market makers can quote at smaller ticks with less risk to provide tighter prices and less slippage.
  
• Inclusive – AMMs offer the ability for retail users to provide passive liquidity and participate in market-making and yield farming strategies that beget the persistent popularity of DEXs like Uniswap.
  
• Trustless – The AMM provides an alternative, default pathway to trade even if the sequencer orderbook goes down.

The sequencer never has control over user assets, but with an AMM back-stop, Vertex can guarantee:

1. The sequencer has no ability to censor transactions; users can force their transactions to be included on the underlying chain (Arbitrum).
   
2. The sequencer cannot stop trading or withdrawals; users can still trade (on the AMM) and withdraw by going directly to the underlying chain (Arbitrum).
   
3. Users do not need to trust the sequencer to report accurate optimistic states; they can wait for confirmations directly on the underlying chain (Arbitrum).

See the “Slo-Mo Mode” section further below for more details on the sequencer.

Implementation - How Does it Work?

The x*y=k pools architecture of AMMs is adopted for both spot and perp markets. Traders can provide liquidity to different pools:

• Perps – single-sided USDC (vAMM).
• Spot – provide both the asset and quote (borrowing enabled) – AMM.

The pooled liquidity will sit alongside the bids and asks on the Vertex orderbook, effectively another market maker contributing to liquidity via smart contracts rather than API.

The AMM liquidity is subsequently combined with liquidity from automated traders via the sequencer, and users trade against this unified source of liquidity.

Trades are always executed at the best possible price, meaning a trade could fill against both limit orders and LP positions concurrently as the sequencer automatically sources the best liquidity available.

More granularly:

• LP positions are split along the orderbook according to x*y=k and the minimum tick size of any given market.
• The liquidity at any given tick is then pooled alongside bids and offers submitted to the orderbook as liquidity is displayed to traders.

This creates several benefits for traders:

• There will always be some liquidity to clear trades against.
• Markets can be seeded with more passive liquidity but also have more flexibility with limit orders – this benefits both illiquid and liquid assets.
• Traders can always trade permissionlessly on-chain without using the sequencer if they wish.

Trade Execution Example

The unified AMM + Orderbook liquidity design is compelling for traders looking to execute trades at performant execution speeds and tiny spreads.

For example, take a look at the scenario below:  

• ETH-USDC pair trading at $1,200.
• Alice (trader) is looking to market buy 75 ETH.
• Alice sets her max slippage to 1%.
• There is 25 ETH worth of asks on the orderbook at a price of $1,200.
• Therefore, ⅓  of the trade is filled at $1,200.
• The next set of asks (50 ETH worth) is sitting at $1,210.
• However, there is 25 ETH worth of LP positions sitting between $1,200 - $1,210.
• The next ⅓ of the trade is purchased from LP positions and filled at a price range of $1,200 - $1,210.
• The last ⅓ of the trade is executed at a price of $1,210, buying up 25 out of the remaining 50 ETH at that price.

Conversely, the same design benefits market sellers by reducing slippage and price impact on the available liquidity.

Slo-Mo Mode

The orderbook is Vertex’s primary edge in the context of a performant trading engine. However, in the case of maintenance, downtime, or other unforeseen circumstances, the AMM integration functions as the backstop of the protocol, enabling users to trade solely against the AMM without needing the orderbook.

It’s called “Slo-mo Mode,” and it's Vertex’s default state. Instead of CEX-like order book performance and liquidity, you’d be getting a Uniswap-style experience but with cross-margined accounts for spot, perps, an integrated money market, and lower fees on Arbitrum.

But let’s analyze the sequencer deeper anyways.  

The Vertex sequencer, in theory, could front-run transactions as an independent node matching inbound orders. But for various reasons, front-running is utterly irrational.

For example, let’s examine what happens under two situational assumptions:

1. The Sequencer is Honest
2. The Sequencer is Dishonest

Sequencer is Honest

The sequencer maintains an order book, and traders can place orders on a scale similar to centralized exchanges. Traders can trust the sequencer to report accurate optimistic states  – similar to Arbitrum as an ETH L2. This means they receive feedback on their orders with similar latency to centralized exchanges.

Traders can trust the sequencer to order transactions fairly. Validators on the underlying chain (Arbitrum’s L2 for ETH) cannot reorder or front-run transactions.

The sequencer model can eventually be expanded to include a decentralized set of sequencer nodes via governance. For example, sequencer nodes could be configured in a manner resembling a randomized round-robin style blockchain consensus where a leader node proposes a catalog of transaction ordering, verified by other sequencer nodes.

The latter design would marginally raise latency for inbound order matching. But the decision is ultimately left to Vertex’s community governance to weigh the benefits of improved latency vs. the costs of having a single sequencer node.

Sequencer is Dishonest

The sequencer still has no custody over user assets – this is done on smart contracts on the underlying chain Arbitrum. The sequencer still cannot censor transactions either; users can force their transactions to be included on Arbitrum. Remember, Vertex’s default state is the on-chain AMM – not the sequencer.

The sequencer also has no ability to stop trading or withdrawals, meaning users can still trade (on the AMM) and withdraw by going directly to Arbitrum. Nor can the sequencer reorder transactions, which is a better security model than the underlying blockchain – validators can already do this via MEV on L1 ETH.

Users do not need to trust the sequencer to report accurate optimistic states either. They can wait for confirmations directly on the underlying chain – Arbitrum. Finally, the sequencer is subject to governance, meaning that governance can vote to remove the sequencer as the off-chain order book matching engine in favor of “Slo-Mo Mode.”  

It’s also worth denoting MEV as a concept when extrapolated to markets outside of crypto for more clarity on a complex topic.

Extracting value from pending orders is also common in TradFi, just more convoluted and not under the ominous actions of MEV bots. For example, selling retail order-flow data to HFTs, like with Robinhood and Citadel, is technically analogous to MEV. However, it’s a polarizing topic because it’s both prevalent in TradFi and touted as a mechanism for better market efficiency.

Of note, Arbitrum, as an L2 on Ethereum, also minimizes MEV anyways since it submits batches of transactions to Ethereum L1 periodically. As a result, in both contexts where Vertex is either functioning with an off-chain sequencer or in its default on-chain state, MEV is minimized, basically mitigating one of the key shortcomings of on-chain DEXs illustrated earlier.    

With the above in mind, front-running transactions with the sequencer is also irrational for two other logical reasons:

1. Front-running would be immediately identifiable by HFTs and other traders plugging into the Vertex API, extinguishing their trust in the sequencer and heavily reducing liquidity for Vertex moving forward.
   
2. Correlated to the first point, Vertex’s primary advantage in latency performance on par with CEXs would be eliminated, nuking a core value proposition of Vertex.
3. Since Vertex sequencers would be forced to operate on millisecond timescales (<20ms for a response), it’s much more difficult, and extracting MEV is less valuable. There’s a general tradeoff between latency & MEV ability – deciding the trade-off’s output is left to governance.

Lastly, while Vertex will operate the initial sequencer upon mainnet launch, Vertex governance can elect a sequencer responsible solely for ordering transactions – meaning it doesn’t have to be the node run by Vertex.

Governance will enable users to decentralize the sequencer node set too.

Again, even if the sequencer node goes down, trading simply reverts to the default state AMM on-chain on Arbitrum – Slo-Mo Mode. Users can still swap assets, open and close perp positions, and interact with the rest of the Vertex protocol, just with increased latency and tighter liquidity analogous to trading on Uniswap with more slippage and wider spreads susceptible to larger market-moving orders.

Key Takeaways:

• The sequencer orders transactions but cannot forge them and does not have custody of user assets. If the sequencer is dishonest, users can automatically fall back to the decentralized smart contracts on Arbitrum. Funds are never at risk.
• If the sequencer is honest, Vertex performs similarly to centralized exchanges.
  

Eventually, a distributed sequencer model can even be translated across EVM-compatible chains, providing a decentralized liquidity layer for DeFi applications between diverse ecosystems.

Food for thought.

—--

Don’t forget to join the Vertex community!

Discord: https://discord.com/invite/vertexprotocol

Twitter: https://twitter.com/vertex_protocol

Website – vertexprotocol.com

Public Testnet App – app.vertexprotocol.com

LinkTree – https://linktr.ee/vertex_protocol