Without accounting for any implementation considerations, the answer is Yes.
Uniswap v3 is the best dex by basically any metric and wins market share wherever it’s deployed
BNB Chain is the second most important chain by economic activity per Polynya
The Business Source License expires at the end of April
You can combine the points above into a tweet: Uniswap stands to capture material market share on a chain where there’s lots of activity happening. Doing so would drive value to both swappers and LPs, expanding the protocol’s reach. If the DAO does not deploy soon, the codebase will be forked and someone else will do it. Therefore, the DAO should deploy.
With that in mind, let’s take a look at the implementation considerations. There’s really only one. Any non-mainnet deployment of Uniswap needs to be able to receive messages from the mainnet governance contracts. This cross-chain communication is enabled by a Bridge protocol. Bridging is a hard technical problem, and there are many different approaches to how it can be accomplished, each with their own trust assumptions and potential attack vectors.
For this vote in particular, I believe the choice of bridge provider is a secondary consideration that should not impact the vote of a tokenholder whose incentives are directly aligned with Uniswap.
There are three primary facts that drive my reasoning here.
In this particular case the economic attack surface of any bridge implementation, while not zero, is quite small. I’ll add an appendix describing how I think about the worst possible outcome of an attack.
The community, with the help of the Uniswap Foundation, is galvanized and taking action to move towards at best a multi-bridge solution that mitigates the security concerns from a single bridge and at worst a framework to better evaluate and implement cross-chain messaging in future deployments. In other words, the bridge that is used in the BNB deployment is subject to change, and I believe with a relatively high degree of confidence that it will change in the medium-term future.
Any delays (e.g. waiting for the above framework to be finished, or a multi-bridge cross chain aggregation protocol to be built and audited) would likely push this deployment back until after the expiration of the BSL.
Despite all that, I have to believe that we’ll see some large token holders abstain from voting until the proposal reaches a quorum and then voting against if and when it does. Bridge projects have raised huge amounts of money from venture capital, resulting in firms with a large number of UNI tokens also holding positions in potential service providers. While the Uniswap use case will not generate meaningful revenue for the project that is chosen to manage the messaging requirements of Uniswap’s BNB deployment, there is some reputational cachet up for grabs.
For some VC delegates, the incremental benefit to their UNI position of a Yes vote is likely outweighed by the incremental detriment to their NotWormholeBridgeProject position that would result from the vote passing and the protocol using Wormhole to implement it. Uniswap is after all a relatively mature protocol with a liquid token and an already-huge market cap. Bridge providers are uniformly nascent, and each is scrambling for legitimacy in a crowded market with uncertain economics. The competitive advantage provided by a synthetic endorsement by Uniswap governance could be material.
In the simplest possible terms - VC delegates that are invested in a Wormhole competitor are economically incentivize to vote against this proposal.
My point here is not to slag off the VC firms that are going to vote against this proposal, but rather to raise the point that tokenholder governance as we have it currently implemented is not guaranteed to produce the best outcome for the protocol or for tokenholders. Conflicts of interest abound and are not limited to VC delegates (service providers who vote, ourselves included, immediately spring to mind). I don’t know that a world exists where we can eliminate these frictions entirely, but one of the reasons I love the governance side of my job is that there’s basically infinite green space to think about and experiment with mechanisms to iteratively improve the way we do things. I’m looking forward to watching things evolve and adding value as and when I can.
Uniswap’s cross-chain governance use case requires a bridge to pass instructions from the mainnet Governor contract to specific contracts on the destination chain. There are no tokens flowing back and forth, just function calls. In order for an attacker to make money on a bridge vulnerability, they would need to pass one set of instructions from mainnet to the destination chain turning on the fee switch in specific pools, wait for fees to accrue to those pools through trading activity, then send another set of instructions collecting the fees to their personal wallet.
To put a number on that risk, we could look at the fees generated for liquidity providers by the protocol on mainnet in January ($26m) and take 25%, which is the max the protocol can extract for itself according to the whitepaper. This gives a total monthly protocol fee (and potential honeypot) of $6.5m. Not a tiny amount of money. However, this is a naive worst case scenario, because:
Mainnet’s fees collected are ~10x those of Arbitrum, the next most active deployment by fees collected
The sum of fees collected as reported by Asymmetric Defi are from every pool; turning on the fee switch in each pool requires its own function call from the Governor
Liquidity would dry up if LP returns suddenly dropped by 25%, volume would drop commensurately
Let’s adjust the $6.5m number to account for each.
A Uniswap deployment on BNB Chain could conceivably do more volume than the Arbitrum deployment. Let’s say it’s double; total LP fees collected could be somewhere in the ballpark of $6m.
The Alastor report from the fall shows that the vast majority of volume flows through a small number of pools, let’s say it’s sort of pareto-ish because i’m too lazy to dig it up and that’s probably directionally right. Assuming the attacker could turn on the fee switch for 20% of the BNB Chain pools, they’d have access to ~80% of the fees. That puts us at (.80 * 6) = $4.8m.
The changes in volume due to the fee switch are notoriously hard to model, but let’s assume that worse LP economics leads to worse liquidity conditions lead to lower volume numbers and just assign it a 10% discount. That puts our total LP fee pool at $4.32m, and assuming the attacker has turned the fee switch on the target pools to 25%, a total honeypot of just over $1m a month.
In order for this hack to be successful, we also have to assume that no one has noticed that the fee switch has been turned on in multiple BNB Chain pools, and that it’s been allowed to run for a month in this manner. If you’re an attacker, does this seem worth it?
Not being an attacker, I’m not really sure of the answer to that. But as a delegate who has votes, I am assigning it a low probability, and believe that the expected value of a BNB Chain deployment net of this risk is greater than zero.