Published: July 28, 2023
Uniswap TVL Source: Coingecko
Primary Chain: Ethereum Mainnet TVL
Availability on CEX: Uniswap’s native $UNI token is available on all major CEXs including Huobi, Binance, Bybit, Coinbase, Kraken, and more.
Historically Uniswap has taken an opinionated approach to liquidity provision. The protocol has balanced many tradeoffs in the process, where new features came at the expense of code complexity. This is most likely due to a lack of maturity in the industry.
Uniswap v1 and v2 were the first two iterations of the Uniswap Protocol. These versions faciliated ERC-20 <> $ETH and ERC-20 <> ERC-20 transactions, respectively. Both used a constant product
market maker (CPMM) model. Uniswap v3 introduced a large innovation in concentrated liquidity, providing more capital-efficient liquidity. It does this through the use of positions that provide liquidity within a limited price range. V3 also introduced multiple fee tiers. Concentrated liquidity and fee tiers increased flexibility for liquidity providers and allowed for new strategies to be implemented. Despite this, Uniswap v3 was not flexible enough to support new functionalities that were invented, as AMMs and markets have also evolved.
For example, v3 enshrined oracles allowed builders to integrate real-time, on-chain pricing data. But this came at the expense of some increased costs for swappers. More notably, something similar occurs with concentrated liquidity. Most passive LPs lose money due to the time and gas costs that come with actively managing positions. Concentrated liquidity is mostly reserved for DeFi power users and people with a sophisticated understanding of the protocol. People who simply wish to park their assets in a pool and earn a passive yield may not be very profitable at all.
The vision for Uniswap v4 is to increase the expressiveness of the underlying primitives. Announced as public infrastructure for the Ethereum ecosystem, the goal of Uniswap V4 is to empower developers with the appropriate tools to build their own unique primitives. Instead of making the tradeoff decisions themselves, the protocol will allow anyone to choose what they want to build and how they want to build it.
Hooks are the most notable feature of Uniswap’s new version. Basically, hooks are contracts that run at various points of a pool action’s lifecycle. This way, it will be up to external builders to add totally new functionality as they wish.
Hooks are customizable functions that can be added to a pool in order to modify its behavior. With hooks, developers can customize and augment the capabilities of the concentrated liquidity model. This makes it possible to create new pools with specified hooks that can execute before or after particular pool actions. The whitepaper and source code shows that there are currently 8 different steps.
To fully understand the potential of hooks, it is worth noting that each Uniswap liquidity pool has a lifecycle: a pool is created with a fee tier, liquidity is added, removed, or readjusted, and users swap tokens. In previous deployments, these lifecycle events are tightly coupled and must be executed in a very strict sequence.
Uniswap v4 improves upon the old implementations by allowing developers to design custom “plugins” that will perform a designated action at key points throughout the pool’s lifecycle. This could be during pool creation, before or after a swap, before or after an LP position is changed…
Hooks make it possible to dynamically adjust fees. They can create new order types
A simpler example could be the creation of protocols that have their own pools with a hook that front-runs and/or backruns swaps. It could then redistribute profits back to LPs using the donate() function.
The donate() function allows users, integrators, and hooks to directly pay in-range liquidity providers. The reward could be either or both of the LP tokens. Potential use-cases could be tipping in-range liquidity providers on TWAMM orders or new types of fee systems.
Chances are high that there will be multiple pools for the same asset pair and with a wide range of configurations (USDC-ETH #1, USDC-ETH #2, …, USDC-ETH #40, …). In that hypothetical scenario, one thing to keep an eye on is whether LPs will opt into the vanilla pools with minimalistic hooks or whether they will trust the MEV redistribution mechanisms in place.
It is reasonable to expect new trends to emerge in the development space. These could be product offerings such as “bring your own oracle” or “hooks as a service. Chances are high that a few teams take the lead and become experts in this field, similar to how the power law has shown what auditing firms are the most dominant and reliable in the industry.
One important thing to note is that hooks cannot completely modify the pricing logic – it’s always a concentrated liquidity constant product AMM (CPAMM) with ticks under the hood – but there are a couple of adjustments that can be made:
One possible benefit would be to implement an oracle-informed MEV-capturing AMM. For example, the hook could block all trading unless someone (presumably either the first trader or block builder) has submitted a fresh oracle price, which is used to create a trade that trades to the new price. Next, the profits from that strategy could be distributed to LPs.
One category that is highly impacted by this announcement is swap aggregators. Paraswap, for example, has an off-chain model of AMM logic that it keeps in sync with the current state on-chain. However, building a new model for each hook and hook combination may prevent swap aggregators from getting involved with Uniswap V4 pools.
The security implications are interesting too. Even though the core smart contracts are immutable, users will still need to watch out for hooks that are upgradeable. Some hooks could have unintended consequences for users’ funds.
Along with the improvements in terms of customization, the new protocol architecture significantly reduces transaction costs. Uniswap v4 employs a singleton model where all pools are managed by a single contract. This significantly reduces the cost of pool creation by ~99%. In other words, all pools live within a single smart contract that will enable more efficient routing across many pools. This design fully aligns with the EVM’s construction of stateful contracts, leading to a better developer experience.
For reference, another example of a smart contract that holds and manages all tokens in a single pool is Balancer’s Vault contract, which was implemented as part of the transition from Balancer V1 to Balancer V2.
Flash accounting further optimizes gas usage. Since pools are managed by the singleton contract, the protocol only needs to update an internal balance instead of executing immediate transfers from one contract to another at the end of each operation. This is especially relevant for multi-hop asset swaps implemented by the Uniswap router. For these swaps, an intermediary swap is executed in order to swap the input asset for the requested output asset.
The design for flash accounting uses “transient storage” which will be enabled by EIP-1153 in the Ethereum Cancun hard fork. Pool creators will no longer be restricted to selecting from a predefined range of fee tiers. Instead, they can choose whatever fee ratio they see as most competitive and even customize them with a dynamic fee hook that reacts to volatility or other market indicators.
One often overlooked issue is the fact that everything is a flash loan. This is related to the concept of “transient storage” as well. Callers need to first “lock”, which creates a flash loan-like accounting structure. Since no data is held in storage throughout the duration of a transaction, this helps to keep gas fees lower. When using swap aggregators, lower gas costs provide DEXs with a competitive advantage relative to their competitors. This is because they are able to route more volume through the most gas-optimized pools.
V4 also introduces support for native $ETH in trading pairs. This reduces gas costs even more since native $ETH transfers are cheaper than ERC-20 transfers. This was not the case in v2 and v3, where $ETH had to be wrapped into $WETH.
Furthermore, the fact that all pool tokens live in a single contract also means that every stablecoin’s blacklist function is effectively dead. Still, Uniswap itself could be targeted and blacklisted, though this would be more unlikely.
This new version supports the minting and burning of ERC-1155 tokens for token accounting within the singleton. By allowing users to keep tokens in the singleton contract, they can avoid ERC-20 transfers to and from the contract. This lowers gas fees for swapping significantly.
In this regard, one of the under-discussed topics is the extreme case where a pool is created with no hooks (including no oracles), native $ETH, and singleton-stored token balances. This would provide one of the most gas-efficient ways to swap assets on-chain.
Because liquidity can be fungible and pools are significantly cheaper to create, V4 becomes an actual candidate to replace multiple Uniswap V2 pools.
Uniswap v4 might be the key that opens up the doors for the emergence of new AMM designs that innovate beyond coming up with new reserves curves. One example of this could be MEV-capturing AMMs. Instead of leaking value to MEV, LPs would keep it.
Currently, the prevailing thought is that the power of transaction ordering is mostly in the hands of block-builders in the current MEV-Boost and PBS (Proposer-Builder Separation) specifications. Transaction ordering power could shift to AMM designers and liquidity providers. MEV-capturing AMMs could auction off the right of the first trade per block via a smart contract auction. This implies that normal users can only trade against the AMM after the auction winner has executed their swap. This creates a scenario where it is game-theoretically optimal for block-builders to respect the first execution right of the AMMs.They would then sort trades so that the first trade is done by the auction winner and normal user trades are not reverting. As a result, by auctioning off the first trade per block, AMMs can basically sell their MEV and capture revenue from it. This revenue can then be shared with LPs.
Additionally, it is worth noting that by delegating the power to innovate to external parties, the design space around value accrual for LPs can significantly expand. The most obvious use cases are likely to involve dynamic fees that could compensate liquidity providers for the risk they are taking by being exposed to toxic order flow caused by arbitrageurs and high market volatility. Existing AMMs already implement dynamic fees in reaction to market conditions, including
New mechanisms might explore AMM designs that resemble an order book and that make it possible for market makers to capture a wider spread. This would allow LPs to make superior returns for the inventory risk they are taking.
The V4 protocol fee mechanism is modeled after v3. V4 comes with two separate governance mechanisms: swap fees and withdrawal fees. Governance will be able to vote to adjust the fees of any particular pool, up to a capped percentage of the swap amount.
Uniswap v3:
If Hooks initially choose to turn on withdrawal fees for a pool, governance also has the ability to take up to a capped percentage of that withdrawal fee. This is in contrast with Uniswap v3, where governance does not control what fee tiers or tick spacings are allowed.
One important consideration is that the presence of hook fees could make swapping even more expensive than Uniswap v2 or v3. Not only that, but this could open up the doors for vampire attacks: if one hook creator charges a 0.05% fee, someone else can copy the code or reimplement the hook and charge a 0.01% or 0% fee.
In fact, the full list of fees is:
Despite many repeated attempts over the past years to turn on the fee switch and share revenue with token holders, there is an implicit concern that revenue-sharing might cause the protocol to be perceived as a security under the current regulatory environment. This concern has only grown stronger with hostile actions from the SEC against crypto.
With V4, the Uniswap fee switch gets an upgrade. Not only can pool deployers turn on their fee switch, competing with the Uniswap DAO, but a withdrawal fee for LPs can also be enabled. This could incentivize “stickier” liquidity.
From a business model perspective, hooks make it possible for external applications to be built on top of the core protocol immutable contracts. With hooks, Uniswap becomes a platform business that sells access to liquidity. It shifts the revenue burden to hook applications and away from directly charging LPs. By not taxing LPs, it becomes more viable to build end-consumer applications and take a cut from them. An analogy could be made with the historical returns of tech platforms like Spotify or Airbnb. These platforms allowed other businesses to deploy on top of their product, with the platform taking a cut from operations. This is a strong value proposition for Uniswap due to network effects.
Up until now, most protocols have largely enabled standalone applications. Users go to the app interface and take actions from there. This model is harder to scale and complicates user retention. This can lead to a constant effort to attract more users while retaining the current ones. At the same time, this standalone business model also forces revenue to come from liquidity providers, who are the ones that are ultimately providing the most valuable asset.
With the hook model, Uniswap effectively becomes a platform where other applications can deploy their own custom logic on top and, like any other application, collect fees in return. This is where Uniswap v4 can benefit from new earnings opportunities by taking a cut of withdrawal fees.
One interesting area that might be worth monitoring is protocols using a combination of hook and POL (Protocol-Owned-Liquidity) to have more granular control over the on-chain liquidity of their assets. As an example, using withdrawal fees and the ability to donate to liquidity providers, a protocol could incentivize buy or sell walls for their native token (at the cost of extra complexity).
One of the most controversial topics is the statement by the Uniswap team that they see Uniswap as a core financial infrastructure. Because of this, the team stated that Uniswap should be built in public with space for community feedback and contribution. The code is open and transparent but it still is released under a business license. More specifically, the Business Source License 1.1 (BSL 1.1) limits the use of Uniswap’s v4 source code in a commercial or production setting for up to 4 years. At the 4-year mark, the BSL license will convert to a GPL license into perpetuity.
Uniswap’s founder Hayden Adams and the Uniswap core team have claimed multiple times that Uniswap’s philosophy is similar to Ethereum. With this in mind, it is worth addressing the elephant in the room: Ethereum’s development is not driven by a for-profit company. Therefore, it does not have a direct conflict of interest with $ETH holders. Not only that, but none of Ethereum’s code or clients are BSL licensed.
Many have pointed out that Uniswap Labs is attempting to attach off-chain rights to the code licensing in order to compensate for the fact that the protocol may never be able to deliver actual value to $UNI holders on-chain.
Ultimately, Uniswap Labs has built 5 core products so far. The DAO owns the on-chain products while Labs owns the products with a fiat component. These issues are not isolated to Uniswap, but $UNI often gets the spotlight due to the massive amount of capital that is at stake.
This approach reflects an unfortunate trend in crypto as more protocols move away from developing truly open-source code. Even though Uniswap Labs and Uniswap Governance can grant exceptions to the current BSL license, this is still a problem. Uniswap users are not necessarily $UNI token holders. Even if they wanted to contribute to Uniswap’s “build-in-public” approach, one should not need to be a token holder to use a DeFi application.
Uniswap V4 can be described as core public infrastructure, as the team puts it. In addition, it is also a developer tool for building on-chain AMMs and a broad range of financial derivatives. Custom hooks allow developers to leverage the security and network effects of Uniswap without needing to build their own DEX from scratch. This makes it a lot easier to ship new DEX designs. This follows a trend of products and solutions in crypto that are aimed at making things easier for developers. Synthetix V3 for example, enables the creation of completely unique derivatives applications that use pre-existing Synthetix liquidity. Solutions like Agoric provide DeFi building blocks and components that shorten the time it takes developers to launch on-chain applications.
The expressivity of the system also raises the question of whether it makes sense to start out a new AMM design from scratch instead of building on top of Uniswap V4 and adding custom hooks. Up until now, a big portion of Uniswap’s success comes from the guarantee that every pool implements similar functionality. Hooks, while flexible and highly customizable, may risk disrupting the historical protocol adoption, mostly due to an expanding attack surface. Because hook contracts are arbitrary, it becomes more difficult to ensure user protection for any given pool. Former versions of the protocol were much simpler and the code was rigid, making it easier to trust. Relying on auditors for looking at individual hooks will become increasingly important over time.
Guess who already found their first issue in v4.
Nothing severe (prob low-med issue): But a malicious `owner` could brick the `initialize` function, preventing new pools from being created.https://t.co/9jyWy6SPT1 https://t.co/MKVClzGaQK
— philogy | new pfp (@real_philogy) June 13, 2023
So far, the source code and whitepaper have been presented in a status of “draft” and no deployment date has been set. Community concerns have arisen particularly around the complexity of performing any aggregate multipool analysis and auditing every individual hook without enforcing some sort of development guide or standard.
It will also be interesting to keep an eye on whether Uniswap Labs will develop a custom front end. Alternatively, they could delegate that function to a community of independent front-end operators. An incentive scheme could be implemented so that operators are rewarded with a hook every time there is a swap through their own interface). However, this is unlikely to happen due to the attack surface of unsafe hooks. This forces Uniswap Labs to take a more centralized approach to building its UI in order to protect users.
"And our UI would not support unsafe hooks"
as in our UI will only support hooks that we feel are safe
— hayden.eth 🦄 (@haydenzadams) June 13, 2023
With Uniswap V4, the community has started wondering whether the fee switch is even relevant anymore. Given the non-activation in V2 and V3, we came to the realization that the decision to use governance to activate a fee switch might not have been the best for either of the stakeholders involved in the protocol.
The fee switch introduces the possibility of attracting rent-seeking market participants. Therefore, despite being a credible case to justify value accrual for the token, this could turn out to be destructive for the protocol. If activated, token holders would add no incremental value to the protocol but would now be extracting value from other participants.
The rationale is that the fee switch would disincentive LPs even more, which would lead to lower TVL and available liquidity, which would then result in more slippage and worse execution prices, leading to lower volumes and lower fees overall for existing LPs.
This takes us to V4, where the token model is superficially similar, but there are more nuances involved. Governance can choose to take a share of LP fees on a pool just like before. However, unlike in previous versions, there is no constraint on deploying pools. Therefore, in a permissionless environment, the manager of an affected pool can simply choose to deploy a new one with the same configuration. This actually circumvents the impact of the fee switch. This evidence shows that, after years of discussion, the fee switch might have caused more headaches than it really should.
Up until now, $UNI has largely been a mere governance token that is subject to the belief system of a very conservative community, and seen as uninvestable by some. However, this might change if a new token model is implemented in V4. The design surface is significantly larger than the trivial possibility of activating a nuclear fee that would affect all protocol pools – this would impose a very risky and dangerous tax on the end users.
With the protocol’s business model getting significantly better with this new version, it is the best time to catch up with a redesigned token model. The best part is that no changes to the core protocol will be required.
The popularity of Uniswap is attributed to the fact that you can trade a lot more assets than you can on a centralized exchange. In other words, the constant function market-making model is great for trading long-tail assets. This comes at the cost that, for tokens with deep liquidity, it is very hard to compete against well-established order book models, which also alleviate the pain of providing liquidity and having impermanent loss exceed any tangible revenue from swap fees.
On July 10, an interesting proposal came out in the Uniswap forum. The post suggests that, instead of using $ETH as the default base pair, one could use the $UNI token instead. This is reinforced by the fact that there is a very obvious opportunity cost to providing liquidity in $ETH – it could be staked for an average 4% APY.
Under this new proposed model, $UNI would act as the hub or connector for all long-tail assets in the protocol pools. The inspiration behind this design comes from Bancor V1. However, the conditions have changed significantly. For that reason, one can expect a different outcome. Uniswap is not the predominant Dex in Ethereum and has a mature ecosystem recording billions in transaction volume. Not only that, but $UNI also has a very high market cap for not having any utility whatsoever.
Instead of the protocol itself forcing other protocols to pair their assets with $UNI, asset managers will do so because it benefits them more than pairing against any other asset, whether it is a stablecoin or $ETH. By virtue of being more correlated to long-tail assets than $ETH, $UNI pairs are inherently less susceptible to impermanent loss.
To bring this idea to reality, two steps would be required:
First, the UCF will offer a more capital-efficient solution compared to external lending platforms like Aave. This is meant to be more similar to a B2B platform rather than a retail-facing service. LPs would only need to collateralize the deficit in their position if the pair token loses value against $UNI. The initial $UNI borrow would be restored to the UCF when the liquidity position is closed. By seeding the UCF with 100 million $UNI and setting a 0% borrow rate, Uniswap Governance could increase demand for $UNI and remove tokens from circulation gradually over time.
Second, this proposal acknowledges the possibility of increased sell pressure of incentives. However, considering the treasury’s value of $2B, these incentives might even elevate the treasury’s value even more. If the implementation succeeds, $UNI could effectively become a reference index for long-tail assets.
Even at 0% borrow rates, we still find ways in which value can accrue to token holders. Ease of access to credit promotes $UNI’s role in liquidity markets, which increases the demand for the token. Not only that, but the UCF could also be able to take a configurable share of the $UNI side of swap fees generated by the hook’s positions, thereby removing tokens from circulation over time.
Finally, even if Uniswap governance ends up either rejecting or overlooking these proposals, it is worth keeping an eye on other projects and Dexes that might end up doing something similar.
Uniswap V4 puts developers at the forefront and unlocks endless possibilities for building DeFi applications on Uniswap Infrastructure. Between flash accounting, hooks, and other features, V4 brings a lot to the table. By pushing development efforts to the edges, it is yet to be seen whether the added abstraction and code complexity give more confidence for developers to build on V4. This additional code could come at the cost of increased security concerns. It is also reasonable to expect that a small group of development studios will emerge that act as middlemen, developing hooks for other projects to use.
With its new version, Uniswap becomes a platform business that sells access to its liquidity. It shifts the revenue burden to hook applications and away from directly charging LPs via fees. With this in mind, it becomes more viable to build end-consumer applications and take a cut from them.
Finally, new venues for value accrual become possible thanks to the inherent design of V4. This could lead to a 180-degree turn in the tokenomics of $UNI, potentially converting it into a reference or index for long-tail assets, increasing demand.
Revelo Intel has never had a commercial relationship with Uniswap and this report was not paid for or commissioned in any way.
Members of the Revelo Intel team, including those directly involved in the analysis above, may have positions in the tokens discussed.
This content is provided for educational purposes only and does not constitute financial or investment advice. You should do your own research and only invest what you can afford to lose. Revelo Intel is a research platform and not an investment or financial advisor.
