lukewasm.eth

Unveiling Intelligent DeFi: The Coprocessor Revolution

lukewasm@newsletter.paragraph.com (lukewasm.eth) — Fri, 23 Feb 2024 10:26:58 GMT

Special thanks to @0xkrane, @atiselsts_eth, Avi from @nil_foundation, @ChundaMcCain, @IsdrsP, @Li_Steven1, Maki and @Phil_Kelly_NYC from @o1_labs and @yilongl_megaeth for their invaluable discussions, insights, and feedback on this article!

Introduction

Today’s decentralized apps face limitations in performing complex on-chain computations due to blockchain’s restricted processing capabilities. However, with the rapid development of technologies such as blockchain coprocessors, in conjunction with game theory and mechanism design, a new wave of use cases emerge to greatly improve user experience.

This article explores the design space of coprocessors, with a focus on potential use cases they empower.

Key takeaways:

Blockchain computation is expensive and limited; one solution is to move computation off-chain and verify the results on-chain through coprocessors, enabling more complex dapp logics.
Coprocessors can be categorized into trustless (ZK), trust-minimized (MPC/TEE), optimistic, and cryptoeconomic based on their security assumptions. These solutions could also be combined to achieve desired security vs efficiency tradeoff.
Different types of coprocessors are suited for different tasks in DeFi. Potential use cases cover DEX (AMM & orderbook), money markets, staking, restaking, etc.
With the rise of decentralized AI, together with coprocessors, we are entering a new era of “Intelligent DeFi”.

The Role of Coprocessors

Blockchain is commonly viewed as a general-purpose CPU virtual machine (VM) that may not be ideal for heavy computations. Tasks involving data-driven analysis and intensive computations often necessitate off-chain solutions. For instance, orderbook exchanges like dydx v3 utilize off-chain matching and risk engines running on centralized servers, with only fund settlements taking place on-chain.

In computing, coprocessors are introduced to assist processors in performing specific tasks, as indicated by the prefix 'co-'. For instance, GPUs serve as coprocessors for CPUs. They excel at handling parallel computations required for tasks like 3D rendering and deep learning. This arrangement allows the primary CPU to concentrate on general-purpose processing. The coprocessor model has empowered computers to handle more complex workloads that would not have been feasible with a single, all-purpose CPU.

By leveraging coprocessors and accessing on-chain data, blockchain applications can potentially provide advanced features and make informed decisions. This creates opportunities for conducting additional computations, enabling the performance of more complex tasks and allowing applications to become more "intelligent".

Different Types of Coprocessors

Based on trust assumptions, coprocessors could be classified into mainly three different types- Zero-Knowledge (ZK), Optimistic, and Cryptoeconomic.

ZK coprocessors, if implemented correctly, are theoretically trustless. They perform off-chain computations and submit on-chain proofs for verification. While they provide speed, there is a trade-off in terms of proving cost. As custom hardware advances and cryptography develops, the final cost passed on to end-consumers could potentially be reduced to a more acceptable level.

Axiom and RISC Zero Bonsai are examples of ZK coprocessors. They allow arbitrary computation with access to the on-chain state to be run off-chain and provide proofs that the computation was performed.

To provide a clearer understanding of how a typical ZK coprocessor operates, let's examine the workflow of RISC Zero Bonsai.

Applications send coprocessing requests to Bonsai Relay, which then forwards the proof request to the Bonsai proving service. The RISC Zero zkVM executes the program and generates a proof to validate the correct execution of the code, which can be verified by anyone. Subsequently, Bonsai Relay publishes the proof on-chain, and the applications receive the results through a callback function.

Bonsai on Ethereum

While ZK coprocessor is one method for achieving verifiable off-chain computations, alternatives such as MPC and TEEs offer different approaches. MPC enables collaborative computing on sensitive data, while TEEs provide secure hardware-based enclaves. Each option comes with its own set of trade-offs between security and efficiency. In this article, we will focus on ZK coprocessors.

Optimistic coprocessors offer cost-effective solutions, but they suffer from significant latency issues (typically weeks). They require honest parties to effectively challenge them with fraud proofs within the challenging window. Therefore, the time to security guarantees are delayed.

Cryptoeconomic coprocessors are optimistic coprocessors with a large enough economic bond on execution and an on-chain insurance system which allows others to secure compensation for erroneous computation. This economic bond and insurance can be purchased through shared security providers like Eigenlayer. The advantage is instant settlement, but the downside is the cost of acquiring insurance.

Characteristics of Various Coprocessor Types

*There are proof generation times of less than a second out there (admittedly for small, optimized, proofs) and they're improving rapidly.

Different types of coprocessors exhibit distinct cost, latency, and security characteristics. Combining different types of coprocessors can lead to an optimized user experience. A standout example is Brevis. Initially launched with a zk-coprocessor, Brevis has now unveiled the Brevis coChain. This innovation combines crypto-economics and ZKP within a ZK coprocessor, resulting in reduced costs, minimized latency, and enhanced user experience.

Pure ZK coprocessors, in their current state, still present challenges such as high proof generation costs and scalability issues. This is because ZK proofs for data access and computation results are always generated upfront. Leveraging Eigenlayer’s restaking infrastructure, Brevis coChain enables dapps to tailor the level of crypto-economic security they desire, granting them greater flexibility to enhance the user experience. Here's a simplified explanation of how it operates.

Brevis coChain would first 'optimistically' generate a result to the coprocessing request based on PoS consensus. Then, two challenge windows initiate, one is application-specific and configurable by developers, and the other one is the longer global coChain slashing window.

Brevis coChain Workflow

During the application challenge window, observers can submit a ZKP contradicting the coprocessing results. Successful challenges slash the proposer and reward the challenger. Failed proposals lead to the challenger’s bond being forfeited.

If there are no challenges, the app will deem the results valid. The global coChain slashing window is there for enhanced security. Even if an app accepts a faulty result, as long as the coChain slashing window is open, malicious validators can be slashed and incorrect results can be rectified.

As different types of coprocessors exhibit distinct cost, latency, and security characteristics, applications must assess their requirements to determine the type of coprocessors they need. If the computation involves high-security tasks, such as calculating balances of validators on the Beacon chain in liquid staking where billions of dollars are at stake, ZK coprocessors are the most appropriate choice. They provide maximum security since the results can be verified trustlessly. Additionally, latency is not a concern in such scenarios, allowing for the generation of proofs within acceptable timeframes.

For tasks that are less latency-sensitive and don't involve significant financial value, such as showcasing on-chain achievement metrics on your social profiles, an optimistic coprocessor that offers the lowest off-chain computation could be preferable.

For other tasks, cryptoeconomic coprocessors prove more cost-effective when the purchased insurance covers the at-risk value. The analysis of insurance costs should be done on a case-by-case basis, heavily influenced by the value facilitated by the application. These tasks often entail diverse analytics and risk modeling.

Another way to categorize coprocessors is by computation type, with examples such as:

RiscZero, Succinct and =nil; for general computation,
Ritual and Modulus for AI,
SpaceandTime for database operations,
MegaETH for EVM computations, and more.

The use of coprocessors in DeFi is an emerging area that holds great potential. In the following, I will outline existing ideas and implementations on how coprocessors could be utilized in various sectors within DeFi including DEX, money markets, staking, restaking, etc.

DEX

There are multiple stakeholders involved in a DEX. These include traders, liquidity providers, market makers, liquidity managers, solvers/fillers, and more. Coprocessors have the potential to efficiently streamline complex tasks with different levels of trust assumptions, ultimately enhancing the experience for these stakeholders.

Cost Reduction

In a basic AMM, one important function is to compute the necessary parameters when users initiate a swap. These parameters include the amount to be swapped in and out, the fee, and the price after swapping. One straightforward use case to harness the computational power of zk-coprocessors while maintaining trust guarantees is to perform a portion of the swap function off-chain, and then complete the remaining steps on-chain. zkAMMs are a variant of Automated Market Makers (AMMs) that integrate zero-knowledge proofs in-protocol. Diego (@0xfuturistic) introduces an implementation of zkAMM (zkUniswap) based on Uniswap v3 where a portion of the AMM swap computation is offloaded to the Risc Zero zkVM. A user starts a swap by making a request on-chain, the swap inputs are picked up by the relayer, and the computation is carried out off-chain. The relayer then posts the output and the proof. The AMM verifies the proof and settles the swap.

While the computation cost is still comparable to that of EVM at the current stage, it is possible to achieve higher efficiency by parallelizing the computation of swaps with independent paths thanks to RiscZero’s continuation feature. Essentially, the execution of swaps can be done sequentially on-chain, but the actual swap steps can be computed in parallel off-chain using this approach. This enables the parallelization of the heaviest part for batches, which is not natively possible in the EVM. The cost of verification could also be amortized by batching multiple transactions together.

Users also have the option to use an alternative data availability layer to send swap requests. Another approach is to utilize EIP712 signature for off-chain propagation, which can further reduce swap costs.

Dynamic Parameters

Coprocessors could also be utilized to dynamically control the swap fee for an AMM pool. The concept of a dynamic fee is to increase the fee rate during periods of market volatility and decrease it during calmer market conditions. This serves as a benefit for passive liquidity providers, as they consistently take the unfavorable side of trades and experience value leakage through Loss-versus-rebalance (LVR). The implementation of dynamic fees aims to address this issue by adequately compensating LPs.

Some AMMs already have this feature. For example, Ambient utilizes an external oracle that monitors and takes snapshots of different fee tier Uniswap v3 pools every 60 minutes to choose the best performing one.

To provide further insights into adjusting the fee rate, additional data can be utilized, both on-chain and off-chain. This includes historical trades conducted on-chain for this particular AMM pool or for the same pair across various liquidity pools (such as the Ambient solution) or even pools on different networks. If certain trust assumptions are allowed, off-chain data (e.g. CEX trade data) from reputable oracles like Chainlink or Pyth, could also be introduced.

The decision on which types of coprocessors to use is influenced by how frequently the fee is adjusted. In cases where a pool requires very frequent dynamic fee changes, cryptoeconomic coprocessors may be more suitable. This is because the costs of proving are likely to outweigh the insurance costs, which can be estimated as the difference in fee rate multiplied by the average volume. In the event of any erroneous calculations, LPs can easily claim their insurance facilitated by Eigenlayer to compensate for their loss in fees.

On the other hand, there are pools that prefer less frequent fee rate changes. However, these pools handle very large volumes, which can drive up the cost of insurance buying. In such cases, ZK coprocessors are more suitable as they provide the strongest guarantee.

Active Liquidity Manager (ALM)

Passive liquidity provision can be an attractive option for less experienced users who want to earn fees from their idle liquidity without being overly concerned about price deviations. However, some liquidity providers (LPs) are more susceptible to losses caused by price deviations and statistical arbitrages. We previously discussed how adjusting fees dynamically could mitigate this issue. But why not go a step further and completely change the shape of the liquidity curve? This is a more sophisticated approach to liquidity management known as Active Liquidity Managers (ALMs).

Regrettably, the majority of existing ALMs only provide basic strategies like rebalancing, which have a limited impact on fee collection. On the other hand, slightly more advanced techniques such as hedging using money markets or derivatives are available. However, they either incur high costs when executed frequently on-chain or rely on centralized off-chain blackbox computation.

Coprocessors have the potential to tackle cost and trust issues, enabling the adoption of advanced strategies. By integrating with cutting-edge zero-knowledge machine learning (ZKML) solutions such as Modulus Labs and decentralized AI platforms like Ritual, liquidity managers can leverage complex strategies based on historical trade data, price correlations, volatility, momentum, and more while enjoying the advantages of privacy and trustlessness.

High-frequency trading strategies require precise timing and rapid execution. While ZK solutions may not always meet the necessary speed, cryptoeconomic coprocessors excel in this area. These coprocessors allow AI algorithms to be executed swiftly, with parameters updated as frequently as the block time allows. However, utilizing this approach comes with insurance costs. Accurately estimating these costs can be challenging due to potential risks like managers mishandling funds or engaging in counter-trades. The decision-making process involves balancing the additional returns against the insurance expenses, which ultimately depends on the total volume occurring within the coprocessor's measured timeframe. Scaling this process may also prove difficult based on the capital available for access in a single AVS and the ability to predict the value at risk at any given moment.

Metrics-Based Reward Distribution

While each transaction is recorded on the blockchain, smart contracts face challenges in determining the metrics these transactions represent, such as transaction volume, number of interactions, TVL per unit of time, etc. One might suggest using indexing solutions like Dune Analytics, which provide valuable information. However, relying on off-chain indexing introduces an additional layer of trust. This is where coprocessors emerge as a promising solution.

One particularly valuable on-chain metric is volume. For example, the accumulated volume within a specific AMM pool associated with a particular address within certain blocks. This metric is very beneficial for DEX. One use case is to allow for setting different fee tiers for users based on their trading volume. This approach is similar to dynamic fees, but instead of relying on general data, it looks at address-specific data.

Brevis provides an interesting example where volume proof could be combined with a customized fee rebate Uniswap hooks to offer volume-based fee rebates similar to VIP traders on CEXes.

Specifically, Uniswap v4 can read a user’s historical transactions in the past 30 days, parse each trade event with customized logic, and compute the trading volume with Brevis. The trading volume and a ZK Proof generated by Brevis are then trustlessly verified in a Uniswap v4 Hook smart contract, which determines and records the user’s VIP fee tier asynchronously. After the proof verification, any future trades of an eligible user will trigger the getFee() function to simply look up the VIP record and reduce trading fees for them accordingly.

The cost of getting certified as a "VIP" is also inexpensive (around $2.5 based on its performance benchmark results). Costs can be further reduced by aggregating multiple users using solutions like NEBRA. The only trade-off is the latency, as it took approximately 400 seconds to access and compute 2600 on-chain Uniswap transactions. However, this is less concerning for features that are not time-sensitive.

To address latency concerns, dapps could leverage Brevis’s coChain. Results are computed and delivered swiftly through a PoS consensus mechanism to minimize delays. In case of malicious activities, a ZKP can be used during the challenge window to penalize the rogue validators.

For instance, in the VIP fee scenario mentioned earlier, if over ⅔ of coChain validators deceitfully assign a higher VIP tier to certain users in a "VIP tier lookup table" linked to the dynamic fee hook, some users might initially receive larger fee discounts. However, when a ZK proof is presented during the slashing window, demonstrating that the VIP tiers are incorrect, the malicious validators will face penalties. The erroneous VIP tiers can then be rectified by enabling the challenge callback to update the VIP tier lookup table. For more cautious scenarios, developers can opt to implement extended application-level challenge windows, providing an additional layer of security and adaptability.

Liquidity Mining

Liquidity mining is a form of reward distribution intended to bootstrap liquidity. DEX could gain a deeper understanding of their Liquidity Providers' behavior through coprocessors and appropriately distribute liquidity mining rewards or incentives. It's important to recognize that not all LPs are alike; some act as mercenaries while others remain loyal long-term believers.

The optimal liquidity incentive should retrospectively evaluate the dedication of LPs, particularly during significant market fluctuations. Those who consistently provide support to the pool during such periods should receive the highest rewards.

Solver/Filler Reputation System

In a future focused on user intent, solvers/fillers play a crucial role by simplifying complex transactions and achieving faster, cheaper, or better results. However, there is ongoing criticism regarding the selection process for solvers. Current solutions include:

A permissionless system that utilizes Dutch auctions or fee escalators. However, this approach faces challenges in ensuring a competitive and permissionless auction environment, potentially resulting in latency issues or even non-execution for users.
A permissionless system requires staking tokens for participation, which creates a financial barrier to entry and may lack clear slashing/penalty conditions, or transparent and trustless enforcements.
Alternatively, a whitelist of solvers can be established based on reputation and relationship.

The path ahead should be both permissionless and trustless. However, in order to achieve this, it is necessary to establish guidelines for distinguishing between great solvers and those that are not so great. By utilizing ZK coprocessors, verifiable proofs can be generated to determine whether certain solvers meet or fail to meet these guidelines. Based on this information, solvers can be subjected to priority order flows, slashing, suspension, or even blacklisting. Ideally, better solvers would receive more order flows while worse solvers would receive fewer. It is important to periodically review and update these ratings to prevent entrenchment and promote competition, giving newcomers an equal chance to participate.

Manipulation-Resistant Price Oracle

Uniswap has already introduced embedded oracles in its v2 and v3 versions. With the release of v4, Uniswap has expanded the possibilities for developers by introducing more advanced oracle options. However, there are still limitations and constraints when it comes to on-chain price oracles.

Firstly, there is the consideration of cost. If a coprocessor computed price oracle can offer cost improvements, it could serve as a more affordable alternative. The more complex the designs of the price oracle, the greater the potential for cost savings.

Secondly, the on-chain price oracle pool is still susceptible to manipulation. To address this, it is common practice to aggregate prices from different sources and perform calculations to create a more manipulation-resistant price oracle. Coprocessors have the ability to retrieve historical trades from various pools, even across different protocols, enabling the generation of a manipulation-resistant price oracle with competitive costs for integration with other DeFi protocols.

DIA Data is working on ZK-based oracles with O(1) Labs from the Mina Ecosystem. The approach is similar - taking market data and performing more sophisticated calculations off-chain, free of gas costs and other execution constraints, but with the ability to verify integrity of the calculation as the result is served on-chain. This can make it feasible to supplement simple price feeds with other market data such as depth, to help assess liquidation impact, as well as metadata to enable protocols to customize their feed.

Margin Systems

To overcome the computational limitations of blockchain technology, many derivatives platforms frequently move certain components, such as risk management systems, off-chain.

@0x_emperor and @0xkrane propose an interesting use case of coprocessors where the margining logic is transparent and verifiable. In many exchanges, risk management systems are in place to prevent excessive leverage. One such example is the Auto Deleveraging System (ADL), which strategically allocates losses to profitable traders in order to offset the losses experienced by liquidated traders. Essentially, it redistributes the losses among profitable traders to cover the unpaid debts resulting from these liquidations.

Users may have questions regarding the forceful closure of their positions. To address this, the exchange could utilize coprocessors to execute margin engine logic using on-chain data and generate proofs to verify correct computation. Since ADL occurrences are infrequent, concerns about latency and proving costs are minimal. However, the use of trustless and verifiable Zk coprocessors enhances transparency and integrity, which is beneficial for the exchange and its users.

Money Market

By leveraging insights from historic on-chain data, coprocessors have the potential to enhance risk management for LPs and lending protocols. Additionally, protocols can offer improved user experience based on data-driven analytics.

When Curve experienced an exploit some months ago, attention turned to money markets with millions of CRV tokens at risk of liquidation. Frax lenders found some solace in the protocol's aggressive interest rate increases when the loan-to-value (LTV) ratio became unhealthy. This incentivized Curve founder to repay the debt more quickly. However, AAVE stakeholders expressed concerns and initiated discussions about reducing collateral capacity and potentially halting the market. Their fear was rooted in the possibility of insufficient liquidity for successful liquidations, which could result in bad debt and vulnerability to market conditions.

Fortunately, the crisis has been resolved. It is important to regularly review assets listed on money markets, with a particular focus on their liquidity in the market, especially during liquidation events. Illiquid assets should be assigned a lower loan-to-value (LTV) ratio and collateral capacity.

However, the decision-making process for risk parameter changes in money markets is often reactive, as we observed in the CRV situation. We need more prompt and proactive measures, including trustless solutions. There have been discussions regarding the use of Feedback Controls to dynamically adjust parameters based on on-chain metrics, such as liquidity utilization, instead of relying on a pre-determined curve. One intriguing concept involves a lending pool that verifies proof of on-chain liquidity for a specific market. The controller receives proof calculated from on-chain metrics by ZK coprocessors, indicating when an asset is no longer sufficiently liquid beyond a certain threshold. Based on this information, the controller can take various measures, such as adjusting interest rates, setting LTV caps, suspending the market, or even discontinuing it altogether.

More advanced strategies could include periodically adjusting the collateral borrow capacity or interest rate curve based on the previous week's on-chain liquidity. The exact threshold would be determined through discussions within the DAO. It could be determined by considering factors such as historic on-chain volume, token reserves, minimum slippage for a lump-sum swap, and so on.

For lenders and borrowers, money markets can provide enhanced services and experiences, similar to fee rebate programs for VIP traders in DEXs. There are existing credit score solutions that aim to create a comprehensive profile of on-chain users. The goal is to incentivize good behaviors, such as effective risk management demonstrated by avoiding liquidation events, maintaining healthy average LTV ratios, making stable large deposits, and more. Trustless rewards can be given for these positive behaviors, including better and smoother interest rates compared to average users, higher maximum LTV and liquidation ratios, a buffer time for liquidation, lower liquidation fees, and more.

Staking & Restaking

Trust-minimized Oracle

Since the Merge and the Shanghai/Shapella upgrade, the liquid staking market has become the largest market in DeFi. Notably, Lido has amassed over $29 billion TVL, while Rocketpool has over $3.6 billion TVL.

Given the substantial amount of money involved, it is important to note that the oracles used to report information, such as accurate balances of associated validators on the beacon chain, are still trusted. These oracles play a crucial role in distributing rewards to stakers on the execution layer.

Currently, Lido employs a 5-of-9 quorum mechanism and maintains a list of trusted members to safeguard against malicious actors. Similarly, Rocketpool operates with an invite-only Oracle DAO comprised of node operators who are trusted with updating reward information in the smart contracts on the execution layer.

However, it is essential to recognize that if a majority of trusted third parties were compromised, it could significantly harm liquid staking token (LST) holders and the entire DeFi ecosystem built on top of LSTs. To mitigate the risk of erroneous/malicious oracle reports, Lido has in place a series of sanity checks that are implemented in the execution layer code of the protocol.

With the introduction of EIP-4788 "beacon block root in the EVM", it becomes easier for coprocessors to gain access to and compute over data on the consensus layer. =nill; Foundation, Succint and DendrETH are all developing their own ZK-proof TVL oracle for Lido. To ensure maximum security, Lido could utilize a multi-proof architecture.

Taking =nil;’s design for example, at a high level, the oracle obtains essential information from the Consensus and Execution layers, such as the Beacon Block Header, Beacon State, Lido contract addresses, etc. It then computes a report on the total locked value and validator counts for all Lido validators. These data, along with additional necessary information are passed to the proof producer and run on specialized circuits to generate a ZK proof. The oracle retrieves the proof and submits both the proof and its report to the smart contract for verification. Note that these oracle designs are still in the testing stage and are subject to changes.

However, it is worth noting that there will always be some sort of data that may not be provable on the EL side due to the limited nature of what is sent over via 4788 and that oracles may still be required for this subset of data.

Additionally, trust-minimized ZK-proof oracles are still in their infancy. The proposed approach by Lido contributors is to use the info provided by ZK oracles as a “sanity check” against the work done by the trusted oracles until these ZK implementations can be battle tested. It would be too risky to move all of the trust that’s currently in the oracle system to ZK systems at this stage.

Furthermore, the proofs for data of this size are very computationally heavy (e.g. can take even 30-45 minutes) and very expensive, so they are not a suitable replacement at the current maturation of the technology for things like daily or even intra-day reporting.

Validator Risk and Performance Analytics

Validators play a crucial role in the staking ecosystem. They lock up 32 ETH on the beacon chain and provide validating services. If they behave properly, they receive rewards. However, if they misbehave, they face slashing. Validators are run by Node Operators who have different risk profiles. They can be curated (e.g. Lido’s Curated Validator Set), bonded (e.g. Rocket pool, Lido’s CSM) or solo stakers. They may choose to run their services on cloud data centers or at home, in regions that are either crypto regulation-friendly or unfriendly. Additionally, validators can utilize DVT technology to split internal nodes or join into clusters for enhanced fault-tolerance. As Eigenlayer and various AVS (Actively Validated Services) emerge, validators could potentially offer additional services beyond validating for Ethereum. Undoubtedly, the risk profile of validators will be complex, making it essential to accurately assess their risk profiles. With good validator risk and performance analytics, it opens the door to endless possibilities, including:

First and foremost, risk assessment plays a crucial role in establishing a permissionless validator set. In the context of Lido, the introduction of the Staking Router and the future EIP-7002 "Execution layer triggerable exits" could pave the way for enabling permissionless joining and exiting of validators. The criteria for joining or exiting can be determined based on the risk profile and performance analytics derived from a validator's past validating activities.

Second, node selection in DVT. For a solo staker, it may be beneficial to choose other nodes to create a DVT cluster. This can help achieve fault tolerance and increase yields. The selection of nodes can be based on various analytics. Additionally, the formation of the cluster can be permissionless, allowing nodes with a strong historical performance to join while underperforming nodes may be removed.

Third, restaking. Liquid Restaking Protocols enable restakers to participate in the Eigenlayer restaking marketplace. These protocols not only produce liquid receipts called Liquid Restaking Tokens (LRT) but also aim to secure the best risk-adjusted returns for restakers. For instance, one of Renzo's strategies involves building the AVS portfolio with the highest Sharpe Ratio while adhering to a specified target maximum loss, adjusting risk tolerance and weights through DAO. As more AVS projects are launched, the importance of optimizing support for specific AVS and selecting the most suitable AVS operators becomes increasingly crucial.

So far, we emphasized the significance of validator risk and performance analytics, as well as the wide range of use cases it enables. However, the question remains: How do we accurately assess the risk profile of validators? One potential solution is being developed by Ion Protocol.

Ion Protocol is a lending platform that utilizes provable validator-backed data. It enables users to borrow ETH against their staked and restaked positions. Loan parameters, including interest rates, LTVs, and position health, are determined by consensus layer data and safeguarded with ZK data systems.

Ion is collaborating with the Succinct team on Precision—a trustless framework to verify the economic state of validators on Ethereum’s consensus layer. This aims to create a verifiable system that accurately assesses the value of collateral assets, mitigating any potential manipulation or slashing risks. Once established, this system could facilitate loan origination and liquidation processes.

Ion is also partnering with Modulus Labs, leveraging ZKML for trustless analysis and parametrization of lending markets, including interest rates, LTVs, and other market details to minimize risk exposure in the event of aberrant slashing incidents.

Conclusion

DeFi is truly remarkable as it revolutionizes the way financial activities are conducted, eliminating the need for intermediaries and reducing counterparty risks. However, DeFi currently falls short in providing a great user experience. The exciting news is that this is on the brink of change with the introduction of coprocessors that will empower DeFi protocols to offer data-driven features, enhance UX and refine risk management. Moreover, as decentralized AI infrastructure advances, we progress towards a future of Intelligent DeFi.

References

https://crypto.mirror.xyz/BFqUfBNVZrqYau3Vz9WJ-BACw5FT3W30iUX3mPlKxtA

https://crypto.mirror.xyz/8TXa9EqNkwjnQNenXscPwyHC6V99dmyhcO7uPYbeaIo

https://blog.brevis.network/2023/11/01/uniswap-v4-hook-brevis-zk-coprocessor-data-driven-dex-experiences/

https://blog.brevis.network/2024/01/18/introducing-brevis-cochain-the-fusion-of-crypto-economics-and-zk-proof-in-a-zk-coprocessor/

https://dev.risczero.com/api/

https://research.lido.fi/t/trustless-zk-proof-based-total-value-locked-oracle/3405

https://research.lido.fi/t/zkllvm-trustless-zk-proof-tvl-oracle/5028

https://docs.ambient.finance/users/dynamic-fees

Uniswap: Zero to Infinity

lukewasm@newsletter.paragraph.com (lukewasm.eth) — Tue, 17 Oct 2023 07:14:35 GMT

Special thanks to Alex from Maru Network, Brad from Uniswap Labs, Dong Mo from CelerNetwork, Shumo from Manta Network, and Suning from Hyperoracle for their invaluable discussions, insights, and feedback on this article.

Introduction

Undoubtedly, Uniswap stands as one of the most widely used decentralized applications. It relentlessly pioneers innovative solutions that redefine the game. In this article, I will delve into Uniswap's awe-inspiring journey from the past to a limitless future. By examining the features of each version of Uniswap, I uncover how it effectively tackles new challenges and adapts to ever-changing demands. Additionally, I explore how the latest advancements in crypto are shaping the future of decentralized exchanges (DEX). Prepare for a journey from zero to infinity.

v0: Proof of Concept

Prior to Uniswap, EtherDelta was the only decentralized exchange (DEX) that gained traction. However, the user experience was poor.

The concept of an Automated Market Maker (AMM), proposed by many industry leaders (Alan Lu of Gnosis and Vitalik), offers an alternative approach to on-chain trading compared to traditional order-book models.

Features

Constant Product AMM

Uniswap utilizes a constant product formula (x * y = k) to calculate the price of an asset. In this formula, x represents the reserve of the base asset, while y represents the reserve of the quote asset. When a token is withdrawn (bought) from a pool, a proportional amount must be deposited (sold) to ensure that the constant k is maintained. The ratio of tokens in the pool determines the price of a token.

Source: Uniswap

It's worth noting that other AMMs utilize different mathematical formulas to represent liquidity curves. Some examples include Curve's Stableswap and Balancer's weighted pools.

Problems

Uniswap v0 is essentially a Proof-of-Concept, meaning there are still many unresolved issues. The two major problems are as follows:

It only worked for a single ETH/ERC20 pair.
It only worked for a single liquidity provider (LP).

v1: Functional DEX

Features

Uniswap v1 launched on Ethereum mainnet on November 2, 2018. It supports multiple liquidity providers using an internal token to track fees and collateral. It utilizes a factory contract that enables anyone to add any token for trading against native ETH. This version provides a functional DEX. However, there are certain issues that need to be addressed.

Problems

Since all tokens are paired with ETH, users can easily swap any ERC20 token for another ERC20 token by using ETH as an intermediary in a single transaction. However, there is a drawback: when it comes to frequent stablecoin swaps like DAI/USDT, relying on ETH as an intermediary for every swap becomes inefficient. In this case, a direct token pair is preferred.

v2: Money Lego

In May 2020, Uniswap v2 was launched, introducing numerous upgrades to the Uniswap Protocol. These enhancements increased its flexibility and expanded the range of trades possible.

Features

ERC20/ERC20 Pairs

In Uniswap V2, there is a notable difference: instead of only pairing ERC20 tokens with ETH, now any ERC20 token can be directly pooled with any other ERC20 token. This feature offers great utility for liquidity providers as they can now maintain more diverse ERC20 token-denominated positions, including Stablecoin pairs.

Price Oracle

Uniswap v2 offers on-chain price feeds that can be utilized by numerous DeFi applications. These price feeds are resistant to manipulation, making them highly valuable. The mechanism involves adding the end-of-block price to a cumulative-price variable in the core contract, which is weighted by the duration of time that particular price existed. This variable essentially represents the sum of Uniswap prices for every second throughout the contract's entire history.

Source: Uniswap

This variable can be utilized by external contracts to accurately track time-weighted average prices (TWAPs) over any given time interval. The process involves reading the cumulative price from an ERC20 token pair at the start and end of the interval. By calculating the difference in this cumulative price and dividing it by the length of the interval, a TWAP for that specific period can be generated.

Source: Uniswap

Flash Swaps

Uniswap v2 also introduces Flash Swaps, which is a type of flash loan pioneered by the lending market AAVE. This feature allows any user to withdraw as much as ERC20 token in a pool with no upfront cost and do arbitrary actions, provided that by the end of the transaction execution equivalent values (plus fees) are returned.

Flash loan features get its bad reputation as it comes often in headline with various kinds of attacks on DeFi protocols. But flash loans are not the problem. The real issues are existing vulnerabilities in a protocol. The atomic nature of flash loans eliminates the need for upfront capital requirements typically associated with operations such as arbitraging between pools and obtaining margin leverage.

Problems

Although the AMM is innovative and beneficial for bootstrapping trading and liquidity in new markets, it still has some inefficiencies. For instance, when dealing with low volatility tokens, liquidity is only necessary within a narrow price range. However, the current design distributes liquidity uniformly across all price ranges.

v3: Capital Efficiency

Uniswap v3 aims to be the most flexible and efficient AMM due to its groundbreaking concentrated liquidity design.

Features

Concentrated Liquidity (CL)

In Uniswap v2, liquidity is evenly distributed across an x*y=k price curve, encompassing all prices from 0 to infinity. However, in most pools, a significant portion of this liquidity remains unused.

In Uniswap v3, liquidity providers (LPs) have the ability to concentrate their capital within specific price ranges, allowing for increased liquidity at desired prices. This customization enables LPs to construct personalized price curves that align with their preferences. These individual positions are then aggregated into a single pool, creating a unified curve against which users can trade. The outcome is mutually beneficial for both traders and liquidity providers: Traders experience reduced slippage and LPs earn greater fees, thanks to the higher concentration of liquidity within a customized range.

CL is incredibly valuable for stable pairs, such as stablecoins and liquid staking derivative tokens. These assets tend to be traded within a narrow price range. However, for more volatile token pairs, CL requires more advanced liquidity management techniques. It may be challenging for average retail liquidity providers to consistently manage their positions effectively.

Range Orders

With CL, a novel order type called range orders are introduced to complement market orders. LPs have the ability to deposit a single token within a custom price range, either above or below the current price. If the market price falls within their specified range, they can sell one asset for another along a smooth curve, all while earning swap fees.

A range order functions similarly to a 'limit order,' but with the drawback of reversibility- when the price reverses, the order is also reversed. However, fees are still earned in the process. Barry Fried (@BarryFried1) offers a detailed example of how to use range orders in this thread.

Multiple Fee Tiers

Instead of having one fee tier, Uniswap v3 introduces three separate fee tiers per pair — 0.05%, 0.30%, and 1.00%, allowing LPs to be appropriately compensated for taking on varying degrees of risk

Advanced Oracles

Uniswap v3 offers significant improvements to the price oracle. Instead of storing only one price cumulative variable, v3 stores an array of variables, making it far easier and cheaper to create more advanced oracles that include simple-moving averages (SMA), exponential moving averages (EMA), outlier filtering, and more.

Problems

Lack of Flexibility

Although concentrated liquidity and fee tiers provided more flexibility for liquidity providers and enabled the implementation of new strategies, Uniswap v3 fell short in accommodating the evolving functionalities and innovations in AMMs and markets. To incorporate additional features such as TWAP orders, limit orders, advanced oracles, and dynamic fees, it would have been necessary to re-implement the core protocol.

Certain features, such as the price oracle initially introduced in Uniswap v2, enabled integrators to utilize decentralized on-chain pricing data. However, this came at the expense of increased gas costs for swappers and lacked customization options for integrators.

Complicated Liquidity Management

As mentioned earlier, concentrated liquidity is challenging to manage for unsophisticated liquidity providers, particularly for volatile pairs. While several automatic liquidity management protocols have emerged, they mostly consist of simple rebalancing strategies designed for pegged assets. Unfortunately, these strategies are ineffective when it comes to volatile pairs because of the limitations imposed by long block times, gas costs, hedging costs, etc.

Moreover, since the concentrated liquidity position varies for each liquidity provider, the LP token is inherently non-fungible. It can only be represented by a non-fungible token (NFT), which presents a challenge for other DeFi protocols looking to integrate with it.

Numerous outstanding projects are actively addressing this issue using a range of strategies, including rebalancing, dynamic hedging with money markets, perpetuals, and options. Atis Elsts (@atiselsts_eth) has written a series of excellent articles on LP strategies that are highly recommended.

Value Leakage

The issue of value leakage is the most significant problem of all. While this is not unique to Uniswap v3, it has gained attention due to the increased volumes and wider adoption of AMMs since the launch of v3. This value leaks out of the DEX system in forms of

Traders end up paying higher slippage than necessary due to front running and sandwich attacks.
Liquidity providers lose value through CEX-DEX arbitrages (a.k.a. Loss-versus-Rebalancing)

To address these problems, we need more customized and sophisticated designs that go beyond what Uniswap v3 currently offers. We require a DEX platform that is more expressive and powerful.

v4: Ultimate Platform

Uniswap v4 builds on top of AMM models introduced in previous generations and through the introduction of 'hooks', it aims to be the ultimate DEX platform with high efficiency and customization.

Efficiency

Singleton

In Uniswap v3, every pool is created as an individual contract through a factory contract. On the other hand, in v4, all pools coexist within a single smart contract (known as a singleton). This singleton model significantly decreases the expenses associated with creating pools and executing multi-hop trades.

Flash Accounting

In v4, the singleton utilizes flash accounting to optimize asset transfers. Unlike in v3, where assets are moved in and out of pools after every swap, the v4 system only transfers based on net balances. This significantly reduces the cost of accounting. Transient storage (proposed in EIP-1153) makes it cheaper to set and clear a storage slot which is necessary for flash accounting to operate effectively.

Source: Uniswap

Native ETH

Uniswap v4 reintroduces support for trading against native ETH, which brings several benefits. Traders can enjoy reduced gas costs for cheaper transfers and the elimination of additional wrapping costs.

Customization

Hooks

Hook contracts (or hooks), are externally deployed contracts that execute pre-defined logic at specific points during the execution of a pool. This is what makes v4 so expressive and customizable. Hooks allow for the implementation of features that were previously built into the protocol, such as oracles, as well as new features that previously required independent protocol implementations.

Uniswap v4 currently supports eight such hook callbacks:

beforeInitialize/afterInitialize
beforeModifyPosition/afterModifyPosition
beforeSwap/afterSwap
beforeDonate/afterDonate

The figure below illustrates the logic flow for a Swap Hook. Before and after executing a swap, there is a dedicated boolean flag that enables the execution of custom code at these specific points. This serves as the basis for developing advanced features like oracles, dynamic fee structures, auctions, and advanced order types, etc. We will delve deeper into these concepts in the following sections.

Swap Hook Flow

Oracles

In previous versions, oracles were integrated into the core Uniswap protocol. While this made integration easier and cheaper for other protocols, it came at the expense of customization options and higher costs for swappers. However, with the introduction of hooks, the design possibilities for oracles have significantly expanded. This opens up the opportunity to create manipulation-resistant oracles such as winsorized price oracles as well as volatility oracles. Additionally, the choice of who bears the costs of updating oracles can now be customized. For example, instead of burdening the first swapper with the cost, which may not be sustainable, a hook contract with an ETH balance could be used for gas payment. Despite these advancements, designing oracles still presents challenges. For instance, TWAP oracles are sometimes susceptible to manipulation and tend to lag behind current prices.

Uniswap Labs has introduced another intriguing price oracle known as the truncated price oracle. This oracle calculates the geometric mean price of an asset in a liquidity pool and imposes a limit on price movement within a single block. By truncating the price, this on-chain oracle mitigates the price impact of significant trades, enhancing resistance to manipulation attempts.

Dynamic Fees

While Uniswap v3 introduced additional fee tiers for LPs to select from, these fee structures remain static and do not consider current market conditions. Consequently, LPs are not adequately compensated for their services.

Alex Nezlobin (@0x94305) proposed a simple yet effective dynamic fee structure that considers the price impact of the previous block and applies different fees for buyers and sellers. The following figure illustrates an example: when the CEX price moves to p*, which is higher than the current AMM price p_AMM, the fee for sales decreases by δ, while the fee for buys increases by δ. The value of δ is proportional to the change in AMM price. The purpose of this dynamic fee structure is to differentiate between arbitrageurs and uninformed flows. Arbitrage flows are more likely to be autocorrelated with price movements.

Source: https://twitter.com/0x94305/status/1674857993740111872

Designing a robust dynamic fee structure presents several challenges. One challenge is how to incorporate off-chain signals, such as CEX price, liquidity depth, and volatility. Additionally, various on-chain signals, including address, size, and execution time, can be unreliable for differentiating between informed and uninformed flow, making it difficult to assess their effectiveness. Furthermore, it is important to ensure that fees do not go below zero in order to limit losses for LPs.

Auctions

Hooks can also serve as a means to implement auctions, which can aid in redistributing value back to LPs. Depending on the timing, auctions can be categorized as either ex ante or ex post auctions.

Ex ante auctions take place prior to the block. This concept was initially introduced in a research article that discussed MEV capturing AMM (McAMM). In this approach, the right to make the first swap in an AMM before a block is auctioned off, and the bid values are subsequently redistributed. However, there are challenges associated with this bidding process, as it essentially involves pricing an option, which can be highly complex. Additionally, since block proposers hold the ultimate decision-making power regarding whether to accept a block containing the trades, issues of censorship may arise. Ensuring fair and efficient distribution of bid values can also prove to be a complicated task. Moreover, there is no guarantee that the winners of the bids would exercise their right to swap first, potentially resulting in a deteriorating experience for other traders.

Ex post auctions are conducted after volatility has been realized, meaning that CEX prices have already moved but before the subsequent block has been committed. The advantage of these auctions is their increased effectiveness. However, they pose challenges as they require off-chain infrastructure that relies either on trusted parties or trustless systems. If trusted parties are used, concerns arise regarding censorship and bid privacy. On the other hand, designing trustless systems is much more complex. Ex post auctions also face the issue of proposers potentially playing games with bidders, such as excluding arbitrage trades from being included in a timely manner. Additionally, there is the significant problem of extra latency involved in bidding, running consensus on winning bids, and distributing those bids to block builders—all of which need to be completed before the subsequent block is committed. Finally, it may be difficult to ensure sufficient competitive conditions in these auctions to capture enough value. Sorella Labs (@SorellaLabs) is leading the charge in addressing these challenges by leveraging its advanced infrastructure and mechanism designs.

Diamond Hook

The Dimond Protocol was initially designed as an LVR-minimizing AMM. In Diamond, block producers conduct auctions to capture any arbitrage opportunities between the external market price of a Diamond pool and the pool's own price. The proceeds from these auctions are shared between the Diamond pool and the block producer in a manner that remains incentive compatible for the block producer.

A variation of the Dimond Protocol, as discussed in this post, involves implementing a collateral pool to maintain the end-of-block price in accordance with the committed price by block producers. Swaps will only execute if there is sufficient collateral available to restore the price to the committed value. Arrakis (@ArrakisFinance) is currently collaborating with Conor McMenamin (@ConorMcMenamin9), one of the authors of the Diamond Protocol, to develop an implementation using v4 hooks.

Advanced Order Types

Hooks could also enable more advanced order types that greatly improve trader experience. Some common order types include limit orders, stop loss, take-profit, TWAP

Limit Orders

Traders have the option to submit on-chain limit orders to the hook contract. When the price reaches the specified tick price, the order is filled. However, these on-chain limit orders have a significant disadvantage compared to traditional finance (tradfi) limit orders. This is primarily because on-chain orders cannot be cancelled without incurring gas fees. As a result, this creates a problem known as a low order-to-trade ratio.

TWAMM

One possible solution for facilitating the execution of large orders over time is to implement a time-weighted average market maker (TWAMM). This approach involves breaking down large orders into smaller blocks and ensuring they are executed as the first trades, thus preventing sandwich attacks. Additionally, reducing TWAP order fees could be considered since they typically involve uninformed flow. However, a challenge arises with the high gas costs and determining who should bear these expenses.

Other Hooks

There are several other features that could be implemented using hooks. Here are some ideas:

A yield-bearing hook that lends out-of-range liquidity into money markets to increase capital efficiency.
A pool with both xy=k liquidity curve and concentrated liquidity.
A pool with withdrawal fees for LPs to reduce Just-in-time liquidity attacks.

Suning (@msfew_eth) provides an awesome curation of hook ideas and implementations on Github. Aiden (@aiden0x4) also publishes a nice open directory for hooks.

zkAMM & zkHooks

ZK Coprocessors empower smart contracts with the ability to access data insights akin to those offered by Dune Analytics, all without compromising trust due to the application of Zero-Knowledge (ZK) Proof technologies. The utilization of zk Coprocessors in AMM designs has been an emerging and actively researched area. The introduction of hooks now allows for the seamless integration of zk proofs into Uniswap v4, ushering in a new era of zero knowledge AMMs, or zkAMMs.

HyperOracle (@HyperOracle) demonstrates an implementation of zkAMM based on Uniswap v2, where the addLiquidity computation is offloaded off-chain. When a user adds liquidity, the token amount, price, and LP token shares need to be computed. In this particular implementation, HyperOracle's zkGraph captures the addLiquidity event, performs the necessary computation, generates the proof, and publishes it. This implementation of zkAMM includes an integrated automation layer that verifies the proof and mints the LP token for the user.

Diego (@0xfuturistic) introduces an implementation of zkAMM (zkUniswap) based on Uniswap v3 where a portion of the AMM swap computation is offloaded to the Risc Zero (@RiscZero) zkVM. When a user performs a swap in a pool, several parameters need to be calculated to finalize the swap. These parameters include the amount to be swapped in and out, the fee, and the price after swapping. Originally, this computation was performed within the solidity contract through EVM. However, with the new implementation, the swap inputs are picked up by the relayer, and the computation is carried out off-chain. The relayer then posts the output and the proof. The AMM verifies the proof and settles the swap. zkUniswap implements a lock auction mechanism to ensure concurrency control. While its current performance is comparable to that of the EVM, the efficiency could be significantly enhanced through parallelization for batched swaps.

Proof of volume serves as another use case for AMMs. Brevis (@brevis_zk) provides an interesting example where a fee rebate hook could be designed based on users' historical trading volume, similar to trading-volume-based fee rebates on centralized exchanges (CEXes). VIP traders now have the ability to calculate their monthly trading volume off-chain and then submit a low-cost ZK proof to the blockchain for asynchronous verification of their VIP status. Once verified, subsequent trades can utilize post-swap hooks to access a "VIP fee-tier table" populated by the ZK Coprocessors. This allows for automatic application of the appropriate fee rebates. Maru Network (@marunetwork) is currently developing trustless volume oracles as their initial use case for their zk Coprocessor network. By implementing a trustless volume oracle, DEXes would be able to distribute rewards in a fair and transparent manner. This approach allows for proportional incentivization of liquidity and user activities, fostering a positive flywheel effect. The cost of proof verification can be reduced by using zero-knowledge proof aggregation services such as NEBRA (@nebrazkp) UPA (Universal Proof Aggregation), which aggregates proofs from different circuits and different parties to a single proof to achieve reduced amortized verification cost.

In summary, the concept of zkAMMs involves utilizing zkCoprocessors or zkOracles to shift computations away from the EVM and verify the proof of computation on-chain. These computations can be significantly more intricate than those related to swaps and liquidity adjustments. For instance, they could involve calculating dynamic fees based on recent market volatility, proving historic volumes of users in a given pool or implementing rebalancing strategies using complex machine learning algorithms. The possibilities are endless, as any computation ultimately results in an O(1) verification cost, no longer constrained by the computational resources of the EVM.

v4 Challenges

Uniswap v4 introduces efficiency and customization to the AMM design space, enabling the creation of pools with diverse features and functionalities. However, this advancement comes with a foreseeable trade-off: an increase in liquidity fragmentation due to the proliferation of pools. As a result, routing becomes significantly more challenging.

UniswapX

UniswapX aims to tackle the issue of liquidity fragmentation by outsourcing the complexity of routing to a open network of third-party fillers. These fillers compete with each other to execute swaps using on-chain liquidity like AMM pools or their own private inventory. This design is intent-centric, allowing users to simply state their desired outcomes and rely on professionals to fulfill them.

These fillers are sophisticated agents equipped with advanced routing algorithms, high computational power, and substantial financial capital. They compete with each other under a predetermined auction mechanism to offer users the best possible execution. Users may also receive price improvement, ensuring that their executions are at least as good as trades directly from Uniswap AMM pools.

The architecture of the UniswapX protocol is depicted below. Swappers submit their intent orders, which are structured as Permit2 executable off-chain signatures, through the Uniswap API. Permit2 is an elegant model that ensures the safe movement of tokens held by users. Fillers devise strategies to fulfill these orders using any liquidity venue available to them, whether on-chain or off-chain. Finally, Order Reactors settle UniswapX orders. They are responsible for validating orders of a specific type, resolving them into inputs and outputs, executing them based on the filler's strategy, and verifying successful fulfillment of the order.

Source: Uniswap

In the current Uniswap Labs interface implementation of UniswapX, the protocol is broken into two phases. The first is the RFQ phase, where whitelisted 'quoters' respond with quotes to the orders. The winner of the quote then has an exclusivity period to fill the order. If they don't, then it enters the second phase, the Dutch Auction phase, which is a auction that any filler can take part in. The plan is to make the quoting system fully permissionless in the near future.

Source: Onchain Trading by Hayden Adams, EthCC

The intent-centric design offers several benefits.

Aggregating liquidity sources for better prices.
No requirement for gas tokens, even for cross-chain swaps.
Internalization of MEV through price improvement.
No cost incurred for failed transactions.

Challenges

Making the quoting system permissionless, e.g. Using an effective reputation system.
Attracting more fillers to ensure a competitive and permissionless auction environment.

The Future: An Infinite Game

The development of DEXes doesn't stop here. In order for crypto to achieve mass adoption, there are several other issues that need to be addressed. Markus Schmitt (@_haikane_) from PropellerHeads (@PropellerSwap), in collaboration with Frontier Research (@FrontierDotTech), has written an outstanding article that delves into what constitutes a good DEX and identifies the remaining problems that need to be solved. According to his perspective, a good exchange should offer:

Trust: Ensuring transparency and minimizing custody risks before, during, and after transactions.
Best Prices: Providing confidence in obtaining the best or competitive prices consistently, eliminating the need to search elsewhere.
Fairness: Preventing abuse of orders and ensuring equal treatment regarding pricing and fees for all users.
Speed and Availability: Offering fast transaction processing and maintaining high availability to avoid delays and inconveniences.
Information: Assisting users in making informed decisions by providing order monitoring, settlement price estimates, and helpful suggestions for limit orders and slippage.
Liquidity: Demonstrating a robust liquidity pool across various asset pairs, instilling confidence in obtaining favorable prices.

If the smart contracts of DEXes are considered safe, trust is already built-in. DEXes don't hold users' assets. The information available to traders is quite extensive now. The permissionless nature of AMMs enables users to create and trade any asset pairs. However, due to blockchain characteristics, ensuring the best prices, fairness, speed, and availability is not always guaranteed. Gas fees, stale prices, and fragmented liquidity all contribute to impacting users' experience.

To address these issues, we are witnessing a proliferation of L2s and DEXes on L2s. Additionally, we are seeing more sophisticated routing, order batching, and Request-for-quotes systems. To prevent front-running and ensure fair value distribution, more MEV-aware channels are being employed. Moreover, efforts are underway to develop order flow auction markets that minimize value leakage for DEX users. The introduction of hooks and zk Coprocessors also significantly expands the design possibilities for AMMs, allowing for more complex logic and heavy computations without compromising trust.

Additionally, there is a suite of protocols that build upon AMMs, effectively stacking the “money lego”. These protocols include liquidity managers that assist unsophisticated users in automating liquidity rebalancing or leveraging farming. There are also protocols that utilize Concentrated Liquidity (CL) positions to create margin trading, perpetuals, options, and structured products.

AMMs have witnessed exponential growth thanks to their permissionless listing, passive liquidity, and ease of trading. However, this convenience also brings along several issues that we have explored so far. Uniswap is consistently pushing the boundaries to address these issues and enhance the user experience. As Dan Robinson (@danrobinson) aptly puts it in his speech at SBC23, DEX design is an infinite game. With increased adoption of DEXes in the future, new challenges and problems are likely to arise, necessitating innovative solutions.