Early on, AMMs were considered inefficient compared to orderbook models, but now Uniswap sometimes gets more volume than centralized exchanges (CEX). People are willing to accept the tradeoffs of providing liquidity, especially if they are indifferent between USDC and ETH, as it can be a good mechanism for cost averaging in or out. Although many things in DeFi seem similar, there are new primitives that expand consumer preferences and allow for successful enterprise building

For more information, here’s the Uniswap history link

v1: Anyone can be a liquidity provider (LP) and open any sort of liquidity pool for any token. LPs could provide full-range liquidity, which supports any price from 0 to infinity

• Problem: Most assets don’t trade at 0 and infinity simultaneously. Stablecoins for instance, usually trades between $0.99 and $1.01

v2: Optimized for LPs to be funds

v3: Introduced concentrated liquidity, which allows for LPs to customize the liquidity provided in a narrow range. This moves the entire reserve curve upwards, improving liquidity efficiency by having more liquidity for swaps within that range

• This provided a much better execution for traders

• Problem: LPs could hardly profit, as they experienced significant increase in impermanent loss (IL), more commonly known as loss versus rebalancing (LVR) these days. The increase in IL was largely due to MEV leakage from MEV bots and arbitrageurs that were carrying out CEX to DEX arbitrages and backrunning transactions. However, this arbitrage value was not returned to both swappers and LPs

v4: Aims to increase profitability for LPs by solving MEV leakage. In addition, it provides more customizability for creators of liquidity pools, allowing them to own the liquidity

v1 and v2: Provided x * y = k

v3: Added price granularity

v4: Added time and fee granularity

The LPs that are profitable from providing liquidity on v3 are mostly professional capital allocators. This dynamics indicate the complexity of Uniswap and liquidity provision

1. Hooks

   Allow owners to customize the liquidity pools they have created

   A key feature of it is MEV internalization:

   • Appchains, such as Osmosis, leverage appchain architecture to achieve state awareness. Being aware of the transaction order within a block allows appchains to calculate MEV opportunities and capture the value for themselves through arbitrage or backrunning. They can then decide whether to provide this protocol revenue back to Osmosis holders

   • With hooks, Uniswap can internalize MEV and allow for transaction ordering preference

   Shortcoming of hooks:

   • Hooks are SCs that are not built into the protocol layer, unlike that of Osmosis where the MEV preferences are baked into the chain. Uniswap sits above Ethereum and does not own the underlying blockspace. As a result, Uniswap can be ‘begin block’ aware, but not ‘end block’ aware. This means that it can timestamp the first transaction in the block, but is unable to know the last transaction of the block. Hence, the level of MEV value capture from ordering is limited as it does not know exactly the full contents of the block

2. Singleton

   Back in v3, every single liquidity pool that was created on Uniswap needed its own smart contract (SC). In v4, all liquidity pools will be housed in a single contract, known as the SIngleton, optimizing gas expenditure for users

   Multi-hop example:

   • A user wishes to swap from $ETH to $ARB

   • There is however, no $ETH/$ARB pool

   • Uniswap first finds the optimal route to go from $ETH to $USDC through a $ETH/$USDC pool

   • Afterwards, the $USDC is swapped into $ARB through a $USDC/$ARB pool

   • Since all of these pools are housed in 1 SC, gas cost is reduced drastically. Comparing that to v3, the hopping between different pools will require additional computation and gas

   Based on whitepaper, cost of creating a new liquidity pools on v4 can be reduced by 99%.

Open source innovation typically leads to the most capital efficient financial systems over time

1. Developer Tooling

   In some sense, v4 is putting the tools in the hands of developers, liquidity pool owners and LPs to leverage the best possible way to profit. However, one concern would be liquidity fragmentation. Given that only a few LPs are profitable, around 80% of Uniswap’s liquidity is made up by less than 10 LPs. This could result in bulk of the liquidity on Uniswap being in permissioned pools, which is unaccessible to users that have not undergone KYC

   Drawing context from web2, there is a tendency for everything to become either a platform or a marketplace. It seems that this trend is slowly maturing within the web3 space, where v4 is acting more like a platform, rather than a siloed protocol. This is because prior to v4, developers have to create a customized SC architecture to build their own DEX. However with v4, it is possible to have a plug and play hook contract

2. Use of Out-of-Range Liquidity

   Capital that lies out-of-range are idle and not being used. With hooks, this liquidity can be used in lending markets. By this theory, it might be possible for Uniswap to become a DeFi super-app, where it leverages out-of-range liquidity to create new financial primitives, with the process being simplified by v4. There is value in exploring this concept given the decent number of protocols being built on v3 currently: Panoptic, GammaSwap, Infinity Pools

   Prior to v4, utilization of out-of-range might look something like this:

   • Create LP NFT on Uniswap

   • Pass LP NFT to DeFi protocol

   • Deposit liquidity into DeFi protocol

   With v4, the above process can be simplified where liquidity can be directly deposited into the DeFi protocols building on Uniswap. The logical execution will then be handled by the hook that points to the SC

With greater customization and flexibility, the question arises as to whether there is an increased surface area for potential of back-firing. For example, should the hook be faulty, does the consequences of it failing ripple to the broader ecosystem of liquidity pools built within Uniswap?

1. Rugging Risk

   This is not a confirmed risk, but this is what it might look like:

   A liquidity pool deployed can be built with a hook that points to a certain SC. Once the liquidity pool has acquired a certain level of liquidity, it will then amend the hook to point to another SC, which could for instance have a logic where the withdrawal fee is 100% of capital, preventing people from withdrawing

2. Lack of Expertise

   It seems that the architecture will require developers to write a lot of custom logic within the SC for the hook. This might be complex and not all teams will have the expertise to do this

   This however, opens up the potential for a new kind of service: Hook templates

With the increased customizability and complexity of v4, Jason was concerned that the barrier would be too high to allow all users to provide liquidity. Santi mentioned that this is actually an existing left curve which is the belief that v2 was the best version with ease of liquidity provision

Nonetheless, given the significant gas optimization provided by v4, it becomes way cheaper to provide liquidity. This opens up the possibility for users to provide only a small sum of liquidity and benefit from low cost. At the end of the day, IL is an opportunity cost, and it is hard to conceptualize and track for most users

Cookies thoughts: Should this be the case, does it eventually spell demand for LP vaults (user deposits into vaults, which automates the liquidity provision for users and collects a fee in return for the service). Despite the fact that the returns might not be attractive given the level of IL, should there be sufficient demand for users to try out the vaults, or initial liquidity mining campaigns, the revenue that these protocols can make it rather sizeable, as they do not take on the IL, and can pass on the costs to users (since these are costs that would have been incurred either way should the user decide to become a LP themself). Examples that I can think of include Arrakis Finance, Gamma Strategies and Charm Finance

David thinks that hooks may eventually allow for passive concentrated liquidity pools. This democratizes market making and serves all users, spanning from professional market makers, institutions etc.

Uniswap’s AMM is based on the constant product formula: x * y = k. The invariant (slope of the curve), x * y, looks like a logarithmic curve, and ranges are created on this curve for concentrated liquidity provision. This was highly innovative as it allowed for trading of tail end assets

Curve created a stableswap invariant. This slope is much flatter because stablecoins have extremely low volatility and do not fluctuate in prices significantly

v4 adds a a new layer of flexibility, where the slope can be changed + curve can be shifted. The whitepaper indicated that v4 will allow for multiple invariants. Instead of creating a hook that builds a new AMM, one can specify for the hook to build a liquidity pool that is able to mimic other functionalities based on market changes. This opens up the opportunity for passive retail users to provide liquidity, where the pool moves the liquidity based on asset price movement.

Cookies thoughts: What does the value accrual and cost structure look like for this? Who, Uniswap or the protocol built on it, gets access to the fees paid by users?

Ren highlighted that it’s likely Curve will still have a significant role to play in the DeFi landscape given its robust ecosystem with veCRV, Convex, the recently launched crvUSD and LLAMMA (borrowing and lending protocol for crvUSD). In addition, Curve has also been undergoing updates, example of which is the launching of v2 pools to significantly reducing the gas fee needed to rebalance pools

• crvUSD: Has been performing relatively well with ~20 - 25 million crvUSD minted

• LLAMMA: Innovative soft liquidation model

With this being said, Uniswap has also started boosting their gas efficient methods, especially through Singleton contracts, which can theoretically reduce pool deployment cost by 99% and allow for cheaper multi-hop transactions. Curve may still be able to complete, however, the investment thesis revolving Curve’s v2 pools, its stablecoin crvUSD and LLAMMA might not be as strong. Nonetheless, it is likely that Curve will remain the de-facto home for stableswaps

David, on the other hand, is a firmer believer of Curve’s ability to retain its market share. This belief primarily stems from the fact that a lot of DeFi protocols are dependent on Curve through two aspects: (1) protocols hold $CRV (2) protocols rely on Curve’s liquidity. Hence, David believes that unless Uniswap starts offering a liquidity mining program and cater to individual protocols, Curve will still retain its use cases and service the existing protocols

David highlighted that Uniswap started with consumer facing applications but is moving more towards the protocol layer (with hooks customization etc.). This puts ahead the precedent that the next step for v5 might be to launch an appchain, given that they are already doing most things an appchain can possibly do, except for being fully state aware

Appchain thesis: When developers / community owns the entire stack (blockspace, middleware and consumer facing applications), there is the potential to monetize every layer of the stack. In addition, it is possible to build fully customized application and ultimately, have the application and chain be aware of each other

Right now, there is a lack of full customizability for Uniswap. For example, for Singleton contracts to achieve the most optimal gas routing and pool creation, there is a need for EIP-1153 (transient storage), which is potentially going into the Ethereum Cancun upgrade. However, it is difficult for Ethereum to prioritize this simply for Uniswap, as this will cause it to lost its credible neutrality

Should Uniswap adopt an appchain thesis, it is possible for them to prioritize the aspects they wish to build, allowing them to innovate at a faster rate, a function of full ownership

Ren, on the other hand, is of the view that v4 itself might be a signal that Uniswap is not heading for an appchain model. The driver for moving to an appchain model is to capture value, which typically comes from either MEV internalization or turning on the fee switch. However, v4 allows MEV internalization through hooks (to a certain extent, not forgetting that it is not end block aware), which already contributes to value capture. In addition, hooks allow potential value capture by LPs through withdrawal and swap fees, supporting the point that it does not have to pivot to an appchain model to achieve value return

Cookies thoughts: In this case, given the potential of Uniswap moving to an appchain model, we might see some activity migrate over to Cosmos, particularly the key protocols including Osmosis and Stride Zone.

Context: This is the fee switch proposal that had been submitted previously

The fee switch discussion has become even harder as there is an additional layer of complexity. Previously, the stakeholders affected by this proposal were limited to that of LPs and $UNI holders. With hooks, protocols that are building on v4 will also be a stakeholder affected by the fee switch. In particular, it could switch the scene back to protocol owned liquidity (POL) instead of having to pay LPs.

Cookies thoughts: Olympus?

David believes that over time, crypto will have digital monopolies. Such monopolies will be able to expand indefinitely, given the significant Lindy effect they have

There has been suspicions raised regarding Uniswap copying CrocSwap and Balancer v2 models

The main issue was the ‘open source narrative’ painted by Uniswap, yet underlying it there is a more restrictive license that limits open innovation

There was a common consensus amongst the co-hosts that this is the power of brand and clout. David, in particular, mentioned that this will also be a contributing factor to the monopolies in the future

Context: Given the myriad of both EVM and non-EVM chains, what role does Uniswap take, and how will this role manifest from a connectivity / interoperability standpoint (e.g. bridging liquidity)

Uniswap has been deploying across L2s. Eventually, there will be a need for the entire crypto space to converge on 1 interoperability standard. This is where the main innovation for Cosmos: Inter-Blockchain Communication (IBC) comes in. IBC is essentially an interoperability standard which makes it possible to remove trust assumptions, and it is one of the most battle tested interoperability standard existing. With efforts to make L2s IBC-compatible (e.g. Polymer Labs), the DeFi vertical is moving towards a super-chain, where it’s possible for all chains to communicate

How this will potentially look like for Uniswap: Front-ends deployed on all L2s. These front-ends will be able to communicate asynchronously, made possible by IBC (or other interoperability standards). Users could be making their swap on a single front-end, when in fact the liquidity is being routed through other chains as well

It is likely that IBC will see a lot of interesting developments in the next 12 months, contributing to making the entire cross-chain experience seamless. Brilliant teams are working towards this, including Strangelove and Stride

The migration from v2 to v3 was slow, and it is anticipated that the migration from v3 to v4 might be even slower, given the complexity of deploying concentrated liquidity pools. It remains to be seen whether Uniswap might run a liquidity mining campaign to incentivize liquidity migration over to v4

Early on, AMMs were considered inefficient compared to orderbook models, but now Uniswap sometimes gets more volume than centralized exchanges (CEX). People are willing to accept the tradeoffs of providing liquidity, especially if they are indifferent between USDC and ETH, as it can be a good mechanism for cost averaging in or out. Although many things in DeFi seem similar, there are new primitives that expand consumer preferences and allow for successful enterprise building

For more information, here’s the Uniswap history link

v1: Anyone can be a liquidity provider (LP) and open any sort of liquidity pool for any token. LPs could provide full-range liquidity, which supports any price from 0 to infinity

• Problem: Most assets don’t trade at 0 and infinity simultaneously. Stablecoins for instance, usually trades between $0.99 and $1.01

v2: Optimized for LPs to be funds

v3: Introduced concentrated liquidity, which allows for LPs to customize the liquidity provided in a narrow range. This moves the entire reserve curve upwards, improving liquidity efficiency by having more liquidity for swaps within that range

• This provided a much better execution for traders

• Problem: LPs could hardly profit, as they experienced significant increase in impermanent loss (IL), more commonly known as loss versus rebalancing (LVR) these days. The increase in IL was largely due to MEV leakage from MEV bots and arbitrageurs that were carrying out CEX to DEX arbitrages and backrunning transactions. However, this arbitrage value was not returned to both swappers and LPs

v4: Aims to increase profitability for LPs by solving MEV leakage. In addition, it provides more customizability for creators of liquidity pools, allowing them to own the liquidity

v1 and v2: Provided x * y = k

v3: Added price granularity

v4: Added time and fee granularity

The LPs that are profitable from providing liquidity on v3 are mostly professional capital allocators. This dynamics indicate the complexity of Uniswap and liquidity provision

1. Hooks

   Allow owners to customize the liquidity pools they have created

   A key feature of it is MEV internalization:

   • Appchains, such as Osmosis, leverage appchain architecture to achieve state awareness. Being aware of the transaction order within a block allows appchains to calculate MEV opportunities and capture the value for themselves through arbitrage or backrunning. They can then decide whether to provide this protocol revenue back to Osmosis holders

   • With hooks, Uniswap can internalize MEV and allow for transaction ordering preference

   Shortcoming of hooks:

   • Hooks are SCs that are not built into the protocol layer, unlike that of Osmosis where the MEV preferences are baked into the chain. Uniswap sits above Ethereum and does not own the underlying blockspace. As a result, Uniswap can be ‘begin block’ aware, but not ‘end block’ aware. This means that it can timestamp the first transaction in the block, but is unable to know the last transaction of the block. Hence, the level of MEV value capture from ordering is limited as it does not know exactly the full contents of the block

2. Singleton

   Back in v3, every single liquidity pool that was created on Uniswap needed its own smart contract (SC). In v4, all liquidity pools will be housed in a single contract, known as the SIngleton, optimizing gas expenditure for users

   Multi-hop example:

   • A user wishes to swap from $ETH to $ARB

   • There is however, no $ETH/$ARB pool

   • Uniswap first finds the optimal route to go from $ETH to $USDC through a $ETH/$USDC pool

   • Afterwards, the $USDC is swapped into $ARB through a $USDC/$ARB pool

   • Since all of these pools are housed in 1 SC, gas cost is reduced drastically. Comparing that to v3, the hopping between different pools will require additional computation and gas

   Based on whitepaper, cost of creating a new liquidity pools on v4 can be reduced by 99%.

Open source innovation typically leads to the most capital efficient financial systems over time

1. Developer Tooling

   In some sense, v4 is putting the tools in the hands of developers, liquidity pool owners and LPs to leverage the best possible way to profit. However, one concern would be liquidity fragmentation. Given that only a few LPs are profitable, around 80% of Uniswap’s liquidity is made up by less than 10 LPs. This could result in bulk of the liquidity on Uniswap being in permissioned pools, which is unaccessible to users that have not undergone KYC

   Drawing context from web2, there is a tendency for everything to become either a platform or a marketplace. It seems that this trend is slowly maturing within the web3 space, where v4 is acting more like a platform, rather than a siloed protocol. This is because prior to v4, developers have to create a customized SC architecture to build their own DEX. However with v4, it is possible to have a plug and play hook contract

2. Use of Out-of-Range Liquidity

   Capital that lies out-of-range are idle and not being used. With hooks, this liquidity can be used in lending markets. By this theory, it might be possible for Uniswap to become a DeFi super-app, where it leverages out-of-range liquidity to create new financial primitives, with the process being simplified by v4. There is value in exploring this concept given the decent number of protocols being built on v3 currently: Panoptic, GammaSwap, Infinity Pools

   Prior to v4, utilization of out-of-range might look something like this:

   • Create LP NFT on Uniswap

   • Pass LP NFT to DeFi protocol

   • Deposit liquidity into DeFi protocol

   With v4, the above process can be simplified where liquidity can be directly deposited into the DeFi protocols building on Uniswap. The logical execution will then be handled by the hook that points to the SC

With greater customization and flexibility, the question arises as to whether there is an increased surface area for potential of back-firing. For example, should the hook be faulty, does the consequences of it failing ripple to the broader ecosystem of liquidity pools built within Uniswap?

1. Rugging Risk

   This is not a confirmed risk, but this is what it might look like:

   A liquidity pool deployed can be built with a hook that points to a certain SC. Once the liquidity pool has acquired a certain level of liquidity, it will then amend the hook to point to another SC, which could for instance have a logic where the withdrawal fee is 100% of capital, preventing people from withdrawing

2. Lack of Expertise

   It seems that the architecture will require developers to write a lot of custom logic within the SC for the hook. This might be complex and not all teams will have the expertise to do this

   This however, opens up the potential for a new kind of service: Hook templates

With the increased customizability and complexity of v4, Jason was concerned that the barrier would be too high to allow all users to provide liquidity. Santi mentioned that this is actually an existing left curve which is the belief that v2 was the best version with ease of liquidity provision

Nonetheless, given the significant gas optimization provided by v4, it becomes way cheaper to provide liquidity. This opens up the possibility for users to provide only a small sum of liquidity and benefit from low cost. At the end of the day, IL is an opportunity cost, and it is hard to conceptualize and track for most users

Cookies thoughts: Should this be the case, does it eventually spell demand for LP vaults (user deposits into vaults, which automates the liquidity provision for users and collects a fee in return for the service). Despite the fact that the returns might not be attractive given the level of IL, should there be sufficient demand for users to try out the vaults, or initial liquidity mining campaigns, the revenue that these protocols can make it rather sizeable, as they do not take on the IL, and can pass on the costs to users (since these are costs that would have been incurred either way should the user decide to become a LP themself). Examples that I can think of include Arrakis Finance, Gamma Strategies and Charm Finance

David thinks that hooks may eventually allow for passive concentrated liquidity pools. This democratizes market making and serves all users, spanning from professional market makers, institutions etc.

Uniswap’s AMM is based on the constant product formula: x * y = k. The invariant (slope of the curve), x * y, looks like a logarithmic curve, and ranges are created on this curve for concentrated liquidity provision. This was highly innovative as it allowed for trading of tail end assets

Curve created a stableswap invariant. This slope is much flatter because stablecoins have extremely low volatility and do not fluctuate in prices significantly

v4 adds a a new layer of flexibility, where the slope can be changed + curve can be shifted. The whitepaper indicated that v4 will allow for multiple invariants. Instead of creating a hook that builds a new AMM, one can specify for the hook to build a liquidity pool that is able to mimic other functionalities based on market changes. This opens up the opportunity for passive retail users to provide liquidity, where the pool moves the liquidity based on asset price movement.

Cookies thoughts: What does the value accrual and cost structure look like for this? Who, Uniswap or the protocol built on it, gets access to the fees paid by users?

Ren highlighted that it’s likely Curve will still have a significant role to play in the DeFi landscape given its robust ecosystem with veCRV, Convex, the recently launched crvUSD and LLAMMA (borrowing and lending protocol for crvUSD). In addition, Curve has also been undergoing updates, example of which is the launching of v2 pools to significantly reducing the gas fee needed to rebalance pools

• crvUSD: Has been performing relatively well with ~20 - 25 million crvUSD minted

• LLAMMA: Innovative soft liquidation model

With this being said, Uniswap has also started boosting their gas efficient methods, especially through Singleton contracts, which can theoretically reduce pool deployment cost by 99% and allow for cheaper multi-hop transactions. Curve may still be able to complete, however, the investment thesis revolving Curve’s v2 pools, its stablecoin crvUSD and LLAMMA might not be as strong. Nonetheless, it is likely that Curve will remain the de-facto home for stableswaps

David, on the other hand, is a firmer believer of Curve’s ability to retain its market share. This belief primarily stems from the fact that a lot of DeFi protocols are dependent on Curve through two aspects: (1) protocols hold $CRV (2) protocols rely on Curve’s liquidity. Hence, David believes that unless Uniswap starts offering a liquidity mining program and cater to individual protocols, Curve will still retain its use cases and service the existing protocols

David highlighted that Uniswap started with consumer facing applications but is moving more towards the protocol layer (with hooks customization etc.). This puts ahead the precedent that the next step for v5 might be to launch an appchain, given that they are already doing most things an appchain can possibly do, except for being fully state aware

Appchain thesis: When developers / community owns the entire stack (blockspace, middleware and consumer facing applications), there is the potential to monetize every layer of the stack. In addition, it is possible to build fully customized application and ultimately, have the application and chain be aware of each other

Right now, there is a lack of full customizability for Uniswap. For example, for Singleton contracts to achieve the most optimal gas routing and pool creation, there is a need for EIP-1153 (transient storage), which is potentially going into the Ethereum Cancun upgrade. However, it is difficult for Ethereum to prioritize this simply for Uniswap, as this will cause it to lost its credible neutrality

Should Uniswap adopt an appchain thesis, it is possible for them to prioritize the aspects they wish to build, allowing them to innovate at a faster rate, a function of full ownership

Ren, on the other hand, is of the view that v4 itself might be a signal that Uniswap is not heading for an appchain model. The driver for moving to an appchain model is to capture value, which typically comes from either MEV internalization or turning on the fee switch. However, v4 allows MEV internalization through hooks (to a certain extent, not forgetting that it is not end block aware), which already contributes to value capture. In addition, hooks allow potential value capture by LPs through withdrawal and swap fees, supporting the point that it does not have to pivot to an appchain model to achieve value return

Cookies thoughts: In this case, given the potential of Uniswap moving to an appchain model, we might see some activity migrate over to Cosmos, particularly the key protocols including Osmosis and Stride Zone.

Context: This is the fee switch proposal that had been submitted previously

The fee switch discussion has become even harder as there is an additional layer of complexity. Previously, the stakeholders affected by this proposal were limited to that of LPs and $UNI holders. With hooks, protocols that are building on v4 will also be a stakeholder affected by the fee switch. In particular, it could switch the scene back to protocol owned liquidity (POL) instead of having to pay LPs.

Cookies thoughts: Olympus?

David believes that over time, crypto will have digital monopolies. Such monopolies will be able to expand indefinitely, given the significant Lindy effect they have

There has been suspicions raised regarding Uniswap copying CrocSwap and Balancer v2 models

The main issue was the ‘open source narrative’ painted by Uniswap, yet underlying it there is a more restrictive license that limits open innovation

There was a common consensus amongst the co-hosts that this is the power of brand and clout. David, in particular, mentioned that this will also be a contributing factor to the monopolies in the future

Context: Given the myriad of both EVM and non-EVM chains, what role does Uniswap take, and how will this role manifest from a connectivity / interoperability standpoint (e.g. bridging liquidity)

Uniswap has been deploying across L2s. Eventually, there will be a need for the entire crypto space to converge on 1 interoperability standard. This is where the main innovation for Cosmos: Inter-Blockchain Communication (IBC) comes in. IBC is essentially an interoperability standard which makes it possible to remove trust assumptions, and it is one of the most battle tested interoperability standard existing. With efforts to make L2s IBC-compatible (e.g. Polymer Labs), the DeFi vertical is moving towards a super-chain, where it’s possible for all chains to communicate

How this will potentially look like for Uniswap: Front-ends deployed on all L2s. These front-ends will be able to communicate asynchronously, made possible by IBC (or other interoperability standards). Users could be making their swap on a single front-end, when in fact the liquidity is being routed through other chains as well

It is likely that IBC will see a lot of interesting developments in the next 12 months, contributing to making the entire cross-chain experience seamless. Brilliant teams are working towards this, including Strangelove and Stride

The migration from v2 to v3 was slow, and it is anticipated that the migration from v3 to v4 might be even slower, given the complexity of deploying concentrated liquidity pools. It remains to be seen whether Uniswap might run a liquidity mining campaign to incentivize liquidity migration over to v4