Yup 100%! Just want to make sure there is clarity
I believe it’s too early to pick any solution. Because all these solutions are early, Uniswap is way too important for this ecosystem’s health, and we still haven’t fully understood each provider’s implications and loopholes.
Would love to provide some insightful links, but don’t have the permissions.
We know we’re late to the party, but we wanted to throw our hat in the ring as well. We understand it’s too late to be formally considered in the temp check vote, but we’d love to have Hyperlane (fka Abacus) considered in future votes. We were previously involved in the RFP process, and chosen by several well known delegates alongside Axelar, which is also conspicuously missing from this vote! You can read more about that here: RFC: Uniswap Universal Governance Module - #21 by blockchaincolumbia
We’ll be submitting our case formally through the Cross Chain Bridge Assessment process, in that thread, using the template provided.
Hey all, we’ve (a16z) reviewed the various bridge proposals, evaluated each, and strongly support LayerZero. We’re unable to vote in the current Snapshot due to infrastructure limitations with the custodian on short notice, but we will be participating in the on-chain vote when it goes live, in addition to any new Snapshot votes that may come up. We just wanted to put this out before the vote ends tomorrow morning for clarity on the process from our end.
There’s been a lot of back and forth in the thread around immutability, decentralization, trusted entities, and degrees of control by cross-chain messaging protocols. We wanted to clarify these discussion points by calling out the two ways Uniswap would integrate a messaging layer and comparing the guarantees of both Wormhole and LayerZero under each scenario.
Simply put, the two scenarios are:
- Uniswap runs infrastructure
- Uniswap doesn’t run infrastructure
LayerZero suggests that integrators can either use their “default” configuration, a low-security option or run infrastructure via a “custom” configuration.
The latter model is proposed as the method by which the application developer (in this case Uniswap) can avoid collusion risk between the default Oracle and Relayer infrastructure operators within LayerZero. Additionally, in this model, Uniswap or its delegates would need to run infrastructure such as a “gasless Oracle” (which has not been released yet), which the LayerZero Relayer would pick up and deliver to the destination. Relayers in LayerZero are always permissioned and are required for liveness and security, thus Uniswap would also have to run Relayer infrastructure. The Relayer source code is currently not open-source, so Uniswap would need to implement a bespoke untested solution or run LayerZero’s proprietary implementation.
However, this may still be problematic. Due to the Proof Library requiring ongoing mitigation with each chain, a non-default config is **insufficient until the issue above is addressed. The LayerZero team can add a new default chain config, register a default proof handler, and exploit an application in a single atomic transaction. The application cannot mitigate this using configuration. Applications can only mitigate via a custom relayer and potentially an “approved chains” list in the application itself. The flagship application on LayerZero, Stargate, itself is semi-immutable and will have a difficult time mitigating this issue, and would need to make a custom Proof Library to implement the approved chains list.
TL;DR — if Uniswap does not want to trust LayerZero’s current default configuration, it needs to run its own infrastructure. Even when doing so, there are underlying issues that necessitate further action from LayerZero’s team to truly make any custom infrastructure setup truly trustless.
We want to clarify that if Uniswap wants to run its own infrastructure with Wormhole, it can achieve the same level of customization that LayerZero touts, as no protocol has a monopoly on deploying bespoke infra. If desired, Uniswap can configure a deployment of Wormhole, which improves upon the security guarantees of LayerZero’s default while also ensuring sovereign security relative to the canonical Wormhole deployment.
Wormhole’s contracts are designed so that the Guardian set is customizable on initial deployment (see here: Setup.sol) and can further be rotated via an in-protocol governance mechanism whereby the current guardian set can vote on the next guardian set. Should Uniswap delegates decide to run their own infrastructure, they may run their own oracle nodes by following instructions at Operations.md. In this model, Uniswap oracles produce signed observations (VAAs) which can be submitted permissionlessly on the target chain (BNB), so no relayer infra is needed, and therefore no need to manage gas funds. However, relayers can very easily be made permissioned if desired, which would allow Uniswap to run a permissioned relayer like the one discussed in the LayerZero model.
From a security and operational load perspective, however, we could offer Uniswap to layer their signers on top of Wormhole i.e. extend the already robust Guardian set with their additional validators. This option surpasses the level of flexibility and security of LayerZero’s oracle (in this case Wormhole) and Relayer (chosen by Uniswap) mode in which Uniswap benefits from Wormhole’s significantly more robust signer set but is safe as long as the signer set does not collude with the Uniswap chosen signers. We start from the far stronger base of 19 signers and can arbitrarily increase security beyond that with additional Uniswap-affiliated validators. The easiest way to produce these additional signatures is for the Uniswap DAO signers to download and run the existing, open-source, and in-production Wormhole oracle software. After verifying the Wormhole signatures, the Uniswap governance contract can verify these additional signatures from the selected Uniswap DAO signers. Additionally, relayers can very quickly be permissioned, allowing Uniswap to run a permissioned relayer like the one discussed in the LayerZero model.
While the proxy contract can point to different implementations, the Wormhole implementation contract is immutable. Thus it is trivial to verify governance messages against a specified implementation. While there are multiple ways to accomplish this, the most straightforward is just including the pinned implementation as an external library in your deployment.
This deployment can be done in a fully permissionless manner without having to trust (or ever interact) with the 19 Guardians that operate the default Wormhole deployment.
The security assumption of LayerZero’s default configuration is that the default Oracle and Relayer are independent. Uniswap would have to trust a 2/2 multisig of these two components. The relayer is unverified, but LayerZero claims that this is not an issue:
“It is common practice to not open source or verify Oracle and Relayer smart contracts. *These smart contracts are only responsible for on-chain quoting in gas. All validation logic resides immutably in the messaging library.
*****These smart contracts can only quote pricing and do not affect security in any way, therefore being verified is irrelevant to its purpose.”
This statement contradicts with the LayerZero whitepaper, which claims the following:
“Given two entities that do not collude, if (1) one entity can produce a block header for the block containing tA on chain A, (2) the other entity can independently produce the proof for tA on that block (transaction proof), and (3) the header and transaction proof in fact agree, then the communication protocol can deliver m to the client on chain B with the guarantee that tA is stably committed on chain A.”
The Oracle is responsible for producing the block headers, and the Relayer is responsible for the inclusion proofs — these responsibilities are far beyond on-chain gas quoting.
“LayerZero leverages direct MPT validation construction of the source transaction and verifies the merkle inclusion proof directly on the destination chain via the protocol’s novel Ultra Light Node (ULN).”
At this point, it’s unclear if there are other Oracle/Relayer options available to choose from outside of the default. In any case, if the Oracle and Relayer collude, they can forge messages.
Contract upgradeability is a critical discussion point. It’s true that bugs can be introduced in upgrades, but upgrades can (and do) fix existing bugs. Presenting only one side of this coin is misleading at best.
If any bugs are discovered in LayerZero’s contracts, patching them would be a significant task. Such a scenario would involve the proof validation code being implemented with a patch, and then all affected user applications would have to change their configurations to the patched implementation.
The 19 Guardians that operate Wormhole’s default deployment are the largest PoS validator companies. The safety assumption is that of an honest superminority (at least 7 of them are honest) or, conversely, that there are no 13 colluding entities. The equivalent assumption under LayerZero’s setup is that the 2 entities do not collude. The contracts are upgradeable via a governance mechanism that requires the approval of 2/3+ of the Guardians. Importantly, the Wormhole cross-chain governance solution has already been tested (see above) and implemented on testnet and is ready for production.
Happy to answer any additional questions.
Hey all, cross-posting a few thoughts from Twitter.
1/ great to see the snapshot driving attention/clarity on bridging’s role in cross-chain protocol deployments
2/ I’m abstaining from the vote as I don’t think the list of options on offer is comprehensive or deeply researched
3/ zooming out, my view is that its suboptimal for communities to be voting on singular bridge choices, effectively king-making solutions.
protocol design needs to adapt for a multi-chain world, to reap the benefits of competition through standardization, not voting.
4/ closing thought: glad the convo is moving forward , and hope this proposal will kick off more efforts to dig deeper into bridge research and protocol design to enable multiple choices.
Blockchain@Columbia’s Uniswap governance team has considered this temperature check with great importance. We appreciated @jkol 's reference to our post the RFC: Uniswap Universal Governance Module - #21 by blockchaincolumbia shared by @jason_of_cs. For anyone who hasn’t, we encourage you to read the post where we proposed a “synergy between Axelar and Hyperlane[previously Abacus] inheriting the PoS validator-set model of Axelar (AXL tokens, which could potentially in an application-specific setting be just the UNI tokens) with the application-customizability of Abacus as having the ideal model for Uniswap’s current purposes, with UNI token holders freely participating in the system (this can be implemented in a variety of ways).” We took extensive time to consider various bridging providers including LayerZero, Wormhole, Nomad, Axelar, and Hyperlane (Abacus), which wouldn’t have been possible without @jason_of_cs a prominent researcher in the AMM space.
As we know, Axelar and Hyperlane weren’t considered for this temperature check, and it raises questions on the hast at which the community is coming to a decision. @pennblockchain, as well as other university organizations, have provided sound commentary on this debate, and we agree with @devinwalsh from the UF team that “assessments of bridge security are time intensive and require significant technical expertise and context.” As of the time of writing this post, it’s clear that LayerZero and Wormhole are the two competing players to win this temperature check, and we’re fortunate to have discussions with both LayerZero and Wormhole
In light of the commentary published by James Prestwich, reading forum responses, and our belief that there are many strong contenders in the bringing space not mentioned in this vote. We find it difficult to choose between, LayerZero and Wormhole, and if an abstain/wait option existed, we’d prefer to vote that way. However, as this is a temperature check, with a deadline of tomorrow, we will be voting for Wormhole.
With more time to assess the technicalities of each bridging option, perhaps we will revise our decision and vote differently for LayerZero or other providers.
This will be our (Stanford Blockchain) final post here in this thread. More posts revolving around this issue can be found at Cross-Chain Bridge Assessment Process.
To save time and be succinct, we will focus this thread mainly on the top two contenders, LayerZero (LZ) and Wormhole (WH).
We would love to discuss further around other protocols in the thread above.
First at foremost, we enjoyed chatting with different bridge providers and their advocates. We believe as contentious as this vote is, this will not be the end for the cross-chain (x-chain for shorthand) governance discussion but the beginning.
We believe regardless of who will win the vote, this result should be temporary and should be immediately changed/updated when the Cross-Chain Bridge Assessment Process concludes. Our vote only convenes that we support the following protocol for a period of fewer than three months. In long term we believe Multi-Message-Aggregation (MMA) is the solution.
We have voted for LZ as the current preferred bridge provider. However, our vote is contingent on a few criteria. If LZ cannot fulfill these criteria, we wish to withdraw our support.
- Uniswap governance message passing will use Uniswap-community-run oracle and NOT the default oracle by ChainLink.
- The Uniswap-community-run oracle is mainnet functional no less than 3 days after the passing of the snapshot vote.
- The Uniswap-community-run oracle have no less than 5 independent signers.
- LZ will provide sufficient technical support for all oracle signers.
If LZ fails to deliver on ANY of the criteria above, Stanford Blockchain Club will NOT support LZ being the bridge provider for Uniswap governance.
We want to say that although the current snapshot will only have one “winner,” it does not mean the work other bridge providers did is wasted. In the next three weeks (laid out in the Cross-Chain Bridge Assessment Process), we would love to continue these conversations and find a long-term and more sustainable solution for x-chain governance.
As we have briefly mentioned in our previous posts (1,2), none of these solutions fits all our requirement and all of them poses serious governance risk to Uniswap; therefore we should not just decide once and move on from this issue. Instead, we should take UF’s proposal seriously and contribute more if not less time and energy to it.
Some key risks: Both WH and LZ’s oracle/relayer networks lack a slashing mechanism for malicious oracles. WH’s contract can be upgraded (can be patched with workarounds). LZ’s relayer is currently just LZ’s core team.
At Stanford Blockchain Club, we understand the difficulties of building bridges and more importantly, the current security gap between any bridge and the Ethereum network. We also recognize how early bridging technologies are and the security assumptions for these bridges might be drastically different from traditional blockchains.
We are not making statements about future designs of these bridges or what they could be; we are stating what we are seeing right now.
LZ and WH on a high level are both multisig bridges.
WH is a 1/1 multisig, with the 1 being 19 validators forming a 13/19 multisig.
LZ is a 2/2 multisig, with 1 being 5 Uniswap members, and the other 1 being LayerZero Lab.
If Ethereum’s current security level is 100, what would you assign to LZ and WH?
Therefore, we would not choose either of them to be the sole message-relaying solution for Uniswap long term. However given we have to make a decision now, we believe the LZ solution is the marginally better one.
From our conversation with bridge providers and other delegates, we believe this is the most logical next step for x-chain governance in Uniswap.
We have proposed an in-depth design on the other thread, but this graph captures it well.
The governance flow is as follows:
- Uni Gov passed on Ethereum.
- Payload to different bridge contracts sent from Timelock.
- Different bridges relay to
dst, BSC in this case.
- Bridges send governance payload to
Message Selection Contract.
- A 11/15
multisigdecides which message payload to execute.
Security analysis and design trade-offs are discussed more in the post.
To be totally unambiguous, we at a16z would have voted 15m tokens toward LayerZero if we were technically able to. And we will be able in future Snapshot votes. So, for the purposes of a “temperature check”, please count us this way.
The only question I have as a contract deployer is who will run Infra for Uniswap and custom LayerZero, and how we will manage it.
We’re excited to see the support behind deploying Uniswap v3 to Binance Smart Chain prior to the expiry of the Business Source License. At Spartan Group, we believe LayerZero’s bridge will be the most secure and decentralized solution for Uniswap, and will be voting to support their solution. We reviewed the different proposals, and believe LayerZero’s approach is the most thoughtful, and appreciate their willingness to engage with the community. Disclosure: we are investors in LayerZero (for the above reasons) and we are also significant holders of UNI tokens.
This will be our (FranklinDAO/Penn) last post here seeing the impending 3 hour deadline for votes. Since we last posted here a few hours ago where we expressed our opinions regarding how we believe future bridging solutions should go, we are currently abstaining from a vote.
For some background, this has certainly been the #1 most lobbied vote on Uniswap that we have ever partaken in. Our opinions expressed above should be coupled with this thought: no matter the outcome, this should be a short term victory for either party. In the very near future, we would like to once again enforce that we think a multiple bridge multisig should be used to give us the best of both worlds.
At the end of the day, taking away our opinions regarding the jurisdiction of this vote, if we were forced to choose on this proposal, our team is genuinely split right down the center with our decision. In short, we believe Wormhole’s council of 19 at face value is more appealing to us, however, custom solutions that L0 have promised @Kydo bring them back up to pretty much par in our eyes if not slightly the edge, given proper execution, which is a whole another story.
Ultimately, this has definitely been a pretty “stressful” day as we’ve been trying to digest information in real time (while trying to grind for the Starknet Hackathon lol). Truly, to everyone who reached out to us, thanks for your time and please understand that this “fence-sitting” by us is not one of inactivity and irresponsibility, but one of careful thought, debate, ultimate stalemate. We’d also like to note that as an organization, we’ll look to continuously improve our internal governance decisions and poise ourselves to better tackle similar situations like this in the future.
Finally, we’d once again like to thank the UF team for their constant communication these past few weeks, the BD teams of both LayerZero and Wormhole who we’re sure have both lost many hours of sleep, and other participants who have either reached out to us or been very responsive with help (@GFXlabs, @Kydo & other schools, VCs, and other interested projects and protocols). We truly are impressed with the activity around this and hope to see it stay around.
PS: Seeing that there’s a good chance this vote might come down to a16z’s verbal communication on the forums, but no vote on Snapshot (custody hurdles?), we’re interested in how this situation will be handled, is there a precedent set here yet?
It is now quite clear that the initial concern raised by the community about Celer’s upgradability contract, which we addressed here and plan to deprecation soon, is absolutely not bigger concerns comparing to many of the issues revealed and discussed in the forum.
While we have a lot to say about the ongoing debates in the forum and CT, we refrain from doing so and instead now deliver a multi-bridge Uniswap governance solution that is vendor-lock-in-free for Uniswap community to consider.
For Uniswap community who has not casted votes yet, please vote for Celer to express your support for this kind of multi-bridge solution.
This solution is strictly better than choosing a single bridge in terms of security and availability. In addition, it also retains the strongest bargaining power in the hands of Uniswap community to always receive the best services. See this for more context.
The implementation combines both Celer and Wormhole and is open-sourced here
All other bridges/cross-chain solutions such as LayerZero can be added easily via adapters.
We are setting up a testnet transaction to demonstrate this end-to-end. @Wormhole team we hope that you can help to set up a relayer for this because otherwise the only easy way would be deploying on Avalanche and BSC testnet where Wormhole generic relayers are available to our knowledge. Feel free to DM!
Now let’s get to the solution specification.
This is a solution for cross-chain message passing without vendor lock-in and with enhanced security beyond any single bridge. A message with multiple copies are sent through different bridges to the destination chains, and will only be executed at the destination chain when the same message has been delivered by a quorum of different bridges.
The current solution are designed for messages being sent from one source chain to multiple destination chains. It also requires that there is only one permitted sender on the source chain. This would be the use case for Uniswap governance contract on Ethereum
calling remote functions of contracts on other EVM chains.
To send a message to execute a remote call on the destintion chain, sender on the source chain should call
MultiBridgeSender, which invokes
sendMessage() of every bridge sender apdater to send messages via different message bridges.
┌─────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ Source chain │ │ │ │ ┌─────────────────┐ ┌───────────────────┐ │ │ ┌──►│ Bridge1 Adapter ├──►│ Bridge1 Contracts │ │ │ │ └─────────────────┘ └───────────────────┘ │ │ │ │ │ ┌────────┐remoteCall()┌───────────────────┐sendMessage()│ ┌─────────────────┐ ┌───────────────────┐ │ │ │ Caller ├───────────►│ MultiBridgeSender ├─────────────┼──►│ Bridge2 Adapter ├──►│ Bridge2 Contracts │ │ │ └────────┘ └───────────────────┘ │ └─────────────────┘ └───────────────────┘ │ │ │ │ │ │ ┌─────────────────┐ ┌───────────────────┐ │ │ └──►│ Bridge3 Adapter ├──►│ Bridge3 Contracts │ │ │ └─────────────────┘ └───────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────┘
On the destination chain, MultiBridgeReceiver receives messages from every bridge receiver adapter. Each receiver adapter gets encoded message data from its bridge contracts, and then decode the message and call
MultiBridgeReceiver maintains a map from bridge adapter address to its power. Only adapter with non-zero power has access to
receiveMessage() function. If the accumulated power of a message has reached the a threshold, which means enough number of different bridges have delivered a same message, the message will be executed by the
The message execution will invoke a function call according to the message content, which will either call functions of other contracts, or call the param adjustment functions of the
MultiBridgeReceiver itself. Note that the only legit message sender is the trusted dApp contract on the source chain, which means only that single dApp contract has the ability to execute functions calls through the
MultiBridgeReceiver contracts on different other chains.
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ Destination chain │ │ │ │ ┌───────────────────┐ ┌─────────────────┐ │ │ │ Bridge1 Contracts ├──►│ Bridge1 Adapter ├──┐ │ │ └───────────────────┘ └─────────────────┘ │ │ │ │ │ │ ┌───────────────────┐ ┌─────────────────┐ │receiveMessage()┌─────────────────────┐ call() ┌──────────┐ │ │ │ Bridge1 Contracts ├──►│ Bridge2 Adapter ├──┼───────────────►│ MultiBridgeReceiver ├────────►│ Receiver │ │ │ └───────────────────┘ └─────────────────┘ │ └─────────────────────┘ └──────────┘ │ │ │ │ │ ┌───────────────────┐ ┌─────────────────┐ │ │ │ │ Bridge2 Contracts ├──►│ Bridge3 Adapter ├──┘ │ │ └───────────────────┘ └─────────────────┘ │ │ │ └────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Below are steps to add a new bridge (e.g. Bridge4) by the dApp community.
- Bridge4 provider should implement and deploy Bridge4 adapters on source chain and all destination chains. The adapter contracts should meet the following requirements.
- On the source chain, the sender adapter should only accept
- On the destination chain, the receiver adapter should only accept messages sent from the Bridge4 sender adapter on the source chain, and then call
MultiBridgeReceiverfor each valid message.
- Renounce any ownership or special roles of the adapter contracts after inital parameter setup.
- On the source chain, the sender adapter should only accept
- Bridge4 provider deploy and open source the adapter contracts. dApp community should review the code and check if the requirements above are met.
- dApp contract (
Caller) on the source chain adds the new Bridge4 sender adapter to
MultiBridgeSenderon the source chain by calling the
- dApp contract (
Caller) on the source chain adds the new Bridge4 receiver adapter to
MultiBridgeReceiveron the destination chain by calling the
MultiBridgeSender, with arguments to call
MultiBridgeReceiveron the destination chain.
Updating quorum threshold is similar to configure a new bridge receiver adapter on destination chain. It requires a
remoteCall() from the source chain
Caller with calldata calling
updateQuorumThreshold() of the
MultiBridgeReceiver on the destination chain.
Use case: contract A on Goerli send message to contract B on BSC Testnet in order to call
enableFeeAmount() for state change. Apply a 2-of-3 messages governance model with message bridge C, D and E.
MultiBridgeSenderon Goerli, set address of A as allowed caller.
MultiBridgeReceiveron BSC Testnet.
- Each message bridge provider prepare their own
ReceiverAdapter, named with a prefix of their bridge name. Take preparation of
CReceiverAdapteras an example.
CSenderAdapteron Goerli, set address of
CReceiverAdapteron BSC Testnet, set address of
- Call updateReceiverAdapter() of
CSenderAdapter, set address of
CReceiverAdapteron BSC Testnet(chain id 97) as a valid ReceiverAdapter.
- Call updateSenderAdapter() of
CReceiverAdapter, set address of
CSenderAdapteron Goerli(chain id 5) as a valid SenderAdapter.
- Transfer ownership of
- Once all message bridges are ready, somehow let contract A call addSenderAdapters() of
MultiBridgeSenderwith an address array of
MultiBridgeReceiver, with an address array of
EReceiverAdapter, and power threshold 2.
Prepare a calldata for contract B for calling
enableFeeAmount(), then somehow let contract A call
_dstChainId = 97,
_target = <address of contract B> and
_callData = <calldata you prepared>.
Imagine that the messages sent via C, D and E received by
MultiBridgeReceiver on BSC Testnet in an order of
1.C 2.D 3.E. During receiving message sent via D, accumulated power reaches power threshold 2, which result in message execution(the calldata will be sent to contract B).
We are more than happy to answer any questions, help with tests, collaborate with similar-minded builders like @AlexSmirnov, iterate based on feedbacks and provide audits from community selected firms.
Although Celer, being a 2018-vintage project, does not have the backing of large UNI-holding investors at this moment, we do trust the integrity and intelligence of all the Uniswap delegates to choose this positive-sum path that ensures the highest level of security and service quality for Uniswap’s multi-blockchain expansion.
We will update this post with testnet transactions once we worked through the small integration work using @Wormhole .
Posting here that I fall into camp that Leighton and Jesse do above.
I abstained from the vote, as I think the process here was unclear and not a comprehensive look at solutions. I also think that singular bridge choices are worse for the ecosystem. Agree with Jesse that competition and choice are best for everyone.
Based on everything above I’d probably lean Layer Zero, but my perspective on the process here is more important to me.
A testnet deployment is done.
- Source Chain: Avalanche Fuji testnet
- Destination Chain: BSC testnet
The reason we did not use Ethereum Goeril is that there is no available generic relayer from @Wormhole on Goeril and Wormhole team has not responded to us in assisting things.
- Cross-chain solutions used: Celer, Wormhole
- Contract addresses:
– MultiBridgeSender Fuji 0x5a5F095183241f4B23a7Aa7f8949fd02D06CaeCf
– CelerSenderAdapter fuji 0x243b40e96c6bF21511E53d85c86F6Ec982f9a879
– WormholeSenderAdapter fuji
– MultiBridgeReceiver bsctest 0x207fF5290Bb518D963CF0a62B371B5B2dB6943A2
– CelerReceiverAdapter bsctest 0x37D2F4DCb5986ce2639bd66B022dcb9e3879156c
– WormholeReceiverAdapter bsctest
– UniswapV3Factory bsctest
- Source chain transaction: Avalanche Transaction Hash (Txhash) Details | SnowTrace
- Destination Chain tx1: message from wormhole:
Binance Transaction Hash (Txhash) Details | BscScan
- Destination Chain tx2: message from celer and execute the governance call:
Binance Transaction Hash (Txhash) Details | BscScan
Happy to answer any questions!
On Monday, I posted a few thoughts which amounted to my decision to abstain from a voting on which bridge Uniswap should use in its deployment of v3 to BNB.
I want to take the opportunity to expand and point to areas for development where I’m excited to see progress. I also wanted to more explicitly commend Devin and UF for their work in stewarding the process here and on other issues, which in sum, has resulted in a lot more momentum in community governance.
Process-wise, the Uniswap Foundation holding a temperature check on which bridge to use in the BSC deployment served both to generally highlight the issue of bridge selection in cross-chain deployment, and advance the decision in this particular instance. Action begets action, and continued forward movement is critical in decentralized governance.
The discussion around the merits of each bridge being considered here was absolutely better than leaving that discussion unconsidered at all. Was it comprehensive? No. That is why I abstained from voting. Was it forward progress? Yes, and I am glad to see that.
Even more importantly this Snapshot highlighted the need for more bridging research - both on existing solutions for future deployments, and so that a single bridge selection doesn’t need to be bundled to new deployments going forward (for example, as Martin proposes here.) That this came up as a result of this Snapshot is a win in my eyes.
Coming on the back of this Snapshot, the focus moving forward is on improving the cross-chain deployment process from first principles. Encourage folks to follow and contribute to the new Cross-Chain Bridge Assessment discussion as a first step there.
There’s already good discussion emerging around multi-bridge deployment designs, as well as the merits of individual bridges. My view stands that the best outcome is for new chain dapp deployments to be bridge agnostic, and to embrace modular standards that foster more competition. Im looking forward to more forthcoming research / commentary on this topic.
Disclaimer: Variant is an investor in the UNI tokens. Disclosures – Variant
Hi all. Following the community discussion on this proposal over the past week, the UF is posting here to answer some open questions and draw attention to next steps.
Next Steps on the BNB Proposal
- The final Governance vote will move forward with the results of the most recent Snapshot Poll. In other words, no votes voiced outside of the Snapshot poll will be counted in the results. The proposal to deploy Uniswap v3 on BNB Chain will go forward to the final governance vote with Wormhole as the selected bridge.
- Delegates, as always, will have the opportunity to vote for or against the proposal in this final vote, based on their view of which choice is best for Uniswap.
Timeframe and Context on Bridge Selection Temperature Check
- Dec. 11, 2022: The Request for Comment (RFC) to deploy Uniswap v3 on BNB was posted in the Uniswap governance forum. This proposal initially contemplated HyperLoop as the bridge. After initial community discussions, DeBridge and Celer were considered as new options. Ultimately 0xPlasma, the proposer, decided to use Celer as the bridge for its proposal.
- Jan. 16 to Jan. 21: Temperature Check to deploy Uniswap v3 to BNB Chain using Celer as the bridge goes live. It passes with 20M UNI votes in support. At this point, the proposal could have moved forward to the final Governance vote.
- Jan. 20: GFX Labs summarizes its diligence on Celer in a forum post. Celer responds to GFX, and other delegate questions, on Jan. 23 (here) and Jan. 24 (here). This discussion focused on the security setup of Celer. [Note that the Assessment process will diligence Celer, and provide an independent review of its security setup for the community’s benefit]
- Jan. 24: Wormhole posts in the forum.
- Jan. 25: LayerZero posts in the forum.
- Jan. 26: UF proposes an additional Temperature check take place to vote on a bridge for the BNB deployment. This proposal was made in order to 1) allow the BNB proposal to move forward in a timely manner, as the community had expressed its support for a BNB deployment in the initial Temp Check, and 2) to allow for a community review of relevant information on Celer, and to consider other bridge providers discussed in the forum: Wormhole, LayerZero, and deBridge.
- Jan. 27 to Jan. 31: A new Temperature Check is posted on bridge selection.
Cross-Chain Bridge Assessment Process
- As the BNB proposal governance process progressed, we also saw the clear opportunity to create a better process for future cross-chain deployment proposals.
- We have proposed the creation of an Assessment Group for bridges here. Community members will have until at least Friday February 17th to review and provide feedback on the process.
- Applicants to join this team can express their interest in the forum by posting the following: a. Name and affiliation, b. Qualifications as they relate to the criteria stated above, stated briefly, c. Explanation of why you are interested in becoming a member of this team. The exact process by which applicants become team members will be confirmed after community feedback is incorporated over the next 2.5 weeks. In the interim we are excited to hear from interested parties.
- Bridges that wish to be assessed may also post their responses to the questions listed in the forum until at least that date.
Clarity on deploying cross-chain with no bridge, and changing the bridge used for a chain
- Upon deployment to X chain, the “owner” of the Uniswap v3 factory contract on that chain is set to a bridge contract which receives and relays messages from the Ethereum L1 timelock contract.
- It is technically possible to deploy Uniswap v3 without a bridge on X chain. However, an implication of that decision is that no future information can be communicated to that deployment by Uniswap governance. Uniswap governance would not be able to turn on the fee switch on X chain or “add” a bridge later on. No fee tiers could be added, unless the deployment includes an affordance for anyone to be able to add any fee tier.
- If a deployment of Uniswap v3 to X chain is made with bridge A chosen, it is possible for Uniswap to later update the bridge to bridge B. This decision would go through the governance process. The final governance vote calldata would be sent from the Ethereum L1 timelock to the X chain deployment through bridge A, and would communicate a change of the Uniswap v3 factory owner from bridge contract A to bridge contract B.
- This proposal has received more attention than any Uniswap proposal in recent memory. It has drawn widespread attention to the role that bridges play in governance, and begun to inform a larger audience about the tradeoffs in and intricacies of bridge design. Delegates had the opportunity to speak directly to bridge teams to learn from them and ask questions.
- The discussion also highlighted the urgent need for a better process to be implemented for bridge selection. We mentioned this above, and are excited to receive your feedback and move this forward.
- It also highlighted the need for more extensive research into bridges for governance, and into bridge-agnostic solutions for protocols. The Uniswap and broader crypto community mobilized themselves to do considerable work in this area in a short period of time. Kydo proposed a Multi Message Aggregation method. Celer designed, deployed, and has already conducted tests for a multi-bridge implementation for Uniswap governance. Martin Koppelmann (Co-founder and CEO of Gnosis) proposed a general bridge framework that may operate independent of, and provide more security than, any single team or approach. This work would not have materialized over such a short time frame without the fervent community discussion here. These solutions, and more, will be processed and assessed by the Bridge Assessment team for future usage by Uniswap governance.
- Uniswap is one of the largest DeFi communities on Ethereum to pursue cross-chain deployments, and is having these difficult but important conversations in public. We hope our learnings, and the new process we create from here, will contribute to the creation of more seamless, standard processes and technological solutions that other protocols can benefit from as they consider deploying across other chains.
- While the focus on and fervor of the discussion was not anticipated by many in the community, including the UF, we believe the developments above are a net positive for Uniswap, and the space as a whole.
We’re happy to lead this off and vote to deploy Uniswap on BNB Chain. Thanks to everyone who contributed to the process for the hard work to get this over the line.
Update with rationalehere.
a16z voted against Proposal 31. We voted this direction for two reasons:
As many others have commented on, the selection of a bridge provider for cross-chain governance messaging should be a comprehensive, structured process that allows for equal comparative analysis between each option. While that didn’t fully occur for this vote, @devinwalsh’s new cross-chain bridge assessment process can help to solve this moving forward. Given the number of possible upcoming bridge deployments, we agree that it’s important to have an independent third party weigh in with their relevant experience and expertise. Consequently, our vote against this proposal is to reset the Binance Uniswap v3 deployment process until the formal assessment is completed.
Second, we do not believe Wormhole offers the most secure or decentralized bridging option. The Wormhole bridge suffered a $326M exploit last year. The bridge then had another critical vulnerability that put all $1.8B TVL at risk. Wormhole has since reduced their maximum bug bounty from $10M to $2.5M. Additionally, the Uniswap DAO will not have the ability to run and control the bridge independently if Wormhole is selected as the provider. We believe this is an equally important factor to consider.
As Uniswap token holders, we are ultimately interested in the long-term success of the Uniswap protocol. We hope to see the Binance deployment process restarted so that all bridge providers can participate in a formal assessment process. We will evaluate all bridge providers in good faith and subsequently vote in the best interest of the Uniswap protocol’s future growth and success.
GFX Labs voted for proposal 31 to deploy Uniswap v3 on BSC. Setting aside the bridge provider discussion after the completion of the Snapshot vote, we would like to elaborate upon our reasoning for voting to deploy on BSC, which some view to be controversial.
Revisiting our post from December, it is evident that Pancake Swap has significant trading volume and utilization. For those who are not familiar, PancakeSwap is a direct Uniswap v2 fork. If Uniswap v3 were to be deployed to BSC, we could significantly reduce PancakeSwap’s position in the DEX market and reduce the incentive for PancakeSwap to fork Uniswap v3 when the BSL expires in April.
The best example of Uniswap v3 competing with a Uniswap v2 fork is Polygon’s QuickSwap. Before Uniswap v3’s deployment on Polygon, QuickSwap had the majority of Polygon DEX market share. Within two months of Uniswap v3’s deployment, it took over most of Polygon DEX’s market share.
Planning beyond proposal 31, we believe Uniswap should be deployed on other popular and up-and-coming EVM chains to reduce the incentive for forks to be launched post-BSL.
There are currently five deployments of Uniswap v3 and one pending deployment (zkSync). In addition to BSC, we expect at least 2-5 more deployments before April 1st, approximately ten deployments by the end of April, and 20-30 by year-end. The question we should be working to solve now is what should Uniswap be doing to make certain it maintains its market share domiance post-BSL?