T-DEX: Redefining DEXs with ππ·
by Can Kisagun, CEO & Co-founder of ππ·
Decentralized Exchanges (DEXs) have emerged as the most vigorous use case in blockchain applications, enabling trustless and permissionless value exchange.
Over the last 4 years, DEX trading volumes have grown significantly, from $12.5bn to $300bn[1]. While DEXs offer a self-custodial alternative to centralized exchanges (CEXs)βwhich have faced, and will likely continue to face, issues such as custody risks (loss of user funds) and lack of transparencyβthe execution quality of DEXs remains notably inferior to that of CEXs.
Liquidity and its efficient allocation around the price determine execution quality in an exchange.
First, blockchains do not match the speed of CEXs, which can update orders continuously. Short block time of rollups is an improvement over Ethereum. However, the discrete nature of blockchains means that prices get stale compared to CEXs. As a result, liquidity allocation will be less efficient on a DEX.
Second, the liquidity fragmentation in the broader Ethereum ecosystem exacerbates this situation:
Ethereum DEXs benefit from high liquidity but suffer from inefficient allocation due to the high (transaction) cost of on-chain liquidity management.
Rollup DEXs offer more efficient liquidity management due to lower gas costs but are constrained by significantly lower liquidity.
As of December 11, 2024, DEX TVL on Ethereum is $8.6bn vs $3.2bn combined DEX TVL of the top 3 rollups (Arbitrum, Base and Optimism). Similarly, DeFi TVL on Ethereum is 75.3bn vs. $8.1bn DeFi TVL of the top 3 rollups.
To address these inefficiencies and achieve near-CEX-level execution quality while preserving self-custody, we are incredibly excited about DEXs powered by ππ·. Built on real-time proving capabilities, ππ· native DEXs can provide low-cost execution and seamless access to Ethereum and EVM ecosystem liquidity.
Furthermore, we introduce T-DEX, a hybrid DEX that combines the strengths of Automated Market Maker (AMM) and Request-For-Quote (RFQ)-based DEXs into an on-chain order book and matching engine that runs frequent batch auctions (FBAs) every second on ππ·. T-DEX is our attempt at addressing DEX inefficiencies we observed in Ethereum and the rollup ecosystem. T-DEX is one of many DEX designs that can be empowered by ππ·.
Iβd like to thank Wee Howe, Tokka Labs team, Andrea Candido, Guy Wuollet, David Hsu, the PNYX team, Miko Glinka, and Orest Tarasiuk for their invaluable feedback and contributions.
I also want to acknowledge the Flashbots Research Proposals (FRPs) grant program, which funded my research on the current DEX landscape and Quintus.
The State of Decentralized Exchanges: AMMs and RFQ DEXs
We are going to make a couple of statements in this section. If youβd like to read more about these, please refer to the Appendix section.
AMMs
AMMs enable continuous liquidity and an automated price discovery and execution mechanism, which are well-suited for blockchains. AMMs also work exceptionally well with long-tail assets.
However, AMMs come with their problems:
Providing liquidity in AMM DEXs is unprofitable:
AMM liquidity today is inefficiently allocated due to the expensive and manual nature of managing liquidity positions. Providing wide ranges reduces manual intervention and gas fees, however it also reduces LP profitability. This query showed that only 12% of liquidity was within +/-2% of the market price for the ETH - USDC 5bps pool.
AMM LPs lose value to Loss-Versus-Rebalancing (LVR), a latency arbitrage. LVR, a fancy name for price sniping, is caused by the difference in price update frequency between DEXs and CEXs.
These problems are exacerbated by Ethereum, which has higher transaction costs and longer block times. On top of this, liquidity fragmentation creates further inefficiencies in liquidity allocation across the broader Ethereum ecosystem.
Trading on AMMs is expensive due to:
slippage due to lack of liquidity and inefficient capital allocation (as explained above)
slippage due to adversarial ordering (sandwich) attacks that are enabled by the public nature of orders
RFQ (Request for Quote) DEXs
AMMs inefficiencies introduced a trade-off between efficiency and decentralization.
RFQ DEXs connect traders with professional market makers (PMMs) through an off-chain auction mechanism, enabling on-chain settlement of funds. Off-chain auctions create an efficiency gain by outsourcing the expensive on-chain price matching (price discovery) and allowing efficient liquidity allocation free of transaction fees. Yet these auctions sacrifice pricing transparency and create a single point of failure.
RFQ DEXs also eliminate slippage due to adversarial ordering attacks.
Today, most RFQ protocols require PMMs to quote bid/ask spreads valid for at least 20-30 seconds. This is primarily due to UX considerations because execution is not automatic, and the taker (i.e., swapper) needs to manually sign an order or submit a transaction on-chain. This delay requires PMMs to quote spreads for a longer duration and price-in volatility risk. This is an important detail because the longer the delay, the higher the volatility risk. As a result, a PMMβs bid/ask spreads on RFQ DEXs are less competitive than their spreads on CEXs, which can update in milliseconds and where execution is automatic.
However, RFQ protocols have disadvantages as well. In addition to relying on off-chain components, RFQ DEXs also provide limited support for long-tail assets, as PMMs are reluctant to hold long-tail assets. For example, PMMs account for 35% of ETH-stable swap fill volume but only 20% of all fills [6] .
To recap, providing liquidity on AMMs by default is unprofitable or requires a lot of operational overhead and expense. Since liquidity is scarce and inefficiently allocated, using AMMs to swap assets provides suboptimal pricing. RFQs offer a more efficient trading alternative. However, RFQs rely on off-chain components that lack transparency and donβt provide coverage for long-tail assets.
The question is: Can we do better? We believe with ππ·, we can!
Why are DEXs is Uniquely Empowered by ππ·
ππ· introduces real-time proving (RTP), enabling instant withdrawals and seamless composability with Ethereum and other rollups. RTP proves the integrity of ππ· execution to Ethereum in less than 12 seconds, allowing near-instant settlement between ππ· and Ethereum.
This frictionless bridging and withdrawal experience allows DEXs on ππ· to provide a UX similar to interacting with smart contracts on the L1. RTP is made possible by leveraging the verifiable computation guarantees of Trusted Execution Environments (TEEs). For a deep dive into ππ·βs architecture check out this post.
ππ·βs 1s block time will reduce LVR, also known as CEX-DEX arbitrage. Reduced arbitrage means improved profitability for liquidity providers.
ππ·βs programmable order execution engine enables significant efficiency gains for PMMs and creates a favorable environment for order-book DEXs. This allows PMMs to broadcast their updated bid/ask spreads (maker orders) every ππ· block (1 second) and automatically fill taker demand. In trusted RFQ DEXs on Ethereum, either the taker (swapper) or the maker (PMM) gets the last look. This manual process forces PMMs to quote longer and price in volatility.
By utilizing the verifiable computation guarantees of TEEs and full nodes, ππ· can allow DEXs to develop innovative vault models that automate retail liquidity positions based on DEX prices across multiple ecosystems. This would enable retail LPs to enjoy higher returns without sacrificing user experience.
In addition, running partner rollup full nodes within the t1 node infrastructure allows ππ· DEXs to complement cross-chain swap enabled by ERC-7683. This means ππ· can become a liquidity hub for solvers, and the liquidity on t1 can be used to fill demand on Ethereum and different rollups. We will have another post that explores this design space in-depth. Stay tuned!
Given that withdrawals to Ethereum (or partner rollups) only take one (or a few) L1 blocks respectively, PMMs can keep their funds on t1 and fill the order flow on different rollups. This is a significant improvement over the status quo of fragmenting funds across different rollups and resorting to centralized exchanges for bridging.
To summarize, ππ· DEXs will have seamless access to L1 liquidity and low-cost capital management properties of rollups to maximize capital efficiency and therefore provide superior DEX execution.
Introducing T-DEX
T-DEX is a hybrid design that combines strengths of AMMs and RFQ DEXs to reduce the cost of trading for swappers (takers) and increase profitability for LPs (makers). Enabled by t1βs ability to produce real-time proofs and settle instantly on Ethereum, T-DEX can offer a βbridge-lessβ, low cost trading experience.
We expect T-DEX to provide improved profitability for liquidity providers:
Passive LPs will benefit from shorter execution times, which reduce the value lost to CEX-DEX arbitrageurs. LVR is further reduced by using FBA execution; on AMMs like Uniswap, a single (the top of the block) transaction captures all the arbitrage between Uniswap and Binance. However, in FBA execution, the arbitrage is distributed across all parties trading in that block.
T-DEX will also provide a better UX for active liquidity management by enabling low-cost position management and automated LP management vaults.
Market makers can quote bid/ask spreads for 1s instead of 24s. Our design partner, Tokka Labs, believes this will allow them to provide 4x tighter quotes compared to UniswapX.
T-DEX will also provide improved execution for swappers: Improved LP profitability and capital allocation efficiency will reduce slippage and lower the cost of trading. Furthermore, FBA execution prevents adversarial ordering (sandwich) attacks.
The combination of low-cost trading and the ability to natively withdraw funds back to Ethereum in the next block is unique! It provides a user experience similar to trading on a CEX while letting you keep custody of your assets.
Now letβs dive into how T-DEX works:
Users deposit funds to t1 deposit contracts on Ethereum or partner rollups and send t1 transactions representing orders or liquidity positions to the T-DEX contract on t1.
T-DEX contract manages the orderbook, runs Frequent Batch Auction (FBA) trade execution logic every second and updates user balances on t1. Combined with ππ·βs real-time proving capability and solvers, a user with funds on Ethereum can swap on T-DEX and receive their funds back in their Ethereum wallet within a single Ethereum blockβall while ππ· remains fully abstracted from the user. We will share more on this later!
Now, letβs get into the design of T-DEX:
Orderbook
T-DEX order book combines liquidity positions from private market makers (i.e., RFQ model with bid-ask spreads) and retail users (i.e., Uniswap V3-like concentrated liquidity). This model is designed to accommodate efficient liquidity for major pairs by market makers and also long-tail liquidity by retail LPs.
PMMs send their bid/ask spreads for a trading pair with a customizable, but ideally single block (1s), expiry condition. Retail users can either send passive liquidity positions to T-DEX or use automated liquidity management strategies (vaults) to opt in for a third party (possibly a Market Maker) to manage their positions actively.
T-DEX contracts on t1 update the order book every block, i.e. every second. T-DEX thus creates a decentralized orderbook and enables permissionless access to retail liquidity and market makers.
Since we donβt rely on off-chain guarantees, we do not need to introduce walled gardens or high capital requirements to participate as a market maker.
We also support a hybrid design that includes retail liquidity because PMMs do not cover long-tail assets, and passive LP ensures price discovery independent of market makers.
Matching engine
T-DEX runs Frequent Batch Auction (FBA) trade execution every second. FBA executes all orders in the money at the clearing price, which maximizes traded quantity.
Therefore, all trades for a given pair execute at the same price in a block. Uniform price execution creates two significant benefits. First, FBA reduces the cost for traders as it eliminates slippage due to sandwich attacks. Second, FBA also increases profitability for LPs as it reduces CEX-DEX arbitrage potential.
In the first version of our devnet, which will be released in Q1 2025, next to Ethereum, we will also be running an Arbitrum full node within the t1 sequencer and deploying a t1 bridge contract to Arbitrum to enable Arbitrum users and applications to swap using T-DEX.
Currently, we are running an early version of T-DEX on our devnet. This version is more like an RFQ DEX that runs on t1, as support for retail liquidity positions is currently under development.
There are a couple of interesting directions we are exploring for T-DEX UX. The first is integrating ERC-7702 for gasless trading. This will allow the T-DEX operator to cover gas costs associated with placing orders. This could be extended to all t1 users and applications. We also aim to empower a user, Alice, with funds on Ethereum or a partner rollup (but not t1) to complete a swap using T-DEX in a single block.
Given real-time proof and the subsequent block withdrawals to Ethereum, T-DEX will become the hub for PMMsβ liquidity to fill the L2 orderflow.
We aim to position T-DEX as the most efficient spot EVM orderbook that can fill swapper demand in different rollups using standards like ERC-7683.
Conclusion
Given its real-time proving (RTP), we expect DEXs on ππ· to provide the most efficient capital allocation in the Ethereum ecosystem. We are excited about how ππ· DEX can create seamless cross-chain trading experiences. We propose a Proof-of-Concept DEX called T-DEX. T-DEX is a permissionless hybrid DEX powered by ππ· that facilitates cross-chain transactions and improves the profitability of both takers and makers.
To learn more about t1:
Follow us on Twitter: Stay updated on the latest news and announcements.
Join our Discord: Connect with the community and ask questions.
Subscribe to our Substack: Receive in-depth articles and insights.
For Market Makers:
Interested in T-DEX? Fill out this form to provide feedback or explore integration opportunities.
For Developers:
Want to build a DEX on ππ· or contribute to T-DEX? Fill out this form or join our Discord to get involved.
Have dApp ideas? Create an issue on our Github page explaining your application and how t1 uniquely enables it.
Want to try T-DEX?
Explore our Devnet: Follow the instructions on our devnet portal to get started.
Get Devnet funds: Join our Discord for instructions.
Appendix
The State of Decentralized Exchanges: AMMs and RFQ DEXs
AMMs
While trading in traditional markets is mostly done on continuous limit order book (CLOB) exchanges, automated market makers (AMMs) emerged as the primary form of exchange in DeFi, as running an on-chain order book, sorting and matching orders are highly inefficient given blockchains' computational and storage limitations.
AMMs enable continuous liquidity and an automated price discovery and execution mechanism, which are well-suited for blockchains. AMMs also work exceptionally well with long-tail assets.
However, AMMs come with their problems:
Providing liquidity in AMM DEXs is unprofitable
AMM liquidity today is inefficiently allocated due to the expensive and manual nature of managing liquidity positions. Pioneered by Uniswap v3, current AMMs allow users to provide liquidity over a specific price range.
A userβs liquidity position is only active and earns trading fees within that specified price range. As a result, users are incentivized to choose wider ranges and make sure they are earning fees without the need to track and update their positions actively.
However, liquidity providers (LPs) collect trading fees proportional to their liquidity share at the execution price.
Therefore, wider liquidity positions reduce the need for active position management; they also reduce LP profitability.
This introduces a trade-off between ease of use and profitability.
We ran this query on data between December 5 - December 12, 2024, to reconstruct the share of liquidity within +/- 2% of the market price on UniswapV3 WETH-USDC pools in a given block.
This analysis showed that only 12% of liquidity was within +/-2% of the market price for the ETH - USDC 5bps pool, which was the largest UniswapV3 pool by trading volume at the time. While there are no industry-accepted benchmarks for this, we would expect higher liquidity concentration around the trading price.
While there are automated liquidity management tools like Arrakis Finance, these tools are mostly used by foundation treasuries.
Furthermore, AMM LPs lose value to Loss-Versus-Rebalancing (LVR), a latency arbitrage. LVR, a fancy name for price sniping, is caused by the difference in price update frequency between DEXs and CEXs.
DEX prices update every block (a few seconds in most rollups and 12 seconds on Ethereum), whereas CEX prices update continuously. As a result, DEX prices become stale compared to CEX prices and provide an arbitrage opportunity at the expense of the LPs.
The larger the time difference (latency advantage), the bigger the value lost to arbitrage. Milionis et al. [2] showed that reducing block times creates a square root reduction in LVR.
In other words, 4x faster block times can reduce the LVR by a factor of 2. LVR is not a phenomenon thatβs unique to blockchains. In traditional markets, hedge funds invest millions of dollars in their infrastructure to gain 1 ms of advantage to arbitrage against stale prices before other market participants can cancel their orders.
Budish et al. suggest Frequent Batch Auction-style execution to minimize LVR [3]. In Frequent Batch Auction execution, all trades for a given pair execute at the same price within a discrete time window (i.e., one block in blockchains or 100ms window in traditional markets).
This eliminates the advantage of having a 1 ms edge and disincentivizes the latency arms race.
These problems are exacerbated by Ethereum, which has higher transaction costs and longer block times. Since liquidity provision is unprofitable for most retail LPs, AMMs fall short of their potential to attract more liquidity.
On top of this, liquidity fragmentation creates further inefficiencies in liquidity allocation across the broader Ethereum ecosystem. All these make trading on AMMs more expensive.
Trading on AMMs is expensive due to:
slippage due to lack of liquidity and inefficient capital allocation (as explained above)
slippage due to adversarial ordering (sandwich) attacks that are enabled by the public nature of orders
A recent paper by Adams et al. [7] that analyzes the cost of trading on the highest volume Uniswap pool ETH-USDC (0.05% fee) suggests that the average cost of trading for ETH-USDC pairs is 22bps, which is more than twice the cost of trading on Binance for a retail trader having no preferential trading fees.
Note that this comparison does not account for deposits and withdrawals transaction fees to Binance, which is less than the gas fee of swapping on Uniswap v3.
RFQ (Request for Quote) DEXs
AMMs inefficiencies introduced a trade-off between efficiency and decentralization.
RFQ DEXs connect traders with professional market makers (PMMs) through an off-chain auction mechanism, enabling on-chain settlement of funds. Off-chain auctions create an efficiency gain by outsourcing the expensive on-chain price matching (price discovery), yet they sacrifice pricing transparency and create a single point of failure.
There are two RFQ designs, RFQm and RFQt, where m and t refer to who gets the last look.
In RFQm, the market maker receives the last look in RFQm (e.g., UniswapX). A user, Alice, is shown a price quoted by the winning market maker (from the off-chain auction), and she signs an intent to trade at that price (minus some slippage limit). After that, the winning market maker can choose to fulfill Aliceβs intent and send the transaction on-chain. In this setup, Alice doesnβt have to pay any gas fees (directly).
In RFQt (e.g., 0x RFQ, Hashflow), the taker gets the last look. Market makers provide binding quotes for a given duration, and Alice has the option to confirm the trade at that price and is responsible for submitting the TX on-chain.
RFQ DEXs improve execution as PMMs are able to offer the most up-to-date liquidity positions (bid-ask spreads) without incurring any on-chain gas cost.
Furthermore, the RFQ model eliminates ordering-related (i.e., sandwiching attacks) slippage as the price discovery takes place off-chain, and the price doesnβt depend on the position of the swap in the block. These ensure that RFQ DEXs can provide better execution to swappers.
Today, most RFQ protocols require PMMs to quote bid/ask spreads valid for at least 20-30 seconds. This is primarily due to UX considerations because execution is not automatic, and the taker (i.e., swapper) needs to manually sign an order or submit a transaction on-chain. This delay requires PMMs to quote spreads for a longer duration and price-in volatility risk. This is an important detail because the longer the delay, the higher the volatility risk. As a result, a PMMβs bid/ask spreads on RFQ DEXs are less competitive than their spreads on CEXs, which can update in milliseconds and where execution is automatic.
However, RFQ protocols have disadvantages as well. In addition to relying on off-chain components, RFQ DEXs also provide limited support for long-tail assets, as PMMs are reluctant to hold long-tail assets. For example, PMMs account for 35% of ETH-stable swap fill volume but only 20% of all fills [6] .
CowSwap: Itβs essential to discuss Cowswap, which is the first FBA DEX that leverages both on-chain AMM liquidity and off-chain PMM liquidity. By tapping into both liquidity sources, CowSwap delivers high execution quality for both major and long-tail token pairs.
Since FBA ensures all trades in a given block execute at the same price, Cowswap eliminates adversarial ordering (sandwich) based slippage.
References
[1] The Block, βDecentralized Finance (DeFi) / DEX (Non-Custodial),β The Block, 2024. [Online]. Available: DeFi Exchange Data and Charts for DEXs, AMMs and Swaps. [Accessed: Dec. 03, 2024].
[2] J. Milionis, C. Moallemi, T. Roughgarden and A. Zhang, βAutomated Market Making and Loss-Versus-Rebalancing,β. arXiv:2208.06046 , 2023. [Online]. Available: https://arxiv.org/pdf/2208.06046.pdf
[3] E. Budish, P. Cramton, and J. Shim, βThe High-Frequency Trading Arms Race: Frequent Batch Auctions as a Market Design Response,β The Quarterly Journal of Economics, vol. 130, no. 4, pp. 1547β1621, Nov. 2015. [Online]. Available: https://academic.oup.com/qje/article/130/4/1547/1916146
[Source 3] [12] A. Adams, B. Chan, S. Markovich and X. Wan, βThe Costs of Swapping on the Uniswap Protocol,β arXiv:2309.13648v1, 2023. [Online]. Available: https://arxiv.org/pdf/2309.13648.pdf
[4] OrderFlow.Art, βOrderflow Visualization for CowSwap with Specific Pairs,β [Online]. Available: https://orderflow.art/?isOrderflow=false&metaAggregator=Cowswap&pairs=USDC-WETH&pairs=USDT-WETH&pairs=WBTC-WETH&pairs=USDT-WBTC&pairs=DAI-WETH&pairs=USDC-WBTC&pairs=DAI-WBTC&pairs=ETH-USDC&pairs=ETH-USDT&pairs=DAI-ETH. [Accessed: Dec. 12, 2024]
[5] OrderFlow.Art, βOrderflow Visualization for CowSwap,β [Online]. Available:
https://orderflow.art/?isOrderflow=false&metaAggregator=Cowswap. [Accessed: Dec. 11, 2024]
[6] OrderFlow.Art, βOrderflow Visualization for Various Builders and Pairs,β [Online]. Available: Link [Accessed: Dec. 12, 2024].
[7] A. Adams, B. Chan, S. Markovich and X. Wan, βThe Costs of Swapping on the Uniswap Protocol,β arXiv:2309.13648v1, 2023. [Online]. Available: https://arxiv.org/pdf/2309.13648.pdf