Uniswap Crosschain Governance: Bridge Findings & Recommendation
Authors
Laura Lotti & Toby Shorin, Other Internet
In our May RFC post, we discussed the need for cross-chain governance as a strategic priority for Uniswap’s expansion to become the premier DEX choice on every chain. We indicated our intention to select a technology and team to work with on building out Uniswap’s cross-chain governance tech, and described a set of criteria against which we would be evaluating vendors.
In this post, we’ll recap our process and discuss Uniswap governance security considerations before delving into our evaluation of teams and describe next steps for moving the cross-chain governance project forward.
Our findings can be summarized as follows:
- Optimistic rollup-like solutions provide the most promising tradeoffs for the use case of cross-chain governance.
- The two bridges that adopt this model, Celer and Nomad, have comparable security models.
- Our final recommendation is to not adopt a universal bridge solution at this stage. Instead, we propose that other chains who wish to deploy Uniswap use only optimistic systems.
Process
First, a note about our process. Before beginning this work, we took stock of different models for vendor procurement and evaluation.
First, we’ve personally seen that governance communities of protocols can be overwhelmed by third parties posting “proposals” that are really service arrangements. The “proposals” to create Uniswap and Gitcoin branded stablecoins by the Ichi team are straightforward examples. Because they are framed as governance initiatives to the “community,” they seem to come with a certain necessity of serious evaluation, even if they are totally unaligned with strategic priorities. This tendency in DAO governance indicates a need for more strategic direction setting and initiatives on behalf of the protocol by more informed advocates.
Secondly, we looked at public vendor evaluation processes pursued by some protocols and were left unimpressed. Two relevant case studies were Compound governance’s selection of an ongoing audit firm, and Osmosis’s selection of a bridge partner. In the case of Compound, a firm was solicited and even went to an initial vote before other audit firms had the opportunity to post their proposals. The vote had to be delayed, and unpleasant accusations were made between firms in the forums. Additionally, the fully open nature of the process led to the competing audit firms price matching the original proposal. While Compound governance generally has more engaged technical and strategic leadership than Uniswap’s, we again viewed this messy process as evidence for more direct solicitation and overt leadership.
In the case of Osmosis, the Osmosis Labs team conducted an initial review of different vendors in private, then published a ranked list of the team’s top choices, before moving to a ranked-choice governance vote. The team also conducted a live video interview with different bridge teams. While we believe the expert-led process is an improvement over Compound, the addition of the ranked-choice vote led to accusations of “governance theater” and a sense among the competing vendors that the process was rigged.
With this in mind, we wanted to be clear about our process up front. It would be expert-led, conducted by a party with the ability to negotiate and legally contract with the bridge team, and would result in a single recommendation for the community’s consideration. This is a new experiment in procurement process for Uniswap governance.
What Happened Next
We made an initial post on the forum soliciting direct outreach from bridge providers. We received interest from Axelar and already had a contact with Nomad, and we were referred to Abacus.
After initial conversations with these teams, we prepared a brief ( UUGM Partner Brief) which we sent to Axelar and Nomad. This brief outlined our expectations for the partner’s commitment — essentially what would be in a legal agreement and scope of work. We asked the Nomad and Axelar teams to prepare proposals based on this brief. The two teams returned proposals.
In the meantime, we consulted with several independent technical leaders and Uniswap delegates in the space to get outsider opinions. In no particular order, we spoke with Medhi Kothari (Variant research team), Rafael Solari (CTO Tally), arr00 (engineer at Compound, designer of Governor Bravo), Noah Zinsmeister (engineering lead at Uniswap Labs), and Leighton Cusack (CEO of PoolTogether). Following this, we started to compile and prepare our recommendation.
As we were preparing our post, we also began to discuss our findings with delegates. Some of these conversations led to other bridges posting proposals on the public forum—namely, Wormhole, Celer, and LayerZero. While this was not our original intent, we decided to look more deeply into these models, and pushed out our recommendation post until we conducted a more thorough evaluation. We engaged Sam Hart and Rick Dudley as technical advisors to assist with this second run. Bridge security is the main issue of importance, so for the sake of thoroughness, we decided we should push through with evaluating players who were previously not in the consideration set.
In the next section we describe Uniswap-specific security considerations, then provide a security overview of the bridges. Ultimately we provide our recommendation and takeaways from the process.
Uniswap governance security considerations
Governable parameters are owned by contracts which will accept governance commands through the bridge messaging channels. Therefore we must understand which risks are specific to Uniswap governance, and how the use of a bridge would change the risk profile associated with these various parameters. In general, Uniswap has very few on-chain parameters.
It is important to remember here that bridging tokens is entirely out of scope for this project; we are only discussing cross-chain message passing.
-
Treasury disbursement attacks. In the specific case of Uniswap governance, a bridge would be an intermediary attack surface if funds were custodied on a different chain than the treasury on Ethereum L1. Today this is not the case. However, with recent fee switch discussions, it is possible that in the future fees on other networks or chains could be activated. This would introduce an attack vector of messages disbursing accrued fees to an attacker, or attacks maliciously attempting to bridge the tokens off the chain. This is especially a risk in the case of bridges that allow passed messages to be updated by external validators or multisig signers. We would advocate against activating protocol fees on other networks until this scenario is given a more comprehensive evaluation.
-
Fee based attacks. The owner of the Uniswap V3 factory contract on L1 is the governance timelock; on L2, it is a contract controlled by the L1 timelock via a bridge. One possible form of governance attack is an invalid message sent to the bridge set this L2 fee switch while setting the address to another owner. This is one of the only clear attack surfaces native to Uniswap’s current governance parameters.
-
Griefing or DOS attacks. Denial of service attacks are possible on validator bridges (requiring 1/3 validators to halt the chain) and optimistic bridges (a malicious agent submits a fraudulent message, disabling the bridge). Given the time-insensitive nature of most governance votes, we do not consider this a significant risk. In optimistic systems, liveness of the fraud proof detection agents is another consideration; we discuss this more later.
Additionally, optimistic interoperability arguably introduces one more attack vector:
-
Latency-based arbitrage opportunities. The the 30 minute “challenge period” or “quarantine” used by Nomad and Celer introduces an opportunity for trades based on governance-related information before execution. However, most information related to governance votes will be available for weeks leading up to the on-chain vote and therefore already reflected in the market state. This is a low risk.
Projects review
We initially talked to 3 teams: Abacus, Axelar and Nomad. Given the early stages of development of the first (discussed below), we focused our evaluation on Nomad and Axelar. After a couple introductory calls, we provided both of these teams with a brief and requested that each team respond with a proposal and scope of work, including timeline for the scoped work and budget.
Both teams responded with details on their proposed implementations, which we include below (please find here Axelar‘s and Nomad‘s original submissions). Other teams’ submissions can be found on the thread above. We review all bridge models below.
Axelar
Axelar Network is a validator-run bridge based on the Cosmos SDK and enjoys similar PoS liveness and security guarantees (67% corruption threshold). The bridge is maintained by a network of validators incentivized by the AXL token. As part of consensus, validators run light-client software of other blockchains, allowing them to verify their state. The validators collectively maintain threshold signature accounts on other blockchains, which allows them to lock and unlock assets and state across chains and to post state on other blockchains. This way Axelar acts as “a “decentralized crosschain read/write oracle”, as per their white paper.
Among the externally verified bridges we talked to, Axelar is is the most resilient one with the largest validator set (currently 45, and aiming for 100). While it offers much higher security guarantees than other validator bridges, it still relies on a honest majority to correctly verify updates (in this case 2/3).
Axelar already connects several chains including Ethereum, Cosmos, Avalanche and more, and it’s recently been selected as canonical bridge by Osmosis. The project is co-founded by Sergey Gorbunov and Georgios Vlachos who have an impressive academic background in cryptography and were founding team members at Algorand. The project has been audited by Ackeeblockchain, Cure53, NCC, Oak Security, and Commonprefix Labs.
On the other hand, Axelar primarily facilitates cross-chain token transfers and they do not have a cross-chain governance application in active development. For the realization of a cross-chain governance technology for Uniswap and updating current deployments, they budgeted $250k excluding smart contract audits and cross-chain front end application, that they would scope separately.
Nomad
Nomad leverages optimistic verification, a novel interoperability model developed by engineers on the Nomad core team while at cLabs. Contrary to externally verified bridges, Nomad’s optimistic verification only requires “1 of n” honest parties (Watchers) in the system to submit a fraud proof during a 30 minute window.
One of the key features of optimistic verification discussed in depth below is its revocation-centric approach. Nomad splits responsibilities between two classes of agents, Updaters that can verify cross-chain messages, and Watchers that can revoke permission to said messages (that is, they can block messages but cannot themselves permit messages to be sent cross-chain). This means that even if all Watcher keys in Nomad are compromised and collude with the Updater, as long as the honest Watcher has a backup key, they may always prevent fraud in Nomad.
Nomad is currently free to use, beyond Ethereum transaction fees, and is the main operator of its Watcher set, but they are in the process of expanding their Watcher network to reputable partners such as Circles and Moonbeam Foundation, and are considering incentives for operators of Watcher agents in the future. Each application that is deployed using Nomad has the choice of utilizing an existing Watcher set or configuring their own Watcher set. An application will always have the option of migrating to its own Watcher set at any point in the future. The contracts have been audited by Quantstamp.
Nomad has partnered with Moonbeam, Gnosis Guild (Nomad Zodiac module), and with Tally and DAOhaus for frontend integrations, which would facilitate cross-chain proposal creation frontend development for Uniswap. Additionally, two Uniswap deployments already use Nomad (Moonbeam and Gnosis Chain). Nomad’s team has also been deeply involved in the development of EIP-5164, which ensures that any future upgrades to UUGM will be done in accordance to the cross-chain governance standards developed for Ethereum.
As we were preparing this post in early August, the Nomad bridge was exploited and drained of funds. The issue was due to a smart contract error in the Replica contract that allowed multiple attackers to send invalid transactions as valid across chains hitting the liquidity of several exchanges, primarily Moonbeam, EVMOS and Milkomeda. Important to note that the optimistic model here didn’t fail, it was a transaction verification that failed; an issue that was already pointed out as “low risk” by the Quantstamp audit and wasn’t addressed by the team. Since then the team put out an open call to the hackers to return the funds. We are waiting on a more substantial response by the team on how they intend to address the loss.
Wormhole
Wormhole is a multisig bridge with 19 guardians (signers). Guardians include some of the largest staking and validation companies, including Chorus, FTX, and P2P Validator. Wormhole has an optional per-message fee, currently set to 0 on most chains.
While multisig oracle bridges are the most widely used trust model for message passing and token bridging, they have the weakest security assumptions. The Horizon bridge (9 multisig) was compromised earlier this year, while the Ronin validator bridge was exploited in a similar way. Wormhole’s significant hack this year was not a compromise of the guardian private keys, but an exploit of its core Solana contract (read more about this here). Jump Trading, the main investor and contributor to Wormhole, covered the over $300mm loss; however the fact that the project relies on a single entity for its source of funding raises concerns over its long term commitment to decentralization.
An issue with multisig bridges in general is that validators may modify messages in the queue. While a 2/3 compromise of validators is unlikely, modification of messages is a primary risk for cross-chain governance.
Wormhole will soon launch a Cosmos appchain, which will act as the governance chain for Wormhole and as an additional security measure. This “accounting chain” aims to provide a check on smart contract balances when calls to move assets have been made. This is an interesting development for token bridging, but is not relevant to the governance message passing use case.
Wormhole stresses its large team, its internal penetration testing unit, and its security credentials in. Wormhole also touts its significant bug bounty program of $10mm. While we are impressed with the team’s professionalism, we feel as if Jump itself is the ultimate point of failure for Wormhole, beyond the security model itself. Wormhole has been audited by firms Neodyme and Kudelski, with more reputable Trail of Bits and Certik to release their own audits in 2022.
Layer Zero
The architecture of Layer Zero’s trust model is a separation between relayers and oracles. Oracles transmit messages from the origin chain to the destination chain, and relayers submit a proof that the message is a valid message emitted by the origin. The oracle and relayer must be separate entities; this separation of roles means that collusion between parties would be required for a message to be altered. As there are no guarantees against collusion between oracle and relayer parties, the decentralization and trust model of the relayer and oracles themselves become paramount.
Users of L0 have the ability to specify their own oracles and relayers. In other words, L0 is not properly bridge technology; it is a message passing system with an agnostic transport and security layer beneath—essentially, an infrastructure for bridges to be built on top. However, L0 does have a default configuration: the Oracle service is provided by a TSS of FTX, Polygon, and Sequoia, and L0 runs a proprietary relayer. This gives Uniswap two options for utilizing Layer Zero: use the default configuration, or build out its own network of oracles and relayers.
Given the current state of Uniswap governance, it’s unrealistic for Uniswap to be rolling its own bridge on L0. This leaves us with the default config. While the 3 default oracles are reputable organizations, L0 hasn’t published any information on the security models of those oracles. Likewise, L0 is rather light on information about the specific security model of its own relayers. One published document details a “PreCrime” function for relayers to check against specific end-user defined invalid states.
Provided that L0’s own relayer is secure, Layer Zero inherits the security of the oracles, about which not much is known. Insufficient security information on the default configuration makes Layer Zero an unsure bet for Uniswap governance.
Celer
The basis of the Celer’s cross-chain messaging solution is the “State Guardian Network.” Similar to Axelar or other validator bridges, this is a Tendermint delegated POS chain. 21 State Guardians, the validator nodes, stake $CELR to operate. When a cross-chain message is sent to a message bus, validators generate stake-weighted attestations to the message’s valid existence on the origin chain. The SGN charges a message passing fee, prorated by message length.
Celer provides an additional security model which can be selectively enabled for higher-risk, higher value messages. This is a fraud proof model based on the design of optimistic rollups, similar to Nomad’s design. The fraud proof “App Guardian” agents are intended to be run by end application developers; but they are also part of the validator State Guardian software package, meaning any of the 21 validators may be engaged as an app guardian. Presumably, Uniswap governance would be using the optimistic model exclusively.
As the fraud proof network is a different security model, there is not a need to separate the agents, as in the Layer Zero design. Finally, while end users can specify which transactions use the fraud proof network instead of the validator bridge, the Celer team’s care for operational security is evident in their addition of guarantees that asset transfers in the 90th percentile in size automatically are sent to the fraud proof network. Celer’s contracts are non-upgradeable, but certain parameters such as the fraud proof submission window may be specified by end users. The State Guardian Network system has been audited by Certik, SlowMist, and PeckShield. It’s unclear whether the fraud proof network has been audited.
Abacus
Abacus is another recently-launched POS bridge with a team of senior blockchain architects. The basic security model is similar to other validator bridges, but offers additional security guarantees by allowing applications to specify their own set of additional validators.
Abacus is still a very new project, having only deployed to mainnet in the last few months and still unaudited. Additionally it currently runs only a proof of authority (POA) network, and is planning to migrate to POS later this year.
A number of the largest bridge exploits in the last year have been of more centralized bridges, which gives us pause about a POA system in the short term. In addition to the relatively untested nature of the protocol the obvious size of commitment that would be required from the early-stage Abacus team to build technology for Uniswap, we were dissuaded from pursuing further talks with Abacus, but we look forward to seeing their POS network come online.
Evaluation
Following our evaluation and review of the competitive bridge providers, we came to the opinion that Uniswap should enforce strong criteria when choosing a base security model. While a message passing bears less risks than fund transfers, we think it’s paramount to choose the security model that is most protective for the governance use case. For cross-chain governance safety is crucial; on the other hand liveness issues can be tolerated to an extent (i.e. slow messages) because of the long timeframes of governance decisions.
In particular:
-
Safety over liveness. Slow messages can be tolerated by governance, but the possibility of message manipulation by relayers should not.
-
Cost and efficiency. Securing the bridge should not require an unrealistic level of technical buildout the Uniswap community.
Criterion 1 eliminates multisig and validator-based solutions from the consideration set; criterion 2 indicates we should not consider light client relays, which are complex and not yet available for all chains. In light of the security tradeoffs that these models make, we think optimistic interoperability is the most promising option for Uniswap.
The optimistic model relies on a new set of agents that are in charge of detecting invalid messages. Any one actor submitting a fraud proof shuts down the channel, superseding the “honest majority” assumption of multisig and validator bridges with a “1-of-N honest parties.” Compared to native verification, where each chain runs a light client of the other chain, optimistic verification also has the advantage of being extensible and reusable across chains at lower costs.
In the following segment we give a deeper look at Nomad and Celer, the two organizations that enable optimistic bridging today.
Optimistic Bridging Deep Dive
In this section, we’ll explain Nomad and Celer’s optimistic rollup-inspired security models in more depth. In plain language, the basis of this model is fraud proof submission. Instead of “pessimistically” assuming that each message needs to be verified at the origin, messages are “optimistically” signed on the origin chain, and a dispute window is enforced at the destination, where some agents and veto any fraudulent message.
Nomad Message Flow Overview
- A message intended for a cross-chain destination is sent to the Home contract on the origin chain (Ethereum).
- The Updater, an offchain agent, observes these messages and sign attestations to their validity, then publish new merkle roots as an update to the home contract state.
- Relayer agents relay updated state to Replica contracts on destination chains.
- Nomad protocol enforces a 30-minute dispute window in which Watcher agents can submit fraud proofs. If fraud is detected, the channel is shut down.
- If the message is valid, it is executed on the destination chains.
Optimistic systems have a parsimonious definition of “fraud.” In the case of Nomad, “fraud” deals exclusively with the Updater. The Updater may A) have signed two conflicting messages, or B) having signed a message which did not exist in the queue of roots awaiting publication.
Celer Message Flow Overview
- A governance proposer constructs a message for a new contract, the Uniswap dApp Plugin contract. The message is sent to the messaging bus and then to the State Guardian Network chain.
- SGN validators reach consensus and create an attestation as to the message’s valid existence.
- A 30 minute dispute period is enforced, during which App Guardian agents check the message against events submitted to the message bus on the origin chain. If fraud is detected, the channel is shut down.
- If the message is valid, it is relayed by the Executor to the destination chain and submitted.
Who Runs Agents?
Nomad
Nomad currently operates the Updater agent. In addition, Nomad maintains a set of Watchers, similar to Optimism’s centralized sequencer. Nomad is currently decentralizing the Watcher set to other reputable parties, such as Circle, the issuer of USDC, and the Moonbeam Foundation. These additional Watchers were estimated to begin operations during the summer; this timeline has been pushed out because of the exploit.
Decentralization of the Updater agent is a stated goal of Nomad’s. In various interviews and documentation, they have cited the intention to introduce both economic incentives for Updater uptime, and staking & slashing model to punish fraudulent activity. Note QSP-33 in Quantstamp’s audit of Nomad recommends this step be taken as well.
Celer
The State Guardian Network of validators monitor messages sent to the origin chain message bus and reach consensus on that message’s existence, generating a typical stake-weighted multi-signature attestation.
“Executor” agents relay attested messages to the destination chain and have the ability to be “App Guardians.” These are trustless entities that cannot fabricate messages. Celer recommends that these agents are run by app developers / Uniswap community members, but the SGN also runs these agents as part of the software package. Celer claims that the App Guardian logic is isolated from the SGN logic; we haven’t been able to confirm this in a cursory GitHub review, and would appreciate a larger smart contract audit.
One difference between Celer and Nomad’s security systems is whether information about fraud is transmitted back to the origin chain. Nomad sends data back to the origin chain so that fraudulent updater agents can be slashed; with Celer, fraud proofs submitted by App Guardians are not subject to the same slashing-based disincentives for the SGN.
In both the Nomad and Celer case, it would behoove the Uniswap community to run a Watcher or App Guardian agent to increase security, in addition to other parties running watchers. While overall cost is one of our main criteria, engaging a trusted partner to run an agent would be the most effective path forward. Uniswap Grants Program previously provided grants to the crypto development agency Scopelift; they are our top pick for an organization we would engage for the dev ops work involved.
Liveness Issues
Optimistic inspired systems turn liveness into a security property. Nomad has incentives for Updater liveness on the roadmap; for Watchers, the basic incentive is for app developers to run Watchers to secure their own system. Celer has arguably stronger liveness-protecting properties, as App Guardian liveness is provided for by needing to run the underlying validator network.
Recommendation & Next Steps
Optimistic verification is the most suited model for cross-chain governance on Uniswap. The balance of costs (running a fraud detection agent) and security guarantees (no message alteration, trust 1-of-any) are the correct tradeoffs to make for a model.
Before the recent Nomad exploit, we were prepared to publish these findings recommending Nomad. Before and following the hack, we’ve also had several conversations with Celer, and think they are an equally strong option.
The Nomad team has been working explicitly on cross-chain governance longer than any other of the teams we’ve interviewed. Furthermore they are deeply familiar with the Uniswap ecosystem, having proactively conducted their own analysis of the state of Uniswap crosschain governance and published the only complete documentation of xchain governance of the protocol. The level of support was an important criteria in evaluation, and the Nomad team’s work here demonstrates that commitment.
While Nomad does not have as large of a pool of Watchers as Celer does with all validators engaged to run App Guardians, there are some benefits to Nomad’s model. Nomad’s optimistic interoperability is more of a “true” optimistic model in that fraud proofs are submitted back to the origin chain. Incentives for agents are critical, and Celer’s model would be even more robust if fraud detection incurred validator fund slashing. We hear this is on the roadmap.
The Nomad exploit did not invalidate the security model of its bridge design. Like the Wormhole hack earlier this year, it was due to a smart contract error. This doesn’t undermine the robustness of optimistic verification; these trends, however, raise concerns about a general tendency in the space, by which VC-funded protocols pursuing growth and TVL do so at the expense of engineering best practices (with thanks to Rick Dudley for his insights on this point). In conversations with Celer, we have been impressed with the level of operational security measures put in place by the team. To date, Celer has not experienced an exploit.
Next Steps
In light of the Nomad hack, we’ve taken a step back to review the state of this proposal. Several bridges teams have put in considerable work to deliver proposals and inform of us on their security models, and we’ve had a number of highly educational conversations. However, our recommendation at this time is no action on a universal bridge model.
The selection of Nomad by the reputable Gnosis Chain and Moonbeam teams earlier this year indicated to us that migrating all of Uniswap’s cross-chain governance platform to a single partner could be a win for Uniswap. This vendor evaluation effort originally grew out of our desire to vet Nomad against alternative bridges, and as our findings indicate, we are satisfied with Nomad and Celer as equally secure models.
However, with the exploit, the deployment timeline for Moonbeam and Gnosis Chain is unclear. Additionally, we’ve seen a pause in Uniswap deployment activity. Current fee switch experimentation is limited to mainnet, and we assume that by the time the first fee switch experiment ends, we will have further information on how Nomad has handled the security issues.
At this time we do not recommend enshrining a universal bridge partner as outlined in our original RFC. For next steps, we recommend the following:
- Uniswap deployers considering a bridge should use Nomad or Celer. Deployed chains should run a first-party fraud proof agent, as well as leverage the respective bridge’s full network of agents. We strongly discourage the use of multisig and validator based bridges.
- Uniswap Foundation should create a grant bounty for proper proposal flow documentation for each of the existing bridges. (We have already engaged UF on this topic.)
- Uniswap Labs or Foundation should engage the Arbitrum team to help fix the broken Arbitrum deployment.
- Other Internet and Uniswap Foundation will continue to monitor the cross-chain bridging ecosystem for the next 6 months, with particular attention to optimistic bridges. We will monitor adoption of Nomad and Celer by reputable protocols, and consider engaging a third party to do a smart contract-level evaluation.
Bridging UNI is out of scope. We are only concerned with bridging governance related contract calls, and for the purposes of this initiative are not considering bridged UNI tokens. Uniswap’s relatively small set of on-chain parameters means reduced attack surface area, and we prefer to keep it that way.
L2 voting is out of scope. The costs of this approach exceed the benefits; Uniswap’s unequal distribution of voting power means that votes are largely contingent on whales and major delegates, even if we make voting for everyone cheaper.
