The Uniswap community and in particular those of us who participate in UNI token governance have only ever had to consider our roles in relation to a set of contracts which enable the core AMM functionality. Specifically, Uniswap users have only ever been able to:
Though its on-chain components are also governed by UNI token holders, the functionality UniswapX enables is a departure from these core functionalities. While we believe its feature set is complementary to the AMM and its development was driven by user needs that the core AMM cannot service, it is a distinctly new protocol.
At the Uniswap Foundation, we are still thinking about how X fits into our mandate. Clearly, it did not exist when the proposal that funded our organization was passed almost a year ago. Just as clearly (we believe), if it is successful, the core AMM benefits in a big way.
Similarly, the DAO has never had to govern anything other than the AMM. Should cross-chain deployments of X be declared canonical in the same way? Should the fee switch be turned on? Do you, as delegates, care about either of those questions?
This post will attempt to set the scene to allow the community to consider how X might be incorporated into the greater ecosystem. We will touch on the basic architecture of X including its on-chain components and the off-chain services required for its success as well as the functionality it enables and how that functionality works alongside Uniswap’s core AMM.
We are still digesting UniswapX’s design and features, as well as its implications for DAO governance and where it fits within the Foundation’s scope of work. To that end, we would love to hear from the community. What do you think about UniswapX? Feel free to start a discussion in the comments, or book a time to chat with me here.
X the protocol is a collection of open source, immutable smart contracts. The protocol’s core contracts are known as Reactors. At a high level, Reactors interpret trade orders and coordinate the distribution of tokens between counterparties according to rules encoded in those orders. While they are highly configurable contracts, each Reactor contract can only interpret one order type.
Reactors make use of signed orders, which necessitates a change in the transaction flow for Swappers. Instead of constructing a trade transaction and broadcasting it to the mempool themselves, Swappers instead just add their signature to a piece of offchain data that contains the terms of a trade that they would be willing to do; someone else executes it for them.
Reactor contracts can manage the distribution of fees on a trade-by-trade basis. Fees can be defined in two ways:
ProtocolFeeController contract. That contract’s configuration determines the criteria of trades that should be charged a fee, the address to which the fees are sent, and the rate (no greater than 5 basis points of the output token). A governance vote is required to enable the ProtocolFeeController contract.In the future there may be many different X Reactors, but there is currently a single implementation handling order flow on Ethereum mainnet. It uses a mechanism similar to a Dutch Auction (referred to in the documentation as a Dutch Order) to guarantee best execution for the swapper. You can read more about Dutch Auctions here.
The counterparties in a X trade are known as Swappers and Fillers. Both roles are entirely permissionless (and you can read about creating a Filler here).
Swappers add their signature to a piece of data known as an Order. An Order authorizes the exchange of token A for token B according to whatever rules the Reactor requires (starting price, reserve price, and time limit for a Dutch order).
Fillers ingest these orders programmatically and calculate the best price at which they can execute them. In practice, this likely involves surveying a number of on- and off-chain liquidity sources, including calculating the optimal route through Uniswap v2 and v3 pools (and eventually v4). When they’ve determined the best price they can provide based on the optimal combination of their available liquidity, a Filler is incentivized to submit the completed order as quickly as possible by calling a function on the Reactor; every other Filler in existence is trying to do the same. Once a valid order has been submitted, the Reactor executes it.
There are several important factors that will determine the success or failure of X that cannot be managed on-chain. We will discuss two of them here.
Order discovery Fillers are incentivized to execute orders at the best price possible because if they don’t, someone else will. However, a Filler that has exclusive access to some source of order flow does not face the same competition. If execution quality drops, Swappers will look elsewhere. It is therefore of paramount importance that as many Fillers as possible see every order and compete to fill it.
Orders are currently initiated by Swappers on the Uniswap Labs-owned app.uniswap.org. They are then passed to an API, also owned by Labs, where they are broadcast through a separate endpoint for Fillers to monitor, ingest, and execute.
Alternative UIs, such as GFX Labs’ Oku, can coordinate with Labs and configure their front ends to pass orders to this same API. Those orders would then also be broadcasted to the Filler. Front ends, or the Swappers that use them, are responsible for parameterizing each order.
This API is currently the only solution for order discovery.
Order parameterization The execution of a Dutch order requires that a Filler can provide a valid price for the trade between when the auction begins and when it ends. The parameters that determine whether a price is valid are set by the Swapper with help from the UI where they generated the order. A badly parameterized order will never be filled, so it is important that the UI provide guidance to the Swapper in setting these parameters (or abstract the process away entirely).
Uniswap Labs runs a proprietary RFQ service to help determine the Dutch order parameters of the orders that Swappers broadcast from their front end to the Filler network. Other front ends may take similar approaches, or they could approach the problem in a different manner entirely. In general, the better-parameterized the orders that are being broadcast to the Filler network, the more volume will flow through X.
Hayden has done a good job describing Uniswap Labs’ rationale behind building X and we recommend watching his ethCC presentation or listening to his Bankless podcast interview. At the Foundation, we have spent a lot of time digging into X and believe that there are two primary ways that it benefits the larger Uniswap ecosystem.
While AMMs have created a novel primitive that makes aggregating liquidity at scale possible, they do not provide the swapping ergonomics required for mass adoption. In other words, the design decisions that make Uniswap v3 an efficient place for Liquidity Providers to deploy capital cause some shortcomings in the Swapper’s user experience. Specific examples of these shortcomings include:
Implementing features that solve for any one of these problems within the AMM itself would require tradeoffs in the existing design. Those tradeoffs would almost certainly come at the cost of a degraded Liquidity Provider feature set. Instead of making sacrifices that might decrease the efficacy of the protocol for Liquidity Providers, X separates the concerns entirely. Effectively, X provides Swappers with customizable access to the liquidity provided by the core AMM’s Liquidity Providers. The Dutch Order format that is currently live eliminates four of the failures noted above, and a pending cross-chain release handles the fifth.
Uniswap v4 presents a massively expanded design space for what a liquidity pool can look like. This expansion is exciting, but it comes at the cost of liquidity fragmentation - there can be dozens or hundreds of distinct pools per token pair, and each pool might make use of a hook that impacts the prices at which it will execute a swap. While the gas cost of routing through many pools to execute a single trade will drop dramatically because of the new singleton architecture, the computational overhead of determining that route has grown exponentially due to the increased complexity. Uniswap Labs’ lead protocol developer Will Pote describes the problem well here.
X provides incentives, in the form of order flow, for any team in the world to build and maintain the best routing algorithm possible. Pote mentions in his thread that “...the skill ceiling for finding swap routes on V4 is significantly higher than V3” and this is undoubtedly true. A potential corollary is that the skill variance between routing teams could also be quite high. If X is processing a large volume of order flow, the profit potential for best-in-class router teams is very, very high. Creating a marketplace for routers, which is one of the stated goals of X, is one potential solution to the massively expanded complexity of the problem routers are trying to solve.
While these benefits are compelling, there are open questions about X’s impact on the current state of the Uniswap protocol. In particular, the Foundation is considering the impact X will have on the AMM’s liquidity in fat tail pairs as well as those parties who provide it, and the potential aggregation of network effects to centralized order discovery services that are not owned by the DAO. We are interested in hearing feedback on the concerns, as well as any issues that we may not have considered. We encourage you to post in the comments here or open another topic entirely.
The Uniswap community and in particular those of us who participate in UNI token governance have only ever had to consider our roles in relation to a set of contracts which enable the core AMM functionality. Specifically, Uniswap users have only ever been able to:
Though its on-chain components are also governed by UNI token holders, the functionality UniswapX enables is a departure from these core functionalities. While we believe its feature set is complementary to the AMM and its development was driven by user needs that the core AMM cannot service, it is a distinctly new protocol.
At the Uniswap Foundation, we are still thinking about how X fits into our mandate. Clearly, it did not exist when the proposal that funded our organization was passed almost a year ago. Just as clearly (we believe), if it is successful, the core AMM benefits in a big way.
Similarly, the DAO has never had to govern anything other than the AMM. Should cross-chain deployments of X be declared canonical in the same way? Should the fee switch be turned on? Do you, as delegates, care about either of those questions?
This post will attempt to set the scene to allow the community to consider how X might be incorporated into the greater ecosystem. We will touch on the basic architecture of X including its on-chain components and the off-chain services required for its success as well as the functionality it enables and how that functionality works alongside Uniswap’s core AMM.
We are still digesting UniswapX’s design and features, as well as its implications for DAO governance and where it fits within the Foundation’s scope of work. To that end, we would love to hear from the community. What do you think about UniswapX? Feel free to start a discussion in the comments, or book a time to chat with me here.
X the protocol is a collection of open source, immutable smart contracts. The protocol’s core contracts are known as Reactors. At a high level, Reactors interpret trade orders and coordinate the distribution of tokens between counterparties according to rules encoded in those orders. While they are highly configurable contracts, each Reactor contract can only interpret one order type.
Reactors make use of signed orders, which necessitates a change in the transaction flow for Swappers. Instead of constructing a trade transaction and broadcasting it to the mempool themselves, Swappers instead just add their signature to a piece of offchain data that contains the terms of a trade that they would be willing to do; someone else executes it for them.
Reactor contracts can manage the distribution of fees on a trade-by-trade basis. Fees can be defined in two ways:
ProtocolFeeController contract. That contract’s configuration determines the criteria of trades that should be charged a fee, the address to which the fees are sent, and the rate (no greater than 5 basis points of the output token). A governance vote is required to enable the ProtocolFeeController contract.In the future there may be many different X Reactors, but there is currently a single implementation handling order flow on Ethereum mainnet. It uses a mechanism similar to a Dutch Auction (referred to in the documentation as a Dutch Order) to guarantee best execution for the swapper. You can read more about Dutch Auctions here.
The counterparties in a X trade are known as Swappers and Fillers. Both roles are entirely permissionless (and you can read about creating a Filler here).
Swappers add their signature to a piece of data known as an Order. An Order authorizes the exchange of token A for token B according to whatever rules the Reactor requires (starting price, reserve price, and time limit for a Dutch order).
Fillers ingest these orders programmatically and calculate the best price at which they can execute them. In practice, this likely involves surveying a number of on- and off-chain liquidity sources, including calculating the optimal route through Uniswap v2 and v3 pools (and eventually v4). When they’ve determined the best price they can provide based on the optimal combination of their available liquidity, a Filler is incentivized to submit the completed order as quickly as possible by calling a function on the Reactor; every other Filler in existence is trying to do the same. Once a valid order has been submitted, the Reactor executes it.
There are several important factors that will determine the success or failure of X that cannot be managed on-chain. We will discuss two of them here.
Order discovery Fillers are incentivized to execute orders at the best price possible because if they don’t, someone else will. However, a Filler that has exclusive access to some source of order flow does not face the same competition. If execution quality drops, Swappers will look elsewhere. It is therefore of paramount importance that as many Fillers as possible see every order and compete to fill it.
Orders are currently initiated by Swappers on the Uniswap Labs-owned app.uniswap.org. They are then passed to an API, also owned by Labs, where they are broadcast through a separate endpoint for Fillers to monitor, ingest, and execute.
Alternative UIs, such as GFX Labs’ Oku, can coordinate with Labs and configure their front ends to pass orders to this same API. Those orders would then also be broadcasted to the Filler. Front ends, or the Swappers that use them, are responsible for parameterizing each order.
This API is currently the only solution for order discovery.
Order parameterization The execution of a Dutch order requires that a Filler can provide a valid price for the trade between when the auction begins and when it ends. The parameters that determine whether a price is valid are set by the Swapper with help from the UI where they generated the order. A badly parameterized order will never be filled, so it is important that the UI provide guidance to the Swapper in setting these parameters (or abstract the process away entirely).
Uniswap Labs runs a proprietary RFQ service to help determine the Dutch order parameters of the orders that Swappers broadcast from their front end to the Filler network. Other front ends may take similar approaches, or they could approach the problem in a different manner entirely. In general, the better-parameterized the orders that are being broadcast to the Filler network, the more volume will flow through X.
Hayden has done a good job describing Uniswap Labs’ rationale behind building X and we recommend watching his ethCC presentation or listening to his Bankless podcast interview. At the Foundation, we have spent a lot of time digging into X and believe that there are two primary ways that it benefits the larger Uniswap ecosystem.
While AMMs have created a novel primitive that makes aggregating liquidity at scale possible, they do not provide the swapping ergonomics required for mass adoption. In other words, the design decisions that make Uniswap v3 an efficient place for Liquidity Providers to deploy capital cause some shortcomings in the Swapper’s user experience. Specific examples of these shortcomings include:
Implementing features that solve for any one of these problems within the AMM itself would require tradeoffs in the existing design. Those tradeoffs would almost certainly come at the cost of a degraded Liquidity Provider feature set. Instead of making sacrifices that might decrease the efficacy of the protocol for Liquidity Providers, X separates the concerns entirely. Effectively, X provides Swappers with customizable access to the liquidity provided by the core AMM’s Liquidity Providers. The Dutch Order format that is currently live eliminates four of the failures noted above, and a pending cross-chain release handles the fifth.
Uniswap v4 presents a massively expanded design space for what a liquidity pool can look like. This expansion is exciting, but it comes at the cost of liquidity fragmentation - there can be dozens or hundreds of distinct pools per token pair, and each pool might make use of a hook that impacts the prices at which it will execute a swap. While the gas cost of routing through many pools to execute a single trade will drop dramatically because of the new singleton architecture, the computational overhead of determining that route has grown exponentially due to the increased complexity. Uniswap Labs’ lead protocol developer Will Pote describes the problem well here.
X provides incentives, in the form of order flow, for any team in the world to build and maintain the best routing algorithm possible. Pote mentions in his thread that “...the skill ceiling for finding swap routes on V4 is significantly higher than V3” and this is undoubtedly true. A potential corollary is that the skill variance between routing teams could also be quite high. If X is processing a large volume of order flow, the profit potential for best-in-class router teams is very, very high. Creating a marketplace for routers, which is one of the stated goals of X, is one potential solution to the massively expanded complexity of the problem routers are trying to solve.
While these benefits are compelling, there are open questions about X’s impact on the current state of the Uniswap protocol. In particular, the Foundation is considering the impact X will have on the AMM’s liquidity in fat tail pairs as well as those parties who provide it, and the potential aggregation of network effects to centralized order discovery services that are not owned by the DAO. We are interested in hearing feedback on the concerns, as well as any issues that we may not have considered. We encourage you to post in the comments here or open another topic entirely.
On enabling cross-chain liquidity, I'm referring to UniswapX GitHub branch xchain
I want to ask if the Uniswap team has any public details about what chains will be supported. And what cross-chain Bridges/Relayers candidate you guys are considering? Can I assume that the discussion about the "cross chain bridge assessment" earlier this year is relevant?
Hi Kydo - Can you expand on "Uniswap quoter RFQ by default, Filler dutch auction for back up" a bit more and how that benefits the protocol?
I'm having trouble understanding what the advantage to LP'ing on Uniswap is, if RFQ get first access to fill orders?
On enabling cross-chain liquidity, I'm referring to UniswapX GitHub branch xchain
I want to ask if the Uniswap team has any public details about what chains will be supported. And what cross-chain Bridges/Relayers candidate you guys are considering? Can I assume that the discussion about the "cross chain bridge assessment" earlier this year is relevant?
Hi Kydo - Can you expand on "Uniswap quoter RFQ by default, Filler dutch auction for back up" a bit more and how that benefits the protocol?
I'm having trouble understanding what the advantage to LP'ing on Uniswap is, if RFQ get first access to fill orders?
Thank you for engaging in the conversation!
While the reactor specifies an exclusive filler, it does not specify the route which the filler must take. So, I do see that the filler will route through the various Uniswap pools.
Thank you for engaging in the conversation!
While the reactor specifies an exclusive filler, it does not specify the route which the filler must take. So, I do see that the filler will route through the various Uniswap pools.
Wrt "advantage of providing liquidity," I am not sure what you mean by this. If you are asking "what is the impact of UniswapX on LPing on Uniswap pools," I think that is a big question, and I am not qualified to answer that.
Thank you for engaging in the conversation!
While the reactor specifies an exclusive filler, it does not specify the route which the filler must take. So, I do see that the filler will route through the various Uniswap pools.
Thank you for engaging in the conversation!
While the reactor specifies an exclusive filler, it does not specify the route which the filler must take. So, I do see that the filler will route through the various Uniswap pools.
Wrt "advantage of providing liquidity," I am not sure what you mean by this. If you are asking "what is the impact of UniswapX on LPing on Uniswap pools," I think that is a big question, and I am not qualified to answer that.
Hey phil - I don't think Uniswap Labs has released any details yet other than what Hayden's said in podcasts. That branch you mention hasn't been touched in 5 months so I wouldn't expect it to be an accurate representation of what eventually gets released. I'm not sure when Labs will publish the final version.
One thing I do know is that the Bridge Assessment Committee (which released this report) was run by the Uniswap Foundation which is completely separate from Uniswap Labs.
Kydo from Native here.
Thank you, @eek637, for your post. It's a great summary of UniswapX and the best explanation I've come across.
UniswapX marks a significant turning point for the DAO. It changes the power dynamics among the protocol, the Labs, and the DAO, prompting us to reconsider our roles.
Kydo from Native here.
Thank you, @eek637, for your post. It's a great summary of UniswapX and the best explanation I've come across.
UniswapX marks a significant turning point for the DAO. It changes the power dynamics among the protocol, the Labs, and the DAO, prompting us to reconsider our roles.
The key lies in the nuances. The currently live reactor is the Exclusive Dutch Order Reactor, accessible at this address. This reactor accepts orders with an exclusiveFiller field. exclusiveFiller designates a unique filler who can execute an order before its Dutch auction start time.
This single field changes everything. It introduces another filler network, an RFQ network of Quoters. Unlike on-chain fillers, quoters compete in a (currently) private network hosted by the Labs.
Based on the available information, it's reasonable to assume that the front-end will route through the Exclusive Dutch Order Reactor. Additionally, when a user signs an order, it can only be executed by this one reactor.
In effect, the swapping flow on Uniswap becomes "Uniswap quoter RFQ by default, Filler dutch auction for back up"
While the Labs have been operating the front-end for years, they previously lacked the ability to choose the liquidity provider; they could only select routes across pools. However, with exclusiveFiller, the Labs gain the power to choose the liquidity provider.
I believe this change is necessary for improving the user experience in trade execution. However, it significantly alters the power dynamics among the protocol, the Labs, and the DAO. This shift is also evident in the licensing of each protocol. Unlike V3 and V4, UniswapX operates under the General Public License v3.0.
In summary, UniswapX represents a crucial milestone in the DAO's journey. Successfully navigating this milestone will bring immense benefits to the DAO.
I urge all delegates to thoroughly read this post and actively participate in this discussion.
Hey phil - I don't think Uniswap Labs has released any details yet other than what Hayden's said in podcasts. That branch you mention hasn't been touched in 5 months so I wouldn't expect it to be an accurate representation of what eventually gets released. I'm not sure when Labs will publish the final version.
One thing I do know is that the Bridge Assessment Committee (which released this report) was run by the Uniswap Foundation which is completely separate from Uniswap Labs.
Kydo from Native here.
Thank you, @eek637, for your post. It's a great summary of UniswapX and the best explanation I've come across.
UniswapX marks a significant turning point for the DAO. It changes the power dynamics among the protocol, the Labs, and the DAO, prompting us to reconsider our roles.
Kydo from Native here.
Thank you, @eek637, for your post. It's a great summary of UniswapX and the best explanation I've come across.
UniswapX marks a significant turning point for the DAO. It changes the power dynamics among the protocol, the Labs, and the DAO, prompting us to reconsider our roles.
The key lies in the nuances. The currently live reactor is the Exclusive Dutch Order Reactor, accessible at this address. This reactor accepts orders with an exclusiveFiller field. exclusiveFiller designates a unique filler who can execute an order before its Dutch auction start time.
This single field changes everything. It introduces another filler network, an RFQ network of Quoters. Unlike on-chain fillers, quoters compete in a (currently) private network hosted by the Labs.
Based on the available information, it's reasonable to assume that the front-end will route through the Exclusive Dutch Order Reactor. Additionally, when a user signs an order, it can only be executed by this one reactor.
In effect, the swapping flow on Uniswap becomes "Uniswap quoter RFQ by default, Filler dutch auction for back up"
While the Labs have been operating the front-end for years, they previously lacked the ability to choose the liquidity provider; they could only select routes across pools. However, with exclusiveFiller, the Labs gain the power to choose the liquidity provider.
I believe this change is necessary for improving the user experience in trade execution. However, it significantly alters the power dynamics among the protocol, the Labs, and the DAO. This shift is also evident in the licensing of each protocol. Unlike V3 and V4, UniswapX operates under the General Public License v3.0.
In summary, UniswapX represents a crucial milestone in the DAO's journey. Successfully navigating this milestone will bring immense benefits to the DAO.
I urge all delegates to thoroughly read this post and actively participate in this discussion.